- cypherpunks-legacy - lists.cpunks.org

Shamir papers are available
by fnerd＠smds.com 09 May '93

09 May '93

The Adi Shamir papers are available by anonymous ftp from soda.berkeley.edu in pub/cypherpunks/papers/ shamir.abstracts shamir.birational shamir.hard.poly Thanks to Eric Hughes. -fnerd

1 0

Random TSR
by Hal 09 May '93

09 May '93

-----BEGIN PGP SIGNED MESSAGE----- We had some discussion on the list a few months ago about hardware RNG's. As I recall, there were problems feared with the Zener diode noise generators involving coupling to other EM signals that might add regularity to the noise. Hardware random numbers are useful, not so much to fill one time pads, with their attendant problems with distribution, but rather as session key generators for Diffie-Hellman key exchange or RSA-type public key programs. This is one of the weak points of PGP, in my opinion; it times keystrokes when you first generate your public key, but then from then on it just uses and re-uses those same random numbers. (It does mix in the time of day for each message sent, but as pointed out on the PGP developers' list, this may not add that much randomness.) Each time you send a message, it has to generate a random session key, which it uses to encrypt your message, sending this random key RSA- encrypted at the head of your message. How random are these session keys? PGP is still re-using the same random information I supplied many months ago. There is no KNOWN way to exploit this lack of randomness but it is still worrisome. Perry Metzger mentioned that he deletes his randseed.bin file every night. This causes PGP to ask him for new keystroke timings every morning when he first runs it. This adds a new daily dose of randomness to the program but it is kind of a pain to do. This is where a hardware RNG would be really useful. Use it to generate your session keys and you don't have to worry too much about someone breaking your message by intelligent key guessing. RIPEM goes to greater lengths than PGP in trying to find good random bits. It has options to scan your filesystem or to use network information, both of which are presumed to be randomly changing. These approaches are more suitable for a multi-user workstation than for a regular PC, though. I had an idea for the PC environment which I don't think I've seen before. (Apologies if I'm regurgitating someone else's idea.) Have a TSR which just extracted random information from your use of the PC. Do keystroke timing all the time, check disk block contents and locations. Record this information and periodically pass it through MD5 then store it in a file. This file would basically hold entropy extracted from how you use your PC. PGP could then read this file (you could even have the file be PC's randseed.bin, making it compatible with current versions of PGP) to get its random bits for session keys. This does not sound like it would be that hard, although the few attempts I have made to write TSR programs which hooked into DOS calls have not been terribly robust. One technical issue is how much randomness or entropy exists in each event. This has been discussed in some detail on the PGP developers' list, but a simple solution would be to just ignore that problem and constantly merge in your new random bits with those in the file. Once you've gotten enough "true" randomness your file will be fully random. You won't know when that's happened but if your file isn't too big and you use the computer quite a bit it will hopefully be fast enough. Or, if you wanted to be more ambitious, I gather from the discussion on pgp-dev that you could collect statistics on the intervals between key- strokes and use these to estimate the amount of random information per keystroke. Then you could have a call to the TSR to tell how much random information is available in the file. This program could be constantly running in the background, unobtrusively, collecting and distilling the randomness you are discarding all the time. Randomness is precious; it's time to stop wasting these bits! Hal Finney 74076.1041(a)compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBK+0lWqgTA69YIUw3AQGPbQP/TUSbeusbaPQ3DF6wpr+tY5H8IcVTzJUb p78E+IZHx8pMSQP/fu8SnBGWuINnurq9fssJT9o7DQJnXBmcEgK+48OHbunHi9OV VrheN8tXHTY5OBd4pvKV9nh200+OalRny5lL4ZviMqGl+iYVJEU5PdZIPnPeRAzV AaZ2gvVBdbE= =gww0 -----END PGP SIGNATURE-----

1 0

Re: RNG from zener is easy.
by markh＠wimsey.bc.ca 09 May '93

