- cypherpunks-legacy - lists.cpunks.org

Re: Real-time BBS Encryption??
by mark＠coombs.anu.edu.au 07 Apr '93

07 Apr '93

>What about a streams module that does encryption? Of course, it'd >require people to run a real OS instead of dos/system... You might want to look at the link.tar.Z program newsham(a)wiliki.eng.hawaii.edu wrote. THe server is currently unix based but it should be transportable. It uses pgp to swap des session key and happily talks away. There are still some bugs and when he has the time they will be taken care of. The client is written for an amiga at the moment, I havent had the opportunity to do the ibm port yet. Contact him at the above address. He is busy with studies but you might get some joy from emailing him. Hope this helps Mark mark(a)coombs.anu.edu.au

1 0

PGP: suggestions from the trench
by grady＠netcom.com 07 Apr '93

07 Apr '93

After carefully reading RSA.COM's FAQ (version 1.0 draft 1e [14 Sep 1992] by Paul Fahn; available via anonymous ftp from RSA.COM) I have some comments about the various PGP implementations. First of all: well done! These implementations and ports have taken a lot of unremunerated work from a lot of people. If you compare the number of people registering public keys on the PGP servers such as pgp-public-keys(a)toxicwaste.mit.edu to the number registering for the RIPEM versions licensed by RSA/PK partners, for example, found on rpub.cl.msu.edu, PGP enjoys an order of magnitude more popularity. So regardless of the outcome of legal, support, standards and interoperability issues, the PGP experiment has already been a tremendous success in letting us common folk learn about effective and convenient public key encryption. One of the great advantages of a popular application is the great number of fingers and eyes that can be used to detect and document problems to make PGP even a greater success. Here are the thoughts of one user: 1. PGP RSA bit lengths are too short. According to RSA's FAQ, the US Government (NSA) does not consider export licenses for RSA moduli used for privacy greater than 512 bits [section 2.23]. This may imply something about NSA's capability in attacking RSA systems with fewer than 512 bits of modulus; Ron Rivest, a co- inventor of RSA, estimates the cost of factoring a 512-bit modulus *today* at $8.2 million dollars (much less of course in the future) [section 2.8]. Although it is true that the time to generate a new RSA key goes as the order of 16 times the modulus length, this is only done once or a very few times. Encryption and signature verification time on the other hand goes only as the order of four time the modulus length [section 2.8]. And the faster computers of tomorrow will virtually eliminate this performance penalty compared to the vastly increased time required for a factoring attack on RSA moduli that increasing its size entails. Taking all these factors into consideration, I would suggest that the *minimum* size of the RSA modulus available for PGP is 1024 bits with a minimum ceiling of 2048 bits (or even more). If for performance reasons on certain platforms 1024 is deemed impossibly slow, then a lesser number of bits ought to be permitted *provided* that the security level for any key length under, say, 768 bits is clearly labeled "TOY GRADE". And because factoring security is a moving target with increases in computer speed and factoring methods, rather than the static (and rather melodramatic) labels of "commercial grade," military grade", and so on, the labels ought to be specific years that intelligent estimates (such as Ron Rivest's) that that size modulus will be factored by a determined opponent. For example, 512 bits should be labeled "1992", 768 bits labeled "2005", 1024 bits labeled "2020", and so on, using an estimate of about 15-20 bits a year of modulus degradation. This also supplies a clue as to selecting intelligent public key expirations given individual security goals. While this may seem too conservative, consider that many public moduli kept by a certifying authority may be attacked in parallel, similar to cracking a passwd file NOT using a salt. We must be *absolutely sure* that the theoretical basis of the encryption function is the paramount consideration in PGP. 2. The hash function generates too short a digest. In section 6.3 of the RSA FAQ, RSA recommends MD5 with its 128 bit digest when using 512 bit or shorter RSA keys. This is because they estimate the work factor of breaking a 128 bit digest is on the order of 2^64 operations or roughly equivalent today to factoring 512 bit numbers. If PGP increases the minimum recommended modulus size but does not simultaneously increase the hash digest size, then attacks such as "guessed plaintext," where guesses are made as to the IDEA key being encrypted under RSA are made compared to a trial RSA encryption, will become more and more attractive. The RSA FAQ recommends using the SHS (Secure Hash Standard) [available from csrc.nist.gov] which generates a 160 bit digest or a modified MD4 algorithm that produces a 256 bit digest. In any event, the 128 bit IDEA key to be encrypted under RSA ought to at the very least have a 64 or 128 bit random salt (that will later be discarded) appended before RSA encryption to thwart the "guessed plaintext" attack on RSA. According to the RSA FAQ, MD4 and MD5 are available for unrestricted use via RSA.COM or ftp.nisc.sri.com as rfc1320 (MD4) and rfc1321 (MD5). 3. Triply encrypted DES with CBC ought to be another "conventional encryption" option under PGP menus. RSA FAQ cites Campbell and Wiener's "Proof that DES is not a group" (Advances in Cryptology - Crypto '92 Springer-Verlag, New York 1993, To appear) that proves that DES with multiple encryption does indeed spread the encryption mapping over a broader space and thus presumably increases the work factor to direct cryptanalysis. IDEA, while attractive in speed, size and theory, has no such group-free proof and has not long withstood the public scrutiny that DES has endured. Three 56 bit keys could easily be derived from a single MD4 256 bit digest (with an additional 64 bits of Initializing Vector, to boot) to double the brute-force key guessing DES work factor to roughly 112 bits. A slightly non- standard version such as Outerbridge/Lau/Gillogly/Karn's newdes, which is provably at *least* as secure as plain DES, might be used in order to thwart dedicated DES hardware attacks. 4. Add a "enter random seed" option in addition to keystroke timing. It is suspected that the timing biases in keystroke timing is far more pronounced than rolls of an ordinary die, especially over the broad range of platforms that PGP has been ported to. A useful option to make user rest easier about the amount of bias in the random seeding for the search for the public-key RSA modulus and the generation of conventional (IDEA and triple-DES keys) would be to permit the direct data entry of fifty or sixty rolls of a die to further disperse the original seed. Given the difficulty of obtaining noisy diodes or sources counting radioactive decay, rolling dice is probably the easiest and comparatively least biased of ways of selecting random seeds [see Knuth v.2] *and* is under the direct personal control of the user. 5. Offer a "use strong primes" option in RSA key generation. While it is true that as it is said in the RSA FAQ [section 2.7] and the PGP documentation that "strong primes" may not now be necessary given the non-favoritism of ECM ("elliptic curve method") of factoring (Lenstra: Factoring integers with elliptic curves. Annals of Mathematics 126:649-673, 1987), there is only the one-time penalty of selecting "strong" primes in public key generation and, as the RSA FAQ suggests, future breakthroughs in factoring technique may very well once again favor the "strong" prime over the garden variety one. 6. Probably my most urgent recommendation: I use MacPGP 2.2 and it did not come with a) a source b) a digitally-signed archive or c) a pointer to send bug reports. Without these features it is very hard to make specific implementation bug reports or interface improvement suggestions. As the RSA FAQ says in section 2.6: "In practice, most successful attacks will likely be aimed at insecure implementations and at the key management stages of an RSA system." Please, please include the source to the Mac version (or upon request), or at least an object map so I can effectively disassemble and test portions of the code. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.2 mQCOAiumM0QAAAED+JPD8OULO2aXRvU2FDksMjJeGT96kGK5eJK1grkXuIHz+6pe jiedYOv72kBQoquycun191Ku4wsWVTz6ox/bpReBs5414OTPzQVJgWQzCW1N4BfV Wr4eEn3qnFsVLXXxk3oYGydIeJcmelSyuPSq/Oq7Q+eHkKgjqxDTjVMu8iEAEQEA AbABh7QuR3JhZHkgV2FyZCAgPGdyYWR5QG5ldGNvbS5jb20+ICAoNzA3KSA4MjYt NzcxNbABAw== =e3rN -----END PGP PUBLIC KEY BLOCK----- Comments appreciated. Grady Ward grady(a)netcom.com

