- cypherpunks-legacy - lists.cpunks.org

Re: Decline and Fall
by dmandl＠panix.com 17 Dec '03

17 Dec '03

At 8:55 AM 6/19/94 -0700, Sandy Sandfort wrote: >Chomsky's error is that he equates governments with democracy. Not true. Chomsky is an anarchist. He would never make a statement like that. Just for the record... --Dave. -- Dave Mandl dmandl(a)panix.com

2 1

MAIL: anon mailing list
by Karl Lui Barrus 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- > Has anyone tried to write some mailing list software that uses > PGP-anon-remailers to implement a double-blind anon system? > a standard mailing list. But has this already been done? It seems > like such an obvious idea, that it's hard to believe no one has > thought of it first, but I haven't heard of anything so far. Comments? Well, Hal Finney offered a service by which people could subscribe to an encrypted version of this list... which is something similar. Say somebody wants to run a mailing list as you propose. I think they should just run the list at the same address unless the remailers can suitably pad, delay, and randomize incoming messages and redirect them to the true list site (but then delay and randomization may lead to loss of coherency on the list ;). If not, surely external observation of the contact point will show where all the messages are headed. The resources needed would be higher than a normal list since each incoming message would need to be checked for a digital signature (or the list could become victim to an anonymous mail bomber, and you can't filter out anonymous remailers since of course everybody is using them to submit posts!), encrypted to every other member, and remailed. Which isn't to say impossible, just maybe impractical for a large mailing list. Take this list, with say 500 members - every incoming post digitally signed and arriving via anonymous remailer, and upon arrival, checked for a valid signature, encrypted with the public keys of the pseudonyms subscribing to the list;), and remailed out... This may work if you have a small group of people dedicated to this setup, but otherwise, no go. I mean, most people on this list don't even sign their posts, most don't submit via anonymous remailer, etc. It would take much work to make it convenient enough to do this. I think a higher priority is finding the bug that keeps unsubscribing everybody ;) Karl Barrus klbarrus(a)owlnet.rice.edu -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLgTdeMSF/V8IjI8hAQHeTwQAjDPXzJgrwubLkxq0Kz6ETM7chR4Ci5kG XbzWrFc3jwT57xpOfHIeeTTWn73Sls7C5UsFAT1sE4hxHRZO2HG6a7psLRa5/82V bhjnW+6KMOByCZb01h4b0toVR+7vF22EzPME0lnlsW+SjBqlAcNYPb+rSnjbnahG g9zzaCL6nJ8= =1WIZ -----END PGP SIGNATURE----- -- Karl L. Barrus: klbarrus(a)owlnet.rice.edu 2.3: 5AD633; D1 59 9D 48 72 E9 19 D5 3D F3 93 7E 81 B5 CC 32 2.6: 088C8F21; 97 73 9E 8B 98 3E DD B5 E8 97 64 7E 20 95 60 D9 "One man's mnemonic is another man's cryptography" - K. Cooper

2 1

Re: Re:
by pcw＠access.digex.net 17 Dec '03

17 Dec '03

>>The cypherpunks mailing list has once again been mysteriously purged. > >I've been receiving mail from cypherpunks all morning. > >-- >Lefty (lefty(a)apple.com) >C:.M:.C:., D:.O:.D:. I've received nothing. Nada. Zero

1 0

Geek of the Week (fwd)
by snyderra＠dunx1.ocs.drexel.edu 17 Dec '03

17 Dec '03

