- cypherpunks-legacy@lists.ogf.org

Re: Free Electronic Cash
by Duncan Frissell 29 Aug '93

29 Aug '93

To: cypherpunks(a)toad.com T >> Michael Elansky Defense Fund T >> 25 Maiden Lane T >> West Hartford, CT 06117 T > T >I just sent $10 cash to them. Better them than the corrupt EFF which T >has been accepting kickbacks/bribes from AT&T and Pac Bell. Speaking T >of which, has anyone bothered to contact the EFF/CPSR/ACLU about this T >case? It seems like a perfect 1st Ammendment issue, and I would T >personally love to see the pigs who raided Mr. Elansky lose their jobs T > because of these outrageous civil rights violations. They have been in contact with the EFF and received some moral support but they mostly have to depend on their own resources. I did determine that the BBS was not siezed, BTW. It was missing when the Geheime Staats Polizei arrived. Duncan Frissell (Net Prime - 01000001st Fiberborne) "A Machine Age army can no more defeat an Information Age army than a Muscle Age army can defeat a Machine Age army." Join in the fun as Slick Willie and the other spearcarriers of the New World Order charge the machine guns of the Info Army. Cyberspace Wants You. Join the 01000001st Fiberborne - recruiting depot open at this address. Phase One guerilla operations have already begun... --- ~ WinQwk 2.0b#0 ~ Unregistered Evaluation Copy

1 0

Free Electronic Cash
by Duncan Frissell 29 Aug '93

29 Aug '93

To: cypherpunks(a)toad.com Be the first on your block to spend some electronic "near" cash. If you are the first to read this post, you may be able to use up to $5 of electronic pseudo-cash. I wanted to be the first to post some so it was worth $5 to me. Yesterday I bought a Western Union Phone Card (tm) from my nearest Western Union money transfer agent. It is good for about 8 minutes of phone calls anywhere in the continental US (fewer minutes of international calls). To use the "cash:" Call 1 (800) 374-8686 Wait for the tone Dial the code 428 22 601 When you get a dial tone, dial the (area code) + phone-number of the number you wish to reach. The system will tell you how many minutes you have available for the call. Western Union Phone Cards (tm) are available from any agent in $5, $10, $20, and $50 denominations. They can be (must be) purchased for cash. I have no idea whether Western Union saves the ANI info of incoming calls and cross indexes it with the outgoing number and the "account" number. All that I ask is that the user(s) of this card send me email (anonymously if you like) so I can send back privacy consulting solicitations. Duncan Frissell Michael Elansky Defense Fund 25 Maiden Lane West Hartford, CT 06117 --- ~ WinQwk 2.0b#0 ~ Unregistered Evaluation Copy

3 2

Re: AT&T Home Security Plus
by doug＠netcom.com 29 Aug '93

29 Aug '93

"George A. Gleason" <gg(a)well.sf.ca.us> said: >Cross-list directories: having served as a key witness against a very deadly >local stalker here, I have taken great pains to let PacBell know that my >service address is not to be released in any form for any reason; I've gone >over this with service reps every single year at directory-compiling season. Yes, unfortunately there are institutions that are obnoxious about this. Here's an innocent anecdote that shows how bad things can be. Last year I got to know a woman via her nome de plume on a mud. She was highly privacy-conscious, to the point where she told no one there anything about her real life (this is common on many muds, but not on that particular one). We'd had a bunch of heart-to-heart's, and since I'm a smart ass, at one point I called her up. Since she hadn't told me her real name nor what city she was in, let alone given me her phone number, she naturally wanted to know how I'd managed this. (I underscore that this was innocent; we talked for 6 hours that time and she recently visited me while passing through the area where I live, which is to say that she wasn't bent out of shape by my doing the above.) Anyway the scary part is that her university lists both *residence* phone and address for all students in their phone directory services. She said that she had tried to get unlisted but that university policy *forbade* that, so she was stuck with being listed. (Yes, this is a U.S. university.) That's the sort of policy that ought to be prevented by law. Even non-deadly stalkers can be a serious nuisance. Doug