2 1

well
by trump＠pluto.ee.cua.edu 07 Apr '93

07 Apr '93

if anyone comes up with a solution to the bbs encryption problem then get to me ... i plan on starting a Waffle based BBS that may have "sensitive" information on line in subs and in files... you all know the story... well if i could have this encryption feature i would be most happy... i have looked into this a bit but to my suprise it has comeup on the list... as for the problem of d distribution of the program the would encryp and decrypt via modem and bbs, i have that pretty much taken care of already... thanks Clovi /s ^ been bbsing for too long

1 0

April 10 meeting
by Eric Hughes 07 Apr '93

07 Apr '93

Last month at Cypherpunks West, we decided that meetings would be held monthly on the second Saturday. So, for any of you planning to be in the area any time, keep this in mind. The April meeting for Cypherpunks West will be April 10, 1993. There was some delay getting this announcement out because our normal meeting sponsor, John Gilmore, will be out of town. Mike Werner, also of Cygnus, will be sponsoring our meeting at the same location, so there's no need to change plans. Thanks, Mike! ANNOUNCEMENT Cypherpunks West April Meeting Saturday, April 10, 1993 12:00 noon - 6:00 pm PDT Cygnus Support Offices, Mt. View (directions follow) Contact Mike Werner for physicalities: mtw(a)cygnus.com, 415-903-1421. AGENDA Arthur Abraham on hash functions Mail services (works in progress) Secure phones (updates) Other stuff as announced If you have anything you want to talk about, send me mail: hughes(a)soda.berkeley.edu DIRECTIONS Cygnus Support 1937 Landings Drive Mt. View, CA 94043 +1 415 903 1400 switchboard +1 415 903 1418 John Gilmore (out of town, see note above) Take US 101 toward Mt. View. From San Francisco, it's about a 40-minute drive. Get off at the Rengstorff Ave/Amphitheatre Parkway exit. If you were heading south on 101, you curve around to the right, cross over the freeway, and get to a stoplight. If you were heading north on 101, you just come right off the exit to the stoplight. The light is the intersection of Amphitheatre and Charleston Rd. Take a right on Charleston; there's a right-turn-only lane. Follow Charleston for a short distance. You'll pass the Metaphor/Kaleida buildings on the right. At a clump of palm trees and a "Landmark Deli" sign, take a right into Landings Drive. At the end of the road, turn left into the complex with the big concrete "Landmark" sign. Follow the road past the deli til you are in front of the clock tower that rises out of one of the buildings, facing you. Enter through the doors immediately under the clock tower. They'll be open between noon and 1PM at least. (See below if you're late.) Once inside, take the stairs up, immediately to your right. At the top of the stairs, turn right past the treetops, and we'll be in 1937 on your left. The door is marked "Cygnus". If you are late and the door under the clock tower is locked, you can walk to the deli (which will be around the building on your left, as you face the door). Go through the gate in the fence to the right of the deli, and into the back lawns between the complex and the farm behind it. Walk forward and right around the buildings until you see a satellite dish in the lawn. Go up the stairs next to the dish, which are the back stairs into the Cygnus office space. We'll prop the door (or you can bang on it if we forget). Or, you can find the guard who's wandering around the complex, who knows there's a meeting happening and will let you in. They can be beeped at 965 5250, though you'll have trouble finding a phone. Don't forget to eat first, or bring food at noon! I recommend hitting the burrito place on Rengstorff (La Costen~a) at about 11:45. To get there, when you get off 101, take Rengstorff (toward the hills) rather than Amphitheatre (toward the bay). Follow it about ten blocks until the major intersection at Middlefield Road. La Costen~a is the store on your left at the corner. You can turn left into the narrow lane behind the store, which leads to a parking lot, and enter by the front door, which faces the intersection. To get to the meeting from there, just retrace your route on Rengstorff, go straight over the freeway, and turn right at the stoplight onto Charleston; see above. See you there! John Gilmore