09 May '93

> To: >Internet:cypherpunks@toad.com > > A simple XOR with the message text is enough to create an unbreakable > cyphertext. Problem is, that both parties have to have exact copies > ... > I'm glad Liam brought this up. It is a good way to produce an > absolutely unbreakable code. This, providing the design is good and > no patterns are allowed to appear (introduced by amplifier > oscillation or nearby noise sources) in the generated numbers. If > there is any interest out there perhaps we (Liam or I) could produce > a few for testing. Yes, I'm certainly interested. A practical use for such a device would be to generate "random" data for use by PGP or RIPEM. Both need "random" data to generate session keys and public/secret keypairs. In fact, the whole security of these programs depends upon the unpredictability of the "random" data used. Mark -- Mark Henderson markh(a)wimsey.bc.ca RIPEM key available by key server/finger/E-mail MD5OfPublicKey: F1F5F0C3984CBEAF3889ADAFA2437433

1 0

RNG from zener is easy.
by William Oldacre 09 May '93

09 May '93

To: >Internet:cypherpunks@toad.com This posting is in response to Liam's earlier message on creating a random number generator using a zener diode. I breadboarded such a circuit over year ago and it worked fine. Zener diodes, operated in their zener region with a reverse voltage generate electrical noise much like a "noise diode". This can be amplified and shaped using a single quad op amp package to create what appears to be a very random data stream. Best way to use this would be to shift it into an eight bit latch before reading the parallel port. Depending on design, it's operation is much (MUCH) faster than a pseudo random number generator written in software. It can fill a floppy disk so fast that the main limitation is the writing speed of the disk drive. A simple XOR with the message text is enough to create an unbreakable cyphertext. Problem is, that both parties have to have exact copies of the random numbers since they cannot be regenerated as with pseudo random numbers using a key. What is needed is a way to encrypt the random numbers so that they can be sent to someone else to use. This would be hard to decode, because it would be difficult to know when success had been achieved. If it is being tested against a message text, the loss of one byte shifts everything to that the text becomes gibberish again. I'm glad Liam brought this up. It is a good way to produce an absolutely unbreakable code. This, providing the design is good and no patterns are allowed to appear (introduced by amplifier oscillation or nearby noise sources) in the generated numbers. If there is any interest out there perhaps we (Liam or I) could produce a few for testing.

1 0

Press: Sunday NY Times
by Harry Shapiro 09 May '93

09 May '93

There is a major "technology" piece in the Sunday NY Times by John Markoff on the Cyhperpunk group, the Wired article (The cover is reproduced a long with the demasked photo to Tim, Eric and John), the encryption as a whole. Great job John!! /harry -- Harry Shapiro habs(a)panix.com List Administrator of the Extropy Institute Mailing List Private Communication for the Extropian Community since 1991

1 0

RNG: from Zener diode?
by Liam David Gray 09 May '93

09 May '93

Tim, I recall you or some other Cypherpunk mentioning that, by some means, strong random numbers can be had by observing some property of Zener diodes. Could you explain this? ...If feasible, I imagine exploiting this phenomenon to make a "random number dongle," an inline device for a PC's serial or parallel port, which could be polled by savvy software. If possible, and if someone hasn't done it already, I'd like to work up a simple recipe (schematic, list of ingredients, and sample code) for this--and get it put into our "crypto-anarchists' cookbook"--i.e., on soda.berkeley.edu. Perhaps a future version of PGP could take advantage of such a random noise dongle, selectable by command-line switch. This is pure speculation at this point. Am I completely off-base? In any case, I'd love to hear more about it. Liam --- PGP public key available by arrangement -- The cat is out of the bag. Too much of a dreamer not to be practical -- Go have your own "valiant defeat." Liam David Gray <lg2g+(a)andrew.cmu.edu>

1 0

Correction!
by edgar＠spectrx.Saigon.COM 09 May '93

