- cypherpunks-legacy@lists.ogf.org

Re: Real time OCR
by nobody＠shell.portal.com 12 Aug '93

12 Aug '93

Neural network hardware is currently being trained to recognize the serial numbers on US$. This is being done by a company that has successfully applied its nn hardware to read the numbers off of checks and distinguish between real/fake while obtaining the numbers too.

1 0

Re: Chaos harnessed for encryption / Fluctuations and Or
by collins＠newton.apple.com 12 Aug '93

12 Aug '93

>[...] that can synchronize without publishing their states. >If this could be done with strong PRNGs, you'd have something. Here is a related article Article = "Secret Key Agreement by Public Discussion from Common Information" Author = Ueli M. Maurer Publication = IEEE Transactions on Information Theory, Vol 39, No. 3 Date = May 1993 --Abstract-- The problem of generating a shared secret key S by two parties knowing dependent random variables X and Y, respectively, but not sharing a secret key initially, is considered. An enemy who knows the random variable Z, jointly distributed with X and Y according to some probability distribution Pxyz, can also receive all messages exchanged by the two parties over a public channel. The goal of a protocol is that the enemy obtains at most a negligible amount of information about S. Upper bounds on H(S) as a function of Pxyz are presented. Lower bounds on the rate H(S)/N (as N-->infinity) are derived for the case where X = [X1, ..., Xn], Y = [Y1, ..., Yn], and Z = [Z1, ..., Zn] result from N independent executions of a random experiment generating Xi, Yi and Zi for i=1, ..., N. In particular, it is shown that such secret key agreement is possible for a scenario where all three parties receive the output of a binary symmetric source over independent binary symmetric channels, even when the enemy's channel is superior to the other two channels. The results suggest how to build cryptographic systems that are provably secure against enemies with unlimited computing power under realistic assumptions about the partial independence of the noise on the involved communications channels. --end of Abstract-- Hope you like it, Scott Collins | "Few people realize what tremendous power there | is in one of these things." -- Willy Wonka ......................|................................................ BUSINESS. voice:408.862.0540 fax:974.6094 collins(a)newton.apple.com Apple Computer, Inc. 1 Infinite Loop, MS 301-2C Cupertino, CA 95014 ....................................................................... PERSONAL. voice/fax:408.257.1746 1024/669687 catalyst(a)netcom.com

1 0

Subliminal channels in signature functions may be unavoidable.
by This is _intense_! 12-Aug-1993 1536 12 Aug '93

12 Aug '93

I was considering the subliminal-channel-in-the-digital-signature question in the shower, and came to an interesting handwaving proof of the following statement: All signature systems (public key and otherwise) that allow timestamped messages contain subliminal channels of bandwidth proportional to the timestamp resolution. Fortunately, this mailing list is wide enough to contain the essence of the proof. 1) Hypothesize an arbitrary signature system that simply provides authentication via a randomish-looking bitstream that is a function only of the input document and (possibly) a secret or public key known to the sender and intended recipient, and that an "external monitor" exists who will verify that each message is indeed signed appropriately; 2) The job of the monitor is to censor communications between the sender and recipient; hie does this by examining the contents of the messages and if 1) their visible contents are innoucuous 2) their signatures do verify he passes the message; otherwise he refuses the message back to the sender. 3) Assume the signature-generating algorithm is published, and is a strongly random function of the input stream. 4) Assume any number of messages may be passed. 5) Assume that the sender and intended recipient have previously arranged for an unknown-to-the-censor second signature and bit count. 6) To send a subliminal-channel message, the sender generates an innocuous message, time-stamps it, and signs it, then signs the signature with the "secret second signature". If the [bit-count] low-order bits of the second secret signature match the desired first N bits of the desired subliminal channel message, then the message plus first (authenticating) signature is handed off to the censor to examine and transport. If the bits don't match, the time-stamp of the original message is updated, and the process repeated until the bits _do_ match. The loop of innoucuous-message/first-signature/second-signature/compare is then repeated again until all the bits of the desired subliminal channel message have been sent. Since for any good signature scheme all bits in the output bitstream are strongly random functions of all bits in the input stream, changing one bit (in the timestamp) has a chance of 1 in 2^bitcount bits of giving the desired secret-signature bitset. Proof of the bandwidth of such a scheme is proportional to 1/2 the resolution in bits of the time-stamp is left to the student. (I just _had_ to say that. :-) ). Extension: If the number of messages per unit time allowed by the censor is limited, then the bandwidth becomes MIN ( [1/2 timestamp resolution] , [bitcount * allowed-message-frequency] -Bill

1 0

ANONYMOUS CONTACT SERVICE
by hfinney＠shell.portal.com 12 Aug '93

12 Aug '93