1 0

Re: WB: public kiosks
by karn＠qualcomm.com 07 Apr '93

07 Apr '93

>Public kiosks are OK as a simple and moderately effective technique for >assuring anonymity, and they're ideal for a security-naive person who >is unable to verify the security of a more complex system. But for >my own use, I am much more confident in the security guarantee given by >encryption on a portable computer and anonymizing using Chaum-style >remailers... Indeed. By definition, a public kiosk is in a public area, with open access to all including the Bad Guy's agents and investigators. And tracking people's physical movements in public places is an art that investigators have had many years to refine and perfect. Many more than, say, factoring large RSA public keys... Phil

2 1

Re: PHRACK: Article from PHRACK 42 on encryption
by Perry E. Metzger 07 Apr '93

07 Apr '93

Douglas Mason says: > > > > >> Exposing factual errors and flaws in reasoning is left as an exercise > > >> for the reader. > > > >The flaws are big enough to drive a bakery truck through. Its trash. > > > maybe you should do a better writeup and publish it in PHRACK or 2600? > > I agree. Anyone can sit and say "Oh, that article is a piece of crap", but > these same people never put their "money where their mouth is" and write an > article of their own. > > I've written for both Phrack and 2600 and it sure as hell isn't hard to get > something submitted. If you think you can do better by all means write an > article and send it in. If trash is being published, why not try to correct > it? Because I lack an interest in doing so? Anyway, there is no need, as the PGP manual is very good and actually explains things properly. Lots of fine articles have already been written on all sorts of cryptography subjects. > If you have any problems with where to send it, I'll gladly forward you the > address. > > Otherwise, shut the hell up. Why should I? The article WAS crap. > If you don't like your goverment, vote. I'm an anarchist. You might as well say to an atheist "if you don't like Catholicism, start a schism." Perry

