From: Scott Mills Area: Public Key Encryption To: John Schofield 17 Oct 94 09:11:12 Subject: Nodelist problems UpdReq Monday October 10 1994, John Schofield writes to All: JS> I just wanted to let everyone know--if you're having trouble sending JS> netmail to me, or anyone else in net 102, there's a simple reason. That explains the bounced netmail with the "address not found" on it. Scott Happiness is Bill Clinton's face on a milk carton! Scott Mills 1024/26CD5D03 For my PGP key just send NetMail with Return Receipt Request flag on. sm@f119.n265.z1.fidonet.org --- 201434369420143436942014343694201434369420143436942014343694718 From: Reed Darsey Area: Public Key Encryption To: Charles Chapman 17 Oct 94 04:08:30 Subject: Re: Article in Dr. Dobb's Journal UpdReq }Quoting Charles Chapman to All on 12 Oct 94 01:11:00{ CC>> There is an article entitled "Truly Random Numbers," on page 113 CC>> of the 11/94 ed. of Dr. Dobb's Journal. The article is by CC>> Colin Plumb, one of the designers and programmers of PGP. Also in that same issue is an ad for the book on PGP, on page 81. (The editorial page is also interesting.) ... PGP 512/AE5BEFB5 [26 D3 A0 FB FB E2 D2 35 B5 26 4A E1 A1 FB CD B8] 201434369420143436942014343694201434369420143436942014343694718 From: John Schofield Area: Public Key Encryption To: Jim Grubs, W8GRT 17 Oct 94 13:40:20 Subject: Clear-Signed "Hole" UpdReq -----BEGIN PGP SIGNED MESSAGE----- --====-- > JGW> The MIT version is written by Phil Zimmerman. What the hell more do yo > JGW> want? > No more than those issued by the Rebel. JGW> Are you saying you think Phil has nothing to do with the MIT version JGW> of PGP? Phil Zimmermann has done no actual writing of source code in later versions of PGP. He delegates that. However, he approves (he says) ALL changes in source code, and guides the development of future versions of PGP. If it is an official PGP, released by MIT, it has Zimmermann's approval. JMS -----BEGIN PGP SIGNATURE----- Version: 2.7 Comment: Call 818-345-8640 voice for info on Keep Out magazine. iQCVAwUBLqLfhmj9fvT+ukJdAQHvkAQApRGI7spyLMTTYiM7E3dsnVDWU1yWP2jV d53uf4cgtkR3ixrzgLpMu1Ji3TdZE8dNUnwo0QlW+CAglQihrbHnn4yZOirIdbC7 5S06QHsl+DwvS4ErlFXZMx2kp5MBa3GIpt0PiO1ltE7rUYvTOCEIVPjkOVTPcJWx LSJGWDT++8k= =pn/H -----END PGP SIGNATURE----- **EZ-PGP v1.07 ... He who gives up freedom for security deserves neither. 201434369420143436942014343694201434369420143436942014343694718 From: Jim Bell Area: Public Key Encryption To: DAVID CHESSLER 11 Oct 94 17:47:00 Subject: Need recommendations UpdReq -=> Quoting David Chessler@1:109/459 to Shawn Mcmahon <=- DC> On 10-01-94 (21:00), Shawn Mcmahon, in a message to David Chessler DC> about "NEED RECOMMENDATIONS", stated the following: SM> DC> Then you must use SFS which won't let him use a weak passphrase. SM>That was a major part of my decision, yes. Depends upon your definition >of "weak" but it darn sure won't let him use as weak a password as he >wanted to. He grumbled, but I gave him the "I can refer you to a DC> 10 characters, minimum. There are some unix logon password programs DC> that require a digit or punctuation mark (but enforce only about 4 or 6 DC> characters). Gutmann should install similar code. But even mixed DC> case helps a lot, since you can't tell whether you are one bit from the DC> correct password or completely wrong. DC> A 10 character password, if put two words, and especially if mixed DC> case, is not especially vulnerable to dictionary attack, though it can DC> be done. Oh really? "Not especially vulnerable?" Assuming we're talking about two words commonly selected from a group of 10,000, we're only talking about 100 million combinations. At a combination per millisecond you've found the solution in a day. ... Way Too Much is Not Nearly Enough. ___ Blue Wave/QWK v2.12 201434369420143436942014343694201434369420143436942014343694718 From: Jim Bell Area: Public Key Encryption To: DAVID CHESSLER 11 Oct 94 17:48:00 Subject: Rsa broken UpdReq -=> Quoting David Chessler@1:109/459 to Raymond Paquin <=- DC> We do know that key sizes should increase from time to time as brute DC> force attacks become more practical with increasing hardware speed, DC> with a limit of about 3100 bits, after which it is easier to attack the DC> Idea key. Even then, probably not. Remember, finding the IDEA key is only valuable for that particular message, not any others. Presumably, finding the public key is useful for far longer, in many other messages. DC> Factoring times are thought to double for every additional DC> 15 bits in the key. I thought the difficulty doubled for each extra 10 bits. DC> When PGP 3.0 comes out, we will all migrate to DC> larger keys. DC> There are more important weaknesses in PGP's algorithm for selecting DC> and validating primes. In particular, there are several classes of DC> numbers which PGP will accept as "probably prime" which are not. I've heard of one type, called "Carmichael numbers." What are the others? DC> This DC> is due to PGP's use of the Fermat test, rather than certain more recent DC> tests. According to messages on sci.crypt and alt.privacy.pgp, this DC> weakness in PGP will be corrected in version 3.0 Question: why can't they do a far more extensive test on the numbers? I mean, the program could issue a preliminary key, then request the user to run a program overnight that would do a far better job weeding out the non-primes. Presumably, this would only rarely generate a "hit" but it could be done when nobody is using the computer. If a weakness were discovered, the "worst" that would happen is that the key would be revoked, etc. Another question: Do these numbers REALLY have to be prime? Let's suppose I select a 1024-bit key, which is the product of two 512-bit numbers. One of those numbers is prime; the other is actually the product of two 256-bit numbers and thus it isn't prime. How much of a flaw is this, really? Admittedly, if you were somehow doing a brute force search you'd "only" have to check an average of (2**256)/4 combinations, rather than 2**512 combinations. Keep in mind that the adversary doesn't KNOW that the key is actually the product of three primes, rather than just two. I understand that factoring is far beyond brute force techniques: My question is whether this makes the overall key significantly less secure. In this case, by "significantly" I mean enough to actually make it likely that the key can be found with modern equipment and techniques. ... Way Too Much is Not Nearly Enough. ___ Blue Wave/QWK v2.12 201434369420143436942014343694201434369420143436942014343694718 From: Jim Bell Area: Public Key Encryption To: TONY BELDING 17 Oct 94 05:00:00 Subject: PGP & headers UpdReq -=> Quoting Tony Belding@1:3612/42.26 to All <=- TB> Suppose I am using PGP to encrypt LHA or ZIP compressed files. Those TB> files have a predictable header. Does this make the encryption less TB> secure? If so, to what degree? I thought of this many months ago. However, I am not familiar with the details of the operation of PGP (or public-key systems in general) to know for sure. The documentation for PGP states (implies?) that the compression would actually make the encryption more secure, because it would eliminate redundancies, but I think when that was written Zimmermann wasn't thinking about this header. The "worst-case" scenario would probably be if the exact same header was always used at the beginning of the file, longer than the encryption block size. In that case, decryptions could be done until the result matched the standard header. Admittedly, this would be impractical by a "brute -force" method, since the IDEA key in PGP is 128 bits. Even so, it would provide a quick test to determine if the proper key had been found. I would hope that Zimmermann did something to foil such an attack; he probably did. ... The rest of this tagline is encryp*&l#1E0+=|>fcd}85^7@jowxz*7"[=- ___ Blue Wave/QWK v2.12 201434369420143436942014343694201434369420143436942014343694718 From: Rob Kowalski Area: Public Key Encryption To: All 18 Oct 94 11:37:10 Subject: Early Public Key Cryptogr UpdReq @SUBJECT:Early Public Key Cryptography N I am doing research on the history of public key cryptography and would like to find early publications and uses of public key cryptography to protect and/or authenticate executable computer programs. Any clues? *---------------------------------------------* rkowalsk@gmuvax.gmu.edu (Rob Kowalski) George Mason University - Fairfax, Virginia *---------------------------------------------* 201434369420143436942014343694201434369420143436942014343694718