OK. I do remember the earlier discussion about forwarding material to the list, but this is forwarding a pointer to data, which I hope is OK. :-) I get my talk radio files from ftp://sunsite.unc.edu/pub/talk-radio, although you may want to check the ITR FAQ for a closer location. (Th FAQ should be on rtfm.mit.edu) Bob >Date: Fri, 15 Jul 1994 04:03:15 -0400 >To: "Announcements" <announce(a)radio.com> >From: "Internet Multicasting Service" <rtfm(a)radio.com> >Org: Internet Multicasting Service >Subject: Geek of the Week >Status: RO > >The MIME-Version header has been deleted from this message to permit >interoperability with a larger number of mailers. > >------- =_aaaaaaaaaa0 >Content-Type: application/x-program-listing >Content-ID: <071594_geek_ITR.2(a)trystero.radio.com> > >Station: Internet Multicasting Service >Channel: Internet Talk Radio >Program: Geek of the Week >Content: Steve Crocker > >Carl Malamud interviews Steve Crocker, a newly elevated member of the >Internet Architecture Board and a leading contributor in efforts to >provide a security infrastructure for the Internet. Crocker discusses >PEM, Clipper, DSS, PKP, and other important security acronyms. > >Geek of the Week is made possible by the sponsors of Internet Multicasting >Service, including O'Reilly & Associates, Sun Microsystems, and Interop >Company. Additional support is provided by NASA, Cisco Systems, Harper >Collins, Persoft, Tadpole Technology, and WAIS Inc. Network connectivity >for the Internet Multicasting Service is provided by UUNET Technologies and >by MFS Datanet. > >Cassette tapes of Geek of the Week are available from O'Reilly & Associates. >Send electronic mail to audio(a)ora.com or point your WWW Viewer to the >Global Network Navigator (http://nearnet.gnn.com/gnn/gnn.html) > >ITR Program Files: > >Size Name Description >========== ====================== ======================= >14,771,098 071594_geek_01_ITR.au Steve Crocker > 071594_geek_ITR.readme (This File) > >To learn about the Internet Multicasting Service, send your electronic >mail to info(a)radio.com. > >------- =_aaaaaaaaaa0 >Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa1" >Content-ID: <071594_geek_ITR.3(a)trystero.radio.com> > >------- =_aaaaaaaaaa1 >Content-Type: message/external-body; > access-type="anon-ftp"; > name="071594_geek_ITR.readme"; > site="$SITE"; directory="$DIRECTORY" > >Content-Type: text/plain >Content-ID: <071594_geek_ITR.4(a)trystero.radio.com> >Content-Description: Readme (This File) > >------- =_aaaaaaaaaa1 >Content-Type: message/external-body; > access-type="anon-ftp"; > name="071594_geek_01_ITR.au"; size="14771098"; > mode="image"; site="$SITE"; directory="$DIRECTORY" > >Content-Type: audio/basic >Content-ID: <071594_geek_ITR.5(a)trystero.radio.com> >Content-Description: Steve Crocker > >------- =_aaaaaaaaaa1-- > >------- =_aaaaaaaaaa0-- -- Bob Snyder N2KGO MIME, RIPEM mail accepted snyderra(a)dunx1.ocs.drexel.edu finger for RIPEM public key When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.

1 0

Handling subscription requests
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