09 May '93

In part of my long post dated May 3, Subject: PGP: Re: Tough Choices: PGP vs. RSA Data Security I said: Jim Bidzos has told me that Phil Z. or anyone else can get a license from RSA for $20,000 plus minimum $10,000/yr. royalties. If we say we don't want to spend more than 50% of our revenues on licensing, then if Phil can get $60,000 of firm orders for a -commercial- USA version of PGP, he's in (a very profitable) business. $60,000 might be 600 copies at $100 or six site licenses at $10,000. Upon reviewing my records, I find I didn't remember those figures correctly. The above -should- have read: Jim Bidzos has told me that Phil Z. or anyone else can get a license from RSA for $25,000 plus minimum $10,000/yr. royalties. ^^^^^^^ If we say we don't want to spend more than 50% of our revenues on licensing, then if Phil can get $70,000 of firm orders for a -commercial- USA version of PGP, he's in (a very profitable) business. $70,000 might be 700 copies at $100 or seven site licenses at $10,000. My apologies to Jim Bidzos for misquoting him; however, the basic point of the paragraph that a commercial license is not too far out of reach remains valid. -- edgar(a)spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca

1 0

ping?
by jdblair＠nextsrv.cas.muohio.edu 09 May '93

09 May '93

Hello? Is anyone out there? The very high mail flow from cypherpunks suddenly ended. Is something wrong, or is this just a normal burp in the system? -john.

1 0

testing again.
by J. Michael Diehl 08 May '93

08 May '93

1 0

Shamir at Stanford on Thursday
by tcmay＠netcom.com 08 May '93

08 May '93

> From daemon(a)Sunburn.Stanford.EDU Thu May 6 14:34:13 1993 > Date: Thu, 6 May 93 14:18:26 -0700 > From: Daphne Koller <daphne(a)Theory.Stanford.EDU> > To: stc(a)Theory.Stanford.EDU > Subject: STANFORD THEORY COLLOQUIUM > > > S T A N F O R D T H E O R Y C O L L O Q U I U M > ===================================================== > > > The Stanford Computer Science Department is pleased to announce the > eighth Stanford Theory Colloquium this Thursday, May 13. > > > Polynomials and Cryptography - Some Recent Results > > Professor Adi Shamir > Weizmann Institute of Science > > > The talk will take place 4:15 -- 5:45 p.m. in Jordan 041. > > A RECEPTION in honor of the speaker will be held in the third floor > lounge of MJH around 3:45. Everyone is welcome. > > ------------------------------------------------------------------- > | Professor Adi Shamir is a coinventor of the RSA public key | > | cryptographic scheme and of several other key management and | > | signature schemes. He was involved in the cryptanalytic attack | > | on the knapsack scheme, and more recently he developed (with E. | > | Biham) the new technique of differential cryptanalysis and | > | applied it to the Data Encryption Standard. | > ------------------------------------------------------------------- > > ----------------------------------------------------------------------------- > > > Polynomials and Cryptography - Some Recent Results > > Professor Adi Shamir > Weizmann Institute of Science > > > Mappings defined by polynomials modulo n=pq are a fundamental tool in > modern cryptography. However, the inversion of such mappings usually > requires the extraction of roots or the evaluation of high degree > polynomials, which is quite slow. This talk will consist of two parts. > In the first part, we give an introduction to some basic cryptographic > techniques. The second part will describe some new results in the area. > We consider the class of birational permutations f, in which both f and > f^-1 are low degree multivariate rational functions mod n. We describe > new families of birational permutations, and how to turn them into new > cryptographic schemes which are much faster than previously known > schemes. In addition, we consider the general problems of factoring > multivariate polynomials mod n and solving systems of polynomial > equations mod n, and develop new techniques for proving the hardness of > randomly chosen instances of such problems. > > The talk will be self contained and accessible to a wide audience. > +----------------------------------------------------------------------------+

1 0