From: Warren Keith Russell <keru(a)cpu.us.dynix.com> > I received a message from System Daemon telling me that I had sent a > message using the anonymous contact service, allocating a code name, and > explaining how I can be reached anonymously. A few months ago, someone subscribed to the list through the Penet service, and it ended up revealing the Penet aliases of everyone who posted. Each post was delivered to that subscriber marked as being from the Penet alias corresponding to the poster. All it took was a parallel non-Penet subscription to break the anonymity provided by Penet. Has this now happened again? At the time, there was some discussion about using "an..." versus "na..." forms of the Penet aliases, one of which would avoid this revelation. Has that been taken care of? Hal Finney hfinney(a)shell.portal.com

2 1

Re: Secure voice software issues
by jthomas＠kolanut.mitre.org 12 Aug '93

12 Aug '93

Phil Karn <karn(a)qualcomm.com> wrote: [Re: squeezing 13.3 kbps data w/o start&stop bits over modem] > Whenever V.42 error correction (LAPM) is enabled, > synchronous HDLC frames are what actually pass over the > link. So the start/stop bits are already removed. > Unfortunately, the packetizing done by LAPM adds delay > we don't want for a real time voice application. And if you > turn off LAPM, you return to sending the start/stop bits > over the wire. Well... How much latency does LAPM really add? Little enough that full duplex keystrokes echo back nearly instantly on my connections. People talk over satellite links with more delay than that all the time. Since we're not going to get toll quality voice out of the vocoders anyway, and the error correcting stuff is especially useful for encrypted data streams... I think V.42 is probably a good idea for a cryptophone project. > Most V.32 and V.32bis modems provide for direct > synchronous operation, which would let us have our cake > and eat it too, except that few PCs can speak > synchronously to a modem. This may require some extra > hardware (sigh). I'm in favor of getting a minimal version that will run on the lowest common denominator hardware first. (Might have something to do with the fact that I just spent a couple hundred dollars on an internal V.32bis modem that doesn't do synchronous :^) Joe

2 1

Cryptographic File System paper available for ftp.
by mab＠vax135.att.com 12 Aug '93

12 Aug '93

Hi, A PostScript pre-print of the final version of my paper "A Cryptographic File System for Unix" is available for anonymous ftp from research.att.com in the file dist/mab/cfs.ps . The paper will be presented at the 1st ACM Conference on Communications and Computing Security, November 3-5, Fairfax, VA. A number of people on this list have seen an early draft; this is the final version. Some of the techniques in the paper may be of general interest to people contemplating file system-level encryption in other systems (e.g., the cryptostacker project). -matt

1 0

Making the World Safe for Steganography
by tcmay＠netcom.com 12 Aug '93

12 Aug '93

How do we make steganography safer to use? An anonymous comentator wrote about my point (in the essay "Libertaria in Cyberspace"), and then Eric Hughes responded: >>Alice better not be carrying any software that could retrieve that >>data. > >Q: What do you call a store that sells 'cryptographic paraphernilia?' > >A: A mind shop. > >If crypto is outlawed, then random numbers will be probable cause for >search for illegal cryptographic devices, software or hardware. > >Q: What is a random number? > >A: Anything I don't understand. With steganographic (data-hiding) schemes, how is the "unhiding" scheme to be stored? If the user has a diskette labelled "Steganography" sitting prominently near his computer, for example, and this diskette has just a single algorithm on it--perhaps for stripping the LSBs out of GIFs--then it is fairly obvious which algorithm is being used, and that steganography is in fact being used in the first place. (However, what comes out of the de-stegging, to coin a phrase, should still be meaningless without the actual decryption, so I'm not sure what the authorities can or will try to do. During wartime, or in many countries, I'm sure that possessing such steganographic software would be a serious matter, but the U.S. has not (yet) reached this point. And there's enough bits to play with on a DAT to make the data bits look almost exactly like audio/microphone noise, with the same statistics, spectrum, etc.) One good way to further confuse the issue is to make certain steganographic schemes *widely available* by wide distribution on CD-ROMs (to ensure that nearly everyone can feign innocense when the Data Patrol asks them some questions) or by easy access by ftp-type approaches (though this has limits which are discussed later). In other words, there is no obvious "smoking gun" pointing to the use of steganography. Or encryption, for that matter, as PGP-like crypto programs could be similary distributed, someday, and only the secret key/passphrase would be "incriminating" to the user. I'll leave it for another time to discuss ways to hide the secret key/passphrase (perhaps in things like Newton PDAs which implement "digital flash paper" in their flash memories, or are carried with the person at all times, etc.). A Cypherpunks CD-ROM? Perhaps the Cypherpunks could someday even make such a CD-ROM widely available, along with rants, source code, whatever. (*Very* speculatively, someday "Wired" may even distribute a CD-ROM in one of their issues.) Remember, the point about steganography schemes, like hiding message bits in the LSBs of music tapes or images, is *not* to make the bits "undetectable," but only to hide them sufficiently to make a case for "plausible deniability." Thus, if the Data Patrol uses "Algorithm A6" (one of many on the CD-ROM) on a DAT you are carrying, and the sequence "1 0 1 1 1 0 1 0 ...." emerges, you just shrug and claim ignorance. "Sounds like noise to me." However, when the Patrol is not around, you apply, say, "Algorithm Z1" to the DAT and then use your private key to decrypt the bits. (How you secure your private key is another issue, of course, as mentioned above.) Some may quibble that this is a kind of low-level encryption...after all, the CD-ROM may contain only a few dozen algorithms for stripping bits out of DATs and images, so the NSA or FBI can simply apply them all, trivially. This method would indeed be low-level (nonexistent, actually) security if the resulting bits were a plaintext message. But the resulting bits are in fact meaningless noise without the private key. I suspect that such wide distribution of steganographic schemes will be enough to ensure that users can safely retrieve "their" bits (using one of the algorithms) without the authorities being able to prove anything. If this analysis is correct, then getting various steganographic schemes out in the public domain is important. Executable code--to allow users to run the programs right off the CD-ROM and thus not have the code copied (incriminatingly) to their hard disks--would be best. This code could be tucked away in a small part of CD-ROMs. What I envision is a CD-ROM (or whatever other distribution modes are popular) containing this steganogrophic and cryptographic software and lots of other stuff, in other domains. That is, the crypto/stego part could just be a tiny fraction of this "Hackers Disc." Speculatively, we could do this ourselves, or work with "Wired," EFF, the Gnu folks, etc., to get these programs tucked in someplace amongst their files. (There are issues of platform compatitibility, which systems can read which CD-ROMs, etc. Details.) Making the algorithms available by ftp is of course already common practice. The reason I don't emphasize this is that users must download the programs to their systems, thus decreasing plausible deniability. (However, if the programs are just part of a larger collection of files, like a "News Magazine" of a bunch of files, then these algorithms will be just some of the _many_ files downloaded, and the user can once again feign ignorance. This would be a kind of "stego stego," where the stegonographic algorithms are themselves hidden amongst a bunch of unrelated files.) I realize all this may be too complicated, that the stego programs themselves are barely starting to appear (I know of a couple of efforts going on), and that the problem of how to claim ignorance may not be important for a few years yet, if ever. On the other hand, there may be value in getting these stego schemes distributed long in advance of their being needed. Comments? -Tim May -- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: by arrangement Note: I put time and money into writing this posting. I hope you enjoy it.