1 0

Re: Examination of ViaCrypt's PGP by members of this group
by smb＠research.att.com 29 Aug '93

29 Aug '93

A group of even the most competent reviewers can overlook some problems in the code. It may take a long time before a flaw is discovered. The stamp of approval by some members of this list to a commercial PGP with a secret source code would therefore be little more than a marketing scheme. It would be no different from the expert review marketing scheme used to sell us Clipper, as --I think it was John Gillmore-- has recently explained. No, there is an important difference: you'd be starting from known- good source. That might make the task feasible. That doesn't mean it's easy, of course. A fair number of years ago, I participated in a review of some code which had been developed, in part, by someone who was later convicted of assorted {h,cr,chr}acking- related offenses. There was far too much source code to check it all; however, we knew when this person had first had access, so we could use diff on many modules. That tremendously reduced the scope of the effort. We did find one curious construct -- a combination of two bugs that together constituted a security hole. Either alone was harmless. And to this day, I don't know if they were inserted deliberately.

2 1

Examination of ViaCrypt's PGP by members of this group
by mbriceno＠aol.com 29 Aug '93

29 Aug '93

A number of posts have proposed that perhaps some of the more astute members of this list should be allowed by ViaCryp to examine the source of the commercial PGP. The idea is that if some of the people we are likely to trust give their O.K. to the code then we can all go out and buy the program without fear of hidden back doors. Unfortunately this proposal has the same fundamental flaws that the recent review of the Clipper chip by Denning et al had. A group of even the most competent reviewers can overlook some problems in the code. It may take a long time before a flaw is discovered. The stamp of approval by some members of this list to a commercial PGP with a secret source code would therefore be little more than a marketing scheme. It would be no different from the expert review marketing scheme used to sell us Clipper, as --I think it was John Gillmore-- has recently explained. ---Marc

1 0

Re: AT&T Home Security Plus
by George A. Gleason 29 Aug '93

29 Aug '93

Re Doug's response to my item on this topic: please don't get the idea that I thought AT&T were going after *me* for any reason, or trying to trap hackers deliberately, or anything like that. I may be dumb but I'm not one of those raving paranoids who assumes that everything that happens means someone is out to get me....! Nor did I mean to suggest that AT&T would actually have a backdoor in their home security systems. I was using that point as a cynical joke with the dude who called me. It was *not* intended to be serious. It *was* intended to make a sarcastic poke at Clipper. Cross-list directories: having served as a key witness against a very deadly local stalker here, I have taken great pains to let PacBell know that my service address is not to be released in any form for any reason; I've gone over this with service reps every single year at directory-compiling season. What I would really like to do is force the issue legally, i.e. serve them with some kind of court order or something, which would bar them from releasing that information. Anyway, enough for now... -gg

1 0

Re: Total RSA in PGP
by collins＠newton.apple.com 29 Aug '93

29 Aug '93