Rishab asked earlier if there isn't some way that Majordomo could automatically filter the requests that go this list instead of to the Majordom agent. Pretty unlikely, for various reasons: - The requests would be poorly formed, such as "Can anyone tell me how to subscribe?" and I can't imagine anything short of a CPU-intensive natural language processor able to deduce the actions needed. Certainly I don't want to get added again, or be sent a message, every time "Pretty Good Autosubscriber" sees the word "subscribe" in one of my messages! (Yes, I can imagine an algorithm--"if not already a subscriber and mentions subscribe, then...") - In any case, this is very far from what Majordomo now does. In fact, Majordomo is very picky about the command syntax it expects to see. - And the CPUi-intensive filtering to look for the right magic words would be unwelcome. Especially if every message to cypherpunks(a)toad.com had to be examined! (Again, I can imagine way to reduce this, such as only looking closely at nonsubscriber messages. But not in Majordomo's current feature set.) So what to do? Frnakly, I don't think it's too big a problem. Only a couple of these hit the list per week, even after the list has gotten some publicity someplace like "Wired." Here's what I try to do, when I remember. When I see one of these requests I reply and attach this message: How to Subscribe to the Cypherpunks List This message is just an informal tip sheet on how to get on and off the Cypherpunks list, sent manually by me to people who ask how they can join the list. The Cypherpunks list is managed automatically by the "Majordomo" program, which is commonly used for mailing lists. Command syntax may be familiar to you from other lists. To subscribe: * Send a message to: majordomo(a)toad.com * No subject is needed, or is used * In the *body* section, include only the following: subscribe cypherpunks * This will subscribe you with the address from which you sent the message. If you wish to subscribe with a different address, for some odd reason, send a "help cypherpunks" message instead. * Unsubscribe by sending the message: unsubscribe cypherpunks * A list of current subscribers can be gotten by sending the message "who cypherpunks" to the same address. Be forewarned--your membership on the list will be known to others. (Hal Finney and others have talked about providing secondary mailing list, which can even be encrypted.) Comments: - Write the above information down somewhere. Do not send unsubscribe messages to the main list (cypherpunks(a)toad.com) And the address "cypherpunks-request(a)toad.com" probably will not work either. Use majordomo(a)toad.com. - The list is a high volume one. Fifty messages a day is common. If you can't handle this, unsubscribe. Or read your mail several times a day and make liberal use of the "delete" function. - The list was started in 1992 and has roughly 600 subscribers. - If you are new to the list, read for a while before posting. Be especially polite by not asking "dumb" questions like "Why is Clipper a bad idea?" and "Can anybody break this code?" (It is sometimes said there are no dumb questions. I disagree.) - You will also receive a longer welcome message after your subscription has been successfully processed. - The subscriber list has gotten corrupted several times, due to disk space problems. If you receive no traffic for several hours or more, do a "who cypherpunks" to see if this has happened again. Either resubscribe in the usual way, or wait for the list to (maybe) be restored. - If you find yourself getting two copies of every message, see if you are subscribed under two different mailing addresses. (The mail headers should tell you.) Then unsubscribe the address you don't want to use. This should answer the most obvious questions. Feel free to pass this message on to folks who ask about subscribing. --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^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."

2 1

Re: Anti-Clipper Article in "THe Computer Applications Journal"
by smb＠research.att.com 17 Dec '03

17 Dec '03

Might I suggest that this is not the right newsgroup for anti-Clipper articles? I've never seen *any* Cypherpunk defend it; what's the point? Preaching to the choir? Repeat doses of brainwashing? Citations are fine; they show what the outside world thinks. Technical aspects are fine; there's a lot to be learned about Skipjack and key escrow. But there's little point -- on this list -- to hearing yet again that Clipper is bad (unless, of course, someone starts defending it here). --Steve Bellovin

2 1

New Money design announced
by nym＠netcom.com 17 Dec '03

17 Dec '03