1 0

Cypherpunk FTP site -- where is it?
by ferguson＠fiber.sprintlink.net 12 Aug '93

12 Aug '93

Could I entice someone to remind me of where the anon FTP site (and directory) is located? I seem to recall that it was on soda.berkeley.edu but beyond that, my memory fails me....

1 0

Re: >Clipper trapdoor?
by Peter Wayner 12 Aug '93

12 Aug '93

Dave Sobel has been wondering just how the Escrow Agency will check up on the requests for keys that it gets from the NSA. The procedures aren't decided yet, but from my understanding of the presentation given at the last CSSAB meeting in Washington, the Escrow agencies won't have a person/phone to escrow id number mapping that would allow them to check if a request for a key is valid. There are two reasons for this. 1) It would be pretty useless because people could sell their phones at garage sales or give them as Christmas gifts and screw up the list. 2) This is also a "feature". If two of the escrow agents (from different agencies) decided to go bad, then they wouldn't be able to look up their enemy Bob's escrow key by name. They would need some of the real-time hardware and access to the family key. Presumably, this would be handled by a third party. -Peter

1 0

ANONYMOUS CONTACT SERVICE
by Duncan Frissell 12 Aug '93

12 Aug '93

To: cypherpunks(a)toad.com H>A few months ago, someone subscribed to H>the list through the Penet service, H>and it ended up revealing the Penet H>aliases of everyone who posted. Each H>post was delivered to that subscriber H>marked as being from the Penet alias H>corresponding to the poster. All it took H>was a parallel non-Penet subscription H>to break the anonymity provided by Penet. H> H>Has this now happened again? Funny you should mention this. Maybe someone else just subscribed via penet since my morning post to cypherpunks was bounced back to *me* from penet (as well as being posted normally). The bounce was caused because penet was reading the originating address as *my* address (not cypherpunks) and since I have been using a penet password and my message did not contain the password, it was not forwarded. I have noticed that some postings show up here from cypherpunks and some from the address of the original poster. I suppose different mailing situations cause different results. Maybe all penet users on the list should activate passwords on penet.fi. Penet may search back along the chain of addresses for any familiar address to check against it's list of password-enabled addresses. Duncan Frissell H> H>At the time, there was some discussion H>about using "an..." versus "na..." H>forms of the Penet aliases, one of which H>would avoid this revelation. Has H>that been taken care of? H> H>Hal Finney H>hfinney(a)shell.portal.com H> H> --- ~ WinQwk 2.0b#0 ~ Unregistered Evaluation Copy

1 0