1 0

ANON: list of remailers Apr 7, 1993
by Karl Barrus 07 Apr '93

07 Apr '93

Sorry this is late, but I was delaying waiting for the uclink remailer's public key to be released, plus, I'm still not getting responses from remailer(a)dis.org (but at least I'm not getting bounced mail). Some users have informed me that they were able to use remailer(a)dis.org, so that's good! -----BEGIN PGP SIGNED MESSAGE----- Q1: What cypherpunk remailers exist? A1: 1: hh(a)pmantis.berkeley.edu 2: hh(a)cicada.berkeley.edu 3: hh(a)soda.berkeley.edu 4: nowhere(a)bsu-cs.bsu.edu 5: ebrandt(a)jarthur.claremont.edu 6: hal(a)alumni.caltech.edu 7: remailer(a)rebma.mn.org 8: elee7h5(a)rosebud.ee.uh.edu 9: phantom(a)mead.u.washington.edu 10: hfinney(a)shell.portal.com 11: remailer(a)utter.dis.org 12: 00x(a)uclink.berkeley.edu 13: remail(a)extropia.wimsey.com NOTES: #1-#5 remail only, no encryption of headers #6-#12 support encrypted headers #13 special - header and message must be encrypted together #7,#13 introduce larger than average delay #11 CANNOT CONFIRM OPERATION YET! TEST BEFORE ATTEMPTING TO USE. * #12 public key not yet released ====================================================================== Q2: What help is available? A2: Check out the pub/cypherpunks directory at soda.berkeley.edu (128.32.149.19). Instructions on how to use the remailers are in the remailer directory, along with some unix scripts and dos batch files. Mail to me (elee9sf(a)menudo.uh.edu) for further help and/or questions. ====================================================================== * I've had others tell me that they have successfully used this remailer, but I still don't get any responses...will keep trying! -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBK8MS/YOA7OpLWtYzAQGgvwQAll6hwIfabxKGdtCSNPUa3M3RCBaqzPT2 VM+k8O94IVxAqX+RUMzRGUVJigrj+5XcNicX1ZvE61rh5InLbzqvUS8mQNbss6wr b098F0uHyCQCKCF13lzkLU0Gu+HxE+LoBuhaTiwonvcbQYgH+2+lhoU9yAbfduIq 9Syr3gaf3fk= =W8vL -----END PGP SIGNATURE-----

1 0

Remailers
by sean＠gomez.Jpl.Nasa.Gov 07 Apr '93

07 Apr '93

Would someone be so good as to mail me the list of anonymous remailers? My copy was lost in a backup-restore cycle. Thanks.

1 0

Smaller is better.
by fergp＠sytex.com 07 Apr '93

07 Apr '93

On Mon, 05 Apr 93 12:36:09 PST, Jonathan Stigelman <uunet!transam.ece.cmu.edu!stig> writes - JS> Yeah.... So if your key can be snooped off the net, so can your JS> cleartext. To decript online, then, is akin to using only weak JS> encription...which indicates only the desire for limited privacy. JS> But if even if you do decript online, you're still protected from JS> file snooping. JS> What's needed is PGP decription built into your terminal program. I think that you guys are missing the point here. IMHO, if you wish maximum assurance of security, than I'd suggest not trying to run programs such as PGP on a multi-user system to begin with! What's wrong with using a PC for this? It offfers a maximum convenience, single-user secure system quite unlike the security problems associated with your university's mainframe. The PC offers the communications availability and the flexibilty to provide an extremely high level of privacy, if you know what you're doing. You should try it sometime .... Cheers. Paul Ferguson | "Sincerity is fine, but it's no Network Integration Consultant | excuse for stupidity." Centreville, Virginia USA | -- Anonymous fergp(a)sytex.com (Internet) | sytex.com!fergp (UUNet) | 1:109/229 (FidoNet) | PGP 2.2 public encryption key available upon request.

3 2

PHRACK: my draft reply to the crypt article
by robichau＠lambda.msfc.nasa.gov 07 Apr '93

07 Apr '93

Attached is a short rebuttal or reply to the PHRACK article I posted last week. I'd appreciate comments and suggestions on how to improve it- my knowledge is far behind Marc, Tim, Perry, and many of the others on this list. So, I got off my butt. Hopefully this will satisfy Doug :) -Paul My background: I've been into the scene for about 12 years. My day job is writing unix s/w for a NASA contractor. My night job... well, never mind that. I have a strong amateur interest in crypto, and I'd like to share some of what people in the usenet/internet community have been kind enough to teach me. Racketeer sez: > If you think that the world of the Hackers is deeply shrouded with >extreme prejudice, I bet you can't wait to talk with crypto-analysts. These >people are traditionally the biggest bunch of holes I've ever laid eyes on. In >their mind, people have been debating the concepts of encryption since the >dawn of time, and if you come up with a totally new method of data encryption, > -YOU ARE INSULTING EVERYONE WHO HAS EVER DONE ENCRYPTION-, mostly by saying >"Oh, I just came up with this idea for an encryption which might be the best >one yet" when people have dedicated all their lives to designing and breaking >encryption techniques -- so what makes you think you're so fucking bright? One real reason for this reaction is that people _have_ been studying encryption for 100 years or so. As a result, many simple cryptosystems are continuallly being reinvented by people who haven't ever made even a simple study of cryptosystems. Imagine if someone came up to you and said "Wow! I just found a totally K00L way to send fake mail! It's radical! No one's ever thought of it before!" You'd laugh, right? _Anyone_ can figure out how to forge mail. Well, _anyone_ can come up with the n-th variation of the Vigniere or substitution cipher. An even more important reason for their 'tude is that cypherpunks are suspicious by nature. A key principle of crypto is that you can only trust algorithms that have been made public and thoroughly picked over. Without that public scrutiny, how can you trust it? The feds' Digital Signature Standard (DSS) got raked in the crypto and industry press because the feds wouldn't disclose details of the algorithm. "How do we know it's secure?" the cypherpunks asked. "We won't use it if we don't know it's secure!" Point being: (for those of you who skipped over) cypherpunks trust NO ONE when the subject is encryption algorithms. Maybe J. Random Hacker has come up with a scheme faster and more secure than, say, RSA. If JRH won't share the details, no one will use it. Racketeer goes on to talk about DES. It's fairly clear that for a known-ciphertext attack (i.e. you have a block of encoded text, but neither the key nor the plaintext) will, at worst, require 2^56 decryption attempts. Various schemes for parallel machines and so forth have been posted in sci.crypt. Does the NSA have something that can crack DES? Probably. My claim would be that cracking passwords is (at minimum) order-of-magnitude faster than a known-ciphertext attack against a "typically secure" ciphertext. By typically secure, I mean one encrypted with DES in CBC mode (_not_ the more common and easier-to-implement ECB mode) using a strong key (not a password of "123", for example.) Remember that DES is mostly used for short-lived session keys. ATMs are a good example; they typically use a DES key for one communication session with the central bank. New session, new key. DES is _not_ very well suited for long-term encryption, since it can probably be attacked in "reasonable" time by a determined, well-equipped opponent. Now, on to PGP. Pretty Good Software was indeed threatened with a lawsuit by Public Key Partners (PKP). PKP holds the patent on the RSA public-key algorithm. (Many people, me included, don't think that the patent would stand up in court; so far, no one's tried.) The nice thing about PGP is that it offers IDEA and RSA in a single, well-integrated package. When you encrypt a file, PGP generates an IDEA session key, which is then encrypted with RSA. An opponent would have to either a) exhaustively search the entire IDEA key space or b) break RSA to decrypt the file without the password. Racketeer also mentions that PGP can optionally compress files before encryption. There's a solid crypto reason behind this, too. One well-known and successful way to attack an encrypted file is to look for patterns of repeated characters. Since the statistical frequencies of word and letter use in English (and many other languages; some folks have even compiled these statistics for Pascal & C!) are well-known, comparing the file contents with a statistical profile can give some insight into the file's contents. By compressing files before encrypting them, PGP is moving the redundancy out of the text and into the small dictionary of compression symbols. You'd still have to decrypt the file before you could do anything useful with that dictionary, or even to determine that it _had_ a signature! -- Paul Robichaux, KD4JZG | May explode if disposed of improperly. NTI Mission Software Development Div. | RIPEM key on request.

1 0