>Am I mistaken in believing RSA is more secure than the present hybrid? .....SHORT ANSWER..... You are mistaken. .....MEDIUM ANSWER..... You are mistaken not because the statement 'RSA is more secure than the present hybrid' is false, but because it is a mistake to put your belief in this statement, which has not been proved true. RSA alone would represent a great increase in computational effort, without risk of a decrease in security, after which you couldn't prove you were any better off (though, in practice, against currently known attacks, and with a large key, you might be). .....LONG ANSWER..... RSA alone is no _less_ secure than the PGP's combination of RSA and IDEA: if you can break RSA, you can extract the IDEA key and decipher the message; if you can break IDEA, you don't need the key. I am guessing that you share a widely echoed predjudice that public-key ciphers are better than secret-key ciphers (I apologize if I have mis-labeled you :). Public-key ciphers have gained a reputation for being more secure, as a class, than secret-key ciphers. Perhaps because public-key ciphers afford 'better' key management, the world at large has gotten the impression that they provide 'better' security. Public-key ciphers as a class are _not_ more secure than secret-key ciphers. One counter example, which periodically rears its ugly head here, is the (truly random) one-time-pad. This secret-key cipher offers perfect security in the Shannon sense. No public-key cipher can make that claim. To prove RSA _more_ secure than the hybrid, RSA must be proved more secure than IDEA. Unfortunately, we don't really know how secure the RSA algorithm is (or IDEA, for that matter). It is known that RSA is no _more_ secure than factoring a component of the public key (readily available to an attacker). To my knowledge, it has not been proved that either a) RSA is at least this secure; or b) factoring is hard. Despite a paucity of formal proof, I know of know better attack on a message enciphered with well chosen keys than factoring, which both man and machine currently find taxing. RSA with well chosen keys is 'empirically' computationally secure. While IDEA has been designed specifically to resist differential cryptanalysis (thanks to those who pointed me to the IDEA papers explaining this), more formal proof of its security awaits further understanding of the information theory aspects of its foundation: mixing operations from incompatible groups. In the end, IDEA is also 'empirically' computationally secure. I know of no comparisons of the security offered by RSA and IDEA against practical attacks. .....FINAL ANSWER..... In theory: theory is as good as practice; but in practice... it isn't. Hope this helps, 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

Total RSA in PGP
by Network Demon 29 Aug '93

29 Aug '93

Is it possible to use RSA all the way through a PGP encrypted message (do not use IDEA)? If so, how? I know it would take a LONG time, but it would make for a nice option. If not, why? Although, it might take "forever", why not make it an option for those willing to wait? Am I mistaken in believing RSA is more secure than the present hybrid? Thanx, --demon

2 1

Re: Commercial PGP; trapdoor rumors
by an31185＠anon.penet.fi 28 Aug '93

28 Aug '93

In message <01H2813M8J6090MZGB(a)delphi.com> Mike Ingle said: >If there is any flaw in PGP, there are only a few places where it >could be. The basic mechanics of the program (RSA, IDEA, etc) obviously >work. I'll agree with you there, or at the least, if they don't work I'm not likely to be able to prove it. I also very much doubt that there's really a 'trapdoor' to deliberately make decryption easy, but there's plenty of scope for a bug or unwarranted assumption to do so by accident. (Look at WordPerfect 5.1 encryption, for a good example). >The file format can easily be checked to make sure it is correct. >A subtle flaw would have to be somewhere like: prime number generation, >random RSA key generation, or random session key generation. If the primes >weren't actually prime, that would make the RSA keys breakable. But >you could take the primes (pgp -kg -l and you will see them in hex) >and feed them into a primality tester to verify that. With regard to the file format, I've just been looking at that, I hacked a test copy of PGP 2.3a to dump out the plaintext that it would normally idea-encrypt to a file, and encrypted a selection of files with a selection of keys to look for known plaintext, then went back into the source code to track down where it came from. The first twelve bytes of the data that gets idea-encrypted contain two bytes of known plaintext, and two repeated bytes. The actual contents are: bytes 1-8: Randomly generated prefix bytes 9-10: Repeat of bytes 7 and 8 (key check bytes) bytes 11-12: ALWAYS 0xA3 and 0x01 !!!! The repeated bytes come from idea_file() in crypto.c, and are used to verify that you got the correct key to decrypt the file. The known bytes come from squish_and_idea_file() in the same file, and verify that the input contains compressed data and that it's zipped. Now, I don't know enough about idea encryption to know how much this would help to break the code, but it still seems to me that much of this does not need to be here. Anyone got any suggestions ? (I'd guess you could at least move the repeated bytes to the end of the file ?). It's definitely a weak point, as a brute-force attack would only need to decrypt 12 bytes to verify (or almost verify ?) a correct idea key, though whether that *greatly* reduces the security, I don't know. I realise that the random bytes are supposed in part to protect you from this, however, I don't see any point in reducing the security of the data if you don't have to. >The most likely place for a bug would be in the randomness. I suppose >it is possible that a one-line bug somewhere could leave out most of >the randomness, making the keys still look random but actually be >predictable. Random number generation is hard to verify. How has >that in PGP been checked? The PGP source is so big and spread out, >it's hard to check. I don't think there is a bug, but it would >be nice if PGP were carefully examined and attacked. Where are these >rumors coming from? They are bad for the cause. Randomness is the next thing I'm going to look at. From the output I've produced, I can't say I'm greatly impressed by the randomness of the random prefix bytes, though that's probably a result of looking at such a small sample. Tomorrow, hopefully, I'll set a program running to generate a few hundred thousand PGP random numbers and look at what comes out. Obviously, I can look at the frequency of different byte values, both overall and in each of the bytes it produces, but does anyone know of any other simple 'randomness' tests for 16-byte random numbers ? ------------------------------------------------------------------------- To find out more about the anon service, send mail to help(a)anon.penet.fi. Due to the double-blind, any mail replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. Please report any problems, inappropriate use etc. to admin(a)anon.penet.fi.