I think this came from a Fidonet channel. an interesting topic: how will this affect the value of US cash? i.e. will it affect the value of the dollar worldwide? often when countries are facing economic trouble they change their currency. **** Conf. : 0008 - FINANCIAL WASHINGTON (AP) -- Move over Ben Franklin, tell Andrew Jackson the news: The portraits on the nation's paper money likely will be enlarged and moved off-center as part of the first major makeover in 65 years. ``Our plan ... is a pre-emptive step to protect U.S. currency from high-tech counterfeiting,'' Treasury Secretary Lloyd Bentsen said in announcing the redesign Wednesday. His department plans to have a final design ready sometime in 1995 and begin circulating new bills about a year later, starting with the most popular target for counterfeiters, $100 notes. Nothing has been decided for certain, but Treasury officials gave the House Banking Committee a rundown Wednesday of what was likely. The enlarged portraits -- Franklin on the $100, Ulysses Grant on the $50, Jackson on the $20, Alexander Hamilton on the $10, Abraham Lincoln on the $5 and George Washington on the $1 -- will allow for more detailed engraving of what is the most recognizable feature on a bill. The $2 bill, with Thomas Jefferson, is not being redesigned. And, moving the portraits will make room for a watermark in the form of a smaller version of the portrait, visible only when a bill is held to the light. Other likely changes include: -- Color-shifting ink that may, for instance, appear green when viewed straight on and gold from an angle. -- Computer-designed ``interactive'' patterns that turn wavy when illicitly copied. -- Iridescent planchettes in bills' paper. These are colored discs only a few millimeters wide that reflect light. -- Micro-printing and machine-detectable threads or fibers in the paper. The last major change in U.S. currency came in 1929, when bills were reduced in size and given a uniform look. Congress added the words ``In God We Trust'' in 1957. In 1990, several small changes made it more difficult to counterfeit with modern color photocopiers. They included adding a microscopic line of type and a polyester thread visible only when a bill is held to a light. Most lawmakers applauded the latest modifications, saying they were long overdue. ``We must protect the dollar's standing as the world's foremost currency. Our financial future depends upon it,'' said the committee chairman, Rep. Henry B. Gonzalez, D-Texas. But others warned against too radical a redesign, saying it would send a message of instability at a time when the value of the dollar is being battered on world currency markets. Peter H. Daly, director of the Bureau of Engraving and Printing, said the bills' traditional look will be maintained as much as possible. The paper will feel the same and the size of notes won't change. And the same engraving style will be used for portraits, borders, numbers and the historic scenes on bills' back. Bentsen stressed that old money will continue as legal tender. ``The redesigned currency will be introduced over a period of years and no U.S. currency will be demonetized, devalued or recalled,'' he said. And U.S. Treasurer Mary Ellen Withrow promised a worldwide educational campaign to encourage public acceptance of the new design. About $357 billion of U.S. paper currency is in circulation, more than 60 percent of it abroad. In fact, in some countries with troubled economies it serves as the principal medium of exchange. According to the Secret Service, counterfeiting abroad now far outweighs domestic counterfeiting. Last year, $120 million in phony bills were seized overseas, compared with $44 million domestically, said Secret Service Deputy Director Guy P. Caputo. Republican Reps. Jim Leach of Iowa and Bill McCollum of Florida suggested the administration may be minimizing the severity of the problem. Leach said a Middle Eastern country, which he did not name, reportedly has developed the capacity to counterfeit large quantities of $100 notes. He was apparently referring to trade press reports that Iran was distributing counterfeit bills through Lebanon. But Bentsen stressed that the changes were being made in anticipation of future problems and not in response to any current counterfeiting crisis.

2 1