1 0

USENET and US-legal PGP (signing only?)
by Clifford A Adams 28 Aug '93

28 Aug '93

Hello again! Has there been any progress on a USA-legal PGP? Are negotiations still in progress or are they stalled? I am willing to write code (up to a few thousand lines of C) to help integrate PGP with USENET newsreaders. (I have a little PGP/RIPEM signature verification fuction now, and a section called "Digital signatures, cryptograpy, and USENET" in the online documentation.) I am waiting for a US-legal version of PGP before coding further. I think that USENET provides a wonderful environment for public key crypto applications. My particular interest is in digital signatures for forgery protection. One use of this is in collaborative message filters where people can rate or add keywords to other messages. I would like for all of this to be updated semi-automagically, using usual (insecure!) USENET postings. Greater numbers of strong-crypto users should also help in the political arena. Many people don't see why the current cryptograpy battles are important, because they don't care very much about strong privacy. An easy-to-use cryptosystem integrated into their ordinary tools like newsreaders and mailers will get some of these people involved. For instance, imagine these interactions: ----- start examples ----- [While reading news, the user types 'r' to reply to a message] The poster included a PGP encryption key, and will accept encrypted replies. Encrypt your reply? [nyh] === [User posts a message] PGP key found. Sign this posting? [yn] [User types 'y'] Signing posting using PGP key. Enter your passphrase: [...] === [User posts a message] Digital signature not found. Would you like to generate a digital signature? (type 'h' for help) [nyh] [user types 'h'] A digital signature allows other people to have some confidence that your postings are really from you, and not a forgery. ...[more explanation of digital signatures, about 10-15 lines]... Generating a digital signature usually takes between 5-15 minutes. You will only have to do this once. Would you like to generate a digital signature? (type 'h' for help) [nyh] [user types y] PGP found. RIPEM not found. Generating digital signature using PGP... [Nice, friendly key generation process.] ----- end examples ----- Finally, would it be possible to release a US-legal/RSAREF *subset* of PGP which allows only signatures and signature verification? To my knowledge this wouldn't require violating the RSAREF interface. (My understanding is that the interface problem is that PGP uses IDEA rather than DES for message encryption. The signature is simply an RSA-encrypted hash of the message--this could be handled by the RSAREF package. Correct?) --Cliff -- Clifford A. Adams caadams(a)polaris.unm.edu | USENET Interface Project: 457 Ash St. NE Albuquerque, NM 87106 | Tools for advanced newsreading STRN (Scan TRN) now in testing: trn 3.3 plus flexible newsgroup menus, fast article scoring with score ordered display, and merged/virtual newsgroups.

1 0