Re: Hashed hash (and Kent's games)
by Ben.Goren＠asu.edu 17 Dec '03

17 Dec '03

At 12:19 AM 7/17/94, Kent Borg wrote: >Ben.Goren(a)asu.edu foolishly says: >>I'm planning on implementing the "cryptographic protection of databases" > >And wonders about the hash being too fast to compute, that a >brute-force traversal of the database would be too easy. The idea is >then to hash a bunch of times to burn CPU cycles, but what if the hash >is a group, extra hashing could be reversed quickly. (Did I get that >right?) On the nose. >Well, as the LOUD proponent of making secret keys s-l-o-w-e-r to >decrypt, I have thought about this a bit, and have a suggestion: > >Hash once, then do a zillion encryptions of the hash with a non-group >cypher like DES. I'll probably do just that. First thought, subject to revision: hash the name, feed it to DES with the output of a deterministic RNG (need not be secure, but the slower the better--BBS? (not that BBS is incesure)) as the key; repeat as needed. Hmmm...perhaps I'll adapt an earlier idea of mine: split the hash into two parts, a and b, and compute (a^(1/b))-1, and use some or all bits after the leading zeros. >Another idea (something I have thought less about): send every legit >user of the database a custom version with the parts encrypted with >that user's public key--and do the trick mailing list companies use, >scatter some dummy info in the list. When a dummy (not just me) gets >a junk mailing, go beat up on the user who's copy had to have supplied >the junk [. . . .] Nice idea, but there's neither the available resources to do that, nor, I think, the desire to beat up on careless users. Berzerk suggests a 0.1 S/N ratio (and in an earlier note a couple useable algorithms for the multiple encryption process); that would not be practical for any decent sized database, and I might have 100K or so people to deal with. But I almost certainly will mix in at least some random padding. I imagine that the database will always be the same length, even as people are added and/or removed with time. And the records, of course, will be premuted randomly. >-kb, the Kent who doesn't want to be thought of as only a card player Then here's a suggestion for you: develop some other primitives, like rolling dice, and you could implement just about any other game you like. Monopoly would need (aside from licensing issues) the dice, two decks of special cards, and some ecash. (Surely MM used as Monopoly Money isn't subversive? After all, it's teaching our young 'uns to be good capitalists.) Scrabble would need a deck of cards, each of which contains only a letter, with many duplicates. Trivial Pursiut is just a huge deck of cards; they'd probably be index positions to the database of questions, so special editions are just a file switch away. These are among the most popular games in the US, and probalby abroad. Build your primitives right, and these games are as simple as specifing paramaters (how many sides to the dice, what info the cards contain, etc.). And maybe you could license the stuff, each and every independent game, to the current owners of the games that aren't PD. So how about becomming "kb, the Kent who digitized the American family evening"? Go for it! And drop me a line when you want beta testers (sometime Thursday?). >Kent Borg +1 (617) 776-6899 b& -- Ben.Goren(a)asu.edu, Arizona State University School of Music net.proselytizing (write for info): Protect your privacy; oppose Clipper. Voice concern over proposed Internet pricing schemes. Stamp out spamming. Finger ben(a)tux.music.asu.edu for PGP 2.3a public key.

2 2

PGP bug *NOT* yet fixed
by Ben.Goren＠asu.edu 17 Dec '03

17 Dec '03

Y'all remember that bug that Colin Plumb told us about in the true random number generation part of PGP? It's still there, in the version from net-dist.mit.edu, as of late yesterday evening. There is *no* mention of the bug anywhere, in any readme files, in the documentation, anything. This strikes me as irresponsible. I would expect PGP 2.6a to have been released the day of the announcement, with the bug fixed. If there's some reason why that couldn't be done, then at least there should be some sort of prominent notice detailing the change, and probably a diff file--or even a simple shell script--to apply the (very simple!) fix. The signature on the following file checks as follows: >File has signature. Public key is required to check signature. . >Good signature from user "Colin Plumb <colin(a)nyx.cs.du.edu>". >Signature made 1994/06/01 14:04 GMT That's a month and a half ago. The *only* copies of PGP 2.6 out there that are free of the bug are those that have been fixed by hand. That's probably not all that many of them. I'm going to bite the bullet and paste in the original message here. Feel free to flame me if this is unnecessary re/cross-posting, but I'm not aware of any place to get this aside from digging through archives, and.... b& -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.5 mQCNAi3L864AAAEEAKRe8j9QUqL4PDQSsliTKQ0yTkdLL8BFBm7c03RC9Ol5PP9K j/RtnsdxFMTtW7wkMwTpY1jF23HR+x54LrOpi8ig6HEmiXVVWuNByRjSMgz8jvrn MM0/tIOCPAgNMxiANUWqretPEWCZE9sLbylkJrrOd54ZKyXBTw/D7AL7u4qxAAUR tCFDb2xpbiBQbHVtYiA8Y29saW5Abnl4LmNzLmR1LmVkdT6JAJUCBRAtyxCUZXmE uMepZt0BAeiyA/4tNXz6loqEwyMv65TMGtqxTlT5ocGNzyE8mkZXvbmoS0m7sdsd aVBvHfK8lrkQz/anrzAHJMBOaZ0V6T7aCLAK6GnjHoeanP8ZyhaXpc2e7EVut4Zi hCpmq45uiA/1diwLXhC8OoHwKqZDT+uNnJLLdlAzrJiOaELAzXXeOvtMXokAYAIF EC3L/BnKPaH9hlqn8wEBXWgCWMgIh8Lsww5pFHRFbAe2HehjGIiOmQ+ZcnL3pOhw tLdoGm6lqWZ4njDSTULxDpKUtbe4pWNv6Go13t9p+1GmTh+RrnGoq6rs3Mlg+IkA lQIFEC3L+zgPw+wC+7uKsQEBDZkEAJYkHK5n02GXLwEEgFKpxQvWLqI2xz33rPDa 0eT6+RYMDcr/1vzTqX7CwNpCuTaFTVNRbRznvwNTDcQXVsnyPg5yGdRIIMPnWuGf gSEP7vjm8zzvfdh5te4ag6jobCN1PVyqIIxIV5S8iPv632gm4vQboJiQ+4+53qoS WJ6BNDq9 =Wjfi -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNED MESSAGE----- I have the unpleasant task of reporting a significant bug in PGP's random number generation (for making primes), and that it's my fault. It *is* a significant problem, although it is *not* end-of-the-world severity. That is, the code is not doing performing as intended, and the results aren't as random as intended. On the other hand, this does not appear to make any generated keys easier to break. Because it has to do with random-number generation, there are no interoperability issues raised. Please read on for details. Thanks to the many people who have submitted other bug reports and porting patches. A new release from MIT is forthcoming with more cleanups. * The Bug In pgp 2.6 (and 2.5), there is a file named "randpool.c", which accumulates entropy from keyboard timings. These random numbers are used in generating session keys, although the primary random number generator for session keys, based on IDEA, is unaffected. The main use of these random numbers is the much more sensitive task of generating RSA secret keys. In that file, a tiny helper function is xorbytes: static void xorbytes(byte *dest, byte const *src, unsigned len) { while (len--) *dest++ = *src++; } A character is missing. '^', to be precise. That "=" should be "^=". I wrote it, and I knew when I was writing it that it was critical code. Since you can't test a random-number generator (except for the most trivial of flaws), you have to walk through the code very carefully. I did, or thought I did, yet still managed to miss this. Oops is too mild. That code is not supposed to have ANY bugs. In other words, I screwed up. There's a lesson in there somewhere. I'll try to learn it. * The Effect The randpool.c code works by maintaining a pool (buffer) of random bits and adding in new "noise" from the environment each time a key is pressed. This "adding" is done by exclusive-oring it with successive bytes from the existing pool. When the pool is "full", a cryptographic stirring operation is performed to mix all the information in the pool together and get ready for new noise. The bytes in the pool at the end are intended to be uncorrelated with the noise bytes that will be added, so the XOR adding does not cause any sort of "cancellation" of information. This stirring is done with a key, which is taken from the pool at the end of each pass. With the bug in place, the noise bytes *replace* the bytes in the pool rather than being added to them. So the information that was in the pool is obliterated. The only trace that remains is what's stored in the key. This is at most the size of the key, 512 bits, rather than the size of the whole pool, 3072 bits. PGP tries to ensure that generated RSA keys are completely unpredictable by accumulating enough Shannon information to make the whole key. Thus, infinite computational power would not let you predict a generated secret RSA key. This bug subverts that. * Security Analysis What effect does this have on someone's chances of breaking an RSA secret key generated with PGP 2.6? Not much, as far as I can tell. But it requires more careful thought and that eats into the comfort margin that should be there. Just for comparison, the RSAREF library's random number generation routines are also based on MD5, but use 16 bytes of seed. Successive random bytes are taken by computing the MD5 hash of the 16-byte seed, using those 16 bytes, incrementing the seed by 1 (taken as a 128-bit number), and repeating. Taking the MD5 of a 16-byte value involves one pass of the MD5Transform function, with 16 of the 64 key bytes unknown, 48 bytes are known (fixed, in fact), and the input hash is known (fixed, in fact). Compared to this, PGP 2.6, even with the bug, is excellent. All 64 bytes of key to MD5Transform are dependent on all of the seed, the input hash varies widely, and the output is XORed with some difficult-to-predict data. The reason that you can get away with less than perfect random numbers (less Shannon information than the size of the generated key) is that you only have to make sure that the weakness does not make any attack easier than the best known attack without the weakness. As long as guessing is only useful to a brute-force attack, it remains far easier to factor. Paul Leyland estimated that the work to try all possible 128-bit IDEA keys is equivalent to factoring a 3100-bit RSA key. Now, recent work by Arjen Lenstra on the number field sieve (Paul Leyland was assuming the MPQS used in RSA-129) has raised this RSA key length somewhat. Thus, an argument can be made in favour of RSAREF's use of a 128-bit random number seed, since that's all that is necessary. PGP prefers to be a little bit more paranoid. Still, once you have 512 bits of uncertainty, trying all possibilities is more work than trying to break a 1024-bit RSA key by trial division. So let's see just how much entropy is in there. Each keystroke, the following data is added to the random pool: - - The cahracter typed, an int (2 or 4 bytes) - - the time_t result of time() (4 bytes) - - the clock_t result of clock() (4 bytes) - - On MS-DOS, 2 bytes of hardware timer 0 - - On Unix, 8 bytes of gettimeofday() and 20 bytes of times() results - - On VMS, 8 bytes of high-resolution timer. The total is 12 bytes on MS-DOS, 32 bytes on Unix (this may vary, but that's very common), and 20 bytes on VMS. The information content of the bytes is taken at a maximum of 8 bits, although it's actually closer to 15 bits on MS-DOS, and less (maybe as low as 1 or 2) on a Unix system with a fast typist and a slow (60 Hz) clock. VMS is in between. This means that the entropy density in the added bytes varies from 1/12 (or better) in MS-DOS to 1/256 on Unix. Thus, the content of a pool's worth (3072 bits) is 256 bits (or more) under MS-DOS and may be as low as 12 bits on some flavours of Unix. The random number accumulation operation adds bytes to the pool until it is either full or the desired number of bits have been accumulated. Then it stors the pool. For a maximum-sized key (1024 bits), it will take many passes through the pool to accumulate the entropy, but owing to the bug, each time the pool is overwritten with the most recently collected data. The only entropy that remains from the previous pass is in the 512-bit key buffer. This applies to every stirring pass until the last, after the last noise data has been added and new data is about to be withdrawn from the pool. This last pass is very likely to be incomplete; some of the data at the tail of the pool is probably not overwritten. This can carry over extra entropy from the previous pass. No more than is there (the 12 to 256 bit range observed before), and then you have to add an unknown fraction of that for data that has been added in the current pass, but the total will vary from 12 bits (an average of 18) to 256 bits (an average of 384). Plus the entropy preserved in the key buffer. So there is from just over 512 to an average of 896 bits of entropy in the pool. 1016 random bits are used to make the starting values for the two primes in a 1024-bit key. This is clearly not the perfect Shannon entropy PGP aims for. As long as the stirring operation is still considered cryptographically strong, this reduction in the possible range of generated keys is not useful to a factoring algorithm, so it doesn't make a factoring attack any easier, yet a factoring attack is still far easier than a guessing attack, so the easiest attack is no easier. So I don't think anything is more attackable. Still, it's NOT what was intended, and that's always bad. My apologies to users of PGP. - -- -Colin -----BEGIN PGP SIGNATURE----- Version: 2.5 iQCVAgUBLeyVSw/D7AL7u4qxAQEjCQP/YlzY5DWT4FrSErQ8W0TP9ibRqpck4gKL YOkUgiMQnvCE2XHEvP1VTfUANgU9O/P7lClJ1oaOXIEbt5GW45DAVPgSZk5PoJ10 TZ5Ly4wqDzMa8YLDu4I2l2Use5wwIIYl5IbGEdZiRlYdox7eWaGRLfOiA8CPVb9p yZ7PgFZU10Y= =Bj83 -----END PGP SIGNATURE----- -- Ben.Goren(a)asu.edu, Arizona State University School of Music net.proselytizing (write for info): Protect your privacy; oppose Clipper. Voice concern over proposed Internet pricing schemes. Stamp out spamming. Finger ben(a)tux.music.asu.edu for PGP 2.3a public key.

1 0

Sue D. Nym
by merriman＠metronet.com 17 Dec '03

17 Dec '03

I trust that everyone got the joke: Sue D. Nym = pseudonym Dave Merriman Wherever you go in Life - there you are!

1 0