From pmetzger at shearson.com Sun Nov 1 13:03:32 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Sun, 1 Nov 92 13:03:32 PPE Subject: PGP vs RSA In-Reply-To: Message-ID: <9211011932.AA07699@newsu.shearson.com> >From: Jim McGrath >The other day someone mentioned that PGP uses a patented algorithm. If this >is the case, then what is the difference between using it and the also >patented RSA. From the little reading that I have done, it sounds like RSA is >a better protocol from the point of view of authentication etc. etc. PGP does use RSA. Obviously the "little reading" that you have done has been little indeed. >So, the question is, apart from the fact that PGP exists, and an RSA >implementation is not yet available, (to the best of my limited knowledge) >is there any reason why we shouldn't use it? There are dozens of RSA implementations available including PGP -- PGP is, however, the only widely available one with its code in the public domain. Perry From Tom.Jennings at f111.n125.z1.FIDONET.ORG Sun Nov 1 19:50:18 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Sun, 1 Nov 92 19:50:18 PPE Subject: Public image... Message-ID: <3410.2AF4969F@fidogate.FIDONET.ORG> Another crosspollination from PUBLIC_KEYS. Just something to think about. It refers to Keith Henson's article I ran in FidoNews (apparently the file was corrupted, but that's another story.) This is in no way to imply that the story is bad, nor that I didn't like it (I did), nor that this is even a common opinion. I actually received a few thanks for running it. It's just something to consider. And implies that Keith's article/story is doing it's job! A message from Tom Jennings to all was released into the bitstream 20 Oct 92 12:51. TJ> re: PUBLIC RELATIONS, hell, substance too -- TJ> If what we're doing here is ensuring PRIVACY, let's call it PRIVACY. TJ> Calling it encryption simply drops us into the same category as TJ> crackers and criminals. TJ> This isn't apologia; it's infowar. The "anti abortion" people calling TJ> themselves "pro life" is a good example (regardless of what you think TJ> of the subject, please, I don't want to know, not even in netmail!) TJ> Naming is powerful, especially when names have content. "PRIVACY" is TJ> age-old, and crosses all boundaries, and is inherently anti-statist. TJ> ENCRYPTION is cloak'n'dagger, late night movies, WWII, espionage, etc. Speaking of which, the story by Keith Henson in this week's FidoNews probably set us back ten years. Now data encryption's indelibly linked with saboteurs, criminals and terrorists. :-( Well, maybe not _everyone_ reads FidoNews... :-) Cheers, Rich -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings at f111.n125.z1.FIDONET.ORG From gg at well.sf.ca.us Mon Nov 2 03:48:32 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Mon, 2 Nov 92 03:48:32 PPE Subject: Privacy etc. Message-ID: <199211021047.AA04396@well.sf.ca.us> Definitely agreed with Tom's take on calling it "privacy" instead of "encryption." Connotations are entirely positive, tie in with modesty and domestic comfort and other nice things. Privacy and it's opposite: The following quote comes from the novel _We_ by Eugene Zamiatin, who wrote it in the USSR in the 20s only to see it banned and himself exiled to Paris. _We_ was also a primary source of inspiration for Orwell's _1984_, and is definitely worth reading. "Normally we live surrounded by transparent walls which seem to be knitted of sparkling air; we live beneath the eyes of everyone, always bathed in light. We have nothing to conceal from one another; besides, this mode of living makes the difficult and exalted task of the Guardians much easier. Without it many bad things might happen." Transparent walls with nothing to conceal. And of course, people who live in glass skyscrapers don't throw stones... -gg From SIVAI%FRSAC11.BITNET at pucc.Princeton.EDU Mon Nov 2 04:40:39 1992 From: SIVAI%FRSAC11.BITNET at pucc.Princeton.EDU (SIVAI%FRSAC11.BITNET at pucc.Princeton.EDU) Date: Mon, 2 Nov 92 04:40:39 PPE Subject: request Message-ID: <9211021140.AA19067@toad.com> Hello , I wish i knew the internet address , if any , to which one should ask so to subscribe to the 'sci.cryp' usenet's bb . I'd like to know either what cypherpunk stands for ? I'm interested in mathematical processing of datum ( well datas or datum....a key issue no doubt ) . Anyway i thank you in advance . Regards Louis Safer From tcmay at netcom.com Tue Nov 3 11:16:54 1992 From: tcmay at netcom.com (Timothy C. May) Date: Tue, 3 Nov 92 11:16:54 PPE Subject: Update on Crypto Session at Hackers Message-ID: <9211031813.AA14130@netcom2.netcom.com> Here's the semi-final information on the Crypto Session at Hackers this coming weekend: (Note: These inputs and volunteered talks came in over the past several days. There may be some changes of course. I'd like to see us get together---anybody who is reading this message---on FRIDAY NIGHT, in the refreshment room at MIDNIGHT, so we can plan, make any schedule changes, etc. This is of course up to you folks. I'll post a message somewhere prominent reminding you and listing time and location, if different from above.) * Time: Saturday afternoon, probably 3:00--4:30 (check the schedule!) (in an earlier update I mistakenly said we had only an hour) * Format: 7-10 minute talks by 4-5 people, followed by open discussion, questions, debate, etc. * Schedule: - Opening comments, groundrules, settling down, etc. (5-10 min), Tim May (I'll point people to a glossary posted on the wall and ask them not to interrupt the speakers with questions about the basics of crypto, such as whether DES has a trapdoor, etc.) - PGP, Fidonet, and Mail....Tom Jennings - Diffie-Hellman key exchange for rlogin, etc....John Gilmore - Anonymous remailers and DC-Nets....Eric Hughes - Digital time-stamping....either Stu Haber or W. Scott Stornetta - Open discussion, debate, etc. (45 minutes) I'll be the moderator, to keep folks to their time allotment. * If you have "poster" material, please bring it * We can also suggest that the discussion be continued later that evening, in one of the ad hoc sessions around midnight. Maybe some new topics can be be planned for a late night session. * Eric Hughes has suggested we stamp our badges with my red "CRYPTO" stamp, so that we can know ourselves (sort of a crypto oxymoron, eh?). See me and I'll stamp you, if you wish. Thanks for all of your excellent suggestions. I think this could be one of the best sessions at Hackers. --Tim May, 408-688-5409 -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at 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^756839 | PGP Public Key: awaiting Macintosh version. From norm at xanadu.com Tue Nov 3 12:37:42 1992 From: norm at xanadu.com (Norm Hardy) Date: Tue, 3 Nov 92 12:37:42 PPE Subject: another service Message-ID: <9211031859.AA01697@xanadu.xanadu.com> I think that there is an even easier time stamping service than that described by Eric Hollander. It too requires a trusted service with a trusted clock. It has just two key pairs, A and B. The protocol is that you send it a message, perhaps with payment under public-A. It returns the message joined with the time provided by its clock under key private-B. The returned message provides evidence in the future that you held the original message at the time indicated in the returned message. This protocol requires no data base of keys. It was once the practice (perhaps still) to mail oneself (US mail) a certified envelope with information that one might want to prove that he had had at some earlier date. One would then keep but not open the delivered envelope. From peb at well.sf.ca.us Tue Nov 3 13:16:52 1992 From: peb at well.sf.ca.us (Paul E Baclace) Date: Tue, 3 Nov 92 13:16:52 PPE Subject: Update on Crypto Session at Hackers Message-ID: <199211032014.AA11739@well.sf.ca.us> Sounds good--too short, of course, so it is going to be challenging to prevent digressions. The "Crypto" stamp sounds like a good way for people to follow up on details/questions after the session. Paul From MATTKELLY at ANTIOC.ANTIOCH.EDU Wed Nov 4 01:44:48 1992 From: MATTKELLY at ANTIOC.ANTIOCH.EDU (Matt_Kelly) Date: Wed, 4 Nov 92 01:44:48 PPE Subject: Please remove me from the list Message-ID: <01GQQN03LOTC00041P@ANTIOC.ANTIOCH.EDU> Please remove me from the cypherpunks distribution list. This is the second time I've asked. thanks, MattKelly at antioc.antioch.edu From bogus@does.not.exist.com Thu Nov 5 00:56:03 1992 From: bogus@does.not.exist.com () Date: Thu, 5 Nov 92 00:56:03 PPE Subject: random numbers Message-ID: <9211050754.AA03719@merde.tfs.com> Here is some code to run on a SparcStaion (I or II) to generate random numbers based on noise from the audio chip. I have not tested the true randomness of the out but cause I don't know how. Thus if anyone can please do and send me the results. I suppose some minor tweeking can be made for the mid range gain for a better spread. unfortunatly there is no way to turn off the u-law audio compression the chip uses to outputs data if you plot the out put you will see the problem the compression caused. #! /bin/sh # here be a shar file echo x - Audio/Makefile cat >Audio/Makefile <<'!E!O!F!' LD= $(CC) CC= cc LDFLAGS=-g CFLAGS=-g -I/usr/demo/SOUND -I/usr/local/include LIBS= -L/usr/demo/SOUND/ -laudio audio_rand: audio_rand.o $(LD) $(LDFLAGS) audio_rand.o $(LIBS) -o $@ test: audio_rand audio_rand | head -10000 > \#fff echo "plot '#fff'" | gnuplot !E!O!F! #! /bin/sh echo x - Audio/audio_rand.c cat >Audio/audio_rand.c <<'!E!O!F!' static char *_author = "Peter Shipley\n"; #define AUDIO_CHIP #include #include #include #include #include #include static char *_who_did_it = "Peter M Shipley (1992) [v0.1]\n"; /* X: 0-15 R: 16-31 GX: 32-33 GR: 33-34 */ #define MMR2_BITS 45 #define GX_GAIN 32 main() { struct audio_ioctl ai; extern void bzero(); int fd; int j, i; if( (fd = open("/dev/audio", O_RDONLY)) < 0) { perror("open:"); exit(1); } bzero(ai, sizeof(struct audio_ioctl) ); ai.control = AUDIO_MAP_ALL; if ( ioctl( fd, AUDIOGETREG, &ai ) < 0 ) { perror( "AUDIOGETREG ALL:" ); exit(1); } /* set audio input to a unconnected pin (audio input B) */ ai.data[MMR2_BITS] = ( ai.data[MMR2_BITS] & ~AUDIO_MMR2_BITS_AINB); /* set gain of the GX reg to the max */ ai.data[GX_GAIN] = 0x7F; ai.data[GX_GAIN+1] = 0x0; for(i=0;;) { char buf[BUFSIZ]; read(fd, buf, BUFSIZ); for(j=0; jAudio/reg.c <<'!E!O!F!' static char *_author = "Peter Shipley\n"; #define AUDIO_CHIP #include #include #include #include #include static char * print_byte(); static struct _map { char *label; char size; } map[] = { "X filter", 16, "R filter", 16, "GX Gain", 2, "GR Gain", 2, "GER Gain", 2, "Sidetone", 2, "Frequency Tone gen", 2, "Amplitude Tone gen", 2, "MMR1", 1, "MMR2", 1 }; #define NMAPS (sizeof(map) / sizeof(struct _map) ) struct audio_ioctl ai; main() { extern void bzero(); int fd; int oldmmr2; int newmmr2; if( (fd = open("/dev/audio", O_RDWR)) < 0) { perror("open:"); exit(1); } dump(fd); /* bzero(ai, sizeof(struct audio_ioctl) ); ai.control = AUDIO_MAP_GX; if ( ioctl( fd, AUDIOGETREG, &ai ) < 0 ) { perror( "AUDIOGETREG MMR2:" ); exit(1); } ai.data[0] = ai.data[1] = 0; if ( ioctl( fd, AUDIOSETREG, &ai ) < 0 ) { perror( "AUDIOSETREG MMR2:" ); exit(1); } */ sleep(5); dump(fd); } dump(f) int f; { int i,k; bzero(ai, sizeof(struct audio_ioctl) ); ai.control = AUDIO_MAP_ALL; if ( ioctl( f, AUDIOGETREG, &ai ) < 0 ) { perror( "AUDIOGETREG MMR2:" ); exit(1); } k=0; for(i = 0 ; i < NMAPS ; i++) { int j; (void) printf("%s:\n", map[i].label); for(j=1; j <= map[i].size; j++,k++) { (void) printf("%10s", print_byte(ai.data[k])); if ( (j % 7) == 0) (void) fputc('\n', stdout); } (void) fputc('\n', stdout); } (void) fputc('\n', stdout); } static char * print_byte(c) char c; { static char bt[9]; bt[0] = ( (c & 0x01) ? '1' : '0'); bt[1] = ( (c & 0x02) ? '1' : '0'); bt[2] = ( (c & 0x03) ? '1' : '0'); bt[3] = ( (c & 0x04) ? '1' : '0'); bt[4] = ( (c & 0x05) ? '1' : '0'); bt[5] = ( (c & 0x06) ? '1' : '0'); bt[6] = ( (c & 0x07) ? '1' : '0'); bt[7] = ( (c & 0x08) ? '1' : '0'); bt[8] = NULL; return bt; } !E!O!F! From efrem at informix.com Thu Nov 5 04:30:16 1992 From: efrem at informix.com (Efrem Lipkin) Date: Thu, 5 Nov 92 04:30:16 PPE Subject: a cryptographic deal with the devil Message-ID: <9211051116.AA27015@godzilla.informix.com> It is widely believed that the Police, the FBI, and other government agencies tap many more phones than they admit in public. This is not counting the NSA's monitoring of all the international traffic they can stuff into a computer. Now the FBI wants telephone switch manufactures to supply them with desktop phone tapping technology. Real-time delivery of all conversations straight to the agent's desk. This is scary, but it might an opportunity. Given that congress is likely to eventually allow the FBI this tech toy, would you go along with a deal that all taps would really require a court order and that the exact time and location of all taps would eventually be made public? No cheating possible. I believe such an compromise may be possible via cyptographic technology, I've not worked out the details, but here is a sketch of the idea. The legislation authorizing the tapping facilities would require that each tap be activated by a key supplied by a court. Each tap would require a new key. The switching gear would not only enforce the key mechanism, but transmit a record of the tap to some agency outside the court system. Both the courts and this agency would be required to periodically make public all old taps. Part of this information would include tamper-proof sequence codes and signatures to guarantee that all taps were in fact reported. The law would effectively be enforced by the switch hardware. We would not only know how many phones were tapped, but whose phones were tapped. This last would pose a privacy problem, The law could just require tappees being eventually informed of the invasion of their lives, rather than public disclosure. Problems: * We consent to the process, it legitimates phone taps. * The hardware would be in place for massive monitoring of communications if the government could get the public to accept dropping the limitations of the scheme. [It might be possible to limit the abuse by having the switches communicate and not accept anymore than a 1,000 taps a year.] * The lobbying for this would be difficult. Additional opportunity: * By proposing and lobbying for this type of scheme, it could be made obvious that the cops and mega cops want to maintain much closer surveillance than they are willing to admit. However, you'd have to be prepared for them to accept the compromise. They may figure on making all their illegal taps via other means. --efrem From shipley at tfs.COM Thu Nov 5 18:25:03 1992 From: shipley at tfs.COM (Peter Shipley) Date: Thu, 5 Nov 92 18:25:03 PPE Subject: random numbers (resend) Message-ID: <9211060124.AA11182@edev0.TFS> [my first send bounced so I am resending] Here is some code to run on a SparcStaion (I or II) to generate random numbers based on noise from the audio chip. I have not tested the true randomness of the out but cause I don't know how. Thus if anyone can please do and send me the results. I suppose some minor tweeking can be made for the mid range gain for a better spread. unfortunatly there is no way to turn off the u-law audio compression the chip uses to outputs data if you plot the out put you will see the problem the compression caused. #! /bin/sh # here be a shar file echo x - Audio/Makefile cat >Audio/Makefile <<'!E!O!F!' LD= $(CC) CC= cc LDFLAGS=-g CFLAGS=-g -I/usr/demo/SOUND -I/usr/local/include LIBS= -L/usr/demo/SOUND/ -laudio audio_rand: audio_rand.o $(LD) $(LDFLAGS) audio_rand.o $(LIBS) -o $@ test: audio_rand audio_rand | head -10000 > \#fff echo "plot '#fff'" | gnuplot !E!O!F! #! /bin/sh echo x - Audio/audio_rand.c cat >Audio/audio_rand.c <<'!E!O!F!' static char *_author = "Peter Shipley\n"; #define AUDIO_CHIP #include #include #include #include #include #include static char *_who_did_it = "Peter M Shipley (1992) [v0.1]\n"; /* X: 0-15 R: 16-31 GX: 32-33 GR: 33-34 */ #define MMR2_BITS 45 #define GX_GAIN 32 main() { struct audio_ioctl ai; extern void bzero(); int fd; int j, i; if( (fd = open("/dev/audio", O_RDONLY)) < 0) { perror("open:"); exit(1); } bzero(ai, sizeof(struct audio_ioctl) ); ai.control = AUDIO_MAP_ALL; if ( ioctl( fd, AUDIOGETREG, &ai ) < 0 ) { perror( "AUDIOGETREG ALL:" ); exit(1); } /* set audio input to a unconnected pin (audio input B) */ ai.data[MMR2_BITS] = ( ai.data[MMR2_BITS] & ~AUDIO_MMR2_BITS_AINB); /* set gain of the GX reg to the max */ ai.data[GX_GAIN] = 0x7F; ai.data[GX_GAIN+1] = 0x0; for(i=0;;) { char buf[BUFSIZ]; read(fd, buf, BUFSIZ); for(j=0; jAudio/reg.c <<'!E!O!F!' static char *_author = "Peter Shipley\n"; #define AUDIO_CHIP #include #include #include #include #include static char * print_byte(); static struct _map { char *label; char size; } map[] = { "X filter", 16, "R filter", 16, "GX Gain", 2, "GR Gain", 2, "GER Gain", 2, "Sidetone", 2, "Frequency Tone gen", 2, "Amplitude Tone gen", 2, "MMR1", 1, "MMR2", 1 }; #define NMAPS (sizeof(map) / sizeof(struct _map) ) struct audio_ioctl ai; main() { extern void bzero(); int fd; int oldmmr2; int newmmr2; if( (fd = open("/dev/audio", O_RDWR)) < 0) { perror("open:"); exit(1); } dump(fd); /* bzero(ai, sizeof(struct audio_ioctl) ); ai.control = AUDIO_MAP_GX; if ( ioctl( fd, AUDIOGETREG, &ai ) < 0 ) { perror( "AUDIOGETREG MMR2:" ); exit(1); } ai.data[0] = ai.data[1] = 0; if ( ioctl( fd, AUDIOSETREG, &ai ) < 0 ) { perror( "AUDIOSETREG MMR2:" ); exit(1); } */ sleep(5); dump(fd); } dump(f) int f; { int i,k; bzero(ai, sizeof(struct audio_ioctl) ); ai.control = AUDIO_MAP_ALL; if ( ioctl( f, AUDIOGETREG, &ai ) < 0 ) { perror( "AUDIOGETREG MMR2:" ); exit(1); } k=0; for(i = 0 ; i < NMAPS ; i++) { int j; (void) printf("%s:\n", map[i].label); for(j=1; j <= map[i].size; j++,k++) { (void) printf("%10s", print_byte(ai.data[k])); if ( (j % 7) == 0) (void) fputc('\n', stdout); } (void) fputc('\n', stdout); } (void) fputc('\n', stdout); } static char * print_byte(c) char c; { static char bt[9]; bt[0] = ( (c & 0x01) ? '1' : '0'); bt[1] = ( (c & 0x02) ? '1' : '0'); bt[2] = ( (c & 0x03) ? '1' : '0'); bt[3] = ( (c & 0x04) ? '1' : '0'); bt[4] = ( (c & 0x05) ? '1' : '0'); bt[5] = ( (c & 0x06) ? '1' : '0'); bt[6] = ( (c & 0x07) ? '1' : '0'); bt[7] = ( (c & 0x08) ? '1' : '0'); bt[8] = NULL; return bt; } !E!O!F! From gg at well.sf.ca.us Fri Nov 6 04:16:03 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Fri, 6 Nov 92 04:16:03 PPE Subject: a cryptographic deal with the devil Message-ID: <199211061115.AA02435@well.sf.ca.us> Re. the digital wiretapping "compromise." As a telecom professional I absolutely resent and will resist any attempts to mandate backdoors into my PBXs. No compromise on that. Period. We've all heard the arguements many times: vast surveillance power, diminution of privacy, potential major security problems... I'd like to suggest something of a compromise which doesn't have these risks. Common carriers (local and long distance telcos) are currently required to provide access to line terminals when presented with a court order for a wiretap. This access could reasonably be extended to requiring the telco to connect a demultiplexer in the case of digital transmission, or some kind of appropriate signal splitter in the case of fiber optics. The agency requesting the tap would of course pay the bill for materials and labor. Now this gets law enforcement their demultiplexed signal path so they can tap only the intended target line, but it preserves the existing structure which prevents law enforcement "hacking," since no backdoors would be involved. For PBXs (this is my department), a slightly distasteful but acceptable compromise would be to have interconnect companies (the folks who install your PBX or key system) register with the local operating telcos, providing the interconnect company's name and contact information on the telco record for each subscriber. So for instance, General Widgets has XYZ Telecom install a new PBX; XYZ Telecom is required to inform the local operating company that they have just acquired General Widgets as a client. Now if a law enforcement agency gets a court order for a tap, they go to the local telco and ask who the interconnect company is for that subscriber. (We're talking here about a scenario in which one or a small number of extensions in a phone system are believed to be used for criminal purposes, so law enforcement has to tap those extensions only and not everyone who is on that phone system.) Now law enforcement visits the interconnect company and presents them with the court order, which requires the interconnect company to provide access to the line terminals of the suspect extension(s), and/or provide a demultiplexer etc. if needed (at law enforcement's expense of course)... and of course, under penalty of contempt of court, refrain from disclosing the situation to the client. Now this gets law enforcement their legitimately needed access to suspect extensions on PBXs, prevents interconnect companies from blowing the whistle to their clients, and still preserves privacy protections since there is no backdoor into the system. Now here is why I think the FBI wants backdoors: Recall that under the "war on drugs" etc., a ruling was handed down (I can't recall which branch of govt originated this) which says that a wiretap may be conducted for up to 72 hours for "investigational purposes" without a court order; and the material recorded may then be used to go and get a court order for a continuing wiretap. This places authority in the hands of law enforcement agencies to conduct taps any time they suspect someone of something, and then go see the judge after the fact. Now without backdoors, law enforcement has to depend on the goodwill of telcos to get access, and is kind of stuck when it comes to PBXs and key systems. I'm willing to bet there is a pretty substantial amount of "investigational" tapping going on, and that the FBI is interested in vastly expanding it. The compromises I'm proposing don't address this investigational tapping, and that's just fine, since that ought to be challenged in court or defeated one way or another. -gg at well From gnu Fri Nov 6 05:03:26 1992 From: gnu (gnu) Date: Fri, 6 Nov 92 05:03:26 PPE Subject: 1993 RSA Data Security Conference Message-ID: <9211061203.AA20359@toad.com> RSA is putting on a conference on public key cryptography on the SF peninsula on January 14th (conference) and 15th (tutorials and exposition). Last year's conference was smaller (one day) and quite interesting. Many of the best cryptographers in the world attended. It's worth prying yourself out of your usual haunts for. The conference is free. Registration is "extremely limited, and is first come, first served". Phone +1 415 595 8782 and ask for Conference Registration, to reserve your place (and a place for anyone else at your company who's interested). I'll see you there! John Gilmore From mcmahonm at wybbs.mi.org Sat Nov 7 19:08:31 1992 From: mcmahonm at wybbs.mi.org (Mike McMahon) Date: Sat, 7 Nov 92 19:08:31 PPE Subject: No Subject Message-ID: <9211072044.AA14863@wybbs.mi.org> Please add my address to the mailing list. From crunch at netcom.com Mon Nov 9 13:39:59 1992 From: crunch at netcom.com (John Draper) Date: Mon, 9 Nov 92 13:39:59 PST Subject: Analysis of cost to produce random serail generator. Message-ID: <9211092136.AA25999@netcom2.netcom.com> At Hackers 8.0, we had a discussion about the feasability of someone building a random data generator. I volunteered to look into this with the hopes of making a cheap and inexpensive device that has 2 DB-9 connectors (Serial through box) to be used to generate random serial data at a particular baud rate. Today, I called Newbridge Micro, they faxed me the data sheets, and gave me the number for a local rep in San Jose. (408) 258-3600, but I was appalled at the price. They wanted $52.50 each in 100 quantity. So it is clear that if I use this chip, which really is a hybred, I cannot charge $50 each. So we have to decide what to do, or how much more it will cost. After examining the data sheet, the chip is probed by a pulse, and a bit comes out with an equal probability of a "1" or a "0". Sorta like a coin toss. I think that the perifery cost of the other electronics, such as shift registers, or UART which would be necessary to clock the bits into an 8 bit register, etc, would cost about $6 - $8 in cost, then I will have to fab the boards. I have friend at Douglas Electronics who can give me a good price. It would cost $150 setup charge for the PC boards and $2 per board. 1 ea RBG1210 $52.50 1 ea PC board $2.00 various chips $8.00 Setup $1.50 (1/100th setup charge) Total parts $63.50 (100 quantity) Cost (4 X parts) $254.00 So, it is clear that the cost is rather high, and not everyone can afford this. But if you think that people will want to buy it at that price, I can go ahead and do it, but the cost to me would be about $250 to build just one of them, and I have someone who can loan me the money to make a prototype. This also includes design time and use of an electronics lab to test and get it running. I wouldn't be able to borrow $6350 to build 100 of them, and I think I can talk the rep into letting me purchase them in smaller quantity, so I can build them on demand. I'm just not so sure that people will want to pay $254 for one of these. So please lets discuss this, among our group to determine if this price is reasonable. Although, it IS possible to use a cesium noise source (Don't know the cost of that) and perhaps I can cut that price down by about a half or a third, but the design time would be much increased, and perhaps there would be twice as much electronics, and perhaps the posibility that the randomness won't be as good. John D. From pozar at kumr.lns.com Mon Nov 9 15:09:09 1992 From: pozar at kumr.lns.com (Tim Pozar) Date: Mon, 9 Nov 92 15:09:09 PST Subject: Analysis of cost to produce random serail generator. In-Reply-To: <9211092136.AA25999@netcom2.netcom.com> Message-ID: John Draper wrote: > [...] > So, it is clear that the cost is rather high, > [...] > Although, it IS possible to use a cesium noise source > [...] > John D. Geez... What happened to the idea of using a reversed-biased diode? That into a cheapy A/D and into a UART, should do the trick... Tim -- Internet: pozar at kumr.lns.com FidoNet: Tim Pozar @ 1:125/555 UUCP: ...!uunet!kumr.lns.com!pozar Snail: Tim Pozar / KKSF / 77 Maiden Lane / San Francisco CA 94108 / USA Voice: +1 415 788 2022 From pmetzger at shearson.com Mon Nov 9 15:09:26 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Mon, 9 Nov 92 15:09:26 PST Subject: Analysis of cost to produce random serail generator. In-Reply-To: <9211092136.AA25999@netcom2.netcom.com> Message-ID: <9211092238.AA05660@newsu.shearson.com> >From: crunch at netcom.com (John Draper) >Although, it IS possible to use a cesium noise source (Don't know >the cost of that) and perhaps I can cut that price down by about >a half or a third, but the design time would be much increased, >and perhaps there would be twice as much electronics, and perhaps >the posibility that the randomness won't be as good. Remember also that a radioactive source thats decaying fast enough to put out 20,000 bits a second the way the RBG1210 can isn't something you want to stand near. >Total parts $63.50 (100 quantity) > >Cost (4 X parts) $254.00 I don't get this -- why is cost four times parts? Is that including profit? Also, shouldn't it just be possible to buy a couple of components and do as well as the Newbridge Micro unit? It would seem that we should be able to build something a lot cheaper than $52 if all we need is a noise source that will make a line go high or low on a clock input... Perry From efrem at spitha.informix.com Mon Nov 9 21:57:15 1992 From: efrem at spitha.informix.com (Efrem Lipkin) Date: Mon, 9 Nov 92 21:57:15 PST Subject: a cryptographic deal with the devil Message-ID: <9211100543.AA00737@spitha.informix.com> >Re. the digital wiretapping "compromise." As a telecom professional I >absolutely resent and will resist any attempts to mandate backdoors into my >PBXs. No compromise on that. Period. We've all heard the arguements many >times: vast surveillance power, diminution of privacy, potential major >security problems... I think you missed the point of my proposal. It is to create a situation in which all taps must be court ordered and eventually disclosed. The police have no business making "investigational" taps, they are not entrepreneurs in search of new business opportunities. My prefered solution is no taps. In my experience taps are more common for political reasons than police reasons. I think anyone who believes anything the FBI says without proof must have not been reading the paper for the last several decades. If the political process will not ban wire (fiber) tapping then it seems sensible to try and force all easedropping into the public record. I see no reason to care where the police put their equipment so long as there is no way they can create taps without going to court and creating a public record. I do not see the difference between building the tap in or making it an extra cost option, unless it can be made a very expensive option. If tap control cannot be reliably accomplished via technology, cryptographic or otherwise, then we might as well just fight against all tapping and for universal encryption even if it is a lost cause. I think it is clear that no organization and especially no government or corporation can be trusted to police itself either at the frontdoor or the backdoor. --efrem From tcmay at netcom.com Wed Nov 11 00:58:51 1992 From: tcmay at netcom.com (Timothy C. May) Date: Wed, 11 Nov 92 00:58:51 PST Subject: Hackers Conference Report Message-ID: <9211110855.AA18408@netcom.netcom.com> Fellow Cypherpunks, Here's a trip report I just sent to another mailing list I'm active on, the "Extropians" list. That's why I "introduce" Tom Jennings, John Gilmore, and Eric Hughes...clearly they need no introduction to readers of _this_ list (although a lot of new folks have signed up recently, I hear). By the way, I just picked up the latest "Mondo 2000." Our own Jude Milhon's article, "The Cypherpunk Movement," is on pp. 36-37 (Issue #8). The address "cypherpunks at toad.com" is mentioned, so we may get even more new folks. Also some good stuff on MindVOX, phreaking, etc. --Tim HACKERS CONFERENCE REPORT I just returned from Hackers 8.0, held 6-8 November in Lake Tahoe, California. Approximately 170 attendees this year. Some Highlights: * Our crypto session went extremely well. The talks were on PGP and FidoNet, Diffie-Hellman key exchange for rlogin, digital time-stamping, and anonymous remailers. More comments later. * Mike Godwin of the Electronic Frontier Foundation (EFF) spoke on the developing conflict between personal privacy and law enforcement, including comments on the "key registration" trial balloon I posted about earlier. (Godwin told me he believes the Denning proposal is deadly serious, that the Department of Justice has put a high priority on limiting the use of cryptography.) * Hacking was well represented. Besides our crypto panel, sessions on cellular phone phreaking and illegal mods to telecom equipment drew large crowds (a "how to" talk on reprogramming the 8051 micro in the Oki 900 cellphone was especially useful). * Eric Drexler gave a talk on nanotechnology (surprise!), with an emphasis on needed work in the next couple of years. Drexler argued that proto-assemblers could be built in as short as 16 years, though there was some skepticism expressed. He also presented a calculation that the "cost" of delaying nanotech is $25 billion a _day_. (I suggested we all skip dinner that night and instead put in another hour in the labs!) * Marvin Minsky answered questions, saying he rarely prepares in advance. AI, robotics, gene expression in embryos, and software were all covered. * Allan Huang of AT&T gave an energetic 90 minute talk on optical computing, going from optical deconvolvers to "computer origami" to optical switches to Sagnac fibers that can store light pulses 6 femtoseconds long! Definitely the most stimulating talk. * Demos in the machine room were better than ever. The "Reality Engine" from Silicon Graphics displayed photorealistic simulations. Lots of Suns, NeXTs, and Macs. Films of SIGGRAPH papers, chaos and fractals, and artificial life were shown at night. Rudy Rucker's session on cellular automata went well. MORE ON CRYPTO Since cryptology and the activities of the "cypherpunks" mailing list are of central concern to me, I'll concentrate on those topics. Our panel was in "prime time," mid-Saturday afternoon, with about 100 in attendance, including a couple of journalists (notably John Markoff of the "New York Times"...if anybody sees an article on this by him, please send me a note about it, OK?). The audience had been prepped for crypto by the comments Friday night by Mike Godwin of the EFF and by a 3 hour rump session on "Digital Cash" from 1 a.m. to 4 a.m on Saturday (remember "hacker hours"). Tom Jennings, one of the chief forces behind FidoNet, an "anarchic" net made up of PCs talking to other PCs, spoke on efforts to spread PGP (Pretty Good Privacy) to as many FidoNet users as possible. It looks like its happening and this will be another avenue to ensure that the "crypto genie" gets safely out of the bottle. John Gilmore, an early UNIX/Sun pioneer and current principal at Cygnus Support, amongst other things, spoke on increasing security against Internet eavesdroppers by using the Diffie-Hellman key exchange protocol for rlogin (for example). This is something we can do fairly soon. Stu Haber and Scott Stornetta of Bellcore (formerly part of Bell Labs) reported on their digital time-stamping system. Some document to be "notarized" is hashed to produce a fairly short number which is hard to forge (i.e., it is very hard to find another document which hashes to the same value). This hash value is then published in, say, a widely read newspaper. If a dispute arises about the time a document was written, the published has value is persuasive. Bellcore actually operates such a service (check the legal notices in the Sunday "New York Times"). Eric Hughes, a mathematician who worked briefly for David Chaum's "DigiCash" outfit, described anonymous remailers implemented in Perl and now running. He also mentioned Hal Finney's version which embeds PGP in the remailer, allowing more security. This generated a lot of excitement, as the ideas of "crypto anarchy" became apparent to all. (John Little, owner and operator of the "Portal Communications Company," a Bay Area-based Internet access service, got excited and offered to run the remailers on his system! The genie is further out of the bottle. Now if we can only get GEnie to do the same!) The spirit of contributing to the larger cause of using crypto to _directly_ protect privacy was exhilarating. More people spoke of actual code they plan to write (as with Russell Whittaker's offer a few weeks ago to help with ProComm mods). There was a real sense that Things Had Changed. With PGP 2.0 arriving a few months ago (and still spreading), with the onset of the "Cypherpunks" group (which got a somehat cryptic write-up by Jude Milhon in the just-published Issue #8 of "Mondo 2000"...but since she coined the term "cypherpunks" to describe us, her article can afford to be cryptic, no?), and with the "Hacker Crackdown" all around us (Sun Devil, Legion of Doom, S.266 attempt to ban encryption, FBI's "Digital Telephony Bill," and the latest "trial balloon" to register keys), the time is right. In the next several months I expect the media, via more articles in magazines like "Mondo 2000" and by articles on crypto policy, to focus in on this issue. Even the "Village Voice" is interested in crypto issues (theme: crypto privacy vs. Big Brother). These are exciting times. If I'm ever busted for sedition, money laundering conspiracy, violation of the Munitions Act, RICO Act violations, or just plain old political incorrectness, carry on the fight. The stakes are high. --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at 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^756839 | PGP Public Key: awaiting Macintosh version. -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at 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^756839 | PGP Public Key: awaiting Macintosh version. -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at 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^756839 | PGP Public Key: awaiting Macintosh version. From hughes at soda.berkeley.edu Wed Nov 11 08:24:36 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Wed, 11 Nov 92 08:24:36 PST Subject: Random number generators Message-ID: <9211111624.AA08843@soda.berkeley.edu> There seems to be some confusion over this random number device. Perry Metzger forwarded me some information about Newbridge Microsystems and the part number of a chip that made random numbers. At the crypto BOF at hackers I mentioned that there was a need for a hardware random number generator and that I knew of some chip to do it. John Draper, who was there, expressed a desire to work on such a device. I forwarded him the information about the chip. What I didn't know was the cost or design of this chip. It appears to use a radioactive source to make random numbers. This may account for the cost. In any case, it is likely that most applications don't need this kind of chip. What is needed, though, is _some_ kind of chip. John Draper is eager to manufacture such a device, once we have a design. Would those people willing to help on this design please get in touch with him directly and start a conversation about it. The conversation could reasonably be discussed on the list, if enough are interested. FYI, random numbers are used generally to create single-use session keys in a wide variety of crypto protocols, including Diffie-Hellman key exchange. Hardware random number sources will be a standard component of all computers in the near future. As far as the design of the device itself goes, the numbers that come out of it don't have to be fully random. Non-randomness can be corrected in software. Two characteristics of the output, though will help such correction. First, the number of ones and zeros should be the same. Not only is this useful for correction, but it is easy to do in hardware. Second, effort should be made to make sure that the generator does not pick up cyclic noise from its environment. This means attention to coupling, shielding, and packaging. No extra expense, likely, but definitely to be thought about some. Eric From hughes at soda.berkeley.edu Wed Nov 11 08:33:18 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Wed, 11 Nov 92 08:33:18 PST Subject: Mac PGP version Message-ID: <9211111630.AA09056@soda.berkeley.edu> I found the address for the Mac version of PGP. anon-ftp to mac.archive.umich.edu directory /mac/util/encryption Would someone try this out and report back to the list how it works? Eric From strat at intercon.com Wed Nov 11 09:01:48 1992 From: strat at intercon.com (Bob Stratton) Date: Wed, 11 Nov 92 09:01:48 PST Subject: Mac PGP Message-ID: <9211111701.AA00740@intercon.com> I will try out the port that Eric Hughes just mentioned, and I also want to make it known that I'm willing to assist in any Macintosh efforts along these lines. (FYI - I use MPW for development). Bob Stratton Engineer, InterCon Systems Corp strat at intercon.com +1 703 709 5525 (W) From pmetzger at shearson.com Wed Nov 11 09:08:59 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Wed, 11 Nov 92 09:08:59 PST Subject: Random number generators In-Reply-To: <9211111624.AA08843@soda.berkeley.edu> Message-ID: <9211111657.AA13574@newsu.shearson.com> >From: Eric Hughes >There seems to be some confusion over this random number device. >Perry Metzger forwarded me some information about Newbridge >Microsystems and the part number of a chip that made random numbers. >At the crypto BOF at hackers I mentioned that there was a need for a >hardware random number generator and that I knew of some chip to do >it. John Draper, who was there, expressed a desire to work on such a >device. I forwarded him the information about the chip. >What I didn't know was the cost or design of this chip. It appears to >use a radioactive source to make random numbers. This may account for >the cost. In any case, it is likely that most applications don't need >this kind of chip. Just for the record... As the data sheet makes clear, it most certainly DOES NOT use a radioactive source. Its very hard to get 20kbits/sec of random numbers reliably out of any radioactive source you are going to want to be near, anyway. It operates off of thermal noise just like virtually every other such device. It should be possible to build a similar device out of ordinary discrete components without overwhelming difficulty. The only problem would be to make sure that the output was reliably random, and not overly dependant on things like temperature. Perry From estensla at mipos2.intel.com Wed Nov 11 09:12:11 1992 From: estensla at mipos2.intel.com (Erik Stensland) Date: Wed, 11 Nov 92 09:12:11 PST Subject: Remove my name please Message-ID: <9211111710.AA08221@mipos2> Please have my name removed from the mailing list! Thanks From tcmay at netcom.com Wed Nov 11 09:25:31 1992 From: tcmay at netcom.com (Timothy C. May) Date: Wed, 11 Nov 92 09:25:31 PST Subject: Random number generators In-Reply-To: <9211111657.AA13574@newsu.shearson.com> Message-ID: <9211111722.AA06575@netcom.netcom.com> Eric Hughes comments and then Perry Metzger responds: > >Perry Metzger forwarded me some information about Newbridge > >Microsystems and the part number of a chip that made random numbers. > >At the crypto BOF at hackers I mentioned that there was a need for a > >hardware random number generator and that I knew of some chip to do > >it. John Draper, who was there, expressed a desire to work on such a > >device. I forwarded him the information about the chip. > > >What I didn't know was the cost or design of this chip. It appears to > >use a radioactive source to make random numbers. This may account for > >the cost. In any case, it is likely that most applications don't need > >this kind of chip. > > Just for the record... > As the data sheet makes clear, it most certainly DOES NOT use a > radioactive source. Its very hard to get 20kbits/sec of random numbers > reliably out of any radioactive source you are going to want to be > near, anyway. It operates off of thermal noise just like virtually > every other such device. > > It should be possible to build a similar device out of ordinary > discrete components without overwhelming difficulty. The only problem > would be to make sure that the output was reliably random, and not > overly dependant on things like temperature. > > Perry Perry is correct. Getting 10K or more bits per second from a radioactive soure usually means it is close enough/strong enough to "drift" the device to the point of radiation-induced permanent failure in a matter of weeks or months (if not much sooner, but this is all so dependent on exact calculations and lab experiments). Tony Patti, editor of a small crypto journal and frequent commentator on sci.crypt, is one of several folks who've designed thermal noise-based RNGs. He's selling them, as I recall. I would _strongly_ advise anyone who's contemplating building and selling such a gizmo to first see what the market has produced and whether or not it's selling, etc. A minor note: the bias between 0s and 1s (unequal distribution, for example) is easily handled by considering pairs of numbers, with a "0 1" being called a "0" and a "1 0" being called a "1." --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at 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^756839 | PGP Public Key: awaiting Macintosh version. From tcmay at netcom.com Wed Nov 11 11:14:11 1992 From: tcmay at netcom.com (Timothy C. May) Date: Wed, 11 Nov 92 11:14:11 PST Subject: (fwd) A Silver Bullet to Limit Crypto? Message-ID: <9211111910.AA19576@netcom.netcom.com> Cypherpunks of the World, Here's a new analysis of the key registration proposal I just posted to a couple of groups. -Tim Newsgroups: sci.crypt,alt.privacy,comp.org.eff.talk From: tcmay at netcom.com (Timothy C. May) Subject: A Silver Bullet to Limit Crypto? Date: Wed, 11 Nov 1992 18:36:44 GMT Key Registration as a "Silver Bullet" to Limit Crypto Use Two weeks ago, and more than 500 related messages ago, I posted the "Trial Balloon to Ban Encryption?" message, alerting sci.crypt and other newsgroups to the Dorothy Denning "trial balloon." Prof. Denning has continued the balloon metaphor, calling her first proposal a "lead balloon" and her improved, law-enforcement-friendly version a "copper balloon." Others have called it a "uranium balloon," i.e., it's worse than the lead balloon. In reading the hundreds of comments about ways to bypass the Denning proposal, about the many clever schemes to avoid detection, I came to some realizations about the likely reason for key registration. Also, at the recent Hackers Conference in Lake Tahoe, lots of interesting points came up (crypto, PGP, anonymous remailers, digital cash, privacy, and the "Crypto Crackdown," to borrow Bruce Sterling's title of "The Hacker Crackdown," were hot topics). Mike Godwin of the EFF, who may be reading this in comp.org.eff.talk, spoke on such policies...he told us this kind of crackdown on crypto tools is a priority of several government agencies and that the issue will not go away with the new administration. But why scheme to register keys, by whatever means, if the system is so easily thwarted and bypassed? Neither Prof. Denning nor her colleagues, both in and out of the NSA and FBI, are dummies. The "silver balloon," or silver bullet, is this: * a formal key registration system will directly affect and limit use of the _most important_ part of public key systems: the ability to use public key directories (like phone books) rather than set up all communications on a one-to-one basis (as private key systems require, for key exchange, and as many of the key registration bypasses implicitly or explicitly require). * enforcement, at least for publicly announced P-K keys, can be by insisting that a special message ("This is J. Random User.") be signed with one's registered/deposited key and then verified with the public key to ensure the same private key-public key pair is used. (Yes, there are still bypasses and clevernesses to spoof these systems, but most "publicly visible" use of P-K methods, the main raison d'etre for public keys, will be affected and effectively controlled.) Keys can and will be registered under this proposal, but many people will simply not bother with the hassle and just won't use P-K methods (thus making the monitoring job easier). * bypassing the key registration laws by "going underground" is always possible, but for this purpose one can already use one-time pads, pack message bits into the least significant bits of digital recordings and images, and generally do all sorts of other devious things. The key point is that the wide use of public key methods is reduced, which may be the real motivation. * reducing the wide use of crypto technology by the masses allows the monitoring agencies a slightly easier job in monitoring those who _are_ using crypto. One can imagine exactly the same arguments for restricting or registering voice scramblers for phone use: by requiring registration, fees, etc., many users will simply not bother to use scrambling (and there may be related to spread the idea that anyone using scrambling--or crypto in general--is somehow suspect, must have something to hide, etc. * the key registration ideas discussed so far severely limit use of crypto protocols that _dynamically_ generate lots of public keys. Cryptographic voting, most forms of digital cash, anonymous remailers, and several other exciting uses all tend to generate a lot of keys "on the fly." Are all of these to be registered? How? For how much money per registration? And how long will it take? Weeks? Instead of concentrating on how these kinds of uses, mentioned by many people, effectively make the Denning/Rivest/Micali proposals unworkable, we should look instead at how these proposals may _in fact_ be aimed at limiting the explosive use of crypto for these new applications. A government afraid of digital cash, of anonymous remailing networks, of information markets in technologies, and of lots of other interesting uses, may see key registration as a way to contain this explosion. Even if the private keys kept at the "trusted key authority" were _never_ looked at by court order or otherwise, the key registration act itself would place severe limits on the use of modern cryptographic protocols for novel uses and for wide use by the public. In this sense, the key registration idea may be a silver bullet, or balloon, to head off these uses. A chilling effect (the "liquid nitrogen balloon"?). Any thoughts on this view? -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at 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^756839 | PGP Public Key: awaiting Macintosh version. From Tom.Jennings at f111.n125.z1.FIDONET.ORG Wed Nov 11 13:01:03 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Wed, 11 Nov 92 13:01:03 PST Subject: (fwd) A Silver Bullet to Limit Crypto? Message-ID: <3565.2B016F5A@fidogate.FIDONET.ORG> U> From: tcmay at netcom.com (Timothy C. May) U> U> Here's a new analysis of the key registration proposal I U> just posted to a couple of groups. U> U> -Tim I've been crossposting selected messages, such as this one, to FidoNet's PUBLIC_KEY conference, just FYI... --- ReadMail * Origin: tomj at fidosw.fidonet.org / World Power Systems (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings at f111.n125.z1.FIDONET.ORG From ebrandt at jarthur.Claremont.EDU Wed Nov 11 13:37:40 1992 From: ebrandt at jarthur.Claremont.EDU (Eli Brandt) Date: Wed, 11 Nov 92 13:37:40 PST Subject: a name for cryptographic currency Message-ID: <9211112137.AA22079@cygnus.com> Nothing makes it big with a dodecasyllabic name. How about "cryp"? (Rhymes with "scrip"?) The idea is for science-fiction writers to ditch these central-intelligence "credits", and start naming currency "1gAu L5 Consortium cryp" and the like. Eli ebrandt at jarthur.claremont.edu From crunch at netcom.com Wed Nov 11 13:56:07 1992 From: crunch at netcom.com (John Draper) Date: Wed, 11 Nov 92 13:56:07 PST Subject: My responses regarding random generator. Message-ID: <9211112152.AA24329@netcom2.netcom.com> In response to everyones comments: I am overwhelmed with all this response that came though during the times I was absent from the Nets. At this time, I am evaluating other approaches to this problem then using the Newbridge system's inflated pricey hybred circuit. It is clear that a simple reversed diode circuit may not be enough to produce truly random data bits unless care is taken to prevent periodic signals from being "injected" into the circuit. Although I don't have access to a "clean lab", I do have access to Techtronix scopes, and a general HW lab, but not sure if that is adequate to completly test out the circuit to determine that things are truly random. An easy test I often devise is to generate a pair of random bytes, and display them as X, Y pairs and plot them on the screen as pixels. First, I start with a clean screen, then plot the dots as they come in. As these dots are plotted on the screen, the dots should be evenly distributed over the screen without "bunching" or "patterns" developing. I know that this is not the best way to determine true randomness, but it is cheap and inexpensive to do. I also agree that we should all check out and determine if there are other random generators currently available, and we should compile a list of them to share with the group as proposed by Tim May. Although I haven't yet visited the crypt newsgroups, I suspect that I should post a query there to see if any such puppie exists. Then, there is the speed of generating these random numbers, and how we will want to deal with the possibility of inadequate speed. I suspect that serial transmission at 9500 baud might be easily obtained, but going much faster withoug "drift" might be problematic as Tim May pointed out. At this point, I would now like to get some other feedback from the group on what Zener noise source to use, and kick around some design ideas. It would be nice to be able to exchange schematic diagrams and pass them around. I have a Mac, but not everyone in this group uses them. So what mechasim can we imploy to send schematics around? My next visit to the Nets will be this weekend, so if anyone wants to contact me, they can try me at (510) 769-1268, and it will refer to the number where I'm staying at that time. I still have NO permenent home (after long period of unemployment), so getting on the Nets daily will be problematic for me. I usually hang out in South San Jose, at my friends VCR Repair lab (where this hardware equipment is located), but have no computer set up there until we can set up proper physical security. That number is (408) 377-2382. I am usually there early in the week, because I can make calls to find work from there on Mondays. As I converge into a workable design and if the lab results are encouraging, and acceptable to the group, I would like to build 2 or 3 prototypes and pass them around to volunteers for Beta testing before making them available to the group as a whole. I can get PC boards made via Douglas Electronics fairly inexpensivly, and plan on making them as orders come in, and initial setup costs would be about $350. I already have people set up to invest this much already. Perhaps it would be prudent to set up a group of other HW designers and meet physically somewhere to hammer out a design and make this a group effort. Do I have any volunteers? I think only one meeting would be necessary to determine a rough approach to take. John D. From karn at qualcomm.com Wed Nov 11 15:00:43 1992 From: karn at qualcomm.com (Phil Karn) Date: Wed, 11 Nov 92 15:00:43 PST Subject: PGP problems with large key rings? Message-ID: <9211112300.AA06194@servo> I'm encountering problems when I try to form a large key ring (on the order of 150 keys, each with several signatures). The file is large enough (60+ Kb) but it is apparently trashed; when I run "pgp -kv" on it I only see 4 keys. This is under UNIX, so I don't think memory exhaustion is the problem. I'm not sure I have the latest version of the UNIX port, so if somebody could steer me to the right repository I'd like to try that too. Phil From hughes at soda.berkeley.edu Wed Nov 11 15:18:28 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Wed, 11 Nov 92 15:18:28 PST Subject: PGP problems with large key rings? In-Reply-To: <9211112300.AA06194@servo> Message-ID: <9211112318.AA18915@soda.berkeley.edu> P.S. The maintenance release is in the works; it may fix the error you describe. Eric From fen at genmagic.com Wed Nov 11 16:20:49 1992 From: fen at genmagic.com (Fen Labalme) Date: Wed, 11 Nov 92 16:20:49 PST Subject: Mac PGP version Message-ID: <9211112022.AA12952@> >I found the address for the Mac version of PGP. > >anon-ftp to mac.archive.umich.edu >directory /mac/util/encryption > >Would someone try this out and report back to the list how it works? I pulled it down and found it to be a "nice little app" with certain problems evident from the beginning. The major bug is **no source code**!! How can I trust an app to make my keys? Why don't I just ask the NSA for them? What I would have liked (and expected) was a set of diff (or changed) files from the PGP 2.0 distribution, and perhaps an extra top-level app-maker file to put the nice wisiwyg on top. This would show me an example, and let me build PGP into other apps that I might build. The next bug is no email address for Z. Fiedorowicz, so I can't complain to him directly. And the third apparent bug (now I haven't used this much yet) is that the help file offers help for the standard MPW-style command line operations, but the app is entirely menu-driven. I hope that ZF doesn't take this as purely negative. I am sure that he did a good implementation, and I thank him for doing the work and for providing a nice gui. But I would especially like to get the source code (preferably as minimal changes to the standard distribution so that it is clear that the same internals are used for each). Thanks, Fen -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQBNAisBeSgAAAECAKvzX/54a9kC5FPXfIN7vjep64zkqXwPzr8VXkiJXyklRTRI kyxcuNlS7ipDveilmSDYYP3W5JJMCC1HSIeCc4kABRG0HkZlbiBMYWJhbG1lIDxm ZW5AZ2VubWFnaWMuY29tPg== =bZWg -----END PGP PUBLIC KEY BLOCK----- From hughes at soda.berkeley.edu Wed Nov 11 18:47:46 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Wed, 11 Nov 92 18:47:46 PST Subject: Mac PGP version In-Reply-To: <9211112022.AA12952@> Message-ID: <9211120247.AA00337@soda.berkeley.edu> Here's the author of the Mac port I referenced: Zbigniew Fiedorowicz This fixes the second of Fen's bugs. Contacting Zig will fix the first (no source). And, Fen, you attached a PGP key. Did you really ask the NSA to generate one for you? :-) Eric From hh at soda.berkeley.edu Thu Nov 12 01:09:12 1992 From: hh at soda.berkeley.edu (Eric Hollander) Date: Thu, 12 Nov 92 01:09:12 PST Subject: mac pgp Message-ID: <9211120909.AA19359@soda.berkeley.edu> I uploaded MacPGP to my powerbook, and used it to generate a key pair. The user interface is easier than the Unix user interface, so I have no problem with that, but I do have a big problem with speed. It expects me to type in my pass phrase at about 20 words per minute. It beeps me if I type it faster than that. This makes it too annoying to be used regularly. It should be able to accept full-speed typing on a powerbook 100. I know that a 100 is not a very fast machine, but still, this is just basic keyboard input. My powerbook is about as secure as you can get (it's with me close to 24 hours a day and probably emits very little radiation and it's not on any kind of net), so ideally it would be my main crypto machine, but I don't want to type my pass phrase at 20wpm, so for now I'll stick with the IBM RS/6000 I normally use PGP on, despite its much weaker security. The other speed problem is key generation. This is very slow. Maybe I am spoiled by the RS/6000, which is extremely fast, but I still feel like it should be faster. Also, it does not allow itself to be backrounded properly under system 7 during key generation. However, I must say that I am glad that Fiedorowicz and others are working on this port. It's a good start. e From tribble at xanadu.com Thu Nov 12 01:25:29 1992 From: tribble at xanadu.com (E. Dean Tribble) Date: Thu, 12 Nov 92 01:25:29 PST Subject: (fwd) A Silver Bullet to Limit Crypto? In-Reply-To: <9211111910.AA19576@netcom.netcom.com> Message-ID: <9211120841.AA17711@xanadu.xanadu.com> I think I agree with it completely. It is also very well written. Is there a well written summary and response such as this that could be more widely distributed electronically? dean From gg at well.sf.ca.us Thu Nov 12 02:38:59 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Thu, 12 Nov 92 02:38:59 PST Subject: a cryptographic deal with the devil Message-ID: <199211121037.AA24895@well.sf.ca.us> Efrem, re your item on tapping and public records. Okay I admit it, I did miss the point of your proposal that any tapping be made the subject of a public record. And basically I agree with you on that point. Now the problem I see is that these agencies will say, "except for taps currently in process," or "investigations which are still open," which is how the FBI gets around FOIA a lot of the time. And we all know that in political cases, the investigation can stay open for a hell of a long time, like until the targeted individuals die or something. Maybe the way to deal with the "open investigations" issue is to mandate disclosure of *something* anyway, in some form, on a regular basis, and certainly it would be nice to have the scheduled disclosures take place a month or so before elections...! I still do not want back doors of any kind in our network. Now speaking of back doors, wouldn't it be a simple matter for someone to hack out a system which would detect the signals coming into the back door, and then do something like turn on a message lamp on the telephones (I'm thinking PBX here, but also consider that deregulation of local switching will result in some amount of "neighborhood telcos" using PBXs to resell service...) Remote access means that some kind of signal has to be sent to the PBX to turn on the tap, either via normal trunks or some signalling channel. Re. John Draper's item about cost of complete RNGs as being 4x the parts cost: that is a standard figure I've seen in use many times. Covers labor and overhead expenses, including parts for prototypes which fail, and all that. COmpletely reasonable estimate. Though it would still be nice to find a less expensive way to do this. Now that I think of it, I believe that Billy Sq-you-know-who designed one of these for me many years ago for exactly this purpose, based on discrete components... and anyone here who knows Bill knows the quality of his designs... so if I can dig up that piece of paper, I'll see about bringing it along to one of our meetings (he drew out a complete schematic). -gg From crunch at netcom.com Thu Nov 12 03:03:12 1992 From: crunch at netcom.com (John Draper) Date: Thu, 12 Nov 92 03:03:12 PST Subject: Mac PGP - Some comments Message-ID: <9211121059.AA11389@netcom.netcom.com> I seem to be having problems using the Mac version of PGP, in that when I type ANY character into it, I just get a "beep". Is there some other thing I have to do to get this thing to work? I also want to start building by public key ring so I can learn how to use this puppie, but I am concerned with possible legal problems in using this to communicate with my friends. According to the disclaimer, PGP is "contraband"? Will I get the "thought police" busting down my door for using it? Is anyone working on a Mac version that is more Mac'ish? Like putting in a nice Mac like GUI for key management. It would be nice if it had a pub (or private) "key list" in an editable scrollable list. The Mac version in "mac.archive.umich.edu" appears with just a "cheapie" console window that behaves like I described above. If I had source code, I could "wrap it" in a nice Object oriented GUI and maintain the file format for the keys. Thanx Eric for the Email address for Zbigniew Fiedorowicz. Has anyone contacted Zbigniew relating to the Mac port? It appears to have some problems, but time limitations has prevented me from fiddling with it tonight. I think I might actually have access to the Nets tommorrow, so I'll be "on-line". Cheers JD From gg at well.sf.ca.us Thu Nov 12 03:07:32 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Thu, 12 Nov 92 03:07:32 PST Subject: (fwd) A Silver Bullet to Limit Crypto? Message-ID: <199211121106.AA25693@well.sf.ca.us> Regarding key registration proposals. Tim's critiques shed a most interesting light on this problem. They also point to parallels with voter registration: It has been well-known for some time that requiring people to register some time in advance of an election, causes a decline in participation. This decline is most evident among the disadvantaged sector of the population, for various reasons including inability to take time off from work. Were the disadvantaged to vote en masse, they would most likely weigh in on the side of substantial change, particularly change which would shift the balance of power in a more socially equitable direction. As the powers-that-be prefer to maintain the status quo, they are quite satisfied with the fact that the disadvantaged aren't voting in larger numbers. Hence Republican administrations have (in recent history) blocked efforts to simplify and ease voter registration, as for instance the "motor voter bill" which would automatically create a voter registration when someone gets a driver's licence or car registration. The United States is the world's only remaining Western democracy which requires advance voter registration. This practice had its roots in attempts to prevent newly naturalised US citizens from voting, again, the result of prejudice and desire to maintain the status quo. Now that the Dems are in power, we might consider tying the crypto key issue to the elimination of voter registration, on the basis that both voting and digital communication are forms of speech which should not be subjected to a chilling effect. Rapid promulgation of decent user-friendly PKSs looks pretty essential at this point. I'm thinking, how about approaching Apple to see if they'll include a PKS along with their Macs, as bundled software, sort of like Hypercard. Even if the PKS which is used, has some problem with is, as for instance the old trapdoor-knapsack system, **anything** is preferable to nothing at all when it comes to getting the public educated. Does anyone here know any of the main people at Apple...? What do you think they'd have to say about bundling privacy software along with Macs? -gg From simsong at next.cambridge.ma.us Thu Nov 12 07:24:57 1992 From: simsong at next.cambridge.ma.us (Simson L. Garfinkel) Date: Thu, 12 Nov 92 07:24:57 PST Subject: (fwd) A Silver Bullet to Limit Crypto? Message-ID: <9211121334.AA08156@next.cambridge.ma.us> Hi. I'm new to this list. Some people may know me. > Date: Thu, 12 Nov 1992 03:06:19 -0800 > From: George A. Gleason > To: cypherpunks at toad.com, tcmay at netcom.com > Subject: Re: (fwd) A Silver Bullet to Limit Crypto? > > Now that the > Dems are in power, we might consider tying the crypto key issue to the > elimination of voter registration, on the basis that both voting and digital > communication are forms of speech which should not be subjected to a > chilling effect. > Good luck. As a practicing journalist, I can say that there is no way that I could make this argument in print. Everybody understand voter registration. There's support for the motor-voter bill. I can't even explain cryptography in the same amount of time that it takes to do an entire article on voter registration. There may be a theoretical connection between the two, but you'll never make that argument outside a university. From hughes at soda.berkeley.edu Thu Nov 12 07:57:00 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Thu, 12 Nov 92 07:57:00 PST Subject: (fwd) A Silver Bullet to Limit Crypto? In-Reply-To: <199211121106.AA25693@well.sf.ca.us> Message-ID: <9211121557.AA25427@soda.berkeley.edu> Re: tying voter and crypto registration issues togther. An excellent idea, if both succeed. But since voter registration is already a partisan issue, tying crypto registration to it make crypto a partisan issue. And once you've made it a partisan issue, you've lost, fundamentally. The way to succeed on any issue is to avoid polarization along party lines. One should not assume that there will be automatically a large opposition. Eric From hughes at soda.berkeley.edu Thu Nov 12 07:59:57 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Thu, 12 Nov 92 07:59:57 PST Subject: (fwd) A Silver Bullet to Limit Crypto? In-Reply-To: <199211121106.AA25693@well.sf.ca.us> Message-ID: <9211121600.AA25453@soda.berkeley.edu> Re: Apple include a PKS with their Macs Well, Apple does have a site license for RSA. Tim Oren, who's on the list, knows more about this than I. I ask him to respond. Maybe Apple could license the PGP code as a system utility? Eric From pmetzger at shearson.com Thu Nov 12 08:38:19 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Thu, 12 Nov 92 08:38:19 PST Subject: My responses regarding random generator. In-Reply-To: <9211112152.AA24329@netcom2.netcom.com> Message-ID: <9211121612.AA03658@newsu.shearson.com> >From: crunch at netcom.com (John Draper) > Then, there is the speed of generating these random numbers, >and how we will want to deal with the possibility of inadequate >speed. I suspect that serial transmission at 9500 baud might >be easily obtained, but going much faster withoug "drift" might >be problematic as Tim May pointed out. I'd like to point out that higher data rates are very very desirable. One would like to be able to cut a pair of CD's for use as one time pads in a reasonable amount of time -- at 9600 baud its going to take a LONG time to do. You can always run multiple units in parallel, but its probably good to get the cost/bitrate ratio as low as possible. Perry From hughes at soda.berkeley.edu Thu Nov 12 09:45:09 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Thu, 12 Nov 92 09:45:09 PST Subject: random generator In-Reply-To: <9211121612.AA03658@newsu.shearson.com> Message-ID: <9211121745.AA27478@soda.berkeley.edu> >I'd like to point out that higher data rates are very very desirable. And higher data rates are more expensive. If you're making one time pads, you need high bit rates, but otherwise you don't. 10Kbps is overcapacity for personal use. Let's do an estimate. Suppose all you use your random numbers for is to create session keys for socket connections. Now lets say you need to open a socket about once a minute. Since you need, say, 500 bits for a DH key exchange, that's a bit rate of about 10 bits per second. One can cache bits coming in from the random number generator in a ring buffer. You can make this ring buffer arbitarily large, or even virtualize it to disk and make it appear as infinite in size. Then you could run your generator continuously and always have enough bits available for use. If you're using a generator for making session keys, then you just don't need that high a bandwidth. Now the $/bps for the Newbridge chip is much lower, but for personal use you throw away too many of its bits to make it worthwhile. This higher bandwidth chip would be useful in a server of some sort, where you are making session keys more than once per second. Proposal: Make this random number generator operate at 100 bps. If higher bit rates are the same price, fine. But a specific design criterion of 100 bps should be a practical and economical goal. Eric From omega at spica.bu.edu Thu Nov 12 09:51:33 1992 From: omega at spica.bu.edu (The Omega) Date: Thu, 12 Nov 92 09:51:33 PST Subject: No Subject Message-ID: <9211121751.AA01503@spica.bu.edu> ---- article one ---- Subject: Reports of "Raid" on 2600 Washington Meeting 11/09/92 From: newsbytes at clarinet.com Date: 9 Nov 92 20:51:16 GMT WASHINGTON, D.C., U.S.A., 1992 NOV 9 (NB) -- The publisher of a well-known hacker magazine claims a recent meeting attended by those interested in the issues his magazine raises was disrupted by threats of arrest by security and Arlington, Virginia police officers. Eric Corley, also known as "Emmanuel Goldstein," editor and publisher of "2600 Magazine: The Hacker Quarterly," told Newsbytes that the meeting was held November 6th at the Pentagon City Mall outside Washington, DC was disrupted and material was confiscated in the raid. 2600 Magazine promotes monthly meetings of hackers, press, and other interested parties throughout the country. The meetings are held in public locations on the first Friday evening of the month and the groups often contact each other by telephone during the meetings. Corley told Newsbytes that meetings were held that evening in New York, Washington, Philadelphia, Cambridge, St. Louis, Chicago, Los Angeles and San Francisco. Corley said, "While I am sure that meetings have been observed by law enforcement agencies, this is the only time that we have been harassed. It is definitely a freedom of speech issue." According to Craig Neidorf, who was present at the meeting and was distributing applications for membership in Computer Professionals For Social Responsibility (CPSR), "I saw the security officers focusing on us. Then they started to come toward us from a number of directions under what seemed to be the direction of a person with a walkie-talkie on a balcony. When they approached, I left the group and observed the security personnel encircling the group of about 30 gatherers. The group was mainly composed of high school and college students. The guards demanded to search the knapsacks and bags of the gatherers. They confiscated material, including CPSR applications, a copy of Mondo 2000 (a magazine), and other material." He adds that the guards also confiscated film "from a person trying to take pictures of the guards. When a hacker called "HackRat" attempted to copy down the names of the guards, they took his pencil and paper." Neidorf continued, "I left to go outside and rejoined the group when they were ejected from the mall. The guards continued challenging the group and told them that they would be arrested if they returned. When one of the people began to take pictures of the guards, the apparent supervisor became excited and threatening but did not confiscate the film." Neidorf also said, "I think that the raid was planned. They hit right about 6:00 and they identified our group as "hackers" and said that they knew that this group met every month." Neidorf's story was supported by a Washington "hacker" called "Inhuman," who told Newsbytes, "I arrived at the meeting late and saw the group being detained by the guards. I walked along with the group as they were being ushered out and when I asked a person who seemed to be in authority his name, he pointed at a badge with his name written in script on it. I couldn't make out the name and, when I mentioned that to the person, he said 'If you can't read it, too bad.' I did read his name, 'C. Thomas,' from another badge." Inhuman also told Newsbytes that he was told by a number of people that the guards said that they were "acting on behalf of the Secret Service." He added, "I was also told that there were two police officers from the Arlington County Police present but I did not see them." Another attendee, Doug Luce, reports, "I also got to the DC meeting very late; 7:45 or so. It seemed like a coordinated harassment episode, not geared toward busting anyone, but designed to get people riled up, and maybe not come back to the mall." Luce adds that he overheard a conversation between someone who had brought a keyboard to sell. The person, he said, was harassed by security forces, one of whom said, "You aren't selling anything in my mall without a vendors permit!" Possible Secret Service involvement was supported by a 19 year-old college student known as the "Lithium Bandit," who told Newsbytes, "I got to the mall about 6:15 and saw the group being detained by approximately 5 Arlington County police and 5 security guards. When I walked over to see what was going on, a security guard asked me for an ID and I refused to show it, saying that I was about to leave. The guard said that I couldn't leave and told me that I had to see a police officer. When I did, the officer demanded ID and, when I once again refused, he informed me that I could be detained for up to 10 hours for refusing to produce identification. I gave in and produced my school ID which the police gave to the security people who copied down my name and social security number." Lithium Bandit continued, "When I asked the police what was behind this action, I was told that they couldn't answer but that 'the Secret Service is involved and we are within our rights doing this." The boy says he and others later went to the Arlington police station to get more information and were told only that there was a report of the use of a stolen credit card and two officers were sent to investigate. "They later admitted that it was 5 [officers]. While I was detained, I heard no mention of a credit card and there was no one arrested." Marc Rotenberg, director of CPSR's Washington office, told Newsbytes, "I have really no details on the incident yet but I am very concerned about the reports. Confiscation of CPSR applications, if true, is outrageous. I will find out more facts on Monday." Newsbytes was told by the Pentagon City Mall office that any information concerning the action would have to come from the director of security, Al Johnson, who was not available until Monday. The Arlington Country Police referred Newsbytes to a "press briefing recording" which had not been updated since the morning before the incident. Corley told Newsbytes, "There have been no reports of misbehavior by any of these people. They were obviously singled out because they were hackers. It's as if they were being singled out as an ethnic group. I admire the way the group responded -- in a courteous fashion. But it is inexcusable that it happened. I will be at the next Washington meeting to insure that it doesn't happen again." The manager of one of New York state's largest malls provided background information to Newsbytes on the rights of malls to police those on mall property, saying, "The primary purpose of a mall is to sell. The interior of the mall is private property and is subject to the regulations of the mall. The only requirement is that the regulations be enforced in an even-handed manner. I do not allow political activities in my mall so I could not make an exception for Democrats. We do allow community groups to meet but they must request space at least two weeks before the meeting and must have proper insurance. Our regulations also say that groups of more than 4 may not congregate in the mall." The spokeswoman added that mall security can ask for identification from those who violate regulations and that they may be barred from the mall for a period of 6 months. She added, "Some people feel that mall atriums and food courts are public space. They are not and the industry is united on this. If the malls were to receive tax benefits for the common space and public service in snow removal and the like, it could possibly be a public area but malls are taxed on the entire space and are totally private property, subject to their own regulations. If a group of 20 or more congregated in my mall, they would be asked to leave." ---- article two ---- Subject: Secret Service Role Questioned in "2600 Washington Raid" 11/10/92 From: newsbytes at clarinet.com Date: 10 Nov 92 21:03:23 GMT WASHINGTON, D.C., U.S.A., 1992 NOV 10 (NB) -- In the aftermath of an action on Friday, November 6th by members of the Pentagon City Mall Police and police from Arlington County, VA in which those attending a 2600 meeting at the mall were ordered from the premises, conflicting stories continue to appear. Attendees at the meeting have contended to Newsbytes that members of the mall police told them that they were "acting on behalf of the Secret Service." They also maintain that the mall police confiscated material from knapsacks and took film from someone attempting to photograph the action and a list of the names of security officers that one attendee was attempting to compile. Al Johnson, chief of security for the mall, denied these allegations to Newsbytes, saying, "No one said that we were acting on behalf of the Secret Service. We were merely enforcing our regulations. While the group was not disruptive, it had pulled tables together and was having a meeting in our food court area. The food court is for people eating and is not for meetings. We therefore asked the people to leave." Johnson denied that security personnel took away any film or lists and further said: "We did not confiscate any material. The group refused to own up to who owned material on the tables and in the vicinity so we collected it as lost material. If it turns out that anything did belong to any of those people, they are welcome to come in and, after making proper identification, take the material." In a conversation early on November 9th, Robert Rasor, Secret Service agent-in-charge of computer crime investigations, told Newsbytes that having mall security forces represent the Secret Service is not something that was done and, that to his knowledge, the Secret Service had no involvement with any Pentagon City mall actions on the previous Friday. A Newsbytes call to the Arlington County police was returned by a Detective Nuneville who said that her instructions were to refer all questions concerning the matter to agent David Adams of the Secret Service. She told Newsbytes that Adams would be providing all information concerning the involvement of both the Arlington Police and the Secret Service in the incident. Adams told Newsbytes: "The mall police were not acting as agents for the Secret Service. Beyond that, I can not confirm or deny that there is an ongoing investigation." Adams also told Newsbytes that: "While I cannot speak for the Arlington police, I understand that their involvement was due to an incident unrelated to the investigation." Marc Rotenberg, director of the Washington office of Computer Professionals for Social Responsibility (CPSR), told Newsbytes that "CPSR has reason to believe that the detention of people at the Pentagon City Mall last Friday was undertaken at the behest of the Secret Service, which is a federal agency." "If that is the case, then there was an illegal search of people at the mall. There was no warrant and no indication of probable illegal activity. This raises constitutional issues. We have undertaken the filing of a Freedom of Information Act (FOIA) request to determine the scope, involvement and purpose of the Secret Service in this action," he said. 2600 meetings are held on the evening of the first Friday of each month in public places and malls in New York City, Washington, Philadelphia, Cambridge, St. Louis, Chicago, Los Angeles and San Francisco. They are promoted by "2600 Magazine: The Hacker Quarterly" and are attended by a variety of persons interested in telecommunications and so-called "hacker issues." The New York meeting, the oldest of its kind, is regularly attended by Eric Corley a/k/a Emmanuel Goldstein, editor and publisher of 2600, hackers, journalists, corporate communications professionals and other interested parties. It is known to have been the subject of surveillance at various times by law enforcement agencies conducting investigations into allegations of computer crime. Corley told Newsbytes: "While I'm sure that meetings have been observed by law enforcement agencies, this is the only time that we have been harassed. It's definitely a freedom of speech issue." Corley also that he plans to be at the December meeting in Washington "to insure that it doesn't happen again." From omega at spica.bu.edu Thu Nov 12 10:50:30 1992 From: omega at spica.bu.edu (The Omega) Date: Thu, 12 Nov 92 10:50:30 PST Subject: DC 2600 -- Secret Service Involvement? Message-ID: <9211121850.AA01807@spica.bu.edu> For more info, see the recent Computer Underground Digest. From strat at intercon.com Thu Nov 12 11:28:41 1992 From: strat at intercon.com (Bob Stratton) Date: Thu, 12 Nov 92 11:28:41 PST Subject: DC 2600 mtg Message-ID: <9211121425.AA32211@horton.intercon.com> Hi all... I was at the latter part of the Washington 2600 meeting, feel free to ask me questions if you want. By the way, today's article about the event was yet another example of the media promoting hysteria about technologically competent people. The whole article was of the "A hacker is someone who breaks into systems" model. It makes me sick, and I think that the crypto community (the part NOT employed by DoD) is next for this sort of misrepresentation. Cheers, Bob Stratton Engineer, InterCon Systems Corp. strat at intercon.com +1 703 709 5525 (W) From gsassoun at shearson.com Thu Nov 12 12:34:29 1992 From: gsassoun at shearson.com (Garo Sassouni) Date: Thu, 12 Nov 92 12:34:29 PST Subject: Subscribe Message-ID: <9211122007.AA15091@tardis.shearson.com> I would like to subscribe to the cypherpunks group. Thanks in advance From Barry.Kapke at f33.n125.z1.FIDONET.ORG Thu Nov 12 12:39:29 1992 From: Barry.Kapke at f33.n125.z1.FIDONET.ORG (Barry Kapke) Date: Thu, 12 Nov 92 12:39:29 PST Subject: cypherpunk-request Message-ID: <3585.2B02B9C5@fidogate.FIDONET.ORG> This is a request to be added to the mailing list. My addressing to cypherpunk-request at toad.com failed. Thanks. ::::::::::::::::::::::::::::::::::: Barry.Kapke at f33.n125.z1.FIDONET.ORG ::::::::::::::::::::::::::::::::::: -- Barry Kapke - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!33!Barry.Kapke INTERNET: Barry.Kapke at f33.n125.z1.FIDONET.ORG From 74076.1041 at CompuServe.COM Thu Nov 12 13:18:01 1992 From: 74076.1041 at CompuServe.COM (Hal) Date: Thu, 12 Nov 92 13:18:01 PST Subject: No Subject Message-ID: <9211122117.AA29329@iha.compuserve.com> Bcc: Blind Recipients List:; Subject: Why hardware random numbers? Message-ID: <921112211037_74076.1041_DHJ46-1 at CompuServe.COM> I don't understand the desire for hardware-based random number generators. It seems to me that a decent software RNG would be adequate for the main uses that I have heard of for RNG's (mostly session key generation). Seed the RNG initially with a nice random set of characters typed in by the user, plus timing information based on the rate of timing of those characters. Also use the local system clock, and possibly a hash of some sectors of the disk or some files on /tmp. Create a pool of random numbers in this way. As you use them, refill the pool, making the refilled bytes a function of the current system clock, and whatever message you are encrypting (or some other appropriate global state). Use a nice strong RNG based on DES, MD5, IDEA, or some other cypher or hash function. I don't think anyone could break the resulting random stream without a physical attack on your computer. Why pay $50 to $200 for a hardware device when you can get the same effect in software that already exist? Both PGP and RIPEM, I think, use the above techniques for their random numbers. Hal 74076.1041 at compuserve.com From nobody at alumni.cco.caltech.edu Thu Nov 12 13:52:59 1992 From: nobody at alumni.cco.caltech.edu (nobody at alumni.cco.caltech.edu) Date: Thu, 12 Nov 92 13:52:59 PST Subject: No Subject Message-ID: <9211122154.AA13213@alumni.cco.caltech.edu> I have a new address where I am running a cryptographically protected, anonymous remailer based on Eric Hughes' perl scripts. It is: . To use the server, put "Request-Remailing-To: " into the header of the message, and send it to the above address. If your mailer won't let you put things into message headers, instead make the first line of your message body be just the two characters "::", and make the next line be "Request-Remailing-To: ", and make the next line be blank. The "::" tells the remailer to take the following lines, up to a blank one, and put them into the header. This particular remailer has PGP integrated into it so that you can encrypt your messages to the remailer. That way a snooper can't see the "Request-Remailing-To" information and can't tell who you are sending to. To use this feature, create a message and put "::" and "Request-Remailing-To:" lines at the beginning, followed by a blank line. Then encrypt this whole message, including these extra lines, using PGP with the remailer key below. (Remember to use the -a flag for ASCII output.) Now, you have to do one more thing. You have to put "Encrypted: PGP" into the message header when you send this message. Again, if you can't put stuff into message headers, you have to edit the PGP ASCII output file to add a line of "::", then a line saying "Encrypted: PGP", then a blank line. This can then be sent to the address above. It will decrypt the message, find the "Request-Remailing-To" line, and forward it for you. This machine is on the Internet so it should have nice, fast turnaround. Be aware that this is a multi-user machine so the encryption is not super secure. Don't bet your life on these messages not being broken. This is strictly experimental at this time. If anyone would like help getting PGP or one of these remailers operating on your local Unix machine, let me know and I will offer any advice that I can. I would really like to see more people than just Eric and myself running remailers. There is a more advanced capability made possible by the cryptographic remailer, which is an "anonymous return address." The idea is, I can post to a group like this, or a usenet group, using a pseudonym. I also include my anonymous return address, which is basically my regular return address, encrypted using the public key of a remailer. People can use this anonymous return address to send to me by forwarding it through the remailer, which decrypts the address, finds out who I am, and sends it to me. The people communicating to me don't even have to know who I am, or what my email address is. Two people could communicate using email, with both of their identities being protected from the other. This kind of capability can really be important in crypto-privacy. Hal 74076.1041 at compuserve.com P.S. Here is the PGP key for this remailer: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.01 mQBNAisCtU0AAAEB/jNOYzN1B2YzOxlK/Zb6axoOaGlPq5I7DV9GH3hcGRN5N6Fi T4sRLhi53Sc5rUdYDa8mFQd4tqvFG6rHcT8LtDcABRG0KlJlbWFpbGluZyBTZXJ2 aWNlIDxoYWxAYWx1bW5pLmNhbHRlY2guZWR1Pg== =K00H -----END PGP PUBLIC KEY BLOCK----- From Tom.Jennings at f111.n125.z1.FIDONET.ORG Thu Nov 12 14:28:48 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Thu, 12 Nov 92 14:28:48 PST Subject: (fwd) A Silver Bullet to Limit Crypto? Message-ID: <3587.2B02D6F4@fidogate.FIDONET.ORG> U> From: gg at well.sf.ca.us (George A. Gleason) U> Rapid promulgation of decent user-friendly PKSs looks U> pretty essential at this point. I'm thinking, how about U> approaching Apple to see if they'll include a PKS along U> with their Macs, as bundled software, sort of like U> Hypercard. Even if the PKS which is used, has some U> problem with is, as for instance the old trapdoor-knapsack U> system, **anything** is preferable to nothing at all when U> it comes to getting the public educated. I agree 101% -- I'd rather have a "bad" system in place, with people asking for a good one (and roundly complaining about the short-sighted implementors :-) than to sit and wait until we can implement the "right" system. I'd much rather have email users want privacy and rag about their compromised system. Even a relatively poor one buts some substantial blocks into routine bulk monitoring of traffic... As frequently happens, the real problem is not technical. --- ReadMail * Origin: tomj at fidosw.fidonet.org / World Power Systems (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET: Tom.Jennings at f111.n125.z1.FIDONET.ORG From romkey at asylum.sf.ca.us Thu Nov 12 15:15:16 1992 From: romkey at asylum.sf.ca.us (John Romkey) Date: Thu, 12 Nov 92 15:15:16 PST Subject: (fwd) A Silver Bullet to Limit Crypto? In-Reply-To: <3587.2B02D6F4@fidogate.FIDONET.ORG> Message-ID: <9211122315.AA09487@asylum.sf.ca.us> Date: Thu, 12 Nov 92 15:09:47 PDT From: Tom.Jennings at F111.N125.Z1.FIDONET.ORG (Tom Jennings) I'd much rather have email users want privacy and rag about their compromised system. Even a relatively poor one buts some substantial blocks into routine bulk monitoring of traffic... As long as they *know* it's compromised. Too many people out there think the Internet, for instance, is secure already. They don't realize how easily one can spy on their email, or find out if they're subscribed to a mailing list. - john romkey ELF Communications romkey at ELF.com From omega at spica.bu.edu Thu Nov 12 15:33:56 1992 From: omega at spica.bu.edu (The Omega) Date: Thu, 12 Nov 92 15:33:56 PST Subject: No Subject Message-ID: <9211122333.AA03023@spica.bu.edu> ---- article one ---- Subject: Reports of "Raid" on 2600 Washington Meeting 11/09/92 From: newsbytes at clarinet.com Date: 9 Nov 92 20:51:16 GMT WASHINGTON, D.C., U.S.A., 1992 NOV 9 (NB) -- The publisher of a well-known hacker magazine claims a recent meeting attended by those interested in the issues his magazine raises was disrupted by threats of arrest by security and Arlington, Virginia police officers. Eric Corley, also known as "Emmanuel Goldstein," editor and publisher of "2600 Magazine: The Hacker Quarterly," told Newsbytes that the meeting was held November 6th at the Pentagon City Mall outside Washington, DC was disrupted and material was confiscated in the raid. 2600 Magazine promotes monthly meetings of hackers, press, and other interested parties throughout the country. The meetings are held in public locations on the first Friday evening of the month and the groups often contact each other by telephone during the meetings. Corley told Newsbytes that meetings were held that evening in New York, Washington, Philadelphia, Cambridge, St. Louis, Chicago, Los Angeles and San Francisco. Corley said, "While I am sure that meetings have been observed by law enforcement agencies, this is the only time that we have been harassed. It is definitely a freedom of speech issue." According to Craig Neidorf, who was present at the meeting and was distributing applications for membership in Computer Professionals For Social Responsibility (CPSR), "I saw the security officers focusing on us. Then they started to come toward us from a number of directions under what seemed to be the direction of a person with a walkie-talkie on a balcony. When they approached, I left the group and observed the security personnel encircling the group of about 30 gatherers. The group was mainly composed of high school and college students. The guards demanded to search the knapsacks and bags of the gatherers. They confiscated material, including CPSR applications, a copy of Mondo 2000 (a magazine), and other material." He adds that the guards also confiscated film "from a person trying to take pictures of the guards. When a hacker called "HackRat" attempted to copy down the names of the guards, they took his pencil and paper." Neidorf continued, "I left to go outside and rejoined the group when they were ejected from the mall. The guards continued challenging the group and told them that they would be arrested if they returned. When one of the people began to take pictures of the guards, the apparent supervisor became excited and threatening but did not confiscate the film." Neidorf also said, "I think that the raid was planned. They hit right about 6:00 and they identified our group as "hackers" and said that they knew that this group met every month." Neidorf's story was supported by a Washington "hacker" called "Inhuman," who told Newsbytes, "I arrived at the meeting late and saw the group being detained by the guards. I walked along with the group as they were being ushered out and when I asked a person who seemed to be in authority his name, he pointed at a badge with his name written in script on it. I couldn't make out the name and, when I mentioned that to the person, he said 'If you can't read it, too bad.' I did read his name, 'C. Thomas,' from another badge." Inhuman also told Newsbytes that he was told by a number of people that the guards said that they were "acting on behalf of the Secret Service." He added, "I was also told that there were two police officers from the Arlington County Police present but I did not see them." Another attendee, Doug Luce, reports, "I also got to the DC meeting very late; 7:45 or so. It seemed like a coordinated harassment episode, not geared toward busting anyone, but designed to get people riled up, and maybe not come back to the mall." Luce adds that he overheard a conversation between someone who had brought a keyboard to sell. The person, he said, was harassed by security forces, one of whom said, "You aren't selling anything in my mall without a vendors permit!" Possible Secret Service involvement was supported by a 19 year-old college student known as the "Lithium Bandit," who told Newsbytes, "I got to the mall about 6:15 and saw the group being detained by approximately 5 Arlington County police and 5 security guards. When I walked over to see what was going on, a security guard asked me for an ID and I refused to show it, saying that I was about to leave. The guard said that I couldn't leave and told me that I had to see a police officer. When I did, the officer demanded ID and, when I once again refused, he informed me that I could be detained for up to 10 hours for refusing to produce identification. I gave in and produced my school ID which the police gave to the security people who copied down my name and social security number." Lithium Bandit continued, "When I asked the police what was behind this action, I was told that they couldn't answer but that 'the Secret Service is involved and we are within our rights doing this." The boy says he and others later went to the Arlington police station to get more information and were told only that there was a report of the use of a stolen credit card and two officers were sent to investigate. "They later admitted that it was 5 [officers]. While I was detained, I heard no mention of a credit card and there was no one arrested." Marc Rotenberg, director of CPSR's Washington office, told Newsbytes, "I have really no details on the incident yet but I am very concerned about the reports. Confiscation of CPSR applications, if true, is outrageous. I will find out more facts on Monday." Newsbytes was told by the Pentagon City Mall office that any information concerning the action would have to come from the director of security, Al Johnson, who was not available until Monday. The Arlington Country Police referred Newsbytes to a "press briefing recording" which had not been updated since the morning before the incident. Corley told Newsbytes, "There have been no reports of misbehavior by any of these people. They were obviously singled out because they were hackers. It's as if they were being singled out as an ethnic group. I admire the way the group responded -- in a courteous fashion. But it is inexcusable that it happened. I will be at the next Washington meeting to insure that it doesn't happen again." The manager of one of New York state's largest malls provided background information to Newsbytes on the rights of malls to police those on mall property, saying, "The primary purpose of a mall is to sell. The interior of the mall is private property and is subject to the regulations of the mall. The only requirement is that the regulations be enforced in an even-handed manner. I do not allow political activities in my mall so I could not make an exception for Democrats. We do allow community groups to meet but they must request space at least two weeks before the meeting and must have proper insurance. Our regulations also say that groups of more than 4 may not congregate in the mall." The spokeswoman added that mall security can ask for identification from those who violate regulations and that they may be barred from the mall for a period of 6 months. She added, "Some people feel that mall atriums and food courts are public space. They are not and the industry is united on this. If the malls were to receive tax benefits for the common space and public service in snow removal and the like, it could possibly be a public area but malls are taxed on the entire space and are totally private property, subject to their own regulations. If a group of 20 or more congregated in my mall, they would be asked to leave." ---- article two ---- Subject: Secret Service Role Questioned in "2600 Washington Raid" 11/10/92 From: newsbytes at clarinet.com Date: 10 Nov 92 21:03:23 GMT WASHINGTON, D.C., U.S.A., 1992 NOV 10 (NB) -- In the aftermath of an action on Friday, November 6th by members of the Pentagon City Mall Police and police from Arlington County, VA in which those attending a 2600 meeting at the mall were ordered from the premises, conflicting stories continue to appear. Attendees at the meeting have contended to Newsbytes that members of the mall police told them that they were "acting on behalf of the Secret Service." They also maintain that the mall police confiscated material from knapsacks and took film from someone attempting to photograph the action and a list of the names of security officers that one attendee was attempting to compile. Al Johnson, chief of security for the mall, denied these allegations to Newsbytes, saying, "No one said that we were acting on behalf of the Secret Service. We were merely enforcing our regulations. While the group was not disruptive, it had pulled tables together and was having a meeting in our food court area. The food court is for people eating and is not for meetings. We therefore asked the people to leave." Johnson denied that security personnel took away any film or lists and further said: "We did not confiscate any material. The group refused to own up to who owned material on the tables and in the vicinity so we collected it as lost material. If it turns out that anything did belong to any of those people, they are welcome to come in and, after making proper identification, take the material." In a conversation early on November 9th, Robert Rasor, Secret Service agent-in-charge of computer crime investigations, told Newsbytes that having mall security forces represent the Secret Service is not something that was done and, that to his knowledge, the Secret Service had no involvement with any Pentagon City mall actions on the previous Friday. A Newsbytes call to the Arlington County police was returned by a Detective Nuneville who said that her instructions were to refer all questions concerning the matter to agent David Adams of the Secret Service. She told Newsbytes that Adams would be providing all information concerning the involvement of both the Arlington Police and the Secret Service in the incident. Adams told Newsbytes: "The mall police were not acting as agents for the Secret Service. Beyond that, I can not confirm or deny that there is an ongoing investigation." Adams also told Newsbytes that: "While I cannot speak for the Arlington police, I understand that their involvement was due to an incident unrelated to the investigation." Marc Rotenberg, director of the Washington office of Computer Professionals for Social Responsibility (CPSR), told Newsbytes that "CPSR has reason to believe that the detention of people at the Pentagon City Mall last Friday was undertaken at the behest of the Secret Service, which is a federal agency." "If that is the case, then there was an illegal search of people at the mall. There was no warrant and no indication of probable illegal activity. This raises constitutional issues. We have undertaken the filing of a Freedom of Information Act (FOIA) request to determine the scope, involvement and purpose of the Secret Service in this action," he said. 2600 meetings are held on the evening of the first Friday of each month in public places and malls in New York City, Washington, Philadelphia, Cambridge, St. Louis, Chicago, Los Angeles and San Francisco. They are promoted by "2600 Magazine: The Hacker Quarterly" and are attended by a variety of persons interested in telecommunications and so-called "hacker issues." The New York meeting, the oldest of its kind, is regularly attended by Eric Corley a/k/a Emmanuel Goldstein, editor and publisher of 2600, hackers, journalists, corporate communications professionals and other interested parties. It is known to have been the subject of surveillance at various times by law enforcement agencies conducting investigations into allegations of computer crime. Corley told Newsbytes: "While I'm sure that meetings have been observed by law enforcement agencies, this is the only time that we have been harassed. It's definitely a freedom of speech issue." Corley also that he plans to be at the December meeting in Washington "to insure that it doesn't happen again." From omega at spica.bu.edu Thu Nov 12 15:34:46 1992 From: omega at spica.bu.edu (The Omega) Date: Thu, 12 Nov 92 15:34:46 PST Subject: IRC Bot Message-ID: <9211122334.AA03027@spica.bu.edu> On a related tangent, There's an interesting bot on IRC in the #hack room, called MACE0, whose purpose is: >> mACe0 exists primarily to accept requests for access to a secure mailing list but it performs other mundane functions as well. To apply for access to the mACe0 mailing list you need to do three things. First, get PGP up and running on your system so that you can generate RSA public keys. Second, get one of the questionaires listing below so u can fill it out. As with all classic elite k-rad systems, we have to know your capabilities and limits so that we can appropriately deny your access. If this bothers you, too bad; the old school k-rad d00dz have seen this type of bullshit before and know exactly what to do. Finally, use mACe0's public key to encrypt your Questionaire and DCC it to mACe0. mACe0 will also take article submissions and public keys via DCC; both of which should be encrypted with mACe0's public key. *Note, when submitting public keys: a) use pgp -kxa to extract them in ascii. b) use a fairly unique filename so DCC won't overwrite your key. /msg mACe0 info .Display this file again. /msg mACe0 dir .Dir of files available /msg mACe0 get filename .To get a file /msg mACe0 sendkey .DCCs mACe0's public key /msg mACe0 quest.1 .Get Hack specific Questionaire /msg mACe0 quest.2 .Get Phreak specific Questionaire /msg mACe0 quest.3 .Get Phreak/Hack mixed Questioniare << From tcmay at netcom.com Thu Nov 12 16:21:35 1992 From: tcmay at netcom.com (Timothy C. May) Date: Thu, 12 Nov 92 16:21:35 PST Subject: The Crypto Singularity Message-ID: <9211130018.AA11046@netcom.netcom.com> We appear to be entering the long-awaited "Crypto Singularity." (Well, long-awaited by me at least!) A "singularity" in the sense of extremely rapid changes in outlook, technology, and culture. (The use comes from Vernor Vinge's science fictional "singularity" in new technologies, as described in "Marooned in Realtime," and appropriated for their own purposes by the nanotechnology enthusiasts.) Some evidence for this "Crypto Singularity": * the appearance of fully-encrypted remailers, using the Perl scripts of Eric Hughes and Hal Finney. With several more such remailing sites (and recall John Little's offer to place the s/w on Portal), a critical mass of remailers may exist. (A packet remailed through 10 remailers, each storing 10 such encrypted packets before remailing, has an intrinsic diffusivity of 10^10. Of course, there will be far fewer than 10 billion messages, but the point is clear that the origin of a message is effectively untraceable.) * the spread of PGP, onto Internet sites, FidoNet, and hacker boards, IRCs, and the like. (I expect the adoption of PGP by the phone hacker/phreaker community--the community so far the main target of formal charges, as in the Legion of Doom, Len Rose, and Sun Devil cases--is setting off alarms in the law enforcement community.) * the "Hacker Crackdown" spreading to "2600" (will Cyperpunks be next? Will the 150-200 of us get raided?) and mere _meetings_ of hacker folks. * the incredible excitement over these topics at the Hackers Conference, with the sense that these are no longer just abstract ideas. * the interest by several journalists in covering these matters (more on this if things develop). * articles in "Scientific American" just in the past months...David Chaum's work on digital cash, and quantum cryptography. * the firestorm of comments (over 500) about the proposal to register cryptographic keys. All of these point to an accelerating situation. Things may get very interesting and very sticky in the next several months, which is quite a bit faster than I'd expected. Justice and the FBI may not wait until the next Administration to get something started. Perhaps a high-publicity case involving drugs or child molestors will be used as a pretext to crack down. This crackdown may not need new laws...the existing conspiracy, RICI Act, and espionage laws may be enough to "set some examples." Our next Cypherpunks meeting (Saturday, 21 November) should look at some of these issues. "Time is of the essence." --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at 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^756839 | PGP Public Key: awaiting Macintosh version. From mitra at pandora.sf.ca.us Thu Nov 12 21:22:58 1992 From: mitra at pandora.sf.ca.us (Mitra) Date: Thu, 12 Nov 92 21:22:58 PST Subject: How to subscribe Message-ID: <9211122121.aa04435@pandora.sf.ca.us> OK, I give up - what is the key I need to get on this list, I've tried cypherpunks-request at toad.com, and listserv at toad.com but neither account exists. Can someone please add me to it. - Mitra P.S. If you reply, do so by email to mitra at pandora.sf.ca.us not to the list, as I cant receive the list yet :-) / From crunch at netcom.com Fri Nov 13 00:00:51 1992 From: crunch at netcom.com (John Draper) Date: Fri, 13 Nov 92 00:00:51 PST Subject: Rander box and other stuff Message-ID: <9211130757.AA27092@netcom2.netcom.com> To Cypherpunks: I think I have a rough description of the hardware serial random generator I want to build. I want to call it the "Rander box" for lack of a better name. It will have two serial connectors, one an input, and other the output, and connect to a modem or serial port. Physically, it should have dip switch to select baud rate, and an on-off switch. When switched on, and a "cr" (or some other character) is sent to it, random bytes will stream out continiously. Another "cr" will stop the byte stream. At least this is ONE approach. If anyone can think of a better way, Pse speak up. Next week, I plan on consulting with another hardware guru and formulate an initial design. I already know what components need to go into it, and now I want to try and eliminate an extra UART if I can figure out how to turn on and off the random stream via software. The internal code of PGP (I am told) uses an internal buffer to hold the random bytes, generated my environmental changes such as key strokes, mouse movements, or other external actions. Some of the Mac implementors are discussing the feasability of not maintaining 100% portability. I suggested that we break up the PGP program into four parts. a) Incryption engine b) Key management engine. c) GUI interface (DOS, MacOS, UNIX, Windows, etc) d) Random number generator (machine dependent, possibly hardware) Parts (a) and (b) are the "portable" parts, and (c) and (d) are the machine dependent parts. Because the Mac is not multi-tasking, we can get around that problem by implementing a random number generator as a driver. Mac drivers provide for "periodic" code to be called as often as possible, and there are plenty of places where this driver can "look for" environmental changes to generate random numbers using the hashing stuff that Phil implemented. Naturally, the IBM-PC and UNIX versions of software random number generation would be different. But as far as the Incryption and Key generators are concerned, all they need to do, is to look into the random "seed" buffer. Implementing the random number generation as a driver also affords the possibility of having total independence of a hardware device, and if one is desired, no changes to the code will be necessary to have one. We just drop an appropriate INIT into the system folder which will contain the appropriate driver. This is the Mac way of doing things. One other problem I am having in participating in this group is the extra phone expenses I will have. I cannot get on Netcom's local lines from here anymore because they are always busy, and there is a lot of other unconsiderate people that hog up all the local lines for many hours at a time, so mail responses to and from me, may take days. For instance, I cannot participate in any IRC chats unless I get local access, as I am unemployed and cannot afford to call out of my area. So please excuse any slow responses you might get from me. John D. From hughes at soda.berkeley.edu Fri Nov 13 01:20:39 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Fri, 13 Nov 92 01:20:39 PST Subject: Rander box In-Reply-To: <9211130757.AA27092@netcom2.netcom.com> Message-ID: <9211130920.AA27066@soda.berkeley.edu> > It will have two serial connectors, one an input, and other the >output, and connect to a modem or serial port. Physically, it should >have dip switch to select baud rate, and an on-off switch. Some simplifications I might suggest: I only think you need an output connector. See below. If you can power it off the RS-232 line, you won't need a power switch. You should be able to draw enough power off, say, the DTR line to power a simple thing like this. For a dedicated random number generator with low bandwidth, there's not much reason for variable baud rate. I'd use a fixed baud rate of, say 1200, or even 300. If you make it low enough you could just kludge together a serial interface, but with the low cost of UART's, it's probably not worth it. You might also consider using a PIC, which has built-in serial. > When switched on, and a "cr" (or some other character) is sent to it, >random bytes will stream out continiously. I'd just make the thing spew continuously. It's not like you're losing real, er, information if you ignore a few random bits. This way you don't need the added circuitry for switching on and off. The actual use of this thing is going to require a device driver to buffer up random bits for later use. So all the flow control to the higher layer happens there anyway. And if the UART buffer overflows, so what? Eric From avalon at coombs.anu.edu.au Fri Nov 13 02:22:34 1992 From: avalon at coombs.anu.edu.au (Darren Reed) Date: Fri, 13 Nov 92 02:22:34 PST Subject: Datalink encryption Message-ID: <9211131022.AA20601@coombs.anu.edu.au> Hi, I've started playing around with doing encryption with telnet/telnetd again (I'm cheating and using the rsa/prime number code from pgp-2.0) and I'm stuck on what to use as the encryption for the actual flow of data. (hmm...if it works for telnet/telnetd, it can probably be made to work for the other r-daemons too :-) The idea is telnet and telnetd each choose an rsa pub & sec key, then use rsa to encode a key for the encryption scheme which both ends send and then use that for the base of the link encryption. Whatever I use for encryption of the session data has to work quickly and efficiently and I've got little idea about what to use/how to and would like some opinions on what would make a good choice. Any suggestions ? (Xor seems a possibility but straight Xor is very easy to break). I hope I'm not duplicating work that has already been done :) cheers, Darren From gg at well.sf.ca.us Fri Nov 13 02:26:03 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Fri, 13 Nov 92 02:26:03 PST Subject: (fwd) A Silver Bullet to Limit Crypto? Message-ID: <199211131024.AA12677@well.sf.ca.us> Responding to Simsong's critique of my comparison with voter registration. Point well taken. Perhaps a comparison with xerox machines in the old USSR would be more apt: the image of the copier in the guarded room with a loyal party cadre at the door, having all comers sign a book saying what their business is using the copier, and showing the material they'd be copying. The KGB of course was interested in preventing "crime" such as the spreading of anti-Soviet propaganda. Now we would say, oh that's not crime, it's just speech. Exactly: enciphered text is just speech, and if an actual crime is organised over a communications medium, the crime itself is the thing to prosecute, not the speech. The parallel of state officials controlling access to communications devices seems to be pretty straightforward to me. But would it fly on Main Street...? -gg From simsong at next.cambridge.ma.us Fri Nov 13 06:24:52 1992 From: simsong at next.cambridge.ma.us (Simson L. Garfinkel) Date: Fri, 13 Nov 92 06:24:52 PST Subject: (fwd) A Silver Bullet to Limit Crypto? Message-ID: <9211131425.AA09897@next.cambridge.ma.us> In making public-policy arguments, analogies are dangerous. You need to take time to explain them. The opposition can use other analogies. It's far more effective to argue on the facts. With respect to encryption, the outgoing administration has argued successfully that encryption is the computer equivalent of a saturday night special. That there is no reason to use encryption unless you don't want law enforcement to be able to read what you send. They say that it is only useful against lawful wiretaps, because there are other protections against unlawful wiretaps (ie: the law). The way to attack this is not by making an analogy to photocopiers, but by saying that there are many unlawful wiretaps, breakins, and thefts, and that most of them go unknown and unreported. Argue that most communications that people have an interest in protecting are not about kidnappings but about business dealings. Argue that encryption is vital for communicating with overseas offices, where wiretaps are even more common. Argue that it is important for protecting information on your hard disk which can be stolen. No need to argue with analogy. From pmetzger at shearson.com Fri Nov 13 08:03:32 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Fri, 13 Nov 92 08:03:32 PST Subject: DC 2600 mtg In-Reply-To: <9211121425.AA32211@horton.intercon.com> Message-ID: <9211131539.AA23245@newsu.shearson.com> >From: Bob Stratton >Hi all... >I was at the latter part of the Washington 2600 meeting, feel free to ask me >questions if you want. >By the way, today's article about the event was yet another example of the >media promoting hysteria about technologically competent people. The whole >article was of the "A hacker is someone who breaks into systems" model. It >makes me sick, and I think that the crypto community (the part NOT employed >by DoD) is next for this sort of misrepresentation. Pardon, but isn't 2600 magazine a magazine by crackers for crackers? 2600 is named after frequency of the disconnect tone used in blue boxes, isn't it? What I'm afraid of is that I will get confused with one of them -- I'm not sure they are necessarily being misrepresented. The tragedies come when idiots raid Steve Jackson Games and sieze copies of "Cyberpunk" instead of shutting down the infants breaking into TRW. Blurring the distinction between hackers and crackers is the last thing we need. Perry From pmetzger at shearson.com Fri Nov 13 08:05:11 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Fri, 13 Nov 92 08:05:11 PST Subject: (fwd) A Silver Bullet to Limit Crypto? In-Reply-To: <9211122315.AA09487@asylum.sf.ca.us> Message-ID: <9211131553.AA23336@newsu.shearson.com> >From: romkey at asylum.sf.ca.us (John Romkey) > Date: Thu, 12 Nov 92 15:09:47 PDT > From: Tom.Jennings at F111.N125.Z1.FIDONET.ORG (Tom Jennings) > I'd much rather have email users want privacy and rag about their > compromised system. Even a relatively poor one buts some substantial > blocks into routine bulk monitoring of traffic... >As long as they *know* it's compromised. Too many people out there >think the Internet, for instance, is secure already. They don't >realize how easily one can spy on their email, or find out if they're >subscribed to a mailing list. I don't see what the point of putting out mediocre things is at all, given that good things exist. PGP is free software. You need a good RSA implementation? There is one out there already. Why put out crap when gold is available and cheap? Perry From pmetzger at shearson.com Fri Nov 13 08:47:05 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Fri, 13 Nov 92 08:47:05 PST Subject: Rander box and other stuff In-Reply-To: <9211130757.AA27092@netcom2.netcom.com> Message-ID: <9211131631.AA23673@newsu.shearson.com> >From: crunch at netcom.com (John Draper) > I think I have a rough description of the hardware serial random >generator I want to build. I want to call it the "Rander box" for >lack of a better name. > It will have two serial connectors, one an input, and other the >output, and connect to a modem or serial port. Physically, it should >have dip switch to select baud rate, and an on-off switch. > When switched on, and a "cr" (or some other character) is sent to it, >random bytes will stream out continiously. Another "cr" will stop the >byte stream. At least this is ONE approach. If anyone can think of >a better way, Pse speak up. Why two serial connectors? RS232 is bidirectional, so you could send control signals down the same pipe the output comes off of. Also, why bother decoding the CRs? Seems like overkill. You could just have CTS/RTS or other lines on the connector control whether bits are clocked out or not. Perry From pmetzger at shearson.com Fri Nov 13 08:47:10 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Fri, 13 Nov 92 08:47:10 PST Subject: Rander box In-Reply-To: <9211130920.AA27066@soda.berkeley.edu> Message-ID: <9211131639.AA23711@newsu.shearson.com> >From: Eric Hughes >Some simplifications I might suggest: >For a dedicated random number generator with low bandwidth, there's >not much reason for variable baud rate. I'd use a fixed baud rate of, >say 1200, or even 300. I strongly disagree -- you really want to be able to do as high a bandwidth as possible. You might think we don't need one time pads ever anymore, but they are still the one and only provably absolutely secure method out there -- thus, sources of large numbers of random bits are going to be of use. >> When switched on, and a "cr" (or some other character) is sent to it, >>random bytes will stream out continiously. >I'd just make the thing spew continuously. It's not like you're >losing real, er, information if you ignore a few random bits. This >way you don't need the added circuitry for switching on and off. Bad idea. If I hooked it up to my workstation, I'd end up spending lots of CPU on the thing and possibly get nasty problems with buffers filling. Not everything on earth is a PC that will ignore the interrupts if the port isn't in use, you know. Perry From pmetzger at shearson.com Fri Nov 13 08:47:19 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Fri, 13 Nov 92 08:47:19 PST Subject: Datalink encryption In-Reply-To: <9211131022.AA20601@coombs.anu.edu.au> Message-ID: <9211131640.AA23728@newsu.shearson.com> >From: avalon at coombs.anu.edu.au (Darren Reed) >Hi, I've started playing around with doing encryption with telnet/telnetd >again (I'm cheating and using the rsa/prime number code from pgp-2.0) >and I'm stuck on what to use as the encryption for the actual flow of data. >(hmm...if it works for telnet/telnetd, it can probably be made to work for > the other r-daemons too :-) >The idea is telnet and telnetd each choose an rsa pub & sec key, then use >rsa to encode a key for the encryption scheme which both ends send and >then use that for the base of the link encryption. Use IDEA; its sitting right in the PGP code. Perry From hughes at soda.berkeley.edu Fri Nov 13 08:57:54 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Fri, 13 Nov 92 08:57:54 PST Subject: (fwd) A Silver Bullet to Limit Crypto? In-Reply-To: <9211131553.AA23336@newsu.shearson.com> Message-ID: <9211131657.AA13124@soda.berkeley.edu> From: Tom.Jennings at F111.N125.Z1.FIDONET.ORG (Tom Jennings) >I'd much rather have email users want privacy and rag about their >compromised system. From: romkey at asylum.sf.ca.us (John Romkey) >>As long as they *know* it's compromised. Perry: >PGP is free software. [...] Why put out crap when gold is available >and cheap? Perry, Tom _is_ using PGP. Please be aware of what the actual question is, rather than red-flagging on keywords like "compromised." Eric From strat at intercon.com Fri Nov 13 09:14:22 1992 From: strat at intercon.com (Bob Stratton) Date: Fri, 13 Nov 92 09:14:22 PST Subject: DC 2600 mtg Message-ID: <9211131211.AA10662@horton.intercon.com> > Date: Fri, 13 Nov 92 10:39:23 EST > From: pmetzger at shearson.com (Perry E. Metzger) > In-Reply-To: Bob Stratton's message of Thu, 12 Nov 1992 14:25:32 -0500 < > 9211121425.AA32211 at horton.intercon.com> Subject: DC 2600 mtg > > Pardon, but isn't 2600 magazine a magazine by crackers for crackers? > 2600 is named after frequency of the disconnect tone used in blue > boxes, isn't it? What I'm afraid of is that I will get confused with one > of them -- I'm not sure they are necessarily being misrepresented. In the case of the recent Washington Post article, I know for a fact that they're being misrepresented. I am one of the original attendees of that gathering, and I've been a professional in the computer industry for the past 9 years, not some rodent cracker downloading /etc/passwd files. Most of the people regularly attending that gathering are not involved in illicit acticity, but rather are computer and radio hobbyists, and in many cases are employed in those fields. I can personally attest to the fact that most of the discussions involve new hardware (announcements and purchases), and people's social lives. I'll grant you that 2600 frequently publishes items from miscreants, but the publisher's consistent goal has been to raise public awareness of the risks of various technologies, and their social side-effects. Unfortunately, the media environment in the country seems more oriented to hysteria and glossing over facts. > The tragedies come when idiots raid Steve Jackson Games and sieze > copies of "Cyberpunk" instead of shutting down the infants breaking into > TRW. Blurring the distinction between hackers and crackers is the last > thing we need. That's my point exactly - the media has all but abolished the distinction. They'd rather incite fear of the technically knowledgeable than educate the populace and the legislatures. The upshot of this are things like the "all hackers break into computers" definitions we frequently read, as well as the blatant misrepresentations on the part of cellular service providers that "your calls are private because it's illegal to listen to them". The papers and TV stations don't want to hear the fact that I can take an old TV set and listen to cellular phone calls without modifying it. I spend a lot of time with younger aspiring hackers in the hopes that I can help them establish productive goals, especially as regards careers. I do this for three reasons: 1) It's more personally satisfying to be paid for a job, than to have to look over your shoulder for law enforcement types. 2) The world's a little bit safer for every cracker who gets steered into a productive career. 3) My personal experience is that many of the college graduates with CS degrees these days are code grinders with no understanding or enthusiasm for an aesthetic engineering solution. I'd much rather see people who love what they do designing the things I use every day. I don't want to get too far afield of the topic of this list, so I'll stop here, but I really do believe, based on the precedents with firearms, radio receivers (scanning and paging), and recent law enforcement proposals, that cryptographic technology will be the next example vilified in the press of "things only evil people use". Bob Stratton Engineer, InterCon Systems Corp. strat at intercon.com +1 703 709 5525 (W) From wcs at anchor.ho.att.com Fri Nov 13 09:18:32 1992 From: wcs at anchor.ho.att.com (Bill Stewart) Date: Fri, 13 Nov 92 09:18:32 PST Subject: Rander box and other stuff Message-ID: <9211131719.AA05276@anchor.ho.att.com> John Draper asked for comments on a proposed interface to the Rander box. I would recommend using different characters to start and stop the transmission; if you use one character for both it's easy to get out of sync. ^S and ^Q are traditional, of course, and hardware flow control is another option (Perry's suggestion). Of course, not everybody's machine handles hardware flow control adequately. If you've got a dip switch annyway, you may want to use one switch to choose hardware or ^S/^Q. Bill From hughes at soda.berkeley.edu Fri Nov 13 09:21:09 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Fri, 13 Nov 92 09:21:09 PST Subject: Rander box In-Reply-To: <9211131639.AA23711@newsu.shearson.com> Message-ID: <9211131721.AA13968@soda.berkeley.edu> Perry on random bit rates: >I strongly disagree -- you really want to be able to do as high a >bandwidth as possible. Cryptography is all economics. The economics here is that John Draper is going to try to market this thing, not play with it in the lab. I don't know what experience you have with electronic design, so pardon me if I condescend. You don't sell features that most people don't need. You don't add parts when only a few people are going to use the feature. You make another version if there is sufficient demand for higher performance. One-time pads are expensive to make relative to other forms of security. Period. No argument. George Gleason and I had a long conversation via email over a period of weeks about this. He was convinced. If you don't believe me, ask him. The largest need for random bits right now is for key material. If you want to use one-time pads, fine. They are secure, no problem. The random number generator we are discussing here is not suitable for making one-time pads. If you want one, build it. It's not what most people need right now. In fact, if one-time pads are economical to use, then surely there is a market for one-time pad systems. Of course, if such a market does not exist, then one-time pads don't provide economical protection for the market as a whole. Which do you think? Re: continuous spewing of bits. Perry thinks this is a bad idea because it won't work with workstations well with respect to interrupts. In my previous post, I mentioned powering the device from DTR. DTR, for those of you not familiar with RS-232, is a device control line which is separately assertable. To turn the device off, toggle DTR. Presto! No more power, no more bits. Simple, when you know what DTR does. My original point remains, though: you don't need a power switch. Eric From anthrax at cow.com Fri Nov 13 09:57:45 1992 From: anthrax at cow.com (anthrax at cow.com) Date: Fri, 13 Nov 92 09:57:45 PST Subject: Hackers, Crackers Message-ID: <9211131757.AA05188@atdt.org> Let's cut out this elitist "crackers" crap altogether. It's just a little bit too PlaySkool, a little bit too "_I'm_ not a third grader! I'm a _fourth grader_!" The people who put so much energy into advertising how they're different tend not to know what the fuck they're talking about, in my experience. >> Pardon, but isn't 2600 magazine a magazine by crackers for crackers? << Beep. Sorry. Thank you for playing. >> 2600 is named after frequency of the disconnect tone used in blue boxes, isn't it? << 2600 is named after the frequency of the disconnect signal used in the telephone system for several decades. But so what? Doesn't PGP violate patent laws (or surely come pretty close)? Why would you want to be associated with PGP and its use, then? From gnu at cygnus.com Fri Nov 13 11:04:31 1992 From: gnu at cygnus.com (gnu at cygnus.com) Date: Fri, 13 Nov 92 11:04:31 PST Subject: Rander box and other stuff In-Reply-To: <9211130757.AA27092@netcom2.netcom.com> Message-ID: <9211131904.AA29178@cygnus.com> > Some of the Mac implementors are discussing the feasability of not > maintaining 100% portability. If portability was a problem, the Mac would certainly be an answer. Howabout actually trying to be Real Programmers and writing Real Software, like the folks who did all the work that you are now benefiting from? Instead of writing dead-end software that will only live on one platform? I know it isn't the Macintosh Way, but you might learn something. The last thing PGP needs is an installed base of Mac users who are always stuck three revs back because they forked off their own wierd version and couldn't upgrade when the rest of us do. John Gilmore From nobody at alumni.cco.caltech.edu Fri Nov 13 11:34:22 1992 From: nobody at alumni.cco.caltech.edu (nobody at alumni.cco.caltech.edu) Date: Fri, 13 Nov 92 11:34:22 PST Subject: Anonymous return addresses Message-ID: <9211131935.AA24489@alumni.cco.caltech.edu> Here is an example of how to use the cryptographic remailer at to implement an anonymous return address. Note: this material is a little complicated, but if you will take it a step at a time you will see that there's not really that much to it. Suppose I want to receive mail at my address of 74076.1041 at compuserve.com, but I don't want that address to be known. First, I create a file with the following contents. Call it t1: ---------------------- cut here ----------------------- :: Request-Remailing-To: 74076.1041 at compuserve.com ---------------------- cut here ----------------------- This is the same as what you would normally put at the front of a message to use the remailer. Note that the last line of the file is blank. Now, I encrypt that file, using PGP, with the public key of the remailer (the key is at the end of this message). I use the command, "pgp -ea t1 alumni". I say "alumni" as a shorthand for the address of the remailer on the keyring. This creates a file, t1.asc, which looks like: ---------------------- cut here ----------------------- -----BEGIN PGP MESSAGE----- Version: 2.01 hEwCG6rHcT8LtDcBAf0YbKADFELfaRay6LFviabwpICAAGMV1Pff8meY3ND5o7hu jNy9hQv2bIMM9IyUCF2LFpgamxmMlSwpGQIVbJLEpgAAAEzDG0ddg2oBmjQFzB4c E0d/k7uE8KgxtCg6Sc+l639LN18sv4UWpq0nnyGRTUGEjL9JqtYZOSlTsiSAFU2c 4RoHslyk51suvGokhod0 =XSHb -----END PGP MESSAGE----- ---------------------- cut here ----------------------- Now, I edit the file by adding lines saying "::", and "Encrypted: PGP", and a blank line, to the beginning (and I delete the blank line at the end of the file), giving: ---------------------- cut here ----------------------- :: Encrypted: PGP -----BEGIN PGP MESSAGE----- Version: 2.01 hEwCG6rHcT8LtDcBAf0YbKADFELfaRay6LFviabwpICAAGMV1Pff8meY3ND5o7hu jNy9hQv2bIMM9IyUCF2LFpgamxmMlSwpGQIVbJLEpgAAAEzDG0ddg2oBmjQFzB4c E0d/k7uE8KgxtCg6Sc+l639LN18sv4UWpq0nnyGRTUGEjL9JqtYZOSlTsiSAFU2c 4RoHslyk51suvGokhod0 =XSHb -----END PGP MESSAGE----- ---------------------- cut here ----------------------- The content of this file is my anonymous return address. To use it, I make my posting, anonymously, and I say something like: "Anonymous return address: mail to hal at alumni.caltech.edu, with your (possibly encrypted) message preceded by:" and I put in the contents of my anonymous return address file, above. So, to use this anonymous return address, suppose someone wants to send me this message: ---------------------- cut here ----------------------- Hello, I am responding to your anonymous post on cypherpunks. I would like to know more about your anonymous habits. Please post some more. ---------------------- cut here ----------------------- All they need to do is to put the anonymous return address at the beginning, giving: ---------------------- cut here ----------------------- :: Encrypted: PGP -----BEGIN PGP MESSAGE----- Version: 2.01 hEwCG6rHcT8LtDcBAf0YbKADFELfaRay6LFviabwpICAAGMV1Pff8meY3ND5o7hu jNy9hQv2bIMM9IyUCF2LFpgamxmMlSwpGQIVbJLEpgAAAEzDG0ddg2oBmjQFzB4c E0d/k7uE8KgxtCg6Sc+l639LN18sv4UWpq0nnyGRTUGEjL9JqtYZOSlTsiSAFU2c 4RoHslyk51suvGokhod0 =XSHb -----END PGP MESSAGE----- Hello, I am responding to your anonymous post on cypherpunks. I would like to know more about your anonymous habits. Please post some more. ---------------------- cut here ----------------------- They would then send this to hal at alumni.caltech.edu. The remailer would decrypt the PGP block, finding the "Request-Remailing-To" line, and then send it on to me. If I had posted a PGP public key along with my anonymous return address, they could have encrypted their message text as well, and put the A.R.A. in front of it. The resulting message would have looked something like: ---------------------- cut here ----------------------- :: Encrypted: PGP -----BEGIN PGP MESSAGE----- Version: 2.01 hEwCG6rHcT8LtDcBAf0YbKADFELfaRay6LFviabwpICAAGMV1Pff8meY3ND5o7hu jNy9hQv2bIMM9IyUCF2LFpgamxmMlSwpGQIVbJLEpgAAAEzDG0ddg2oBmjQFzB4c E0d/k7uE8KgxtCg6Sc+l639LN18sv4UWpq0nnyGRTUGEjL9JqtYZOSlTsiSAFU2c 4RoHslyk51suvGokhod0 =XSHb -----END PGP MESSAGE----- -----BEGIN PGP MESSAGE----- Version: 2.01 hIwCqBMDr1ghTDcBA/sGAyloGGHX/CBNRFOkov8RGNxNw/HqehwZ3yT5r0n45qAt AKmETej9GyJVFLZ5Oom7cqFN6+ARaZpp4LFqaxGF7phxC6l9HEPh2zI7w2G1/Df6 pMIwJJ7G+0vk7qBKoctmanNkYVTIb/bKAxJAbK6mUfcXPdRjyUaT/vf2X9RocKYA AAB/sjDjuW2cSN7o3HOKvQ4s+CyqshOGWe7xLRIfSBVyL2PXFOJKx7QMVdRyzDwC HO62PhXswqTlgxqIod0EXDzfEA8kI4Oz2gp45AMy8ElT1nV1jEKjCGC6HWGDU/P5 ZCTPgzOgmLetDNi5Yf8cPDMTHQ3Dcl7vDyNhpMD4+fdFog== =8FPE -----END PGP MESSAGE----- ---------------------- cut here ----------------------- The first PGP message is my anonymous return address, and the 2nd PGP message (which the remailer won't try to decrypt) is the encrypted message for me. If more people will implement cryptographic remailers, you will be able to create more secure ARA's which are "nested" so that they go through two or more remailers, and no one remailer will see the correspondence between your ARA and your real address. How might you use an ARA? You could create a pseudonym, and a public key corresponding to it. You could post anonymously, using our current remailers, to this list or another list. You could sign your messages using the public key of your pseudonym, so no one else could pretend to be you. And you could put an ARA into your messages so people could reply to you. They could reply anonymously if they wanted to, and could supply you with an ARA of their own. People could communicate freely under their online net identities, with cryptographic protection of their True Names, a la Vernor Vinge. Hal P.S. Here again is the public key of the remailer at . -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.01 mQBNAisCtU0AAAEB/jNOYzN1B2YzOxlK/Zb6axoOaGlPq5I7DV9GH3hcGRN5N6Fi T4sRLhi53Sc5rUdYDa8mFQd4tqvFG6rHcT8LtDcABRG0KlJlbWFpbGluZyBTZXJ2 aWNlIDxoYWxAYWx1bW5pLmNhbHRlY2guZWR1Pg== =K00H -----END PGP PUBLIC KEY BLOCK----- From dmandl at shearson.com Fri Nov 13 11:35:30 1992 From: dmandl at shearson.com (David Mandl) Date: Fri, 13 Nov 92 11:35:30 PST Subject: DC 2600 mtg Message-ID: <9211131905.AA00246@tardis.shearson.com> > Perry Metzger writes: > Pardon, but isn't 2600 magazine a magazine by crackers for crackers? No. It's called "The Hacker's Quarterly" and never claims to be anything else. Eric Corley (editor/publisher) is completely above-ground. He even does a computer show on WBAI here in New York, though I haven't heard it. In fact, he was on MY radio show (WFMU) a few years ago talking about hackers. I was initially surprised that he was willing to use his real name on the show; I ended up being almost disappointed by how "apolitical" he seemed. 2600 prints plenty of articles by flamboyant young pranksters on how to break into this or that system, but rather than an editorial line or policy, this is more a result of 2600's view that all this information should be available and uncensored. These are the kinds of guys who uncover holes in multinationals' computer security and TELL THEM about it. (BTW, I'm not involved with the magazine in any way; in fact, I find most of its articles kinda uninspiring or mundane.) --Dave. From jordan at imsi.com Fri Nov 13 11:58:01 1992 From: jordan at imsi.com (Jordan Hayes) Date: Fri, 13 Nov 92 11:58:01 PST Subject: Hackers, Crackers Message-ID: <9211131918.AA17661@IMSI.COM> From anthrax at cow.com Fri Nov 13 14:03:27 1992 Doesn't PGP violate patent laws (or surely come pretty close)? Why would you want to be associated with PGP and its use, then? Are you saying that contributing to this mailing list (let alone *subscribing* to it) necessarily implies that one is using the PGP code? If so, take me off. /jordan From crunch at netcom.com Fri Nov 13 13:13:30 1992 From: crunch at netcom.com (John Draper) Date: Fri, 13 Nov 92 13:13:30 PST Subject: Rander box Message-ID: <9211132109.AA27735@netcom2.netcom.com> >>I'd just make the thing spew continuously. It's not like you're >>losing real, er, information if you ignore a few random bits. This >>way you don't need the added circuitry for switching on and off. >Bad idea. If I hooked it up to my workstation, I'd end up spending >lots of CPU on the thing and possibly get nasty problems with buffers >filling. Not everything on earth is a PC that will ignore the >interrupts if the port isn't in use, you know. I agree, dealing with continious data streams might be problematic, but it was mentioned that we could use CTS/RTS or other lines on the connector to turn on and off the stream. Any comments on doing it this way? From crunch at netcom.com Fri Nov 13 13:26:53 1992 From: crunch at netcom.com (John Draper) Date: Fri, 13 Nov 92 13:26:53 PST Subject: Rander Message-ID: <9211132123.AA29207@netcom2.netcom.com> Eric says: >In my previous post, I mentioned powering the device from DTR. DTR, >for those of you not familiar with RS-232, is a device control line >which is separately assertable. To turn the device off, toggle DTR. >Presto! No more power, no more bits. Simple, when you know what DTR >does. So far, I think this is the best idea, and after checking out my methodology and initial circuit design, I see no reason why I cannot go as high as 9600 baud. Even the more inexpensive AD converters can achieve that speed when we only want to use 8 bits. I am toying around the idea for using an 8 bit AD converter, then its just a matter of clocking them out a UART. From crunch at netcom.com Fri Nov 13 13:31:29 1992 From: crunch at netcom.com (John Draper) Date: Fri, 13 Nov 92 13:31:29 PST Subject: PGP portability Message-ID: <9211132127.AA29554@netcom2.netcom.com> John Gilmore writes: >The last thing PGP needs is an installed base of Mac users who are >always stuck three revs back because they forked off their own wierd >version and couldn't upgrade when the rest of us do. This was why I proposed the internal "engine" concept where I keep the machine independent code intact and the GUI seperate. At the moment, I can't think of a better idea. So perhaps you can give us some suggestions towards a solution to the problem, John! From anthrax at cow.com Fri Nov 13 15:41:16 1992 From: anthrax at cow.com (anthrax at cow.com) Date: Fri, 13 Nov 92 15:41:16 PST Subject: Take you off Message-ID: <9211132341.AA06610@atdt.org> >> Are you saying that contributing to this mailing list (let alone *subscribing* to it) necessarily implies that one is using the PGP code? If so, take me off. << As a counter to that, would you or Perry necessarily imply that subscribing to a "KrAcKeR" magazine makes you an evil "KrAcKeR"? Anyway, if you can figure out the unix commands to navigate through your mail-box, then you should have just enough intelligence not to have jumped to any short-sided conclusions like the one you proposed above. Then again, I could be wrong. From shawnb at ecst.csuchico.edu Fri Nov 13 16:07:22 1992 From: shawnb at ecst.csuchico.edu (S.E. Brown) Date: Fri, 13 Nov 92 16:07:22 PST Subject: The legality of PGP Message-ID: <9211140007.AA19365@toad.com> Well, I've been reading a lot of speculation and outright disinformation about the legality of PGP. Does anyone have any informed information about the actual legal status us sing and disseminating the program? Gratis My SuperIllegal Key : -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAirSjlcAAAED/ijVaTjlU62mQdXwxj+bEO3wqdMKkZlRNt1rSi8VOSkeQ0G7 7KbBeINoVCTIi12ax74q7ANhKCga+ZkBxAVTnfSBQZXfFh/5XMxzzqk7NT2fKKlZ /Hrf4cDd8VYgSl6WPhyVO+EpvyZn5HezGLBbryGpCcloSmjBcwd2g1pYVIhjAAUR tCxTLkUuIEJyb3duIDxzaGF3bmJAY3NjaWhwLmVjc3QuY3N1Y2hpY28uZWR1Pg== =Wrv7 -----END PGP PUBLIC KEY BLOCK----- From schwarte at CS.ColoState.EDU Fri Nov 13 16:47:32 1992 From: schwarte at CS.ColoState.EDU (eric schwartz) Date: Fri, 13 Nov 92 16:47:32 PST Subject: Take You Off Message-ID: <9211140047.AA02325@beethoven> > > >> > Are you saying that contributing to this mailing list (let alone > *subscribing* to it) necessarily implies that one is using the PGP > code? > > > If so, take me off. > << > > As a counter to that, would you or Perry necessarily imply that > subscribing to a "KrAcKeR" magazine makes you an evil > "KrAcKeR"? > > Anyway, if you can figure out the unix commands to navigate through > your mail-box, then you should have just enough intelligence > not to have jumped to any short-sided conclusions like the one > you proposed above. > > Then again, I could be wrong. > Then again, you could be missing his (albeit subtly) sarcastic point, which is exactly what you just said. Sheesh. From shawnb at ecst.csuchico.edu Fri Nov 13 18:44:10 1992 From: shawnb at ecst.csuchico.edu (S.E. Brown) Date: Fri, 13 Nov 92 18:44:10 PST Subject: PGP 2.01 2.02 Message-ID: <9211140244.AA22290@toad.com> Where can the latest revisions of PGP be found? Tried the sci.crypt archive site, but the just had 2.0. Can anyone help? BTW, here's my key: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAirSjlcAAAED/ijVaTjlU62mQdXwxj+bEO3wqdMKkZlRNt1rSi8VOSkeQ0G7 7KbBeINoVCTIi12ax74q7ANhKCga+ZkBxAVTnfSBQZXfFh/5XMxzzqk7NT2fKKlZ /Hrf4cDd8VYgSl6WPhyVO+EpvyZn5HezGLBbryGpCcloSmjBcwd2g1pYVIhjAAUR tCxTLkUuIEJyb3duIDxzaGF3bmJAY3NjaWhwLmVjc3QuY3N1Y2hpY28uZWR1Pg== =Wrv7 -----END PGP PUBLIC KEY BLOCK----- From hughes at soda.berkeley.edu Fri Nov 13 18:59:39 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Fri, 13 Nov 92 18:59:39 PST Subject: PGP 2.01 2.02 In-Reply-To: <9211140244.AA22290@toad.com> Message-ID: <9211140259.AA12754@soda.berkeley.edu> As of now, PGP 2.0 is the current version. A newer one will be out shortly (it's being tested). The list will certainly be the first to know. Eric From Tom.Jennings at f111.n125.z1.FIDONET.ORG Fri Nov 13 19:23:25 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Fri, 13 Nov 92 19:23:25 PST Subject: Rander box and other stuff Message-ID: <3612.2B045BBD@fidogate.FIDONET.ORG> U> From: crunch at netcom.com (John Draper) U> I think I have a rough description of the hardware U> serial random generator I want to build. I want to call U> it the "Rander box" for lack of a better name. Using serial ports is probably not a good idea on PC clones. The IBM hardware design limits a machine to two ports comfortably, four practical maximum. Any machine that uses telecomm. (BBSs, etc) will have to consume the serial hardware, and will interfere with whatever you have to do. A good choice would be a parallel port, ie. a printer port. The IBM design allows 4 or more easily, and rarely do you see a pclone with more than two printers attached. If there isn't a spare port available, Fry's sells printer adapters for $19.95. Late-model printer adapters are 8 bit in and out, and are capable of Ethernet speeds. The parallel port uses standard busy/done and TTL levels. (For a "universal" serial version, you could internally have the 8 bit busy/done interface drive a UART. I bet simply fixing the data rate to 9600 baud would work.) U> When switched on, and a "cr" (or some other U> character) is sent to it, random bytes will stream out U> continiously. Another "cr" will stop the byte stream. U> At least this is ONE approach. If anyone can think of a U> better way, Pse speak up. I was about to say "prolly not necessary", but others make valid points... XON/XOFF, DTR, etc are all workable... DTR is compat w/serial and parallel too. On a pclone, producing bits continuously is easier. When not in use, the driver will dump bits onto the floor. Fancy (software) drivers could spool the bits into a nice big pile ("every bit is sacred..."). A simple driver could simply have say 10,000 bits, and continuously overwrite the oldest (wrap around the buffer...) --- ReadMail * Origin: tomj at fidosw.fidonet.org / World Power Systems (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET - Tom.Jennings at f111.n125.z1.FIDONET.ORG From Tom.Jennings at f111.n125.z1.FIDONET.ORG Fri Nov 13 19:23:48 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Fri, 13 Nov 92 19:23:48 PST Subject: (fwd) A Silver Bullet to Limit Crypto? Message-ID: <3613.2B045BBE@fidogate.FIDONET.ORG> U> From: pmetzger at shearson.com (Perry E. Metzger) U> I don't see what the point of putting out mediocre things U> is at all, given that good things exist. PGP is free U> software. You need a good RSA implementation? There is one U> out there already. Why put out crap when gold is available U> and cheap? I don't think anyone has a desire to put bad things out there. My comments were assuming the real-life context of FidoNet, where we have a need to get people thinking about privacy, security, etc, and our relationships and responsibilities to each other. We *are* using PGP, which seems to be good software. Any "mediocrity" or inherent flaws I was referring to were in key systems, and suchlike. The social environment in FidoNet is completely different from here. There will never be any directed training or committees to define what a "proper" way to handle keys is, and even if there was, the newbie sysop coming online in East Overshoe Alaska wouldn't even hear about it, and would install what s/he finds available on the net. All of our social/technical systems assume this chaotic environment. It makes for some ahem interesting problems, but the robustness and growth and innovation are pretty hot. --- ReadMail * Origin: tomj at fidosw.fidonet.org / World Power Systems (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET - Tom.Jennings at f111.n125.z1.FIDONET.ORG From tom.jennings at f111.n125.z1.FIDONET.ORG Fri Nov 13 19:23:56 1992 From: tom.jennings at f111.n125.z1.FIDONET.ORG (tom jennings) Date: Fri, 13 Nov 92 19:23:56 PST Subject: 1/3 Cryptography bibliography Message-ID: <3615.2B0467B1@fidogate.FIDONET.ORG> * Forwarded by Rich Veraa To: All Message #: 365 From: Ed Beroset Submitted: 10 Nov 92 20:34:38 Subject: 1/3 cryptographic bibliog Status: Public Received: ** New Message Read! ** Group: 80XXX (17) I'm sorry it took me a little longer than I had anticipated to put together this list, but I think you'll find it worth while. This is a list of books which deal with various aspects of cryptography (including DES, RSA, and many other schemes and topics.) They're organized roughly in reverse chronological order, with newer texts toward the top of the list. TITLE : Cryptography : a new dimension in computer data security : a guide for the design and implementation of secure systems / AUTHOR: Meyer, Carl H. IMPR : New York : Wiley, 1982. TITLE : Traffic analysis and the Zendian problem : an exercise in communications intelligence operations / AUTHOR: Callimahos, Lambros D. IMPR : Laguna Hills, Calif. : Aegean Park Press, c1989. TITLE : Military communications : a test for technology / AUTHOR: Bergen, John D., 1942-. IMPR : Washington, D.C. : Center of Military History, U.S. Army : For sale by the Supt. of Docs., U.S. G.P.O., 1986. TITLE : Principles of secure communication systems / AUTHOR: Torrieri, Don J. IMPR : Dedham, MA : Artech House, c1985. TITLE : Contemporary cryptology : the science of information integrity / IMPR : Piscataway, NJ : IEEE Press, c1992. TITLE : Public-key cryptography : state of the art and future directions : E.I.S.S. workshop, Oberwolfach, Germany, July 3-6 1991 : final report / IMPR : Berlin ; New York : Springer-Verlag, 1992. TITLE : Advances in cryptology--EUROCRYPT '91 : Workshop on the Theory and Application of Cryptographic Techniques, Brighton, UK, April 8-11, 1991 : proceedings / AUTHOR: EUROCRYPT '91 (1991 : Brighton, England) IMPR : Berlin ; New York : Springer-Verlag, c1991. TITLE : United States cryptographic patents, 1861-1989 / ED : [2nd ed.] AUTHOR: Levine, Jack, 1907-. IMPR : Terre Haute, Ind. : Cryptologia, 1991. TITLE : Geometries, codes and cryptography / IMPR : Wien ; New York : Springer-Verlag, c1990. TITLE : Number theory and cryptography / IMPR : Cambridge ; New York : Cambridge University Press, 1990. TITLE : Cryptography : an introduction to computer security / AUTHOR: Seberry, Jennifer, 1944-. IMPR : New York : Prentice-Hall, c1989. TITLE : Codes and cryptography / AUTHOR: Welsh, D. J. A. IMPR : Oxford [Oxfordshire] : Clarendon Press ; New York : Oxford University Press, 1988. TITLE : Crypto users' handbook : a guide for implementors of cryptographic protection in computer systems / IMPR : Amsterdam [The Netherlands] ; New York : North-Holland ; New York, N.Y., U.S.A. : Sole distributors for the U.S.A. and Canada, Elsevier Science Pub. Co., 1988. TITLE : An introduction to cryptology / AUTHOR: Tilborg, Henk C. A. van, 1947-. IMPR : Boston : Kluwer Academic Publishers, c1987. TITLE : Modern cryptology : a tutorial / AUTHOR: Brassard, Gilles, 1955-. IMPR : New York : Springer-Verlag, c1988. TITLE : A course in number theory and cryptography / AUTHOR: Koblitz, Neal, 1948-. IMPR : New York : Springer-Verlag, c1987. TITLE : Cryptology yesterday, today, and tomorrow / IMPR : Norwood, MA : Artech House, c1987. TITLE : Mathematical cryptology for computer scientists and mathematicians / AUTHOR: Patterson, Wayne, 1945-. IMPR : Totowa, N.J. : Rowman & Littlefield, 1987. TITLE : Analysis and design of stream ciphers / AUTHOR: Rueppel, Rainer A., 1955-. IMPR : Berlin ; New York : Springer-Verlag, c1986. TITLE : Primality and cryptography / AUTHOR: Kranakis, Evangelos. IMPR : Stuttgart : Teubner ; Chichester [Sussex] ; New York : Wiley, c1986. -+--- continued next message ----- --- XAP 1.02+ * Origin: the birds round about are against her; (1:135/907) -- tom jennings - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!111!tom.jennings INTERNET - tom.jennings at f111.n125.z1.FIDONET.ORG rom fidogate!f111.n125.z1.FIDONET.ORG!tom.jennings at kumr.lns.com Fri Nov 13 19:23:59 1992 Return-Path: Received: from kumr.lns.com by toad.com id AA23114; Fri, 13 Nov 92 19:23:59 PST Received: by kumr.lns.com (/\==/\ Smail3.1.25.1 #25.3) id ; Fri, 13 Nov 92 18:57 PST Received: by fidogate.FIDONET.ORG (mailout1.26); Fri, 13 Nov 92 18:42:59 PDT Date: Fri, 13 Nov 92 18:56:32 PDT Message-Id: <3616.2B0467B3 at fidogate.FIDONET.ORG> From: tom.jennings at f111.n125.z1.FIDONET.ORG (tom jennings) Subject: 2/3 Cryptography bibliography To: cypherpunks at toad.com X-Mailer: mailout v1.26 released * Forwarded by Rich Veraa To: All Message #: 366 From: Ed Beroset Submitted: 10 Nov 92 20:34:38 Subject: 2/3 cryptographic bibliog Status: Public Received: ** New Message Read! ** Group: 80XXX (17) RE: 2/3 cryptographic bibliography -+--- continued from previous message ----- TITLE : Two issues in public-key cryptography : RSA bit security and a new knapsack type system / AUTHOR: Chor, Ben-Zion. IMPR : Cambridge, Mass. : MIT Press, c1986. TITLE : Kryptologie / AUTHOR: Horster, Patrick. IMPR : Mannheim : Bibliographisches Institut, c1985. LANG : German TITLE : Machine cryptography and modern cryptanalysis / AUTHOR: Deavours, Cipher A. IMPR : Dedham, MA : Artech House, c1985. TITLE : Cryptanalysis of shift-register generated stream cipher systems / AUTHOR: Barker, Wayne G. IMPR : Laguna Hills, Calif. : Aegean Park Press, c1984. TITLE : Applied cryptology, cryptographic protocols, and computer security models. IMPR : Providence, R.I. : American Mathematical Society, c1983. TITLE : Secure digital communications / IMPR : Wien ; New York : Springer-Verlag, c1983. TITLE : Cipher systems : the protection of communications / AUTHOR: Beker, Henry. IMPR : New York : Wiley, c1982. TITLE : Codes, ciphers, and computers : an introduction to information security / AUTHOR: Bosworth, Bruce. IMPR : Rochelle Park, N.J. : Hayden Book Co., c1982. TITLE : Cryptography and data security / AUTHOR: Denning, Dorothy Elizabeth Robling, 1945-. IMPR : Reading, Mass. : Addison-Wesley, c1982. TITLE : Secure communications and asymmetric cryptosystems / IMPR : Boulder, Colo. : Published by Westview Press for the American Association for the Advancement of Science, 1982. TITLE : Cryptography, a primer / AUTHOR: Konheim, Alan G., 1934-. IMPR : New York : Wiley, c1981. TITLE : The origin and development of the National Security Agency / AUTHOR: Brownell, George A. IMPR : Laguna Hills, Calif. : Aegean Park Press, 1981. UNI-TI: Traite de cryptographie. English. TITLE : Treatise on cryptography / AUTHOR: Langie, Andre, 1871-. IMPR : Laguna Hills, Calif. : Aegean Park Press, c1981. TITLE : Cryptanalysis of an enciphered code problem : where an "additive" method of encipherment has been used / AUTHOR: Barker, Wayne G. IMPR : Laguna Hills, Calif. : Aegean Park Press, c1979. UNI-TI: Chifferbyraernas insatser i varldskriget till lands. English. TITLE : The contribution of the cryptographic bureaus in the World War / AUTHOR: Gylden, Yves. IMPR : Laguna Hills, Calif. : Aegean Park Press, c1978. TITLE : The protection of data by crytography / AUTHOR: Davies, (Donald Watts) IMPR : Middlesex : National Physical Laboratory, 1978. TITLE : Cryptanalysis of the Hagelin cryptograph / AUTHOR: Barker, Wayne G. IMPR : Laguna Hills, Calif. : Aegean Park Press, c1977. UNI-TI: Manuale di crittografia. Italian. TITLE : Manual of cryptography / AUTHOR: Sacco, Luigi. IMPR : Laguna Hills, Calif. : Aegean Park Press, c1977. TITLE : Pattern-word list / AUTHOR: Lynch, Frederick D. IMPR : Laguna Hills, Calif. : Aegean Park Press, c1977-. -+--- continued next message ----- --- XAP 1.02+ * Origin: If at first you don't succeed, try, try a bird. (1:135/907) -- tom jennings - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!111!tom.jennings INTERNET - tom.jennings at f111.n125.z1.FIDONET.ORG From tom.jennings at f111.n125.z1.FIDONET.ORG Fri Nov 13 19:24:04 1992 From: tom.jennings at f111.n125.z1.FIDONET.ORG (tom jennings) Date: Fri, 13 Nov 92 19:24:04 PST Subject: 3/3 Cryptography bibliography Message-ID: <3617.2B0467B4@fidogate.FIDONET.ORG> * Forwarded by Rich Veraa To: All Message #: 367 From: Ed Beroset Submitted: 10 Nov 92 20:41:08 Subject: 3/3 cryptographic bibliog Status: Public Received: ** New Message Read! ** Group: 80XXX (17) -+--- continued from previous message ----- TITLE : Advanced military cryptography / AUTHOR: Friedman, William Frederick, 1891-. IMPR : Laguna Hills, Calif. : Aegean Park Press, c1976. TITLE : Elementary military cryptography / AUTHOR: Friedman, William Frederick, 1891-. IMPR : Laguna Hills, Calif. : Aegean Park Press, c1976. TITLE : Elements of cryptanalysis / AUTHOR: Friedman, William Frederick, 1891-. IMPR : Laguna Hills, Calif. : Aegean Park Press, c1976. TITLE : Statistical methods in cryptanalysis / ED : [Rev. ed.] AUTHOR: Kullback, Solomon. IMPR : Laguna Hills, Calif. : Aegean Park Press, c1976. TITLE : Mathematical recreations & essays / ED : 12th ed. AUTHOR: Ball, Walter William Rouse, 1850-1925. IMPR : Toronto ; Buffalo : University of Toronto Press, [1974] TITLE : Elementary cryptanalysis; a mathematical approach. AUTHOR: Sinkov, Abraham, 1907-. IMPR : [New York] Random House [c1968] -+--- end of listing ----- I think that you'll find there's a lot more useful information out there, just waiting for you at your public library. The U.S. Government can also be a useful source of information, as are trade and technical journals and hobbyist magazines. -> Ed <- --- XAP 1.02+ * Origin: two birds alive and clean, (1:135/907) -- tom jennings - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!111!tom.jennings INTERNET - tom.jennings at f111.n125.z1.FIDONET.ORG From simsong at next.cambridge.ma.us Fri Nov 13 22:24:49 1992 From: simsong at next.cambridge.ma.us (Simson L. Garfinkel) Date: Fri, 13 Nov 92 22:24:49 PST Subject: Rander Message-ID: <9211140619.AA11189@next.cambridge.ma.us> Perhaps I'm just out of the loop, but what do you intend to do with your stream of random numbers? You going to send a tape to your friends under armed guard? Just curious. Oh, I built a hardware random number generator a few years ago for some ESP experiments I was doing. I wanted to see if computer hackers had better odds of affecting the output of a RNG than non-hackers. (You know, the hacker walks into the room and suddenly the broken piece of equipment starts working?) Turns out they can. -simson From hh at soda.berkeley.edu Fri Nov 13 22:38:47 1992 From: hh at soda.berkeley.edu (Eric Hollander) Date: Fri, 13 Nov 92 22:38:47 PST Subject: Rander box and other stuff In-Reply-To: <3612.2B045BBD@fidogate.FIDONET.ORG> Message-ID: <9211140637.AA25631@soda.berkeley.edu> All of these designs leave us Mac users a bit out in the cold. My powerbook 100 has one lonely little serial port and no parallel port. Desktop macs usually have two serial ports, and it's not easy to add more. For us powerbook users (and also for users of other notebooks), we want something which is internal. It's horible to have little things dangling off of your nice little notebook. They inevitably get pulled out, etc. Basically it seems to me that a good solution would be to use some type of serial device for Unix type machines, and then work on a series of cards for IBM clones and notebooks. How about a random bit device on one of those little cards that most of the newer notebooks have? I forget the name of the standard for that, but lots of them use it now. e From crunch at netcom.com Sat Nov 14 01:23:48 1992 From: crunch at netcom.com (John Draper) Date: Sat, 14 Nov 92 01:23:48 PST Subject: Rander Message-ID: <9211140920.AA01475@netcom2.netcom.com> Tom Jennings writes: >Using serial ports is probably not a good idea on PC clones. The IBM >hardware design limits a machine to two ports comfortably, four >practical maximum. Any machine that uses telecomm. (BBSs, etc) will >have to consume the serial hardware, and will interfere with whatever >you have to do. >A good choice would be a parallel port, ie. a printer port. The IBM >design allows 4 or more easily, and rarely do you see a pclone with >more than two printers attached. If there isn't a spare port >available, Fry's sells printer adapters for $19.95. Late-model printer >adapters are 8 bit in and out, and are capable of Ethernet speeds. >The parallel port uses standard busy/done and TTL levels. I already thought of that, but it would make it difficult to work on other platforms. Tom also writes: >A simple driver could simply have say 10,000 bits, and continuously >overwrite the oldest (wrap around the buffer...) This was (and probably still is) my overall intention. From gg at well.sf.ca.us Sat Nov 14 04:11:21 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Sat, 14 Nov 92 04:11:21 PST Subject: Rander box Message-ID: <199211141210.AA21995@well.sf.ca.us> Re Eric's quote of me agreeing with him that OTPs are "expensive to make relative to other forms of security." A point of clarification seems in order. I do agree that OTPs are more expensive and less convenient to use than PKSs. However, I also believe that the public interest would *best* be served by having *many* different kinds of cyphers available, including OTPs, PKSs, and various conventional cyphers, historic cyphers with relatively little current security value (for educational purposes) and so on. The main advantages of OTPs are provable absolute security and the fact that the basic technique is so straightforward that it probably could never be banned and put out of circulation. The time may come when we *need* OTPs, and we ought to have them ready beforehand, and have them in use in appropriate situations long before any crisis comes (to gain operational experience which could lead to improvements). With regard to PGP, I am not sure what the copyright status is on that one; and if there is any doubt about it, the govt could screw a lot of people to the wall on copyright-related charges if they so chose. I would like it very very much if PGP was free & clear public domain. The last thing we need is for the first warning of tyrrany to be a wave of hardware seizures on the grounds of having unauthorised copies of copyrighted material. Now I may be off base on this point, but the key here is the idea that many different kinds of cyphers, like many different varieties of plants and animals, make for a robust ecosystem which can't be wiped out by one plague. -gg From jordan at imsi.com Sat Nov 14 06:59:01 1992 From: jordan at imsi.com (Jordan Hayes) Date: Sat, 14 Nov 92 06:59:01 PST Subject: Rander box and other stuff Message-ID: <9211141425.AA00660@IMSI.COM> Hey, I have a PowerBook too, but don't say you're limited to one serial port. You could use the desktop bus, and there are extenders available. I do agree that a parallel box wouldn't do me much good on my Sparc. For a while, my IPX was my "portable" computer, albeit with monitors on both coasts. But the box itself is quite lugable. If I wanted to, I could plug it in along the hallways of airports and use a palmtop with a serial connection to read mail and up/down load ... /jordan From tcmay at netcom.com Sat Nov 14 10:55:08 1992 From: tcmay at netcom.com (Timothy C. May) Date: Sat, 14 Nov 92 10:55:08 PST Subject: "Cryptodiversity" and Foiling the "Key Grabbers" In-Reply-To: <199211141210.AA21995@well.sf.ca.us> Message-ID: <9211141851.AA05846@netcom.netcom.com> George Gleason argues for having and using several types of cryptosystems, a kind of "cryptodiversity." He writes: > I do agree that OTPs are more expensive and less convenient to use than > PKSs. However, I also believe that the public interest would *best* be > served by having *many* different kinds of cyphers available, including > OTPs, PKSs, and various conventional cyphers, historic cyphers with > relatively little current security value (for educational purposes) and so > on. The main advantages of OTPs are provable absolute security and the fact > that the basic technique is so straightforward that it probably could never > be banned and put out of circulation. The time may come when we *need* > OTPs, and we ought to have them ready beforehand, and have them in use in > appropriate situations long before any crisis comes (to gain operational > experience which could lead to improvements). .......... > on the grounds of having unauthorised copies of copyrighted material. Now I > may be off base on this point, but the key here is the idea that many > different kinds of cyphers, like many different varieties of plants and > animals, make for a robust ecosystem which can't be wiped out by one plague. A great idea. Getting several forms of crypto out there is a good insurance policy. The problem I see is that no system, be it OTP or something else, is likely to get much penetration in the market. PGP has taken off, but another system will face an uphill battle unless it is very well-written, very easy to use, and/or fills some special need. Still, I want to encourage George to pursue this (somehow). I have a CD-ROM on my Mac, but I doubt it'll be practical to burn CD-ROMs economically (one service wants $200 for one CD-ROM, with a second one for nominally more...and note that such a service is an obvious security hole). 128 MB magneto-opticals may be a better bet, though few folks have them. In terms of programming energy, vis-a-vis a point John Gilmore made recently about adding to the PGP effort, I'm sure enhancing PGP by integrating it into standard mailers (yes, I'm aware of the security holes here, too) would be even more beneficial to cryptodiversity, just in the sense of getting the volume of encrypted traffic way up. A good Mac version would also help, of course. And to head off the "key grabbers," developing steganographic methods to hide our encrypted bitstreams inside innocuous GIF files and the like (as I have written about before) may be useful. --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at 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^756839 | PGP Public Key: awaiting Macintosh version. From tcmay at netcom.com Sat Nov 14 11:15:08 1992 From: tcmay at netcom.com (Timothy C. May) Date: Sat, 14 Nov 92 11:15:08 PST Subject: Rander box and other stuff Message-ID: <9211141911.AA08123@netcom.netcom.com> Eric Hollander writes: > All of these designs leave us Mac users a bit out in the cold. My powerbook > 100 has one lonely little serial port and no parallel port. Desktop macs > usually have two serial ports, and it's not easy to add more. > > For us powerbook users (and also for users of other notebooks), we want > something which is internal. It's horible to have little things dangling > off of your nice little notebook. They inevitably get pulled out, etc. Maybe I'm being crypto-dense, but why would individual Powerbook 100 users care so much about generating the bits in the volumes that a hardware-based RNG is designed to supply? For filling a CD-ROM (600 MB) with good random bits, I can see the need for a back-biased diode source (such as Tony Patti's widget), but such filling of a CD-ROM presumes a fair amount of other stuff, like the CD-ROM burners, etc. I can't imagine a PB 100 user, and I'm one of them, developing OTPs on CD-ROMs on the PowerBook. For generating PGP keys, the keyboard timing methods work quite well, as several folks have pointed out. Maybe for some of the dynamic key generation applications that will be appearing in the next couple of years such a hardware RNG will be useful (so that the bits can be generated in the absence of a human operator, and at higher rates). But I don't see them needed immediately, and certainly not on a PowerBook. (No insult to the PowerBook, it's just that I can't see Eric Hughes' and Hal Finney's remailer running on such a platform, for obvious reasons.) Am I missing something? --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at 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^756839 | PGP Public Key: awaiting Macintosh version. -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at 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^756839 | PGP Public Key: awaiting Macintosh version. From crunch at netcom.com Sat Nov 14 14:02:15 1992 From: crunch at netcom.com (John Draper) Date: Sat, 14 Nov 92 14:02:15 PST Subject: Some organizational trivia to consider Message-ID: <9211142158.AA23080@netcom2.netcom.com> I will be "off line" for a few days now, as I have to do some work to help out an old friend. I'll be back "on line" sometime late Tuesday, and hopefull will have formulated some organizational plan to propose to the group. In the meantime, start thinking about how we can organize "on line" meetings (Or even meetings in person) to hammer out some type of plan. Someone mentioned a meeting to be taken place later, is this meeting for the Cypherpunks project? My involvement at this point will be that of an adviser, and perhaps pump in some ideas to the group. As the host of the Programmers Netsork, I am experienced at setting up organizational groups, but often these groups tend to "fizzle out" as people have other time committments, so it's important that we try and work out a mechanism for "passing the torch" when one person has to bow out for some reason. My recommendation is to set up an FTP site where one can download the latest organizational plan, people involved, who is doing what, etc, and keep this info updated on a regular basis. I don't recommend that just ONE person do this, it has to be done by several people in the event one (or more) have to drop out for some reason. In the meantime, just be thinking about the following: a) Setting up a cypherpunks FTP site to contain organizational info, latest source code, who is doing what, and a list of things that need to be done. b) Maintaining a SOurce code control mechanism whereby people can "check out" code modules and work in parallel towards a common goal. c) Provide periodic updates by posting important info to the rest of Cyberspace via UseNet or other on-line systems. Till next Tuesday, take care Y'all.... See U in Cypherspace next Tues Cheers John Draper crunc at netcom.com crunch at well.sf.ca.us From basil at cs.odu.edu Sat Nov 14 16:15:04 1992 From: basil at cs.odu.edu (Keith Basil) Date: Sat, 14 Nov 92 16:15:04 PST Subject: cypherpunks mail list. Message-ID: <9211150014.AA14236@penda.cs.odu.edu> i'd like to be added to the list. thanks. keith From gg at well.sf.ca.us Sat Nov 14 16:27:09 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Sat, 14 Nov 92 16:27:09 PST Subject: Rander box and other stuff Message-ID: <199211150026.AA01440@well.sf.ca.us> I have a question regarding the ideas which have been circulating about using CD ROMs as key storage. How does one go about rapidly and effectively erasing everything on a CD ROM? The reason I ask is, in the case of OTPs you want to cancel your key as it's used, to prevent accidental double-use of key; and of course in any system you want to make sure that all your crypto material can be wiped squeaky clean in the event of a barbarian invasion. -gg From tcmay at netcom.com Sat Nov 14 17:30:13 1992 From: tcmay at netcom.com (Timothy C. May) Date: Sat, 14 Nov 92 17:30:13 PST Subject: Some organizational trivia to consider In-Reply-To: <9211142158.AA23080@netcom2.netcom.com> Message-ID: <9211150126.AA08860@netcom.netcom.com> > Till next Tuesday, take care Y'all.... See U in Cypherspace next Tues > > Cheers > John Draper "Cypherspace" is a _great_ name! Thanks, John. --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at 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^756839 | PGP Public Key: awaiting Macintosh version. From tcmay at netcom.com Sat Nov 14 18:22:36 1992 From: tcmay at netcom.com (Timothy C. May) Date: Sat, 14 Nov 92 18:22:36 PST Subject: What's More Important? Message-ID: <9211150219.AA12711@netcom.netcom.com> I try to never say on lists or newsgroups that some subject is inappropriate, or boring, has already been beaten to death, etc. Instead, I figure it's up to others to make this choice. I can always ignore threads that don't interest me. But let me confess I'm mystified as to why the subject of random number generators (and CD-ROMs filled with them) is getting so much attention while Hal Finney's remarkable post on his work toward a fully-encrypted remailer (allowing digital pseudonyms) has received no discussion whatsover! Random number generators, in software and in hardware, pop up in discussions on sci.crypt every couple of months or so. Every argument made here, every basic question, etc., has already come up several times in just past year! Furthermore, and I don't mean to sound chiding or condescending, one-time pads are fundamentally not the way to go. Yes, I know that I just applauded George Gleason's cryptodiversity idea...but I see the stark contrast between the dozens of postings on RNGs, Rander, one-time pads, and CD-ROMs and the utter lack of postings about Hal's remailer...and I am chagrined. Granted, Hal's system is hard to follow. This is another area where some diagrams would help immensely, especially drawn on a blackboard. But anonymous remailing is where cypherpunks need to be. --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at 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^756839 | PGP Public Key: awaiting Macintosh version. From gg at well.sf.ca.us Sun Nov 15 00:42:09 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Sun, 15 Nov 92 00:42:09 PST Subject: What's More Important? Message-ID: <199211150841.AA06938@well.sf.ca.us> I suspect the reason why anon remailers haven't gotten their due, and OTPs are getting so much press here, is that anon remailers are being developed locally and the development problems for these are straightforward, whereas good RNGs for OTPs are a sort of sticky technical issue which seems to call for a lot of debate. You don't see anyone debating the **software** for OTPs now, do you...? And I do agree, anon remailers are absolutely vital in the overall scheme of things. If for no other reason, to stop or hinder traffic analysis, which is a way more powerful form of signals intelligence than most people realise. -gg From nobody at alumni.cco.caltech.edu Sun Nov 15 03:17:12 1992 From: nobody at alumni.cco.caltech.edu (nobody at alumni.cco.caltech.edu) Date: Sun, 15 Nov 92 03:17:12 PST Subject: test message Message-ID: <9211151118.AA09055@alumni.cco.caltech.edu> This is an un-encrypted test message. Please ignore. From oren at apple.com Sun Nov 15 13:42:22 1992 From: oren at apple.com (oren at apple.com) Date: Sun, 15 Nov 92 13:42:22 PST Subject: Apple including PKS? Message-ID: <9211152141.AA24753@apple.com> >Re: Apple include a PKS with their Macs > >Well, Apple does have a site license for RSA. Tim Oren, who's on the >list, knows more about this than I. I ask him to respond. > >Maybe Apple could license the PGP code as a system utility? > >Eric Apple does have a license from RSA, which includes both site and redistribution rights. The intent is to make security-enhanced features available in something called OCE (Open Collaboration Environment) which is to be Apple's entry in the E-mail / user directory / etc. marketplace. OCE is likely to be an add-on, that is, something not shipped with every Mac, but available at extra cost. Since I'm under NDA for the details of OCE, I will simply quote what MacLeak says: According to MacWeek, Apple is using RSA software with 150-200 digit primes for Digital Signatures. They are using "RSA's RC4 algorithm [which will] provide encryption of the fly for data transmitted across an OCE (open Collaboratioon Environment) network. Each message will be scrambled using a unique 64-bit key. BTW, notice that's decimal digits, not bits, in the signature length. Apple is set up as a certifying authority, but I don't know any details of the plans on how to certify keys. It's a far from simple problem to work out something that will work in the current personal computer market structure and isn't subject to spoofing. Re Apple licensing PGP code: While Apple could presumably do so without violating any laws, so long as any copyright holders in PGP granted appropriate rights, I don't think it's very likely. OCE is a package to be differentiated by its user interface, and apparently MacPGP's (though I haven't tried it myself yet) is rather crufty from the Mac point of view. Also, Apple traditionally wants very tight control over its source code, and is unlikely to adopt something that arrives in such a (shall we say) 'informal' fashion from outside. Finally, as a dose of preventive medicine, I should mention that all of the above is my best interpretation of Apple policy and probable action, with which I don't necessarily agree personally. Flameage ignoring this statement will be routed appropriately. Tim Oren From oren at apple.com Sun Nov 15 13:48:38 1992 From: oren at apple.com (oren at apple.com) Date: Sun, 15 Nov 92 13:48:38 PST Subject: Rander box and other stuff Message-ID: <9211152148.AA24934@apple.com> >I have a question regarding the ideas which have been circulating about >using CD ROMs as key storage. How does one go about rapidly and effectively >erasing everything on a CD ROM? The reason I ask is, in the case of OTPs >you want to cancel your key as it's used, to prevent accidental double-use >of key; and of course in any system you want to make sure that all your >crypto material can be wiped squeaky clean in the event of a barbarian >invasion. > >-gg A lab proven method: Take CD-ROM. Place in standard kitchen microwave. Set on high power cook for 5 seconds. Press start. Watch the action. Hang resulting artifact on wall as curiosity, which is all it's good for now. Let the wave air out a little (this won't fry it). A great way of trashing obsolete but confidential CD's, and perhaps the cypherpunk equivalent of flushing the dope stash. Tim O. From karn at qualcomm.com Sun Nov 15 13:58:13 1992 From: karn at qualcomm.com (Phil Karn) Date: Sun, 15 Nov 92 13:58:13 PST Subject: Apple including PKS? Message-ID: <9211152157.AA22323@servo> After reading the details of that (formerly) secret back-room agreement between NSA and SPA, I don't think I'll *ever* trust a commercial encryption package, especially one for which source code is unavailable for scrutiny. I've learned an important lesson in this business. You can never depend on someone else to ensure your privacy. You have to do it yourself. Phil From nobody at alumni.cco.caltech.edu Sun Nov 15 17:29:37 1992 From: nobody at alumni.cco.caltech.edu (nobody at alumni.cco.caltech.edu) Date: Sun, 15 Nov 92 17:29:37 PST Subject: Extortion Explosion Message-ID: <9211160130.AA12418@alumni.cco.caltech.edu> Extortion Explosion Introduction: Governments are in the extortion-and-protection racket, as are some well-known smaller ventures. Why do these major organizations spend effort on protecting, instead of just extorting? Current protection rackets maintain a monopoly and manage "their" resources for sustained yield. Without protection, their revenues would decline through a tragedy of the commons mechanism. Other rackets would threaten the same victims, piling extortion on extortion, until the economic field is bare. Crypto technologies promise to liberate us from government extortion and the "protection" of victimless crime laws by enabling the growth of a new sphere of economic activity based on voluntary, secret transactions. But are these technologies so limited in their power? New opportunities in the extortion industry: Old problem: the victim may inform the police, making it risky to pick up the money, which will likely be watched. New solution: demand payment via cryptomoney. Old problem: if you build a reputation for carrying out your threats, parasitic competitors can issue threats in your name, collecting while your reputation is good but destroying your reputation by not following through on threats. New solution: authenticate your threats and demands with digital signatures. Old problem: you may be caught firebombing the house, shooting the victim, slashing the victim's daughter's face, or whatever; if you subcontract to a thug, the thug may be caught and inform on you. New solution: use cryptomoney (and a reputation for paying) to hire thugs while maintaining anonymity. Old problem: providing protection, so that you keep a supply of economically viable victims from whom to extort. New solution: Please find one! If the government can't protect victims from you, how can you protect them from competitors? If this analysis is correct, then crypto technologies will make extortion a highly profitable growth industry, making the security of property and persons (outside tightly-knit walled communities?) incompatible with the continued existence of free computer networks as we know them. Rather than suffering from a single oppressor with an incentive to keep us productive, we would become prey to an unbounded number, each competing to strip our assets before they vanish. Society will surely suppress free networks once this starts to happen; the harder it is to suppress free networks, the greater the oppression will be. Some objections and answers: Q:Isn't it too bleak and pessimistic to believe that the best we can do is to help our oppressors to maintain their monopoly on oppressing us? A1: The Soviet Union was established as a result of a movement that aimed to overthrow an oppressive order. Millions then died under an even more oppressive order. This was bleak, but it happened anyway. A2: Better one oppressor than many, all competing to be the first to kill and eat the goose, knowing that they can't get the golden eggs anyway. A3: Profit is a powerful motive, and conventional profitable activities are imitated and expanded until demand saturates. Crypto-extortion should be highly profitable, but the "supply" is delivered by force, so there is no problem with competitors saturating the "demand" until the victims are drained quite dry. This gives grounds for pessimism. Q: Doesn't the enormous potential of this technology for expanding liberty outweigh these theoretical dangers? What about our hopes and dreams, our vision of a better world? A: These hopes spring from a theoretical social and economic analysis of the impact of crypto technologies, and cryptomoney in particular. The above line of reasoning extends the same analysis. I hope it is wrong, and would be greatly relieved to hear a convincing reason for dismissing it. If it stands, the prospect seems to be either the destruction of society by free networks, or the destruction of free networks by society. The longer we can postpone this choice, the better. Q: Won't cryptomoney be so hard to establish that there's no point in worrying about this? A: If so, then there is equally well no benefit in attempting to implement it. The question is, are there any conditions for "success" that don't generate disaster? Saying the gun probably isn't loaded isn't an argument for putting it to your head and pulling the trigger. Q: Isn't it too late to stop these technologies? A: For public key communication (secrecy and authentication), probably yes. For cryptomoney, possibly no. Most of the benefits of crypto technology seem to come from the former, and most of the danger of an extortion explosion seems to come from the latter. Wishful thinking in the pursuit of liberty is no virtue; realism in the defense of imperfect liberty is no vice. Free-lance oppression isn't freedom, and I don't want it. Cassandra 9531290065272860 P.S. Your neighbor didn't pay me, and his house is ash. Will you pay me? All I ask this month is $100, which you can well afford. (Next month is negotiable, and I can't speak for my competitors.) From 74076.1041 at CompuServe.COM Sun Nov 15 17:37:40 1992 From: 74076.1041 at CompuServe.COM (Hal) Date: Sun, 15 Nov 92 17:37:40 PST Subject: Why remailers... Message-ID: <921116013001_74076.1041_DHJ41-1@CompuServe.COM> Tim mentioned that not many people on the list have expressed interest in the remailers, and it occurs to me that maybe people don't all share the vision of why this crypto technology is important. I'm trying to recall how I learned about the possibilities of this technology. I recall reading "True Names" a few years ago. Vinge had his netters exchanging mail anonymously. The hero downloaded a big batch of messages from a BBS and tried decrypting all of them to see which were for him. Okay, I thought, that would be a way of disguising which messages you were _receiving_. Then Vinge said something like "and using more elaborate techniques, the sender of a message could be hidden as well." Hold on, I thought. That will never work. If they tap your line, they're going to know exactly what messages you're sending. Too bad. Vinge had a clever idea going, but it's flawed. I only learned about Chaum's crypto stuff last year. Somebody on the Extropians list mentioned PGP, and I'd always had a casual interest in crypto, so I downloaded it and played with it some. I thought it was great and really got into it in a big way. This got me interested in crypto in general, so I started doing some library research. When I found Chaum's stuff, it just blew me away. The first article I found, I think, was his CACM paper which is an overview of many of the things that are possible. I started trying to track down other papers by Chaum. Here were all the technologies needed to make Vinge's world work, technologies which Vinge apparently knew about long before I did. It seemed so obvious to me. Here we are faced with the problems of loss of privacy, creeping computerization, massive databases, more centralization - and Chaum offers a completely different direction to go in, one which puts power into the hands of individuals rather than governments and corporations. The computer can be used as a tool to liberate and protect people, rather than to control them. Unlike the world of today, where people are more or less at the mercy of credit agencies, large corporations, and governments, Chaum's approach balances power between individuals and organizations. Both kinds of groups are protected against fraud and mistreatment by the other. Naturally, in today's society, with power allocated so disproportionately, such ideas are a threat to large organizations. Balancing power would mean a net loss of power for them. So no institution is going to pick up and champion Chaum's ideas. It's going to have to be a grass-roots activity, one in which individuals first learn of how much power they can have, and then demand it. Where do the remailers fit in? They represent the "ground floor" of this house of ideas - the ability to exchange messages privately, without revealing our true identities. In this way we can engage in transactions, show credentials, and make deals, without government or corporate databases tracking our every move as they can today. Only by securing the ability to communicate privately and anonymously can we take the next steps towards a world in which we each have true ownership and control over information about our lives. Chaum's ACM paper is titled, provocatively, "Security Without Identification - Transaction Systems to Make Big Brother Obsolete." The work we are doing here, broadly speaking, is dedicated to this goal of making Big Brother obsolete. It's important work. If things work out well, we may be able to look back and see that it was the most important work we have ever done. Hal Finney 74076.1041 at compuserve.com From barrus at tree.egr.uh.edu Sun Nov 15 18:43:30 1992 From: barrus at tree.egr.uh.edu (Karl L. Barrus) Date: Sun, 15 Nov 92 18:43:30 PST Subject: Chaum's papers Message-ID: <9211160243.AA07165@tree.egr.uh.edu> Hal Finney writes: > This got me interested in crypto in general, so I started doing some > library research. When I found Chaum's stuff, it just blew me away. What else has Chaum written about? I saw his Scientific American cryptomoney article, and have heard of his dc-nets, but what other protocols has he discussed? Any pointers on journal articles would be appreciated - I think tomorrow I'll hit the library and go sifting for everything Chaum has written! /-----------------------------------\ | Karl L. Barrus | | barrus at tree.egr.uh.edu (NeXTMail) | | elee9sf at menudo.uh.edu | \-----------------------------------/ From nobody at alumni.cco.caltech.edu Sun Nov 15 19:09:16 1992 From: nobody at alumni.cco.caltech.edu (nobody at alumni.cco.caltech.edu) Date: Sun, 15 Nov 92 19:09:16 PST Subject: Extortion Explosion Message-ID: <9211160310.AA14098@alumni.cco.caltech.edu> Cheer up, Cassandra! Things aren't all that bad. > New opportunities in the extortion industry: > > Old problem: the victim may inform the police, making it risky to pick up the > money, which will likely be watched. > New solution: demand payment via cryptomoney. Many forms of electronic money can be traced if there is cooperation between the payer and the bank. For example, in "Untraceable Electronic Cash", by Chaum, Fiat, and Naor, in Crypto 88, we find Alice withdrawing money from the bank, re-blinding it, and developing a "digital coin", C. She then pays that to Bob, who deposits C in the bank. The protocol goes to great length to protect Alice, so that the bank can't link C with her account. However, if she simply _tells_ the bank the value of C, then when Bob goes to deposit it, he can get caught. > Old problem: if you build a reputation for carrying out your threats, > parasitic competitors can issue threats in your name, collecting while your > reputation is good but destroying your reputation by not following through on > threats. > New solution: authenticate your threats and demands with digital > signatures. I can't imagine that this is a big problem right now - people falsely claiming to represent Big Willie when they actually don't, and trying to extort money based on Willie's fearsome reputation. That sounds like a dangerous business. So reducing this "problem" won't make much of a difference. > Old problem: you may be caught firebombing the house, shooting the victim, > slashing the victim's daughter's face, or whatever; if you subcontract to a > thug, the thug may be caught and inform on you. > New solution: use cryptomoney (and a reputation for paying) to hire thugs > while maintaining anonymity. Well, if thugs know that they are now going to be taking the sole responsibility for their actions, without the safety of knowing that they can rat on their employer if worse comes to worst, then they'll charge more to make up for the greater risk. This will make extortion less profitable. > Old problem: providing protection, so that you keep a supply of economically > viable victims from whom to extort. > New solution: Please find one! If the government can't protect victims > from you, how can you protect them from competitors? This is the key point. What stops protection rackets now? Is it really the points listed above: that the money may be traced, that others may falsely benefit from my reputation, that thugs may inform on me? What about simple physical surveillance of property? What about revenge on the transgressors? (As above, the revenge would be restricted to the thugs who did the job, but if it was bad enough it would still have a strong deterrent effect.) > Wishful thinking in the pursuit of liberty is no virtue; realism in the > defense of imperfect liberty is no vice. Free-lance oppression isn't freedom, > and I don't want it. > > Cassandra > 9531290065272860 It makes more sense to have good fire and police forces to deal with the bad guys than to get all in a tizzy because the bad guys can talk to each other now without getting caught. Polyanna --- Undressed PGP public key. Dress it up yourself. --- mQA9AisGm6sAAAEBgLsub7XIi32DjNFKJmGFajDNNIeql4RBmHG/mh9Ns58aBgMv wGRi0KkZ0YIYZZnLpwAFEbQkUG9seWFubmEsIGMvbyA8Y3lwaGVycHVua3NAdG9h ZC5jb20+ =uoWN From phr at napa.Telebit.COM Sun Nov 15 19:43:32 1992 From: phr at napa.Telebit.COM (Paul Rubin) Date: Sun, 15 Nov 92 19:43:32 PST Subject: Rander box and other stuff In-Reply-To: <9211152148.AA24934@apple.com> Message-ID: <9211160343.AA11287@napa.TELEBIT.COM> >I have a question regarding the ideas which have been circulating >about using CD ROMs as key storage. How does one go about >rapidly and effectively erasing everything on a CD ROM? A lab proven method: Take CD-ROM. Place in standard kitchen microwave. Set on high power cook for 5 seconds. Press start. Watch the action. Hang resulting artifact on wall as curiosity, which is all it's good for now. Let the wave air out a little (this won't fry it). You should know better than this. Microwaving cracks the aluminum coating into a lot of small pieces, but almost all the pieces are larger than a few square mm. even if you cook until quite "well done". A few mm. of a CD is a *lot* of contiguous bits that could be recovered by a determined enough adversary, and you likely wouldn't ebe bothering with OTP's unless you're concerned with very determined adversaries. I agree with the person who griped that OTP's are making excessive list traffic compared with interesting protocols, etc. OTP's get rehashed on sci.crypt every few months, as that person pointed out. From Tom.Jennings at f111.n125.z1.FIDONET.ORG Sun Nov 15 22:27:49 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Sun, 15 Nov 92 22:27:49 PST Subject: Why remailers... Message-ID: <3744.2B07398C@fidogate.FIDONET.ORG> U> From: 74076.1041 at CompuServe.COM (Hal) re: why remailers aren't as exciting as RNG's. Well, remailers are working, admittedly a bit clunky at the moment, and RNGs being talked about aren't. And we're primarily hackers. Once something's working, it's less interesting, no? :-) The next step for remailers is to make them actually *usable*, routinely. Their current status is no fault of the implementors, it's a first pass and a test bed (I ain't complaining!) I just don't think it's a big secret, nor a big problem. Development is always slow and boring... :-) --- ReadMail * Origin: tomj at fidosw.fidonet.org / World Power Systems (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET - Tom.Jennings at f111.n125.z1.FIDONET.ORG From Tom.Jennings at f111.n125.z1.FIDONET.ORG Sun Nov 15 22:27:50 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Sun, 15 Nov 92 22:27:50 PST Subject: Rander box and other stuff Message-ID: <3745.2B07398E@fidogate.FIDONET.ORG> U> A lab proven method: Take CD-ROM. Place in standard U> kitchen microwave. Set on high power cook for 5 U> seconds. Press start. Watch the action. If its a CD ROM, then there's a bunch of them. Someone else will have a copy. Aternately, Iif you mark which keys are used, then it will be detectable which keys were used (sic). It would be better to have all of the CD ROMs laying about, untouched, and secret the key-selection elsewhere. PS: I get lots of really bad CDs in the mail, from the days when I was doing HOMOCORE zine. I used to save up big stacks of them and try to trade them in at used record stores. They are all so awful (eg. bottom-rotation gunk on "modern rock" stations.) that the stores won't take them! I now nuke 'em. Far more fun! --- ReadMail * Origin: tomj at fidosw.fidonet.org / World Power Systems (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET - Tom.Jennings at f111.n125.z1.FIDONET.ORG From 74076.1041 at CompuServe.COM Sun Nov 15 23:37:38 1992 From: 74076.1041 at CompuServe.COM (Hal) Date: Sun, 15 Nov 92 23:37:38 PST Subject: Chaum's papers Message-ID: <921116073129_74076.1041_DHJ35-1@CompuServe.COM> A couple of people have asked for references to Chaum's papers. The August, 1992 issue of Scientific American was mentioned here, I think. The ACM paper I referred to is "Security Without Identification: Transaction Systems to Make Big Brother Obsolete", October 1985. The "DC-Net" is described in "The Dining Cryptographers Problem: Unconditional Sender and Recipient Untraceability", Cryptology, 1988, volume 1, p65-75. The "Mix-net", which is similar to the remailers we are experimenting with, is described in "Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms", CACM, February, 1981. Chaum also frequently presents papers at the Crypto conferences, so if you can get access to the proceedings of these at the library you will usually find one or two papers by him in each volume. However, in recent years he has published on other topics which don't seem as relevant to the freedom/privacy issues we are concerned with. Hal 74076.1041 at compuserve.com From gg at well.sf.ca.us Mon Nov 16 00:59:25 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Mon, 16 Nov 92 00:59:25 PST Subject: Rander box and other stuff Message-ID: <199211160858.AA23576@well.sf.ca.us> So we need to set up UPSs (uninterruptable power supplies, i.e. backup power) for our u-wave ovens, and build a standard interface which will set the appropriate parameters (5 sec on high cook) and start, which can be connected to a burglar alarm with panic switches and keypad with duress code. Then if the barbarians come to the door, it's one-two-three-FLUSH! Somewhat inconvenient if the barbarians come a-callin' when you're in the middle of a crypto session ("'scuse me while I put something in for dinner...") but doable... -gg From tcmay at netcom.com Mon Nov 16 01:13:51 1992 From: tcmay at netcom.com (Timothy C. May) Date: Mon, 16 Nov 92 01:13:51 PST Subject: The Dining Cryptographers Protocol Message-ID: <9211160910.AA13370@netcom.netcom.com> Fellow Dining Cryptographers (and Cypherpunks), Hal Finney has been suggesting I forward to this list some articles I wrote for another list of like-minded folks, the "Extropians" list. We had some fascinating discussions of digital money, DC-nets, digital pseudonyms (a la Vernor Vinge's "True Names," as Hal has noted), etc. Basically the stuff I put in my .signature, and so on. These topics are, in my opinion, at the core of what we are doing on this list. It is highly gratifying to see the pieces falling into place. And at our crypto session at the Hackers Conference, it became clear to many people just how close we are. So since Hal just forwarded me one of my old postings, how can I resist? (I still _have_ my old posts, but no longer on my NETCOM system, so reposting them takes a bit of effort. So I'll just forward to you the posting Hal just forwarded to me!) Hal Finney writes: I was looking through some old Extropians messages and found this one which you wrote about DC nets. I don't know if you archive your old messages, but I thought this had some good stuff, especially at the end where you talk about the applications of crypto anonymity. You would probably want to change the use of Extropians to Cypherpunks or some such, if you wanted to re-post it there. Hal Return-Path: To: Extropians at gnu.ai.mit.edu From: uunet!netcom.com!tcmay (Timothy C. May) Subject: Dining Cryptographers X-Original-To: Extropians at gnu.ai.mit.edu Date: Tue, 18 Aug 92 15:45:34 PDT X-Extropian-Date: Remailed on August 18, 372 P.N.O. [22:46:47 UTC] Reply-To: uunet!gnu.ai.mit.edu!Extropians Marc R. has opened the door for me to get into some really exciting stuff: > > Tim May mentioned a new method from Chaum for defeating traffic analysis: > > > Chaum has since improved the tamper-responding "mix" by going to a pure > > software scheme which he calls "the Dining Cryptographers Protocol." It's > > described in Vol. 1, Number 1 of "Journal of Cryptology," 1988. If there's > > interest, I'll summarize it. > > Yes, please, Tim! > > > M. Complexity Warning: This stuff (I'm being informal) is easy once you get the basic idea. But getting the basic idea usually involves reading several articles on what RSA, digital signatures, etc., are all about, working out some examples, thinking about it, drawing pictures with other folks, and finally having an "Aha!" experience (in Werner Erhard's terms, you "get it"). The ASCII nature of the Net is not conducive to learning this stuff, despite the excellent summaries of crypto by Marc R. and Perry M. The almost-latest "Scientific American," August, has an article by David Chaum on digital money, and the latest "Spectrum," available at selected newstands, has several articles on security and cryptography. Also, there are lots of books. Look 'em up in a university library or flip through them at a large technical bookstore and pick the one you like the most. (I like a slim Springer-Verlag paperback, "Modern Cryptology," by Gilles Brassard, 1988, as a good intro to "modern"--as opposed to "classical"--crypto.) If the stuff in this posting, and on crypto in general, is beyond your current understanding, either ignore it, skim it and try to get the gist, or dig into the articles and books. Anyway, back to "The Dining Cryptographers Problem: Unconditional Sender and Recipient Untraceability," David Chaum, Journal of Cryptology, I, 1, 1988. Since this journal is hard to get, I'll discuss the article in some detail. (The techniques have major implications for anarchocapitalism and for Extropian ideas.) Abstract: "Keeping confidential who sends which messages, in a world where any physical transmission can be traced to its origin, seems impossible. The solution presented here is unconditionally or cryptographically secure, depending on whether it is based on one-time-use keys or on public keys. respectively. It can be adapted to address efficiently a wide variety of practical considerations." A word on terminology: "Unconditionally secure" means what it says: no computer will ever crack it. One-time pads are unconditionally secure...no code or cipher is involved, except the one-time pad, so the message is secure as long as the pad has not been compromised. "Cryptographically secure" means secure so long as various crypto ciphers are secure, which may be for a very, very long time (e.g., with very large primes, in RSA). Chaum describes some "dining cryptographers," which I will playfully change to "dining Extropians." (The term is of course a variant of the seminal "dining logicians problem" in computer science) Three Extropians are having dinner, perhaps in New York City. Their waiter tells them that their bill has already been paid, either by the NSA or by one of them. The waiter won't say more. The Extropians wish to know whether one of them paid, or the NSA paid. But they don't want to be impolite and force the Extropina payer to 'fess up, so they carry out this protocol (or procedure): Each Extropian flips a fair coin behind a menu placed upright between himself and the Extropian on his right. The coin is visible to himself AND to the Extropian on his left. Each Extropian can see his own coin and the coin to his right. STOP RIGHT HERE! Please take the time to make a sketch of the situation I've described. If you lost it here, all that follows will be a blur. I'm sparing you folks my attempt at an ASCII drawing! Each Extropians then states out loud whether the two coins he can see are the SAME or are DIFFERENT, e.g., "Heads-Tails" means DIFFERENT, and so forth. For now, assume the Extropians are truthful. A little bit of thinking shows that the total number of "DIFFERENCES" must be either 0 (the coins all came up the same), or 2. Odd parity is impossible. Now the Extropians agree that if one of them paid, he or she will SAY THE OPPOSITE of what they actually see. Remember, they don't announce what their coin turned up as, only whether it was the same or different as their neighbor. Suppose none of them paid, i.e., the NSA paid. Then they all report the truth and the parity is even (either 0 or 2 differences). They then know the NSA paid. Suppose one of them paid the bill. He reports the opposite of what he actually sees, and the parity is suddenly odd. That is, there is 1 difference reported. The Extropians now know that one of them paid. But can they determine which one? Suppose you are one of the Extropians and you know you didn't pay. One of the other two did. You either reported SAME or DIFFERENT, based on what your neighbor to the right (whose coin you can see) had. But you can't tell which of the other two is lying! (You can see you right-hand neighbor's coin, but you can't see the coin he sees to his right!) This all generalizes to any number of people. If none of them paid, the parity is even. If one of them paid, the parity is odd. But which one of them paid cannot be deduced. And it should be clear that each round can transmit a bit, e.g., "I paid" is a "1". The message "Attack at dawn" could thus be "sent" untraceably with multiple rounds of the protocol. The Crypto Ouija Board: I explain this to people as a kind of ouija board. A message, like "I paid" or a more interesting "Transfer funds from.....," just "emerges" out of the group, with no means of knowing where it came from. Truly astounding. Now there are many interesting wrinkles and elaborations to this protocol. I'll note just a few. 1. Collusion. Obviously the Extropians can collude to deduce the payer. This is best dealt with by creating multiple subcircuits (groups doing the protocol amongst themselves). Lots more stuff here. Chaum devotes most of the paper to these kind of issues and their solutions. 2. With each round of this protocol, a single bit is transmitted. Sending a long message means many coin flips. Instead of coins and menus, the neighbors would exchange lists of random numbers (with the right partners, as per the protocol above, of course. Details are easy to figure out.) 3. Since the lists are essentially one-time pads, the protocol is unconditionally secure, i.e., no assumptions are made about the difficulty of factoring large numbers or any other crypto assumptions. 4. Participants in such a "DC-Net" (and here we are coming to the heart of the "crypto anarchy" I have mentioned several times, and which is perhaps foolishly advertised in my .sig) could exchange CD-ROMs or DATs, giving them enough "coin flips" for zillions of messages, all untraceable! The logistics are not simple, but one can imagine personal devices, like smart card or Apple "Newtons," that can handle these protocols (early applications may be for untraceable brainstorming comments, secure voting in corportate settings, etc.) 5. The lists of random numbers (coin flips) can be generated with standard cryptographic methods, requiring only a key to be exchanged between the appropriate participants. This eliminates the need for the one-time pad, but means the method is now only cryptographically secure, which is often sufficient. (Don't think "only cryptographically secure" means insecure....the messages may remain encrypted for the next billion years) 6. Collisions occur when multiple messages are sent at the same time. Various schemes can be devised to handle this, like backing off when you detect another sender (when even parity is seen instead of odd parity). In large systems this is likely to be a problem. Solutions are left as an exercise. 7. Noise. Some participants may try to flood the circuit with spurious messages, to defeat the system or for whatever other reasons. This is still an issue. (If there's anything to take away from crypto, it's that nothing is as simple as it looks, that there are always devious ways to spoof, jam, and forge. I expect you've seen this from some of the debate on digital voting schemes.) What Can "DC-Net" Be Used For?: * Untraceable mail. Useful for avoiding censorship, for avoiding lawsuits, and for all kinds of crypto anarchy things. * Fully anonymous bulletin boards, with no traceability of postings or responses. Illegal materials can be offered for sale (my 1987 canonical example, which freaked out a few people: "Stealth bomber blueprints for sale. Post highest offer and include public key."). Think for a few minutes about this and you'll see the profound implications. * Decentralized nexus of activity. Since messages "emerge" (a la the ouija board metaphor), there is no central posting area. Nothing for the government to shut down, complete deniability by the participants. * Only you know who your a partners are....in any given circuit. And you can be in as many circuits as you wish. (Payments can be made to others, to create a profit motive. I won't deal with this issue, or with the issue of how reputations are handled, in this posting.) * The tamper-responding "digital mixes" can still be useful, and may supplement this purely software-based approach. * Digital money gets involved, too, both for payments in this system, and in terms of "alternative currencies." I'm not an economist, so I'll leave this for others to go into in more detail. Enough for now. Chaum's work is just the start. These systems can initially be set up for "innocuous" purposes like research into crypto techniques (not yet banned in the U.S.), role-playing games, religions, and the like. Once they get going, it'll be too late to stop the other things. Hope you liked this summary. Please read the articles...there's just no way my posting can do justice to them (though I admit I've concentrated my efforts on the political aspects, which "respectable" crypto researchers rarely mention, so perhaps the flavor here is a bit more Extropian than you'll find elsewhere.) --Tim (part of the "Too Many Tims!" Conspiracy) -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at 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^756839 | PGP Public Key: awaiting Macintosh version. From mark at coombs.anu.edu.au Mon Nov 16 01:23:23 1992 From: mark at coombs.anu.edu.au (Mark) Date: Mon, 16 Nov 92 01:23:23 PST Subject: Nuking CD's Message-ID: <9211160914.AA29147@coombs.anu.edu.au> If you dont have small children about the house get a container of the right acid so you slip your cd through the slot and 3 bubbles later it's disintegrated. Mark From gnu Mon Nov 16 01:45:42 1992 From: gnu (gnu) Date: Mon, 16 Nov 92 01:45:42 PST Subject: Cryptographer jailed for selling crypto to political opposition? Message-ID: <9211160945.AA19475@toad.com> Date: Sun, 15 Nov 92 02:17:47 -0500 From: barlow at icecube.pinedale.wy.us (John Perry Barlow) Message-Id: <9211150717.AA00755 at icecube.pinedale.wy.us> To: gnu at toad.com Subject: Here's one to pass on to CypherPunk Begin forwarded message: Date: Sun, 15 Nov 1992 2:53:58 UTC+0100 From: "(Miguel Gallardo)" Subject: Cryptodanger!!! To: barlow at eff.org, barlow at icecube.pindale.wy.us, postmaster at eff.org Dear friends, I think that paranoid is almost inevitable in Cryptology. The real danger is just trying to avoid that thinking. But sometimes things are really difficult! One year ago I met a man in a conference on Cryptology. He was from Switzerland and was working for a company named CRYPTO AG. He is fluent in several lenguages, including Spanish and Arabic, and was not afraid about his interest in taboo (cryptoanalysis). I really enjoyed that conversation. Last week I listened a conversation about him, and I know now that he is in jail at Teheran (Iran). He is acused for atenting against the shii goverment just because he was sellin cryptology to the political opposition. Do you know about that? If so, do you have anything published on it? His name is Hans Buhler, CRYPTO AG, P.O. Box 474 CH-6301 Zug/Switzerland. I am really interested in any information about him! Nobody answer my fax to his company, or to Iran embassy here (!?). _ _ _ _ ' ) ) ) // / / / o __ _ // / ' (_<_(_//_/_ Date: Sat, 14 Nov 1992 20:17:06 -0500 To: interesting_people at aurora.cis.upenn.edu From: Dave Farber Subject: from RISKS Reprinted with permission ("do with it as you wish. Granger") A "Viewpoint " piece in The Institute, November 1992 Balancing National Interests The September/October issue of The Institute carried a front page story reporting that the Federal Bureau of Investigation is promoting legislation that would require all telephone systems to be designed in such a way that they can be wiretapped by law enforcement officials. The argument is that wiretapping is a key tool in much of law enforcement, particularly in fields such as drugs, racketeering, conspiracy and white collar crime, and that unless care is taken in the design of future telecommunications systems, this tool may become difficult or impossible to exercise. To solve this problem the FBI is promoting legislation that would establish design requirements on future telephone systems. Not surprisingly, civil liberties groups and telephone companies are reported to be less than enthusiastic. While interesting and important in its own right, this controversy is perhaps even more important as a symbol of a broader set of conflicts between a number of important national interests. As a country, we want to promote: * Individual privacy (including the right of citizens and other residents of the U.S. to keep personal records private, hold private communications with others, and move about without being "tracked".) * Security for organizations (including protection of financial transactions, and the ability to keep corporate data, plans, and communications confidential.) * Effective domestic law enforcement (including the ability to perform surveillance of legitimately identified suspects, and the ability to audit and reconstruct fraudulent activities.) * Effective international intelligence gathering (including the ability to monitor the plans and activities of organizations abroad that may pose a threat to the U.S. or to other peaceful states and peoples.) * Secure world-wide reliable communications for U.S. diplomats and the military, for U.S. business, and for U.S. citizens in their activities all around the world (including the ability to maintain and gain access to secure, reliable, communications channels.) Just as with most of our society's other fundamental objectives, these objectives are in conflict. You can not maximize them all because getting more of some involves giving up some of others. A dynamic tension must be created that keeps the various objectives properly balanced. That socially optimal point of balance may change gradually over time as world conditions and our society's values evolve. An electrical engineer who thinks for a moment about the problem of achieving any particular specified balance among the various objectives I have listed will quickly conclude that communications and information technology design choices lie at the heart of the way in which many of the necessary tradeoffs will be made. We would like easy portable communications for all, but doing that in a way that allows people to keep their legitimate travels private poses significant design challenges. Banks and other businesses would like secure encrypted communications world-wide, but promoting the general availability of such technologies all around the world severely complicates the signal intelligence operations of intelligence organizations. The troubling thing about the FBI's legislative proposals is not that they are being made, but that we lack a broader institutional context within which to evaluate them. In making such choices, we need to look systematically at all the legitimate interests that are at stake in telecommunications and information technology design choices, consider the ways in which technology and the world are evolving, and integrate all these considerations to arrive at a reasoned balance. In the old days, if things got too far out of line in some balance (for example, between freedom of the press and protection against liable), the courts simply readjusted things and we went on. Today, and increasingly in the future, with many of these balances hard wired into the basic design of our information and communication systems, it may be much harder to readjust the balance after the fact. There are several organizations that should be working harder on these issues. On the government side the Telecommunication and Computing Technologies Program in the Office of Technology Assessment should be doing more systematic studies of these tradeoffs to help inform the Congress; The National Telecommunications and Information Administration in the Department of Commerce (or some appropriate interagency committee) should be doing similar studies to develop more coherent and comprehensive executive branch policy; and the Office of Policy and Plans in the Federal Communications Commission (which is an independent regulatory agency not directly subject to executive branch policy) should be giving these issues more attention so it can better support the Commissioners when they confront such tradeoffs. On the non-government side, the Office of Computer and Information Technology at the National Research Council might appropriately mount a comprehensive study. There is an ideal opportunity here for a private foundation to fund an independent blue-ribbon commission. Finally, the computer and telecommunications industries, both individually and collectively through their industry associations, should be taking more interest in how the country will strike these all important balances. M. Granger Morgan M. Granger Morgan (F) is head of the Department of Engineering and Public Policy at Carnegie Mellon University where he is also a Professor in the Department of Electrical and Computer Engineering and in the H. John Heinz III School of Public Policy and Management. He teaches and performs research on a variety of problems in technology and public policy in which technical issues are of central importance. From c0408982 at techst02.technion.ac.il Mon Nov 16 02:33:09 1992 From: c0408982 at techst02.technion.ac.il (Michael Gleibman) Date: Mon, 16 Nov 92 02:33:09 PST Subject: Unsubscribe Message-ID: <9211161029.AA14695@techst02.technion.ac.il> Unsubscribe me from this list, please, it is a huge value of mail:-)... Thank you in advance. c0408982 at techst02.technion.ac.il From gg at well.sf.ca.us Mon Nov 16 03:31:18 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Mon, 16 Nov 92 03:31:18 PST Subject: Cryptographer jailed for selling crypto to political opposition? Message-ID: <199211161129.AA29310@well.sf.ca.us> Crypto AG is the current name of the Hagelin company, which was founded by Boris Hagelin shortly before WW2. Hagelin's main contribution was the advancement of the mechanical rotor system; their M-209 was a basic part of Allied battlefield operations. This machine was about the size of a desk phone base, and had a little knob which you'd turn to the letter you wanted to enter, one letter at a time, and after each letter you'd press a handle, whicc would operate the mechanism and printo out both a cleartext and ciphertext strip on paper. The ciphertext would be handed to the radio operator to be sent in morse (or in civilian use, via telegraph land-lines). Hagelin made various versions of their basic rotor machine. One was a pocket-sized unit, like 3" x 5", with a rotary alphabetic dial on the front. Hagelin supplied most of the noncommunist world with crypto tech after WW2. Chances are that Crypto AG has sufficient connexions in high places as to be able to get its people out of there. I'm familiar with another case involving a large northern Euro maker of telecom systems who had two engineers taken hostage in Iraq on some inflated charge, and sentenced to 7 years... the company fully expects to have its engineers out of there within six months, no question about it. -gg at well.sf.ca.us From mark at coombs.anu.edu.au Mon Nov 16 05:12:40 1992 From: mark at coombs.anu.edu.au (Mark) Date: Mon, 16 Nov 92 05:12:40 PST Subject: Cryptographer jailed for selling crypto to political opposition? Message-ID: <9211161312.AA09303@coombs.anu.edu.au> >Chances are that Crypto AG has sufficient connexions in high places as to be >able to get its people out of there. I'm familiar with another case >involving a large northern Euro maker of telecom systems who had two >engineers taken hostage in Iraq on some inflated charge, and sentenced to 7 >years... the company fully expects to have its engineers out of there within >six months, no question about it. Shades of Ross Perot. Is it illegal to attempt to attack Iraq's computer systems if you were sitting in your room one day and decided it was time to play havoc right back at them? I realise the CIA etc would be involved in that sort of thing anyway but if a private citizen decided to quietly have a dabble, and he wasnt spotted by the Iraqi's at least, would many people get upset? There is the possibility of encroaching on USA clandestine operations I guess... Are there any precedents for this? Has anyone actually become aware of attempts? :) Mark From avalon at coombs.anu.edu.au Mon Nov 16 07:03:26 1992 From: avalon at coombs.anu.edu.au (Darren Reed) Date: Mon, 16 Nov 92 07:03:26 PST Subject: AUSCRYPT '92 Message-ID: <9211161438.AA12340@coombs.anu.edu.au> Hmmm...after reading the announcement in alt.security it seems quite a huge conference for ppl interested in cryptology...anyone going ? (Rather large number of papers being presented too!) darren From whitaker at eternity.demon.co.uk Mon Nov 16 08:51:45 1992 From: whitaker at eternity.demon.co.uk (Russell E. Whitaker) Date: Mon, 16 Nov 92 08:51:45 PST Subject: Apple including PKS? Message-ID: <4195@eternity.demon.co.uk> Phil Karn says: > > I've learned an important lesson in this business. You can never depend on > someone else to ensure your privacy. You have to do it yourself. > The same goes for the ultimate standard of physical security: defence of one's person against physical attack. Arguments for the right to keep and bear arms can often be directly mapped onto arguments for the right to keep and use pkeys. Russell Earl Whitaker whitaker at eternity.demon.co.uk Communications Editor 71750.2413 at compuserve.com EXTROPY: The Journal of Transhumanist Thought AMiX: RWHITAKER Board member, Extropy Institute (ExI) ================ PGP 2.0 public key available ======================= From hughes at soda.berkeley.edu Mon Nov 16 09:12:39 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Mon, 16 Nov 92 09:12:39 PST Subject: November 21 meeting, 12 noon, at Cygnus offices Message-ID: <9211161712.AA15115@soda.berkeley.edu> ANNOUNCEMENT ============ The Third Physical Cypherpunks Meeting: Project Planning It has become clear that lots of code needs to be written, and that we will be writing it. Therefore the Third Meeting will be devoted to project planning and design review. Date: November 21 Time: 12 noon Where: Cygnus Support offices Who: you, and anybody you know who wants to come, and so on. (Please do not post this announcements to public places, but do encourage private circulation.) Positive-Confimation: Please tell me if you are coming. Replies to hughes at soda.berkeley.edu. Please, I urge all of you on the list that can make to attend this time. This will be a pivotal meeting, since we are deciding priorities here. If you want to affect the course of development, you ought to show up. If you can't attend, corner someone on the list who will be there and convince them to represent your position. Eric Hughes AGENDA ====== 1. Key exchange. Bring a diskette with your PGP public key on it. Bring a machine which can read this diskette. Bring extra diskettes to collect keys on and to give out. Let us not be hypocrites and let us all know each other's public keys. 2. Project planning. We need a list of crypto projects and who is working on them. This will help coordination and avoid duplication of effort. We need to prioritize the projects to avoid premature development. We need to create strategies and design criteria. 3. Project logistics. We need to talk about the best ways to do widely distributed software development in this fairly anarchic environment. 4. Design review. Hal Finney and I have been duking it out behind the scenes working on a design schema for the next generation remailer. I'd like to present the design and have people critique it. (would be 5.) We won't be playing the crypto-anarchy game this time. It's not a dead duck, but this time we've got more urgent things to do. DIRECTIONS ========== Here is a reposting of the directions to the meeting place. ------------------------------------------------------------------ To: cypherpunks at toad.com Subject: Better directions to the meeting on Saturday at noon From: gnu at cygnus.com Someone asked for better directions, and the original ones were pretty skimpy anyway. Here's a better try. Cygnus Support 1937 Landings Drive Mt. View, CA 94043 There's no phone service there yet. 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, you can take a right into Landings Drive; this gets you into the complex from the north. Or you can go slightly further along Charleston and take the next right, into a driveway with a big "Landmark" sign in the middle. No matter which way you got into the complex, follow around it until you are on the side that faces the freeway. There's a clock tower that rises out of one of the buildings, to the right (south) of the deli. 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. If you are late and the door under the clock tower is locked, you can go to the deli (which will be around a building and left, as you face the door), cut between the buildings to the right of the deli, and into the back lawns between the complex and the farm behind it. Walk 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 From Marc.Ringuette at GS80.SP.CS.CMU.EDU Mon Nov 16 10:15:43 1992 From: Marc.Ringuette at GS80.SP.CS.CMU.EDU (Marc.Ringuette at GS80.SP.CS.CMU.EDU) Date: Mon, 16 Nov 92 10:15:43 PST Subject: The Dining Cryptographers Protocol Message-ID: <9211161815.AA29148@toad.com> My spin on the Dining Cryptographers Protocol is, it's nifty and theoretically strong, but in practice mixes are better for almost all uses. If you have N people in a DC-net, you must exchange N bits of traffic per bit of anonymous message transmitted. If you use mixes and send each message on M hops, you exchange M bits of traffic per bit of anonymous message transmitted. N is typically 100-10000, and M is typically 2-10. Mixes are more efficient. One advantage of DC-nets is that they're instant; with mixes there must be some delays in order to accumulate enough cover messages to defeat traffic analysis. -- Marc Ringuette (mnr at cs.cmu.edu) From hh at soda.berkeley.edu Mon Nov 16 10:44:37 1992 From: hh at soda.berkeley.edu (Eric Hollander) Date: Mon, 16 Nov 92 10:44:37 PST Subject: Rander box and other stuff In-Reply-To: <199211160858.AA23576@well.sf.ca.us> Message-ID: <9211161844.AA20421@soda.berkeley.edu> I heard something somewhere about hard disks with a layer of thermite inside the platter. Can you say "ferrous vapor"? For me the ideal cryptosystem would be a small notebook with a thermite hard drive and TEMPEST shielding and no multitasking. e From shipley at tfs.COM Mon Nov 16 11:21:05 1992 From: shipley at tfs.COM (Peter Shipley) Date: Mon, 16 Nov 92 11:21:05 PST Subject: Rander box and other stuff In-Reply-To: <9211161844.AA20421@soda.berkeley.edu> Message-ID: <9211161920.AA22901@edev0.TFS> > >I heard something somewhere about hard disks with a layer of thermite >inside the platter. Can you say "ferrous vapor"? > >For me the ideal cryptosystem would be a small notebook with a thermite hard >drive and TEMPEST shielding and no multitasking. > you forgot the auto self destruct if the unit is more then 4 meters from your person. -Pete From pmetzger at shearson.com Mon Nov 16 11:26:52 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Mon, 16 Nov 92 11:26:52 PST Subject: The legality of PGP In-Reply-To: <9211140007.AA19365@toad.com> Message-ID: <9211161902.AA08397@newsu.shearson.com> >From: S.E. Brown >Well, >I've been reading a lot of speculation and outright disinformation about >the legality of PGP. Does anyone have any informed information about the >actual legal status us sing and disseminating the program? PGP is based on RSA cryptography, which is patented. The patent is controlled by Public Key Partners, which has not granted a license for people to use PGP. Therefore, using PGP is possibly a patent violation, although thus far no action seems to have been taken by PKP in this respect. Perry From oren at apple.com Mon Nov 16 14:47:57 1992 From: oren at apple.com (Tim Oren) Date: Mon, 16 Nov 92 14:47:57 PST Subject: Digital Cash bibliography Message-ID: <9211162247.AA24502@apple.com> As a followup to Tom's bibliography, here's a list I compiled about six months ago on digital cash, including Chaum's basic articles, others published in this area, and a list of relevant U.S. patents. - Tim O. ----------- Bibliography for Digital Cash and Checks using Cryptographic Techniques Articles Chaum, D., Showing credentials without identification: transferring signatures between unconditionally unlinkable pseudonyms. (Springer-Verlag, Berlin, West Germany, p. 246-64, 1990)(Conference: Advances in Cryptology-AUSCRYPT '90 International Conference on Cryptology. Proceedings, Sydney, NSW, Australia, 8-11 Jan. 1990) Chaum, D. den Boer, B. van Heyst, E. Mjolsnes, S. Steenbeek, A., Efficient offline electronic checks. (Springer-Verlag, Berlin, Germany, p. 294-301, 1990)(Conference: Advances in Cryptology - EUROCRYPT '89. Workshop on the Theory and Application of Cryptographic Techniques Proceedings, Houthalen, Belgium, 10-13 April 1989) Chaum, D., Online cash checks. (Springer-Verlag, Berlin, Germany, p. 288-93, 1990)(Conference: Advances in Cryptology - EUROCRYPT '89. Workshop on the Theory and Application of Cryptographic Techniques Proceedings, Houthalen, Belgium, 10-13 April 1989) Chaum, David, Security without Identification: Transaction Systems to make Big Brother Obsolete; Communications of the ACM 28/10 (1985) 1030-1044. Chaum, D. Fiat, A. Naor, M., Untraceable electronic cash. (Springer-Verlag, Berlin, West Germany, p. 319-27, 1990)(Conference: Advances in Cryptology - CRYPTO '88. Proceedings, Santa Barbara, CA, USA, 21-25 Aug. 1988) Okamoto, T. Ohta, K., Disposable zero-knowledge authentications and their applications to untraceable electronic cash. (Springer-Verlag, Berlin, West Germany, p. 481-96, 1990)(Conference: Advances in Cryptology - CRYPTO '89. Proceedings, Santa Barbara, CA, USA, 20-24 Aug. 1989) Even, S., Secure off-line electronic fund transfer between nontrusting parties. (North-Holland, Amsterdam, Netherlands, p. 57-66, 1989)(Conference: Smart Card 2000: The Future of IC Cards. Proceedings of the IFIP WG 11.6 International Conference, Laxenburg, Austria, 19-20 Oct. 1987) Tunstall, J.S., Electronic currency. (North-Holland, Amsterdam, Netherlands, p. 47-8, 1989)(Conference: Smart Card 2000: The Future of IC Cards. Proceedings of the IFIP WG 11.6 International Conference, Laxenburg, Austria, 19-20 Oct. 1987) Hayes, Barry, Anonymous One-Time Signatures and Flexible Untracable Electronic Cash, in AusCrypt '90: A Workshop on Cryptology, Secure Communication and Computer Security, January, 1990. U. S. Patents W. M. Benton, Funds Transfer System using Optically Coupled, Portable Modules, US Pat. #4,454,414, Jun 12, 1984. W. G. Bouricius and P. E. Stuckert, Method and Apparatus for Secure Message Transmission for Use in Electronic Funds Transfer Systems, US Pat. #4,302,810, Nov. 24, 1981. D. Chaum, "Cryptographic Identification, Financial Transaction, and Credential Device," US Pat #4,529,870, Jul. 16, 1985. W. S. Powell, "Information Communicating Apparatus and Method," US Pat. #4,320,387, Mar. 16, 1982. P. E. Stuckert, "Personal Portable Terminal for Financial Transactions," US Pat. #4,277,837, Jul. 7, 1981. From hh at soda.berkeley.edu Mon Nov 16 15:11:38 1992 From: hh at soda.berkeley.edu (Eric Hollander) Date: Mon, 16 Nov 92 15:11:38 PST Subject: Rander box and other stuff In-Reply-To: <9211161920.AA22901@edev0.TFS> Message-ID: <9211162311.AA09645@soda.berkeley.edu> >>I heard something somewhere about hard disks with a layer of thermite >>inside the platter. Can you say "ferrous vapor"? >> >>For me the ideal cryptosystem would be a small notebook with a thermite hard >>drive and TEMPEST shielding and no multitasking. >> > >you forgot the auto self destruct if the unit is more then 4 meters from >your person. If we're going to have auto self destruct with a range limit, it should also be waterproof so I can take it swimming (and so that the self destruct system won't be impeded by water). And if it's going to have a four meter limit, it needs to be so light that I can carry it absolutely everywhere, like under 500 grams, and if it's going to be that small, it won't be able to have a keyboard (use pen input) or a hard drive (lots of battery backed ram instead). In fact, now that we've dropped the hard drive and the keyboard, it might as well just be a dedicated crytosystem, make it about 10cmX10cmX1cm and give it an ether port, an rs232 port, a pcmcia port and an rj11 port. It's doable and would provide the ultimate security. e From hh at soda.berkeley.edu Mon Nov 16 15:33:38 1992 From: hh at soda.berkeley.edu (Eric Hollander) Date: Mon, 16 Nov 92 15:33:38 PST Subject: Why remailers... In-Reply-To: <921116013001_74076.1041_DHJ41-1@CompuServe.COM> Message-ID: <9211162333.AA10951@soda.berkeley.edu> Remailers are extremely important, but we also need anonymous IP bouncers. An IP bouncer might work like this: there would be a user, a server, and a target. The server and user would each have key pairs (probably a new pair for each session), and would trade public keys. The user would request a port from the server, and then would issue (encrypted) commands to the server. These commands might include: telnet - open a connection to the target. The target would route its packets to the server, and the server would encrypt them and route them to the user. ignore - get ready to recieve lots of random bits and perhaps pass them on to other servers. This is needed to help a user confuse trafic analysis. A side note: it would be useful to have a standard port on all machines that would accept the encrypted ignore command, so that packets could just be sent off into the ether. Users who use bouncers would want to have their machines open up connections, issue the ignore command, and send random bits at some random interval. mail - act as an anonymous remailer (like the ones we already have set up). port - provide a port that other people can telnet in to. This type of anonymous bouncer would be helpful for everything we do with TCP, including perhaps mail. e From tribble at xanadu.com Mon Nov 16 18:19:20 1992 From: tribble at xanadu.com (E. Dean Tribble) Date: Mon, 16 Nov 92 18:19:20 PST Subject: The legality of PGP In-Reply-To: <9211161902.AA08397@newsu.shearson.com> Message-ID: <9211170057.AA11937@xanadu.xanadu.com> Also, every day they don't enforce the patent is silent reinforcement to the view that their patent is illegitamate (in that it covers a mathematical algorithm). I doubt this has legal standing other than as material to try to convince juries with. dean From hugh at domingo.teracons.com Mon Nov 16 19:11:21 1992 From: hugh at domingo.teracons.com (Hugh Daniel) Date: Mon, 16 Nov 92 19:11:21 PST Subject: Idea on Random Number Generators Message-ID: <9211170302.AA02806@domingo.teracons.com> The problem with Diodes and the like is that it is possable to induce a pattern into the output of these things. Well, might we be able to look at how and set up a counter such that if the open end is held high on one diode it gets driven down on a second circuit which get added togethor before we go onto to 0/1 ballencing? Next I would set up a drifting clock rate on the device reading the diode, this messes up many efects of interference and might help look for induced patterens! Hey, imagen a random number generator that tells you when the bad guys are trying to influence your random numbers! ||ugh From phr at napa.Telebit.COM Mon Nov 16 19:19:15 1992 From: phr at napa.Telebit.COM (Paul Rubin) Date: Mon, 16 Nov 92 19:19:15 PST Subject: Idea on Random Number Generators In-Reply-To: <9211170302.AA02806@domingo.teracons.com> Message-ID: <9211170318.AA25949@napa.TELEBIT.COM> It is very hard to generate really random numbers no matter what you do. See the famous RAND book "One Million Random Digits with 100,000 Normal Deviates" for their adventures trying to generate random numbers by counting particle emissions from a radioactive source. Even after all kinds of statistical massaging there were still correlations in the output. From mark at coombs.anu.edu.au Mon Nov 16 20:01:36 1992 From: mark at coombs.anu.edu.au (Mark) Date: Mon, 16 Nov 92 20:01:36 PST Subject: IP bouncers Message-ID: <9211170401.AA22825@coombs.anu.edu.au> >Remailers are extremely important, but we also need anonymous IP bouncers. > >An IP bouncer might work like this: there would be a user, a server, and a >target. The server and user would each have key pairs (probably a new pair >for each session), and would trade public keys. The user would request a >port from the server, and then would issue (encrypted) commands to the >server. > >These commands might include: >telnet - open a connection to the target. The target would route its >ignore - get ready to recieve lots of random bits and perhaps pass them on to >mail - act as an anonymous remailer (like the ones we already have set up). >port - provide a port that other people can telnet in to. >This type of anonymous bouncer would be helpful for everything we do with I have and use something along these lines. It was written by someone for other purposes but it should be easy enough to port to this application. It's rather inefficient at the moment unfortunately. I'll see what I can do to it. Mark From tom.jennings at f111.n125.z1.FIDONET.ORG Mon Nov 16 20:52:02 1992 From: tom.jennings at f111.n125.z1.FIDONET.ORG (tom jennings) Date: Mon, 16 Nov 92 20:52:02 PST Subject: ECPA - PRIVACY Message-ID: <3759.2B0852B9@fidogate.FIDONET.ORG> Crossposted from FidoNet PUBLIC_KEYS from: GK Pace to: Mike Riddle I just finished reading your article concerning the "laymans view" of the ECPA. I found it very informative, and interesting reading. Thank you for taking the time to study this issue, and share with the rest of us the conclusions you arrived at, upon doing so. I would like to comment upon some of what you've written, in hopes of expanding upon what you have conveyed, and have quoted your article so that those who haven't read your article will find it easier to understand the nature of my comments. ========== Begin Quote ========== Anytime someone passes what they hope to be a private communication to another, they expect that their fellow citizens will respect its privacy. Not only do the customs of society enforce this expectation, statute laws have been enacted to insure it. Thus, everyone knows, or should know, not to tamper with the mail. Everyone knows, or should know, not to electronically eavesdrop ("bug") someone else's telephone calls. And everyone knows, or should know, not to do likewise with computer communications. Alas, not everyone knows that. If everyone did, we wouldn't need laws to protect what ought to be our reasonable expectations of privacy. Not too long ago, the Congress of the United States passed PL 99-508, the Electronic Communications Privacy Act of 1986. In doing so, Congress was recognizing the way technology has changed society and trying to react to that change. ========== End Quote ========== This statement kinda sums up what the discussion is all about... and ties this subject into the provisions of the ECPA. seems like a fitting beginning for the remainder of what I'd like to discuss. ========== Begin Quote ========== What about electronic mail, or "e-mail?" E-Mail has been the single biggest area of misinformation about the new law. First, section 2701 does make it a federal offense to read someone else's electronic mail. That would be exceeding your authorization, since "private" e-mail systems do not intend for anyone other than the sender or receiver to see that mail. But, and a big but, sysops are excluded. ========== End Quote ========== This statement in and of itself lends credibility to the position that we have the right to read any messages passing thru our system... however as you continue to mention, this exclusion is not without conditions, and it isn't necessarily a "right" but is perhaps more accurately defined as an acknowledgement of the technical aspects of our respective systems, and the part we play in accomodating the transfer of E-mail... ========== Begin Quote ========== Whoever staffed the bill for Congress realized that system operators were going to have access to information stored on their systems. ========== End Quote ========== You also of course mention reasons for which this ability might be desired: ========== Begin Quote ========== There are practical technical reasons for this, but there are also practical legal reasons. While the Act does not directly address the liability of sysops for the use of their systems in illegal acts, it recognizes they might have some liability, and so allows them to protect themselves from illegal use. ========== End Quote ========== This statement reeks of common sense... but is there anything in the ECPA which would indicate a "responsibility" on the part of the Sysop to actively monitor such communications, requiring the Sysop to assume the position of censor, police, and/or judge, over the content of those messages passing thru ones system - or does it again acknowledge the techical aspects, and responsibilities the Sysop might be required to exercise in the event the Sysop were to become aware of a message containing potentially illegal information? ========== Begin Quote ========== Sysops are given a special responsibility to go along with this special privilege. Just like a letter carrier can't give your mail to someone else, just like a telegraph operator can't pass your telegram to someone else, just like a telephone operator overhearing your call can't tell someone else what it was about, so sysops are prohibited from disclosing your e-mail traffic to anyone, unless you (or the other party to the traffic) give them permission. ========== End Quote ========== This analysis is again just plain common sense, and again the question arises, are the provisions this refers to those which are acknowledged as technical limitations, accomodating them as such, or are they to be construed as indications that we have obligations above and beyond that which is necessary for the performance of the service we are providing? ========== Begin Quote ========== What all this has said is that the federal criminal code now protects electronic communications the way it previously protected written ones. It understands that mailmen, physical or electronic, have access to the mail they carry, so it tells them not to tell. ========== End Quote ========== This statement seems clear enough... but when viewed from the aspect of the issue of wheather "private" E-mail should be allowed in Fidonet, it gives rise to some questions which can possibly be best conveyed by following the analog you have chosen... i/e that of a mailman, and that of "paper mail". The issue of the Sysop having the ability to read e-mail, as compared to the provisions of the ECPA appear to be more closely comparable to "postcards" being carried by a mailman. In this case, no one could deny that the mailman has a "technical" ability to read the postcards being carried, and that the requirements on the part of the mailman not to divulge such information he/she might happen to notice is clear... as are the responsibilities that would be evident were he/she to become aware of information which could resonably be contrued as illegal in nature. But as in the example of the mailman handling paper mail, there exists the ability to send "private" paper mail, which is enclosed in an envelope. In such cases is is not within the rights of the mailman to open such mail to enable his ability to determine the contents thereof, nor is there any legal responsibility for the mailman to have knowledge of the contents thereof. Indeed it would be a criminal act were the mailman to do so. With the above in mind, wouldn't the introduction of private e-mail capabilities in Fidonet be governed by the same logic? And isn't public key encryption simply the means of wrapping an envelope around e-mail to make it private? -gk --- GenMsg vers:1.14/a * Origin: Privacy... everyone needs it, Lets Route it thru FidoNet (1:374/26) SEEN-BY: 11/2 13/13 101/1 109/25 114/5 123/19 124/1 125/20 28 33 40 111 125 SEEN-BY: 125/180 1212 203/1 23 205/10 209/209 280/1 390/1 396/1 ;;PATH: 374/26 12 1 151/1003 13/13 396/1 203/23 125/125 33 -- tom jennings - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!111!tom.jennings INTERNET - tom.jennings at f111.n125.z1.FIDONET.ORG From nobody at alumni.cco.caltech.edu Mon Nov 16 21:32:47 1992 From: nobody at alumni.cco.caltech.edu (nobody at alumni.cco.caltech.edu) Date: Mon, 16 Nov 92 21:32:47 PST Subject: Extortion Explosion Message-ID: <9211170533.AA27523@alumni.cco.caltech.edu> Cheer up, Cassandra! Things aren't all that bad. > New opportunities in the extortion industry: > > Old problem: the victim may inform the police, making it risky to pick up the > money, which will likely be watched. > New solution: demand payment via cryptomoney. Many forms of electronic money can be traced if there is cooperation between the payer and the bank. For example, [...] However, if she simply _tells_ the bank the value of C, then when Bob goes to deposit it, he can get caught. Fine, if there are some forms of electronic money which can be traced sufficiently to suppress extortion by rivals, and there are some forms which are less traceable, will we have the wisdom to advocate the ones which enable our main oppressor to maintain its monopoly on extorting us? I suspect for many on this list, it would be a bitter pill indeed (it was for me). > Old problem: you may be caught firebombing the house, shooting the victim, > slashing the victim's daughter's face, or whatever; if you subcontract to a > thug, the thug may be caught and inform on you. > New solution: use cryptomoney (and a reputation for paying) to hire thugs > while maintaining anonymity. Well, if thugs know that they are now going to be taking the sole responsibility for their actions, without the safety of knowing that they can rat on their employer if worse comes to worst, then they'll charge more to make up for the greater risk. This will make extortion less profitable. Enough to outweigh the new advantages? > Old problem: providing protection, so that you keep a supply of economically > viable victims from whom to extort. > New solution: Please find one! If the government can't protect victims > from you, how can you protect them from competitors? This is the key point. What stops protection rackets now? Is it really the points listed above: that the money may be traced, that others may falsely benefit from my reputation, that thugs may inform on me? What about simple physical surveillance of property? What about revenge on the transgressors? (As above, the revenge would be restricted to the thugs who did the job, but if it was bad enough it would still have a strong deterrent effect.) My impression is that *the* weak link in extortion activities now is how to pick up the money. This is where most extorters get caught, and it is where our monopolistic extortion & protect racket concentrate their protection activities when faced with a competitor. If someone has a more informed understanding of the practice of "law enforcement authorities" when faced with competitive extortion, please post. Thanks. > Wishful thinking in the pursuit of liberty is no virtue; realism in the > defense of imperfect liberty is no vice. Free-lance oppression isn't freedom, > and I don't want it. > > Cassandra It makes more sense to have good fire and police forces to deal with the bad guys than to get all in a tizzy because the bad guys can talk to each other now without getting caught. If I believed that the police forces could still protect effectively when deprived of their major tool (monitoring the money pickup), then my objection would go away. However, I don't see how they can. It's just too easy to firebomb a house (or any number of other attacks) when no one's looking. Polyanna Cassandra 1784360449840245 From Tom.Jennings at f111.n125.z1.FIDONET.ORG Mon Nov 16 21:58:10 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Mon, 16 Nov 92 21:58:10 PST Subject: Rander box and other stuff Message-ID: <3762.2B08842B@fidogate.FIDONET.ORG> U> In fact, now that we've dropped the hard drive and the U> keyboard, it might as well just be a dedicated U> crytosystem, make it about 10cmX10cmX1cm and give it an U> ether port, an rs232 port, a pcmcia port and an rj11 port. U> It's doable and would provide the ultimate security. And if all this is a real consideration, it might be better to use a tool that lets you use a completely non-physical key -- one you can remember in your head. Fit the tool to the job... --- ReadMail * Origin: tomj at fidosw.fidonet.org / World Power Systems (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET - Tom.Jennings at f111.n125.z1.FIDONET.ORG From Tom.Jennings at f111.n125.z1.FIDONET.ORG Mon Nov 16 22:58:21 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Mon, 16 Nov 92 22:58:21 PST Subject: November 21 meeting, 12 noon, at Cygnus offices Message-ID: <3765.2B0896A5@fidogate.FIDONET.ORG> U> ANNOUNCEMENT U> ============ U> U> The Third Physical Cypherpunks Meeting: Project Planning U> [...] U> U> DIRECTIONS U> ========== [...] U> U> Cygnus Support U> 1937 Landings Drive U> Mt. View, CA 94043 U> U> There's no phone service there yet. Wrong! 415-903-1400 --- ReadMail * Origin: tomj at fidosw.fidonet.org / World Power Systems (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET - Tom.Jennings at f111.n125.z1.FIDONET.ORG From gg at well.sf.ca.us Tue Nov 17 00:50:35 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Tue, 17 Nov 92 00:50:35 PST Subject: Rander box and other stuff Message-ID: <199211170849.AA24504@well.sf.ca.us> Eric (Hollander; my last post was to Eric Hughes)- Your "small laptop with (goodies)" was EXACTLY what we were trying to go for in 1983/84. This was the "Cryptex CS-3" project. Remember that there was no such thing as a laptop at the time. What I was proposing was a self-contained portable encryption terminal. It would have measured about a foot wide by 10" long by about 2-3" thick, had an LCD for about six to eight lines of text at a time, two 3-1/2" FDDs, a pair of sockets for "Codepacks" (hardware key storage devices which would have been tamper-resistant and password protected), a good quality keyboard, a modem with modular jack and optional acoustic couplers (for payphones: low-tech anonymity)... the Tempest feature would have been achieved by putting 100dB of white noise on the metal housing, which would have been imperfect but decent enough. There was no plan for a hard drive; the operating software would have been a simple line editor and the crypto routines, all burned into ROM and part of the main processor board. No plans for thermite linings at the time either, though we did have a password routine with a duress option, which would have erased anything on the FDDs or the Codepacks. My first intended market for this thing was the political dissident community, where communication has always suffered to a small but noticeable degree by the "we can't talk on the phone" factor. It never got going because the market was too small. Now it would seem the time has definitely come... though whatever ultimately arises out of the cypherpunk scene will be many many times more sophisticated and versatile. -gg From hugh at domingo.teracons.com Tue Nov 17 01:21:53 1992 From: hugh at domingo.teracons.com (Hugh Daniel) Date: Tue, 17 Nov 92 01:21:53 PST Subject: Random Numbers Boxes and Cypher Processers In-Reply-To: <3762.2B08842B@fidogate.FIDONET.ORG> Message-ID: <9211170913.AA02943@domingo.teracons.com> Ok folks, sounds like its time to look into the guts of Telebits and XyZel's and see if we can make cypher-processers of them. Both have real CPU's and DSP's, what more do you want? ||ugh From phr at napa.Telebit.COM Tue Nov 17 01:29:58 1992 From: phr at napa.Telebit.COM (Paul Rubin) Date: Tue, 17 Nov 92 01:29:58 PST Subject: Random Numbers Boxes and Cypher Processers In-Reply-To: <9211170913.AA02943@domingo.teracons.com> Message-ID: <9211170929.AA07530@napa.TELEBIT.COM> Ok folks, sounds like its time to look into the guts of Telebits and XyZel's and see if we can make cypher-processers of them. Both have real CPU's and DSP's, what more do you want? Hardware devices tend to have barely enough processing power to do the function they were designed for---if there were some power left over, the designers would have used a cheaper and weaker processor. Why would you want to do encryption in your modem instead of on the host cpu that the modem is talking to? From hughes at soda.berkeley.edu Tue Nov 17 03:40:49 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 17 Nov 92 03:40:49 PST Subject: The Dining Cryptographers Protocol In-Reply-To: <9211161815.AA29148@toad.com> Message-ID: <9211171140.AA14731@soda.berkeley.edu> Marc.Ringuette writes: >My spin on the Dining Cryptographers Protocol is, it's nifty and >theoretically strong, but in practice mixes are better for almost all >uses. [...] N is typically 100-10000, and M is typically 2-10. >Mixes are more efficient. Let me continue to be a broken record. Cryptography is all economics. You want unconditional security, you pay. Period. Sometimes it's worth it, sometimes it's not. It is not up to the cryptographer to make the economic judgement, it is up to the user. >One advantage of DC-nets is that they're instant; with mixes there must be >some delays in order to accumulate enough cover messages to defeat traffic >analysis. This idea of "delays" providing security for a mix is a common, but incorrect, notion. I don't think Marc is incorrect about this here, merely unclear. In a well used mix system, the latency time to accumulate ten messages would be only a few minutes. It is the reordering of the output messages with respect to the input that provides mix security. Any delay in merely a consequence of the time to collect. Eric From hugh at domingo.teracons.com Tue Nov 17 04:00:36 1992 From: hugh at domingo.teracons.com (Hugh Daniel) Date: Tue, 17 Nov 92 04:00:36 PST Subject: Random Numbers Boxes and Cypher Processers In-Reply-To: <9211170929.AA07530@napa.TELEBIT.COM> Message-ID: <9211171151.AA03083@domingo.teracons.com> Folks had been talking about doing some crypto things in custom hardware about the size of a Telebit. Telebits are just computers with ROM's in them and since Telebits are falling behind the tide of telecommunications I thought it might be nice to reporgram them as remote processers. The DSP's are quite fast and might give us very nice random numbers, the box has buffers and a CPU that can do flat out UUCP 'g' with compression so is likely more processer then most of the Fido systems out there currently. All around a nice box sitting there wasting, waiting to do something usefull. So, maybe hook up the modem with a shielded cable, cut/add something on the phone side so one of the phone line DSP can get random garbage (it might be much easyer then that once someone looks at the design of the things), reporgram the ROMS to add random noise software and maybe even do some number crunching for you (lets see a T2500 has three DSP's in it?) for encryption/decryption. This is all a bit far feched, but as time goes on there will be lots of discarded Telebits (can't do V.32bis, V.fast, FAX, Voice, DSU/CSU, etc.). XyZel also has a smart modem that one can blast ROM's for. Just something to think about on rainey days... ||ugh From fnerd at smds.com Tue Nov 17 08:16:02 1992 From: fnerd at smds.com (FutureNerd Steve Witham) Date: Tue, 17 Nov 92 08:16:02 PST Subject: Hackers, Crackers Message-ID: <9211171542.AB00557@smds.com> >Let's cut out this elitist "crackers" crap altogether. Well, I don't know about this guy, but there's something similar that occurred to me during the hackers conference. Some of the people on this list heard me express it badly, and I wanted to clarify. We always used to distinguish hackers from crackers. But cracking reveals the cracks in a way that nothing else does. It makes them real, sometimes laughably or painfully so. Electronic privacy is currently a joke. It's bad. You need to know what kinds of attacks you're trying to defend against. I used to think those arguments were rationalizations. Now I'm glad there are people who know this stuff, who are actually doing it. Some of "them" are on what I think of as the good side, and "we" need that kind of knowledge, if only as an occasional splash of cold water, a spur (to switch metaphorical, er, horses in mid, um, stream). -fnerd quote me fnerd at smds.com (FutureNerd Steve Witham) From tcmay at netcom.com Tue Nov 17 10:13:59 1992 From: tcmay at netcom.com (Timothy C. May) Date: Tue, 17 Nov 92 10:13:59 PST Subject: Random Numbers Boxes and Cypher Processers Message-ID: <9211171810.AA16367@netcom.netcom.com> Hugh Daniel writes about converting used Telebit modems for crypto use: > Folks had been talking about doing some crypto things in custom > hardware about the size of a Telebit. Telebits are just computers > with ROM's in them and since Telebits are falling behind the tide of > telecommunications I thought it might be nice to reporgram them as > remote processers. The DSP's are quite fast and might give us very > nice random numbers, the box has buffers and a CPU that can do flat > out UUCP 'g' with compression so is likely more processer then most of > the Fido systems out there currently. > All around a nice box sitting there wasting, waiting to do something > usefull. Great idea! Figuring out how to rewire and reprogram a Telebit modem and then writing a port of PGP for it seems like a real service to the half-dozen or so people in the world who have these Telebits and who want what you describe. I hope my good friend Hugh is not angered by my mocking tone! A serious issue is economics, the allocation of scarce resources. Eric Hughes keeps pounding on this. A cheap RNG might be useful, but not for most people. And I can't imagine many people trying to scrounge old Telebits so as to get good random numbers (this assumes someone actually writes the RNG code, tests it for statistical properties, and submits it for "breaking" by others). More important is getting easy to use software out there. Modifying relatively scarce hardware (which Telbitw are, outside our circle of friends :-}) goes against this "populist crypto" philosophy. Zimmerman's really important contribution was to actually get RSA out to anyone with a PC or vanilla UNIX. Finally, why focus on the Telebit? I have an old Processor Technology "Sol" computer that could be similary reprogrammed for RNG use. Any takers? (Just kidding.) --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at 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^756839 | PGP Public Key: awaiting Macintosh version. -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at 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^756839 | PGP Public Key: awaiting Macintosh version. From oharaw at jmb.ads.com Tue Nov 17 12:20:42 1992 From: oharaw at jmb.ads.com (O'Hara Walter) Date: Tue, 17 Nov 92 12:20:42 PST Subject: Any suggestions on what to do with this junk? Message-ID: <2B098C48@gallows> Hi, I'm new to this list so pardon my ignorance/naivete I'm a systems admin type who is upgrading a bunch of desktop computers next month. As a consequence, about half a dozen computers of the XT vintage will fall under my wing with instructions to "find something useful to do with them." Are there any good suggestions out there about what I could do with old 8-bit technology vis-a-vis crypto? Thanks, Walt From RODENBEC at newschool.edu Tue Nov 17 15:50:34 1992 From: RODENBEC at newschool.edu (erodenbeck) Date: Tue, 17 Nov 92 15:50:34 PST Subject: a patently false rumor Message-ID: all right so i got it from MONDO. accepting that the world has already been taken over and that if its not on tv it doesn't happen I submit and propose to you that it is for the taking but of course you already know that From hh at soda.berkeley.edu Tue Nov 17 16:37:25 1992 From: hh at soda.berkeley.edu (Eric Hollander) Date: Tue, 17 Nov 92 16:37:25 PST Subject: Rander box and other stuff In-Reply-To: <199211170849.AA24504@well.sf.ca.us> Message-ID: <9211180036.AA19273@soda.berkeley.edu> I thought of another thing to add to my wish list for a dedicated cryptosystem: analog input and output, for use as a phone line scambler. Such a system could be manufactured for not too much money, I think. It would be like a specialized version of the Apple Newton. Apple would never make something like this, though; they are becoming good buddies with our favorite agency. Also you would probably need a permit to own thermite. e From eichin at cygnus.com Tue Nov 17 16:58:34 1992 From: eichin at cygnus.com (Mark W. Eichin) Date: Tue, 17 Nov 92 16:58:34 PST Subject: Rander box and other stuff In-Reply-To: <9211180036.AA19273@soda.berkeley.edu> Message-ID: <9211180058.AA15692@tweedledumber.cygnus.com> >> Also you would probably need a permit to own thermite. I don't think there's a problem with owning it or making it -- only (perhaps) selling it and transporting it; thermite is not strictly an explosive. You may wish to consider alternate ways of destroying the data, especially if you wish to ever transport the device on a commercial airline; if you've only got one RAM device that has critical data in it, then simply arrange for the battery backup circuit to have a "high current mode", perhaps feeding more of the pins -- a "light emitting RAM" should be just as blank as one burned through by thermite. >> cryptosystem: analog input and output, for use as a phone line scambler. >> Such a system could be manufactured for not too much money, I think. It Let's see -- an ISDN-quality (quality? I use the term loosely) codec should be under $50 single quantity, the data rate isn't very high so you don't need much of a CPU (6811 might even be enough, and they're easy to interface to things -- lots of on-chip I/O). You'd need a modem-style encoder for the output (running digital from box-to-box -- "analog" scrambling (Time or Frequency domain) is way too easy to break) so maybe another $50 DSP chip... after all, you don't need to support 30 different baud rates, just one data rate with perhaps a low-line-quality backoff. The connectors and the box are probably the major recurring cost (the chip prices will go way down in quantity.) Am I missing anything? The technology level of the Newton seems to be a bit of overkill (unless you actually want that kind of user interface.) _Mark_ : note that this is an unsigned message. From phr at napa.Telebit.COM Tue Nov 17 17:22:27 1992 From: phr at napa.Telebit.COM (Paul Rubin) Date: Tue, 17 Nov 92 17:22:27 PST Subject: Rander box and other stuff In-Reply-To: <9211180058.AA15692@tweedledumber.cygnus.com> Message-ID: <9211180121.AA02510@napa.TELEBIT.COM> Let's see -- an ISDN-quality (quality? I use the term loosely) codec should be under $50 single quantity, the data rate isn't very high so you don't need much of a CPU (6811 might even be enough, and they're easy to interface to things -- lots of on-chip I/O). You'd need a modem-style encoder for the output (running digital from box-to-box -- "analog" scrambling (Time or Frequency domain) is way too easy to break) so maybe another $50 DSP chip... after all, you don't need to support 30 different baud rates, just one data rate with perhaps a low-line-quality backoff. The codec is pretty cheap, but you want a nice low bit rate so you can send the encrypted data over the phone. Some talk of how to do this is happening on sci.crypt. I have a scheme which I plan to float around at the cypherpunks meeting on Saturday. However, the hardware ends up being on the expensive side ($150 or so). From huntting at glarp.com Tue Nov 17 18:50:46 1992 From: huntting at glarp.com (Brad Huntting) Date: Tue, 17 Nov 92 18:50:46 PST Subject: No Subject In-Reply-To: <9211150654.AA20021@toad.com> Message-ID: <199211180249.AA00524@misc.glarp.com> Please add me to the cypherpunks mailing lists. Here are my two public PGP keys if your interested: brad -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQBNAir99E4AAAECALCo19KN/eLnMKicKH9NK9uY3gpaNAZ3vMPpiIAOH5sWOfxK t0bv/T0NnUC0kGr+kJsYAx7dTGc4C/Rx3rZuO/8ABRG0JkJyYWQgSHVudHRpbmcg PGh1bnR0aW5nLjUxMkBnbGFycC5jb20+iQBFAgUQKv32PjNoJjtQO7sNAQHQPAF/ TK1mO9Bpm0JCtxqYvCilvMEYohlDmC6pTl6XPxViil8WXOs04nkq+vy26+QCrgd4 =T+VL -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQA9Air9nn0AAAEBgNK6vPMg3KFzZxuB4llRoKEOxJvlO/TE0NNObgpRFs+px45+ 3z4YQbgzaCY7UDu7DQAFEbQiQnJhZCBIdW50dGluZyA8aHVudHRpbmdAZ2xhcnAu Y29tPokAVQIFECr99nML9HHetm47/wEB6OMCAK82O/iSxEK6PzUd4Y0FXvfoJRKD F/h+6NvbIf2tt0b7IARoLL2e/fw0AaR0TY2U+47s3NBWEAL1Iy+5AV16qyc= =cpUM -----END PGP PUBLIC KEY BLOCK----- From Tom.Jennings at f111.n125.z1.FIDONET.ORG Tue Nov 17 21:27:43 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Tue, 17 Nov 92 21:27:43 PST Subject: Message-ID: <3790.2B09CE75@fidogate.FIDONET.ORG> U> From: huntting at glarp.com (Brad Huntting) U> two public PGP keys if your interested: Why did you sign your key? --- ReadMail * Origin: tomj at fidosw.fidonet.org / World Power Systems (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET - Tom.Jennings at f111.n125.z1.FIDONET.ORG From gg at well.sf.ca.us Wed Nov 18 01:03:18 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Wed, 18 Nov 92 01:03:18 PST Subject: Random Numbers Boxes and Cypher Processers Message-ID: <199211180900.AA05387@well.sf.ca.us> Why do encryption in the modem instead of the host cpu? Because then you have a product which will work with any computer, and all you need is software to make it adapt to whatever you're using. Might make it easier to encrypt and decrypt on the fly also, though this point is of debatable merit. -gg From stjude at well.sf.ca.us Wed Nov 18 12:04:21 1992 From: stjude at well.sf.ca.us (Judith Milhon) Date: Wed, 18 Nov 92 12:04:21 PST Subject: damn: sorry Message-ID: <199211182003.AA08793@well.sf.ca.us> my column in the current issue of mONdo pointed readers to this list, rather than -request. the final line edit didn't correct that, and the issue is now on the stands. if there ARE any readers, they may blunder in here cluelessly, and it's all my fault. damn sorry. >jude< From stjude at well.sf.ca.us Wed Nov 18 13:18:24 1992 From: stjude at well.sf.ca.us (Judith Milhon) Date: Wed, 18 Nov 92 13:18:24 PST Subject: a patently false rumor Message-ID: <199211182113.AA22716@well.sf.ca.us> uh oh: i gave the wrong contact info with that Irresponsible emission: it was spozed to be cypherpunks-request at toad.com. HOWEVER: here you are, d00d. you've landed in the midst of a multistrand technical argument about the logistics of applied cryptography... >jude< From edgar at spectrx.Saigon.COM Wed Nov 18 15:04:26 1992 From: edgar at spectrx.Saigon.COM (Edgar W. Swank) Date: Wed, 18 Nov 92 15:04:26 PST Subject: Request for more detail Message-ID: On Nov 15, Phil Karn wrote: After reading the details of that (formerly) secret back-room agreement between NSA and SPA, I don't think I'll *ever* trust a commercial encryption package, especially one for which source code is unavailable for scrutiny. Could Phil or anyone give more details about that agreement and/or where one could read more about it? -- edgar at spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca From MCGRATHJ%GRNET at lan.lincoln.cri.nz Wed Nov 18 15:54:04 1992 From: MCGRATHJ%GRNET at lan.lincoln.cri.nz (McGrath, James) Date: Wed, 18 Nov 92 15:54:04 PST Subject: PGP to SMTP mailer Message-ID: <9211182353.AA04620@crop.lincoln.cri.nz> Gudday, People were suggesting that someone write a mailer with PGP support, and because my site uses lots of PCs connected to an internet host, I was thinking of using an SMTP-client based system. That much I think I can do. However, I am also now trying to learn to program for Windows, and the idea of a windows based PGP is quite nice, and with an integrated mailer it would be great. Is anyone else working on either of these two things? What are the implications (security wise) of using something like windows where tasks aren't really that hidden from each other and that swaps to disk? I notice that PGP bothers to erase its stacks and work areas. It seems that this would be a lot less possible under windows. Comments? Jim McGrath From MCGRATHJ%GRNET at lan.lincoln.cri.nz Wed Nov 18 17:36:04 1992 From: MCGRATHJ%GRNET at lan.lincoln.cri.nz (McGrath, James) Date: Wed, 18 Nov 92 17:36:04 PST Subject: PGP to SMTP mailer Message-ID: <9211190135.AA04790@crop.lincoln.cri.nz> Gudday, People were suggesting that someone write a mailer with PGP support, and because my site uses lots of PCs connected to an internet host, I was thinking of using an SMTP-client based system. That much I think I can do. However, I am also now trying to learn to program for Windows, and the idea of a windows based PGP is quite nice, and with an integrated mailer it would be great. Is anyone else working on either of these two things? What are the implications (security wise) of using something like windows where tasks aren't really that hidden from each other and that swaps to disk? I notice that PGP bothers to erase its stacks and work areas. It seems that this would be a lot less possible under windows. Comments? Jim McGrath From hh at soda.berkeley.edu Wed Nov 18 18:07:09 1992 From: hh at soda.berkeley.edu (Eric Hollander) Date: Wed, 18 Nov 92 18:07:09 PST Subject: PGP to SMTP mailer In-Reply-To: <9211182353.AA04620@crop.lincoln.cri.nz> Message-ID: <9211190206.AA13706@soda.berkeley.edu> sounds like it might be a good idea to implement windowing support for pgp. we could write versions for windows, xwindows, mac and possibly other systems. it would not be too hard to write a generic windowed pgp and then make it specific for these systems. e From wcs at anchor.ho.att.com Wed Nov 18 19:16:30 1992 From: wcs at anchor.ho.att.com (Bill Stewart) Date: Wed, 18 Nov 92 19:16:30 PST Subject: PGP to SMTP mailer Message-ID: <9211190308.AA25694@anchor.ho.att.com> Embedding SMTP support into a PGP mail reader is the wrong approach, though the DOS world seems to be going bananas over mail APIs. You gain a lot of flexibility by separating the Mail User Agent, which handles user interface, file storage, encryption and other decoding, etc. from the Mail Transfer Agent function, which lets you send/receive PGP messages over whatever mail systems you have available. That way you don't need to write one PGP program for SMTP, another for uucp, another for Fido, etc. On the other hand, I'd be interested in seeing a PGP hook built into Lotus Notes - does it have an open programming or file-transfer interface? It seems to be multimedia netnews for the mundanes, and getting some flavor of Public-Key encryption out there could help spread the technology, especially if Lotus were to license RSA support. Bill Stewart, somewhere in New Jersey. From crunch at netcom.com Thu Nov 19 03:54:30 1992 From: crunch at netcom.com (John Draper) Date: Thu, 19 Nov 92 03:54:30 PST Subject: Finally back Message-ID: <9211191150.AA16617@netcom2.netcom.com> Greetings, I'm finally back on-line for a few days here, and want to make the most of it. I'll be checking my Email frequently during the day tommorrow, and reading all back messages (All 120 of them), getting cought up on the latest... Before I forget, if anyone wants to send me an encrypted message, My key is as follows, so Pse add it to your pubkey list in case you want to send me an encrypted message. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQBNAisLBHoAAAECALXEdhLz3F9RmO6ypGFbR4/YqLgbHOrkDxVEgGMCMVQJh8zr /75cTwvXI7dyGorWqvkvhUw1jU7BvMSvyK9YOv8ABRG0IkpvaG4gVC4gRHJhcGVy IDxjcnVuY2hAbmV0Y29tLmNvbT4= =rTrk -----END PGP PUBLIC KEY BLOCK----- I haven't really started collecting pub keys yet, but I propose that we have a list stored somewhere on an ftp site. Or perhaps someone who has the keyrings. I'll have more things to Email later on, it has been a long night here, finally got to most Email. Had one fatal crash of the MacPGP program where it hung up the system when I tried to encrypt a message to someone. I have now tested out the PGP program fully, and now know how to use it. I can see plenty of omprovements I will want to make, but to do it right, we might have extensive changes to make. Still not done looking at code yet, but the modules I ve seen are pretty easy to inderstand. Later... John D> From mark at coombs.anu.edu.au Thu Nov 19 04:30:00 1992 From: mark at coombs.anu.edu.au (Mark) Date: Thu, 19 Nov 92 04:30:00 PST Subject: IP Bouncer.. source included. Message-ID: <9211191229.AA12629@coombs.anu.edu.au> Ok an IP bouncer is something that runs on a host that basically accepts connections on one port and redirects them to another specified host and port. The one below is for tcp connections but it could also be for udp with a little work. I actually have the code for a 'server' version of this that you connect to it, tell it which host you want and then it opens a connection to it. It's on another machine at the moment which is down. I had the sent to me via IRC a while ago and have used it off and on. Ive been meaning to fine tune it a bit as it's supposed to chew CPU a bit... -------cut here--------cut here--------cut here---------cut here------------- /* This file is telserv.c and is part of the Telnet Server package v. 1.0, written by "Hal-9000". Much of this package was developed by Richard Stephens and my thanks go to "Xanadude" for providing me with that section. To compile, type "cc -O -s telserv.c -o telserv". */ #include #include #include #include #include #include #include #define SERV_TCP_PORT 12345 /* port I'll listen for connections on */ #define REM_HOST_ADDR "128.128.128.7" /* host I will bounce to */ #define REM_TCP_PORT 23 /* port I will bounce to */ main() { int sockfd, newsockfd, clilen, childpid; struct sockaddr_in cli_addr, serv_addr; sockfd = socket(AF_INET, SOCK_STREAM, 0); bzero((char *) &serv_addr, sizeof(serv_addr)); serv_addr.sin_family = AF_INET; serv_addr.sin_addr.s_addr = htonl(INADDR_ANY); serv_addr.sin_port = htons(SERV_TCP_PORT); bind(sockfd, (struct sockaddr *) &serv_addr, sizeof(serv_addr)); listen(sockfd, 5); while (1) { clilen = sizeof(cli_addr); newsockfd=accept(sockfd, (struct sockaddr *) &cli_addr, &clilen); fcntl(newsockfd,F_SETFL,O_NDELAY); childpid = fork(); if (childpid == 0) { /* child process */ close(sockfd); /* close original socket */ telcli(newsockfd); /* process the request */ exit(0); } close(newsockfd); /* parent process */ wait(0); } } telcli(clisockfd) { int servsockfd; struct sockaddr_in serv_addr; bzero((char *) &serv_addr, sizeof(serv_addr)); serv_addr.sin_family = AF_INET; serv_addr.sin_addr.s_addr = inet_addr(REM_HOST_ADDR); serv_addr.sin_port = htons(REM_TCP_PORT); servsockfd = socket(AF_INET, SOCK_STREAM, 0); connect(servsockfd, (struct sockaddr *) &serv_addr, sizeof(serv_addr)); fcntl(servsockfd,F_SETFL,O_NDELAY); communicate(servsockfd,clisockfd); close(servsockfd); exit(0); } communicate(servsockfd,clisockfd) { char rec[1]; int num; extern int errno; while (1) { num=read(servsockfd,rec,1); if ((num==-1) && (errno != EWOULDBLOCK)) return; if (num==0) return; if (num==1) write(clisockfd,rec,1); num=read(clisockfd,rec,1); if ((num==-1) && (errno != EWOULDBLOCK)) return; if (num==0) return; if (num==1) write(servsockfd,rec,1); } } From VANGUARD at gribb.hsr.no Thu Nov 19 04:57:31 1992 From: VANGUARD at gribb.hsr.no (VANGUARD at gribb.hsr.no) Date: Thu, 19 Nov 92 04:57:31 PST Subject: Anymous Remailers and Newsposters Message-ID: I have tried out the anonymous reply service at hal at alumni.caltech.com and I am very satisfied with the service, however I have a suggestion that will improve the security. The way it works now it is possible to link different messages that have the same originator, simply by comparing the return adress. Example I have a deal going with Bob and a different deal going with Alice, and it would be of my interest that Alice and Bob didnt know they where dealing with the same person. If a had given the the same Anonymous reply adress they could compare them and see that in fact they were dealing with the same person, thereby making it easier to trace me: Solutions: Use different remailers that have different public keys, or allow for a field of "random" i.e. different bytes so that if the return adress is identical the encoded block would be totally different. I have been aware of the need to make anonymous postings on the newsnet. I have made most of the neseccery softwar to allow for such a gateway, but it seems that the local system administartor is strongly opposed to the idea of the protection given by beeing anonymous. Such a gateway has an enourmous potential, and it is easy to see why some wouldn't like the idea. I have also been thinking about up such a gateway in my own name (i.e the anonymous postings would appear to come from me, with some sort of disclaimer) but I have so far been reluctant to take the risk of beeing identified with things that are none of my business. Any comments and suggestions would be appreciated. From VANGUARD at gribb.hsr.no Thu Nov 19 05:24:18 1992 From: VANGUARD at gribb.hsr.no (VANGUARD at gribb.hsr.no) Date: Thu, 19 Nov 92 05:24:18 PST Subject: Anonymous Reply... Message-ID: Well after I made my last posting I realized there is a mush better way to avoid having identical reply adresses: Simply let pgp make a new encryption of the return adress. This works because pgp uses a different key for each message, and the key is the only information that is encrypted with th RSA algorithm. In other words if you encrypt a message once with a key and encrypt the same message again with the same key, the resulting ciphertext will be totally different, with exeption of the first bytes and the length of the text. From mark at coombs.anu.edu.au Thu Nov 19 05:43:04 1992 From: mark at coombs.anu.edu.au (Mark) Date: Thu, 19 Nov 92 05:43:04 PST Subject: How far is to far? Message-ID: <9211191342.AA18149@coombs.anu.edu.au> Maybe it's not in the spirit of this mailing group but what of the question of purposeful abuse of the anon mailers/newsposters? Say for instance some person posts either a sh*tload of garbage to every known group, flooding the USENET or a more personal attack whereby they send out anonymously information that was so fundamentally personal to someone they could possibly react very badly.... What if someone posted some top secret information and the various three letter acronyms all went out for someone's blood. As a few people have mentioned they would *like* the opportunity to use an anon system but the initial step of creating and running it isnt so appealing due to the fundamental dangers of it. Most people would respect such systems but you find one really rotten or immature loser that will use it for there own anti-social ends. Comments? Mark mark at coombs.anu.edu.au mark at gnu.ai.mit.edu markm at rmit.edu.au From crunch at netcom.com Thu Nov 19 19:33:56 1992 From: crunch at netcom.com (John Draper) Date: Thu, 19 Nov 92 19:33:56 PST Subject: Some proposals to consider Message-ID: <9211200059.AA27380@netcom2.netcom.com> Greetings fellow cypherpunks: A lot has happened since I got on here last Friday. My previous message contains my public key, Pse use it if you want to send me private mail. I bet the NSA boys are tearing the hair out of their heads by now, but it's about time we do something to preserve our privacy. It is my plan to help "organize" the Mac implementation of PGP, by putting together a Mac Implementation team of programmers to beef up MacPGP, by added better GUI, such as cutting and pasting of keys DIRECTLY into key rings without having to go through a file (makes for added security). My plans also call for tight coordination with the other platform development teams. I've been getting good support for my ideas on implementing machine independent modules or "Libraries" of PGP routines that don't include I/O portions, but after looking at the code, I see this is going to take a lot of work, both in organizing the effort, and in implementing the code. Just how this is going to be done, I'm not sure, but this is what cypherpunks is all about. To hash these things over, flame on each other's ideas, etc. So far, the Mac inplementaion team consists of the following individuals, and are (or soon will be) working closly with Eric Hughs, Phil Zimmerman, and the other PGP folks Mac PGP team: Richard Outerbridge [71755.204] Jim Clausing internet: jac at cis.ohio-state.edu Zbigniew Fiedorowicz internet: fiedorow at function.mps.ohio-state.edu INTERNET:crunch at netcom.com INTERNET:crunch at netcom.com Doug McNaught internet: doug at midget.towson.edu Philip Zimmermann internet: prz at sage.cgd.ucar.edu I talked with another individual last evening who also wants to be added to the team, but the others haven't yet been introduced to him yet. It is my plan to propose this idea to the PGP meeting at Sygnus this upcoming Saturday at noon. Then, I'll report to those that couldn't make it, due to their location. The progress on the Rander box is as follows: I am currently evaluating several proposed designs, and have sent out queries for data sheets on devices I plan on checking out for use, prices, etc. I have been studying the PGP code, and can see it's going to take a lot of work to get it into a form where true machine portability can be realized. As a Mac purist, a abhore the idea if translating Mac GUI actions into ascii text and sending it to the current PGP "engine". Although it would take a lot of work, I propose that we develop PGP to have the following form. a) Encryption engine library - Main set of routines currently in the PGP program dealing with encryption of data. These would be a set of "support" routines that would permit encryption of data in files, as well as data in memory. These would be totally machine independent, and only ONE set of sources should exist and contain compiler options for platform specific code. These functions would then return error codes instead of console output. Needed "key phrases" can be passed in as "char *", and sucessful operations would return NULL or if error, an appropriate code be returned. Other routines would be necessary, such as telling it where the random ring buffer is located, and how long it is. These routines would maintain their own pointers into this buffer. This library would call routines in the Random number manager and pass information such as where the buffer is located. See below: b) Key management library - Main set of routines that know how to manage the keyring files, it would have functions designed to extract keys, add and remove them, and work on the keyring files directly. Again, these would be machine independent routines. This would also call routines in the Random number manager below. c) Random number management - Main set of routines to manage a "circular buffer" of random numbers used to generate keys. This would work with both software and hardware random number generators, and would provide externally machine independent functions, but internally they would be machine specific. d) GUI's for the various PGP application programs. Mail management, file management, network applications, etc, all calling the routines in a,b, and c. Also includes Hypercard Xcmds, etc. Items a and b should have only ONE set of source code, and be maintained and managed by existing people. Items c would also be same source code, but have conditional compiler statements to "switch in" the machine dependent portions as apppropriate. I think it's possible to design the code in a and b to have very few machine dependent conditional compiler #ifdef statements, by forming the main PGP guts portion to operate on textual input in the form of "char *" instead of console input, and let the calling code pass "char *" to PGP library routines. Machine dependent stuff is in (d) and might include existing UNIX PGP "main()", Mac PGP main application, and lower level "utilities" such as Hypercar XCMD's etc. In fact, it is even possible to build these libraries to use NO global variables, and use structures instead. But me, being Mac biased, will probably get a lot of resistance to this proposal, but it is just that, a PROPOSAL. At any rate, I think that portability issues would be better solved if we were to adopt C code portability and to assume that not ALL platforms work well with console type input, and that Console I/O should be "factored out" of the machine independent portions of the existing PGP code. So, what way folks, has anyone got a better idea or proposal? Cheers JD From avalon at coombs.anu.edu.au Thu Nov 19 19:35:05 1992 From: avalon at coombs.anu.edu.au (Darren Reed) Date: Thu, 19 Nov 92 19:35:05 PST Subject: How far is to far? In-Reply-To: <9211191342.AA18149@coombs.anu.edu.au> Message-ID: <9211192343.AA27930@coombs.anu.edu.au> I've fixed the IP bouncer so it doesnt chew so much cpu any more, backgrounds itself and detachs from the tty. In testing last night, it was using less %cpu than the telnet being used to connect to it on the same machine (hope that bodes well! :). Darren ----------------------------------------------------------------------------- /* This file is telserv.c and is part of the Telnet Server package v. 1.0, written by "Hal-9000". Much of this package was developed by Richard Stephens and my thanks go to "Xanadude" for providing me with that section. Performance fix by Darren Reed. To compile, type "cc -O -s telserv.c -o telserv". */ #include #include #include #include #include #include #include #include #define SERV_TCP_PORT 12345 /* port I'll listen for connections on */ #define REM_HOST_ADDR "127.0.0.1" /* host I will bounce to */ #define REM_TCP_PORT 19 /* port I will bounce to */ char sbuf[2048], cbuf[2048]; main() { int sockfd, newsockfd, clilen, childpid, opt = 1; struct sockaddr_in cli_addr, serv_addr; sockfd = socket(AF_INET, SOCK_STREAM, 0); setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)); bzero((char *) &serv_addr, sizeof(serv_addr)); serv_addr.sin_family = AF_INET; serv_addr.sin_addr.s_addr = htonl(INADDR_ANY); serv_addr.sin_port = htons(SERV_TCP_PORT); if (bind(sockfd, (struct sockaddr *) &serv_addr, sizeof(serv_addr)) == -1) { perror("bind"); exit(-1); } listen(sockfd, 5); setpgrp(getpid(), 0); close(0); close(1); close(2); #ifdef TIOCNOTTY if ((newsockfd = open("/dev/tty", O_RDWR)) >= 0) { ioctl(newsockfd, TIOCNOTTY, (char *)0); close(newsockfd); } #endif if (fork()) exit(0); while (1) { clilen = sizeof(cli_addr); newsockfd=accept(sockfd, (struct sockaddr *) &cli_addr, &clilen); if (newsockfd == -1) exit(-1); setsockopt(newsockfd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)); /* ** NB: FNDELAY and O_NDELAY aren't the same on all machines and on most ** we want FNDELAY. The differences are subtle but differences all the ** same. */ #ifdef FNDELAY fcntl(newsockfd,F_SETFL,fcntl(newsockfd,F_GETFL,0)|FNDELAY); #else fcntl(newsockfd,F_SETFL,O_NDELAY); #endif childpid = fork(); if (childpid == 0) { /* child process */ close(sockfd); /* close original socket */ telcli(newsockfd); /* process the request */ exit(0); } close(newsockfd); /* parent process */ wait(0); } } telcli(clisockfd) { int servsockfd; struct sockaddr_in serv_addr; bzero((char *) &serv_addr, sizeof(serv_addr)); serv_addr.sin_family = AF_INET; serv_addr.sin_addr.s_addr = inet_addr(REM_HOST_ADDR); serv_addr.sin_port = htons(REM_TCP_PORT); servsockfd = socket(AF_INET, SOCK_STREAM, 0); connect(servsockfd, (struct sockaddr *) &serv_addr, sizeof(serv_addr)); #ifdef FNDELAY fcntl(servsockfd,F_SETFL,fcntl(clisockfd,F_GETFL,0)|FNDELAY); #else fcntl(servsockfd,F_SETFL,O_NDELAY); #endif communicate(servsockfd,clisockfd); close(servsockfd); exit(0); } communicate(sfd,cfd) { char *chead, *ctail, *shead, *stail; int num, nfd, spos, cpos; extern int errno; fd_set rd, wr; chead = ctail = cbuf; cpos = 0; shead = stail = sbuf; spos = 0; while (1) { FD_ZERO(&rd); FD_ZERO(&wr); if (spos < sizeof(sbuf)-1) FD_SET(sfd, &rd); if (ctail > chead) FD_SET(sfd, &wr); if (cpos < sizeof(cbuf)-1) FD_SET(cfd, &rd); if (stail > shead) FD_SET(cfd, &wr); nfd = select(256, &rd, &wr, 0, 0); if (nfd <= 0) continue; if (FD_ISSET(sfd, &rd)) { num=read(sfd,stail,sizeof(sbuf)-spos); if ((num==-1) && (errno != EWOULDBLOCK)) return; if (num==0) return; if (num>0) { spos += num; stail += num; if (!--nfd) continue; } } if (FD_ISSET(cfd, &rd)) { num=read(cfd,ctail,sizeof(cbuf)-cpos); if ((num==-1) && (errno != EWOULDBLOCK)) return; if (num==0) return; if (num>0) { cpos += num; ctail += num; if (!--nfd) continue; } } if (FD_ISSET(sfd, &wr)) { num=write(sfd,chead,ctail-chead); if ((num==-1) && (errno != EWOULDBLOCK)) return; if (num>0) { chead += num; if (chead == ctail) { chead = ctail = cbuf; cpos = 0; } if (!--nfd) continue; } } if (FD_ISSET(cfd, &wr)) { num=write(cfd,shead,stail-shead); if ((num==-1) && (errno != EWOULDBLOCK)) return; if (num>0) { shead += num; if (shead == stail) { shead = stail = sbuf; spos = 0; } if (!--nfd) continue; } } } } From fen at genmagic.com Thu Nov 19 19:37:21 1992 From: fen at genmagic.com (Fen Labalme) Date: Thu, 19 Nov 92 19:37:21 PST Subject: PGP to SMTP mailer Message-ID: <9211191957.AA18482@> [wcs at anchor.ho.att.com (Bill Stewart) writes:] >On the other hand, I'd be interested in seeing a PGP hook built into >Lotus Notes .... if Lotus were to license RSA support. I believe that Lotus has licensed RSA technology for notes. Fen ~~~ ~~~ Fen Labalme General Magic We Are Everywhere 40 Carl Street #4 2465 Latham Street ------------------- San Francisco CA 94117 Mountain View CA 94040 The US Constitution 415/731-1174 (home) 415/966-6273 (my desk) may not be perfect, 415/965-9424 (fax) but it's better than what we've got now. From fen at genmagic.com Thu Nov 19 19:37:21 1992 From: fen at genmagic.com (Fen Labalme by way of fen@genmagic Fen Labalme) Date: Thu, 19 Nov 92 19:37:21 PST Subject: Anymous Remailers and Newsposters Message-ID: <9211191959.AA18490@> [VANGUARD at gribb.hsr.n0 writes:] >I have been aware of the need to make anonymous postings on the >newsnet. I have made most of the neseccery softwar to allow for such >a gateway, but it seems that the local system administartor is >strongly opposed to the idea of the protection given by beeing >anonymous. Such a gateway has an enourmous potential, and it is easy >to see why some wouldn't like the idea. I just thought I'd mention that there are several anonymous remailers currently in use by users of the alt.sex.bondage newsgroup. Unfortunately, I don't have the addresses handy, but they re-post the address and instructions for use every week or so... Fen ~~~ ~~~ Fen Labalme General Magic We Are Everywhere 40 Carl Street #4 2465 Latham Street ------------------- San Francisco CA 94117 Mountain View CA 94040 The US Constitution 415/731-1174 (home) 415/966-6273 (my desk) may not be perfect, 415/965-9424 (fax) but it's better than what we've got now. From fen at genmagic.com Thu Nov 19 19:38:52 1992 From: fen at genmagic.com (Fen Labalme by way of fen@genmagic Fen Labalme) Date: Thu, 19 Nov 92 19:38:52 PST Subject: How far is to far? Message-ID: <9211191959.AA18495@> [mark at coombs.anu.edu.au writes:] >Maybe it's not in the spirit of this mailing group but what of the question >of purposeful abuse of the anon mailers/newsposters? Say for instance some >person posts either a sh*tload of garbage to every known group, flooding >the USENET or a more personal attack whereby they send out anonymously >information that was so fundamentally personal to someone they could >possibly react very badly.... I see two answers: one is public censure, which has appeared to work to a large extent in at least one newsgroup whose users make habitual use of an anonymous remailer (alt.sex.bondage) . Another is broadcatch, a favorite topic of mine, which is concerned with the filtering of information. (Note: where "broadcast" is a one-source-to-many subscriber system, "broadcatch" scans many sources for information relevant to one subscriber. The end result is less quantity and higher quality.) With broadcatch, you could turn off threads of conversation you were not interested in, block out flamers, and IGNORE ANONYMOUS EMAIL in general. Of course, pseudonyms may come to be trusted and thus not filtered out, though they, too, are cryptographically anonymous. (Another common mechanism of broadcatch filters is to allow through articles with mentions of the subscriber's name.) Also, in the long run, when networks are made up of smarter, cooperating machines, neighboring machines to a flamer that is generating mass ammounts of email will begin to choose not to listen as often at that address. In sum, I think that it is someone's right to say anything they want, as long as I don't have to listen. Fen ~~~ ~~~ Fen Labalme General Magic We Are Everywhere 40 Carl Street #4 2465 Latham Street ------------------- San Francisco CA 94117 Mountain View CA 94040 The US Constitution 415/731-1174 (home) 415/966-6273 (my desk) may not be perfect, 415/965-9424 (fax) but it's better than what we've got now. From tcmay at netcom.com Thu Nov 19 19:40:10 1992 From: tcmay at netcom.com (Timothy C. May) Date: Thu, 19 Nov 92 19:40:10 PST Subject: How far is to far? Message-ID: <9211191822.AA06330@netcom.netcom.com> Mark (mark at coombs.anu.edu.au) writes: > Maybe it's not in the spirit of this mailing group but what of the question > of purposeful abuse of the anon mailers/newsposters? Say for instance some > person posts either a sh*tload of garbage to every known group, flooding > the USENET or a more personal attack whereby they send out anonymously > information that was so fundamentally personal to someone they could > possibly react very badly.... > > What if someone posted some top secret information and the various three > letter acronyms all went out for someone's blood. Abuses of various sorts will surely occur. The same thing happens with the postal systems of the world ("blackmail," poison pen letters, ransom demands, extortion threats, child pornography, sedition, etc.), with the phone systems (ditto above), freely available Xerox machines, and so on. Computers and computers nets will be no different. A difference is that the authorities are trying to stop all such abuses on computer nets and all such things they dislike by banning privacy and by restricting use. This is a doomed effort. > As a few people have mentioned they would *like* the opportunity to use > an anon system but the initial step of creating and running it isnt so > appealing due to the fundamental dangers of it. > > Most people would respect such systems but you find one really rotten or > immature loser that will use it for there own anti-social ends. This is where "reputations" and "kill" files come to the fore. Immature flames and other minor crimes are best dealt with by "down-checking" the reputation of the digital pseudonym of the offender. (Completely anonymous postings, where no "handle" or digital pseudonym is provided are likely to be "killed" by most readers.) For more serious "crimes" perpetrated by crypto users, well, nothing's perfect. As I said above, they have other channels to use as well. An advantage of the digital pseudonym nets is that these criminals don't know who you are or where you live (a la "True Names") and hence can't perpetrate certain crimes. When in cypherspace, be careful! --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at 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^756839 | PGP Public Key: awaiting Macintosh version. -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at 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^756839 | PGP Public Key: awaiting Macintosh version. From wmo at rebma.rebma.mn.org Thu Nov 19 19:43:57 1992 From: wmo at rebma.rebma.mn.org (Bill O'Hanlon) Date: Thu, 19 Nov 92 19:43:57 PST Subject: Another remailer Message-ID: I've installed Eric's anonymous remailer scripts at remailer at rebma.mn.org. Rebma is my home machine... It's not right on the Internet, but it is a Telebit connection away. Feel free to use it as you see fit. I don't have Hal's PGP additions, but I am interested in running them. Hal's messages said he hoped more people put up remailers so that they could be chained together. Sounded good to me. -Bill -- Bill O'Hanlon wmo at rebma.mn.org From hkhenson at cup.portal.com Thu Nov 19 20:02:08 1992 From: hkhenson at cup.portal.com (hkhenson at cup.portal.com) Date: Thu, 19 Nov 92 20:02:08 PST Subject: The legality of PGP Message-ID: <9211191023.1.22089@cup.portal.com> Perry writes PGP is based on RSA . . . which has not granted a license for people to use . . . . using PGP is possibly a pattent violation . . . I wonder--I have RSA Mailsafe. Do you think that would give me a license to use RSA if I loaded up PGP? Keith From miron at extropia.wimsey.com Thu Nov 19 21:09:14 1992 From: miron at extropia.wimsey.com (Miron Cuperman) Date: Thu, 19 Nov 92 21:09:14 PST Subject: Some proposals to consider In-Reply-To: <9211200059.AA27380@netcom2.netcom.com> Message-ID: <1992Nov20.045112.2129@extropia.wimsey.bc.ca> crunch at netcom.com (John Draper) writes: >Greetings fellow cypherpunks: > I've been getting good support for my ideas on implementing machine >independent modules or "Libraries" of PGP routines that don't include >I/O portions, but after looking at the code, I see this is going to >take a lot of work, both in organizing the effort, and in implementing >the code. Just how this is going to be done, I'm not sure, but this >is what cypherpunks is all about. To hash these things over, flame on >each other's ideas, etc. It would be very nice if PGP behaved better as a UNIX filter. For example, I'd like it to return an exit code if it fails. I'd also like it to have a flag that disables any access to the tty for prompts. For example, if I have an automatic filter that tries to decrypt all incoming messages, I don't want it to prompt for a secret ring file when it can't decrypt something. A very important addition to PGP would be multi-recipient encryption. RIPEM implements this nicely, by having one private key (PGP has this too - it uses IDEA) and encrypting this key with each recipient's key. We could then run this list encrypted, in order to excercise PGP and to see what user interface issues become important with heavy use. (Not much security is afforded because of the public nature of the list.) -- Miron Cuperman | NeXTmail/mime ok | Public key avail AMIX: MCuperman | immortalcybercomputinglaissezfaire | From phr at napa.Telebit.COM Thu Nov 19 22:54:40 1992 From: phr at napa.Telebit.COM (Paul Rubin) Date: Thu, 19 Nov 92 22:54:40 PST Subject: PGP to SMTP mailer Message-ID: <9211200654.AA27391@napa.TELEBIT.COM> Those of us who support the freedom to use cryptography, run PGP, and write whatever programs we wish (cryptographic and otherwise) should be aware that the boycott against Lotus and Apple is still on. By making PGP run on Macintoshes and with Lotus Notes, we improve the usefulness of those systems and thereby help our enemies take away our rights. From dclunie at pax.tpa.com.AU Thu Nov 19 23:01:19 1992 From: dclunie at pax.tpa.com.AU (David Clunie) Date: Thu, 19 Nov 92 23:01:19 PST Subject: Some proposals, Anonymous mailers Message-ID: <9211200659.AA00380@britt> > I've been getting good support for my ideas on implementing machine > independent modules or "Libraries" of PGP routines that don't include > I/O portions, but after looking at the code, I see this is going to > take a lot of work, both in organizing the effort, and in implementing > the code. Just how this is going to be done, I'm not sure, but this > is what cypherpunks is all about. To hash these things over, flame on > each other's ideas, etc. > > I have been studying the PGP code, and can see it's going to take a > lot of work to get it into a form where true machine portability can > be realized. As a Mac purist, a abhore the idea if translating Mac > GUI actions into ascii text and sending it to the current PGP "engine". > > Although it would take a lot of work, I propose that we develop PGP > to have the following form. > > a) Encryption engine library - Main set of routines currently in the > PGP program dealing with encryption of data. These would be I strongly support this concept. Having just implemented a new anonymous mail and posting system with privacy enhancement using PGP on a Unix machine, using the existing PGP code which is very keyboard oriented, proved to be a real headache, trying to second guess the responses that pgp expected. The whole deal would have been much easier calling library routines, or even more "Unix" like tool type interfaces. I am seriously considering rewriting some bits of PGP to do what I need but unfortunately: 1. I don't know anything about encryption, as Phil has made obvious in his responses to my ideas (quite rightly so). 2. A preliminary perusal of the code makes it obvious that extracting the functionality from the interface is not an easy task. However, I would be happy to volunteer my services should no one Unix based with more PGP or encryption experience is available. I also live outside the US at present which is a plus I guess as far as RSA is concerned. BTW. Re. my anonymous service - once I have Phil and Hal's suggestions implemented feel free to use it. Send mail to "anon.info at pax.tpa.com.au". The service is not yet really on-line, but if anyone wants to play with it feel free (given the proviso that I might change things and take it up and down periodically until I get it right; I will try to preserve alias #'s and stored public keys that have already been sent along). It is not based on the current perl scripts - I hacked it up in Bourne shell scripts before I heard about other peoples efforts, so all bugs are mine ! Note that it is basically a typical anonymous mailing system like that used in the various alt.personals and alt.sex groups, except that you can encrypt your messages to it, and it will encrypt responses back to you automatically, so dubious bounced mail and replies will not be readable by other's at your site or on the path. At present it is set up to allow posting to any group, but I am seriously considering blocking out the k12 groups after the recent godiva fiasco, quite against my philosophy, but my better judgement may yet prevail :( The same may go for file size and even rapidly repeated messages to the same addresses to prevent common patterns of "anonymous abuse". I hate to do this and may not, but I get the impression that I would be foolish not to. The immaturity of some people out there amazes me. BTW. I have also started a new mailing list for discussion of anonymous groups in general as well as my system. Send mail to "anon.subscribe@ pax.tpa.com.au" if you want to join. The list is strictly plaintext at the moment though unfortunately ! david From tenney at netcom.com Thu Nov 19 23:49:58 1992 From: tenney at netcom.com (Glenn S. Tenney) Date: Thu, 19 Nov 92 23:49:58 PST Subject: PGP to SMTP mailer In-Reply-To: <9211200654.AA27391@napa.TELEBIT.COM> Message-ID: <9211200744.AA28178@netcom2.netcom.com> phr at napa.Telebit.COM says: > > Those of us who support the freedom to use cryptography, run PGP, and > write whatever programs we wish (cryptographic and otherwise) should > be aware that the boycott against Lotus and Apple is still on. By > making PGP run on Macintoshes and with Lotus Notes, we improve the > usefulness of those systems and thereby help our enemies take away our > rights. > Oh give me a break! I don't see YOU boycotting the Hayes modem standard (AT). Enough of this boycott crap! -- Glenn Tenney voice: (415) 574-3420 fax: (415) 574-0546 tenney at netcom.com Ham radio: AA6ER From gg at well.sf.ca.us Fri Nov 20 00:29:17 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Fri, 20 Nov 92 00:29:17 PST Subject: How far is to far? Message-ID: <199211200828.AA03551@well.sf.ca.us> Re. Fen's proposal to utilise "broadcatch." We still have the problems of slander/libel and breaches of legitimate secrecy. At risk of sounding naive/idealistic, it would seem that since there is no way to block information passing through the net (aside from screening at source, impractical at least!), the solution rests with education of the net-using population. Power carries responsibility in equal measure. We are giving ourselves the power which comes with privacy; we can begin to take responsibility for promoting a sense of ethics in the use of the net. One possible place to start would be at highschool-level computer courses; perhaps with accomplished hackers coming in and giving guest lectures or something... the culture of computer-literate youth can begin to include strong ethical positions regarding respect for the privacy of others, respect for truthfulness, and a position of personal conscience regarding law and authority. Re the latter, this isn't the same thing as blind obedience, but rather the idea that if there is to be disobedience it needs to be grounded in deeply held personal ethics, as for example in the case of civil disobedience. A strong set of cultural values in these areas might set a tone which discourages mindless negativity and wrecking. Now there will always be those who wreck for thrills.... I don't know how to address that problem except to note that such individuals are hardly stopped today by the threat of prosecution. -gg at well.sf.ca.us From crunch at netcom.com Fri Nov 20 01:01:11 1992 From: crunch at netcom.com (John Draper) Date: Fri, 20 Nov 92 01:01:11 PST Subject: Lots of work to do. Message-ID: <9211200857.AA02944@netcom2.netcom.com> I said earlier: >> I've been getting good support for my ideas on implementing machine >>independent modules or "Libraries" of PGP routines that don't include >>I/O portions, but after looking at the code, I see this is going to >>take a lot of work, both in organizing the effort, and in implementing >>the code. Just how this is going to be done, I'm not sure, but this >>is what cypherpunks is all about. To hash these things over, flame on >>each other's ideas, etc. Miron says: >It would be very nice if PGP behaved better as a UNIX filter. For >example, I'd like it to return an exit code if it fails. I'd >also like it to have a flag that disables any access to the tty >for prompts. For example, if I have an automatic filter that >tries to decrypt all incoming messages, I don't want it to prompt >for a secret ring file when it can't decrypt something. I say the folliwing: The UNIX filter can certainly be written, but it should use the "services" of the PGP library code, which might have functions specifically for use with UNIX, But may not be called by Mac API's. It's important for me to point out that these PGP routines as C functions should be implemented as "Agents" or "Engines" and be totally self contained and not be depending on UNIX, MacOS or other facilities. It is fair for UNIX programs to CALL them, but the PGP should not depend on UNIX, or Machine dependent facilities other than File IO. Paul Rubin writes: >Those of us who support the freedom to use cryptography, run PGP, and >write whatever programs we wish (cryptographic and otherwise) should >be aware that the boycott against Lotus and Apple is still on. By >making PGP run on Macintoshes and with Lotus Notes, we improve the >usefulness of those systems and thereby help our enemies take away our >rights. I say --- Great!! but I have invested a lot of my own finances into purchasing my Mac II (Probably long before the boycott), and I certainly want to put it to good use. This includes my rights to privacy and to use PGP. I don't like Apple's policy, and think it sucks, especially if they dump hundreds of Mac programmers on the job marketplace, but sure don't want to ditch my Mac just because a few Apple FAT CATS made bad decisions. David Clunie writes: >2. A preliminary perusal of the code makes it obvious that extracting the > functionality from the interface is not an easy task. I agree, this isn't going to be easy, SW development is NEVER easy, so who is afraid of a little work? With all those unemployed programmers out there, we should be able to get PLENTY of help! JD From miron at extropia.wimsey.com Fri Nov 20 04:11:08 1992 From: miron at extropia.wimsey.com (Miron Cuperman) Date: Fri, 20 Nov 92 04:11:08 PST Subject: How far is to far? In-Reply-To: <199211200828.AA03551@well.sf.ca.us> Message-ID: <1992Nov20.111126.1376@extropia.wimsey.bc.ca> gg at well.sf.ca.us (George A. Gleason) writes: >Re. Fen's proposal to utilise "broadcatch." We still have the problems of >slander/libel and breaches of legitimate secrecy. >At risk of sounding naive/idealistic, it would seem that since there is no >way to block information passing through the net (aside from screening at >source, impractical at least!), the solution rests with education of the >net-using population. Power carries responsibility in equal measure. We Nah, education is too hard. :) There are two other options: - Have the mix accessible to only a selected group. Provide the group with signed certificates. It is possible to sign certificates such that they are untracable to their owner, exactly like crypto money. A security concern here is that the mix owner can tell when the same user uses the mix more than once (but the owner can't tell which user). - Charge for the mix services with crypto-money. The crypto-money could be some networking service. It could be even mix transmission. For example, the basic currency could be the transmission of 10K through a mix. One would have to create a mix and let the bank route some traffic through it thereby putting credits in your account. Once you have credits, you could spend them anywhere. One might want to fiddle with the definition of the currency so that it does not depreciate with time. I prefer the second option. I think mixes and crypto-money really go hand in hand. -- Miron Cuperman | NeXTmail/mime ok | Public key avail AMIX: MCuperman | immortalcybercomputinglaissezfaire | From Marc.Ringuette at GS80.SP.CS.CMU.EDU Fri Nov 20 14:17:44 1992 From: Marc.Ringuette at GS80.SP.CS.CMU.EDU (Marc.Ringuette at GS80.SP.CS.CMU.EDU) Date: Fri, 20 Nov 92 14:17:44 PST Subject: The Dining Cryptographers Protocol Message-ID: <9211201907.AA12713@cygnus.com> Can DC-nets be used in a hierarchical or "backbone" framework to reduce communications overhead? Bill Stewart (in personal mail) suggested that such a scheme could satisfy my objections to DC-nets, namely that in order to get N-way anonymity, you must exchange N bits of traffic per bit of anonymous message transmitted. But when we tried to come up with such a scheme, it ended up being an unsatisfying hybrid of DC-nets and mixes. If you know of a backbone arrangement for DC-nets with a local net of size L< Hey, this means you! Have you sent me the name of the software you use to read e-mail with yet? Even if you've never posted to the list or replied to any of the messages, I expect to hear from you. I not only want to collect a list of names of software, I want to know which ones are in most common use. Eric From hughes at soda.berkeley.edu Fri Nov 20 14:18:20 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Fri, 20 Nov 92 14:18:20 PST Subject: The Cypherpunks Mail Project Message-ID: <9211201843.AA29819@soda.berkeley.edu> Step Two in the Mail Project is to gather together the social facts of mail software development: where the source code is and who maintains it. Participation in this step is not required, but a distributed effort to find this information would be greatly appreciated. Therefore, if you know where to find source code for your own (or any other) mail reader, please send it along. Be complete. Include at least the following information: 1. The name of the mail agent. 2. The current version number. 3. A machine name where the code is located, presumably via anonymous ftp. 4. The directory on the machine where it can be found. 5. The author(s) and maintainer(s) of the software. 6. The licensing status of the software: public domain, Gnuware, university property but publicly usable, etc. 7. Any useful political information about convincing whoever to support encryption. If your mail agent is commercial, then send the name of the manufacturer and any other information you can think of. Eric From hughes at soda.berkeley.edu Fri Nov 20 14:18:40 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Fri, 20 Nov 92 14:18:40 PST Subject: The Cypherpunks Mail Project Message-ID: <9211201830.AA29311@soda.berkeley.edu> The time is now arrived for a more concerted effort to deploy encryption. It has become clear from the discussions on the list here that the first step should be encrypted e-mail. Unfortunately, mail is not homogeneous; there is no one place to push on the mail system to add encryption. Thus, regardless of the method used for encryption, we will need to add support to every single mail user agent. I now call for this work to begin. We will begin with the first step: a survey of existing mail agents. I volunteer to conduct the survey. I want to collect the following information from _everybody_ on the list: 1. What mail agent(s) do you use to read your everyday mail? 2. What platforms, hardware and software, do you use it on? Reply to hughes at soda.berkeley.edu as soon as you read this message. It only takes a minute to tell me how you read mail. Eric From tcmay at netcom.com Fri Nov 20 14:19:20 1992 From: tcmay at netcom.com (Timothy C. May) Date: Fri, 20 Nov 92 14:19:20 PST Subject: "Young Men's Crypto Association," (YMCA) In-Reply-To: <199211200828.AA03551@well.sf.ca.us> Message-ID: <9211201741.AA11668@netcom.netcom.com> "Young Men's Crypto Association" (YMCA) George Gleason raises some interesting points about teaching ethics and morality to nascent hackers, in the hope of heading off some of the darker aspects of anonymous remailers, digital pseudonyms, and the like: > At risk of sounding naive/idealistic, it would seem that since there is no > way to block information passing through the net (aside from screening at > source, impractical at least!), the solution rests with education of the > net-using population. Power carries responsibility in equal measure. We > are giving ourselves the power which comes with privacy; we can begin to > take responsibility for promoting a sense of ethics in the use of the net. > One possible place to start would be at highschool-level computer courses; > perhaps with accomplished hackers coming in and giving guest lectures or > something... the culture of computer-literate youth can begin to include > strong ethical positions regarding respect for the privacy of others, > respect for truthfulness, and a position of personal conscience regarding > law and authority. Re the latter, this isn't the same thing as blind I doubt this'll work. You're welcome to try, though. We had this same discussion in a nanotech group I attend (Ted Kaehler's "Assembler Multitude," in Palo Alto), where the concern was about the "grey goo" that could result from replicator development. Several folks recommended that the best approach to handling malicious "nanotech hacking" is _education_, just as George is recommending for what might be called "malicious crypto." The problems are: 1. Moral education (= Christian, in the West) has been tried for centuries, with little apparent effect on murders, rapes, war, and pillage. I won't knock religion here, but the teachings don't seem to have much of an effect. 2. There's usually some fringe, which may be 10% or which may be 1%, which does the _opposite_ of the mainstream teachings. For example, let us suppose George successfully organizes the "Young Men's Crypto Association," or YMCA, to go out to high schools and shopping malls to preach the virtues of crypto temperance, of the evils of computer viruses (a parallel to the crypto stuff talked about here, and an even better example of "hacker morality"), etc. This YMCA will perhaps teach some set of values to perhaps 90% or even 99% of the hacker community it preaches to. But what of the rest? A case can be made that such preaching will _energize_ this minority into action, if only to poke a stick into the eye of society. 3. Practically speaking, how can a handful of we crypto enthusiasts even begin to compete with the teachings of other moralists and religious types? We've got other fish to fry. 4. Finally, many of the "crypto anarchy" views I've been espousing for several years now have been seen by some as grossly immoral and dangerous. Should the YMCA (the Young Men's Crypto Association, remember) argue _against_ such ideas? > obedience, but rather the idea that if there is to be disobedience it needs > to be grounded in deeply held personal ethics, as for example in the case of > civil disobedience. A strong set of cultural values in these areas might > set a tone which discourages mindless negativity and wrecking. Now there > will always be those who wreck for thrills.... I don't know how to address > that problem except to note that such individuals are hardly stopped today > by the threat of prosecution. I agree with George that some will always "wreck for thrills." What crypto and privacy techniques do is give us some protection against these vandals. Like locks on doors, or sealed envelopes, these techniques protect us a lot better than moral lectures against thievery or fraud. Having said all this, if George decides to go ahead with his version of the YMCA, maybe I'll even stand outside in the cold and ring a bell. --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at 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^756839 | PGP Public Key: by arrangement. From pmetzger at shearson.com Fri Nov 20 14:25:24 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Fri, 20 Nov 92 14:25:24 PST Subject: The legality of PGP In-Reply-To: <9211191023.1.22089@cup.portal.com> Message-ID: <9211201648.AA19486@newsu.shearson.com> >From: hkhenson at cup.portal.com >Perry writes PGP is based on RSA . . . which has not granted a license >for people to use . . . . using PGP is possibly a pattent violation . . . >I wonder--I have RSA Mailsafe. Do you think that would give me a license >to use RSA if I loaded up PGP? Keith Doubtful -- RSA tends to be licensed on a per application per copy basis, not on a per human basis. If it was licensed on a per-human basis, I would have bought a personal "unlimited use" license long ago. Perry From ccat at casa-next1.Stanford.EDU Fri Nov 20 15:04:50 1992 From: ccat at casa-next1.Stanford.EDU (Chris Beaumont) Date: Fri, 20 Nov 92 15:04:50 PST Subject: Encrypting all mail and the protection of.. Message-ID: <9211202300.AA10992@ casa-next1.Stanford.EDU > I thinat in the case of  n reading back over the debate about mail encryptionthrough the encryption debate,my main thought seems to be,like the someone said earlier, that really the thing to push for is a mass people's movement to encrypyt all mail as a matter of course, with the tools to encrypt/decrypt be ing programs whose source code is freely published and open to scrutiny.Ultimately,if ALL mail, of any kind is routinely encrypted and decrypted using a suitable encryption metheod,privacy will be something we will tajke for granted.This right should be guaranteed via a Constitutional amendment.The decreasing cost of silicon will make this increasingly practical, and the money saved through the curtailment of credit card fraud,etc. (uncrackable digital suignatures would also have a side-benefit in that they would eliminate most credit card fraud.)would make this a win win situation..(except fotr the spooks and the crooks..) -Chris. From hh at soda.berkeley.edu Fri Nov 20 16:37:47 1992 From: hh at soda.berkeley.edu (Eric Hollander) Date: Fri, 20 Nov 92 16:37:47 PST Subject: transport Message-ID: <9211210037.AA08344@soda.berkeley.edu> Is there anyone going to tommorow's meeting from bekreley that I could get a ride from? If so please mail me or call me at 510 559 8470. Thanks, Eric Hollander From huntting at glarp.com Fri Nov 20 17:10:16 1992 From: huntting at glarp.com (Brad Huntting) Date: Fri, 20 Nov 92 17:10:16 PST Subject: The Cypherpunks Mail Project In-Reply-To: <9211201847.AA29990@soda.berkeley.edu> Message-ID: <199211210109.AA00635@misc.glarp.com> > Hey, this means you! Have you sent me the name of the software you > use to read e-mail with yet? > Even if you've never posted to the list or replied to any of the > messages, I expect to hear from you. > I not only want to collect a list of names of software, I want to know > which ones are in most common use. I use mime-mh... A variant of mh which supports MIME. Incorporating pgp with MIME, and then cleaning up pgp a little so it can deal with stdin/stdout would probably serve me just fine... brad From whitaker at eternity.demon.co.uk Fri Nov 20 18:17:57 1992 From: whitaker at eternity.demon.co.uk (Russell E. Whitaker) Date: Fri, 20 Nov 92 18:17:57 PST Subject: The Cypherpunks Mail Project Message-ID: <4475@eternity.demon.co.uk> > Hey, this means you! Have you sent me the name of the software you > use to read e-mail with yet? > > Eric > PCElm 3.01. Russell Earl Whitaker whitaker at eternity.demon.co.uk Communications Editor 71750.2413 at compuserve.com EXTROPY: The Journal of Transhumanist Thought AMiX: RWHITAKER Board member, Extropy Institute (ExI) ================ PGP 2.0 public key available ======================= From phr at napa.Telebit.COM Fri Nov 20 18:47:12 1992 From: phr at napa.Telebit.COM (Paul Rubin) Date: Fri, 20 Nov 92 18:47:12 PST Subject: The Cypherpunks Mail Project In-Reply-To: <4475@eternity.demon.co.uk> Message-ID: <9211210246.AA17433@napa.TELEBIT.COM> > Hey, this means you! Have you sent me the name of the software you > use to read e-mail with yet? > > Eric > PCElm 3.01. Everyone, please send the name of your email software to Eric, so he can do useful and wonderful things with the information. But please *don't* clutter the rest of the list with it. Thanks. From ghoast at gnu.ai.mit.edu Fri Nov 20 19:21:02 1992 From: ghoast at gnu.ai.mit.edu (ghoast at gnu.ai.mit.edu) Date: Fri, 20 Nov 92 19:21:02 PST Subject: NSA readings Message-ID: <9211210320.AA49284@hal.gnu.ai.mit.edu> If one is looking to find out as much as possible on the NSA (it s past doings as well as known present doings), what should one read, aside from the aforementioned "Puzzle Palace"? Are there any other accurate books or articles available? From wmo at rebma Fri Nov 20 20:46:59 1992 From: wmo at rebma (Bill O'Hanlon) Date: Fri, 20 Nov 92 20:46:59 PST Subject: The Cypherpunks Mail Project In-Reply-To: <9211201847.AA29990@soda.berkeley.edu> Message-ID: I use elm and mh-6.7. I just started using mh and am still learning my way around it. The platforms I use are Sun Sparcstations, at work, and 386-based PCs running Interactive, DOS, and 386BSD at home. Good luck with the survey, Bill From wmo at rebma.rebma.mn.org Fri Nov 20 23:24:21 1992 From: wmo at rebma.rebma.mn.org (Bill O'Hanlon) Date: Fri, 20 Nov 92 23:24:21 PST Subject: Apology Message-ID: Oops. Sorry about sending my response to Eric's survey to the entire list. Honestly, I know better, but I think that was the first time that I've used mh's repl, and I didn't check the cc. Oops. Anyway, I've had a couple queries on Eric's remailer. Hal Finney, just so you know, I've not heard responses from you to a couple letters, and neither has at least one other person. We're interested in your code for the Encrypted: part of the remailer. -- Bill O'Hanlon wmo at rebma.mn.org From Tom.Jennings at f111.n125.z1.FIDONET.ORG Fri Nov 20 23:28:18 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Fri, 20 Nov 92 23:28:18 PST Subject: The Cypherpunks Mail Project Message-ID: <3844.2B0DE187@fidogate.FIDONET.ORG> U> From: hughes at soda.berkeley.edu (Eric Hughes) U> Have you sent me the name of the U> software you use to read e-mail with yet? Program: ReadMail. MSDOS, FidoNet *.MSG message base compatible. --- ReadMail * Origin: tomj at fidosw.fidonet.org / World Power Systems (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET - Tom.Jennings at f111.n125.z1.FIDONET.ORG From fen at well.sf.ca.us Sat Nov 21 00:35:00 1992 From: fen at well.sf.ca.us (Fen Labalme) Date: Sat, 21 Nov 92 00:35:00 PST Subject: The Cypherpunks Mail Project Message-ID: <199211210833.AA19473@well.sf.ca.us> Eric Hughes writes: >It has become clear from the discussions on the list here that the >first step should be encrypted e-mail. Unfortunately, mail is not >homogeneous; there is no one place to push on the mail system to add >encryption. I may disagree with this (I say, "I may" as there are many sides to this compicated issue, but the side I currently agree with I will state here) and I hesitate to bring this up as I don't want to slow down the (imo) much-needed development of encrypted mailers. But I think that an approach may exist that has better long-term consequences than the one that advocates shoe-horning PGP into every mailer. There is an attempt to to create a new mail standard on top (or next to) the current so-called RFC-822 mail standard that will allow multi-part typed messages. This proposed standard, known as MIME (for Multipurpose Internet Mail Extensions) is nearly complete and will allow rich text, binary and other formats to be included in a single internet mail message. There has been a disagreement between the PEM (Privacy Enhanced Mail) and MIME communities as to which should be integrated into the other; simply put, the PEM folk feel that you simply encrypt an entire MIME message, and the MIME folk think that PEM messages are just another one of the many types of content parts that a MIME message can contain. I tend to agree with the latter camp, as it appears to be more flexible. For example, what happens if I wish to start communications with someone using a different standard than PGP (gasp - they may be using RSA's mailsafe), or even a newer, perhaps incompatible version of PGP? Or maybe I want to send them a message partly encrypted and partly in the clear? MIME is designed to handle these scenarios (and more). I must admit that this thought coalesced in my head due to the confluence of two different streams of communications both heading towards this solution at the same time: 1) I asked Steve Dorner (author of the excellent Eudora Macintosh email reader) if he was considering adding encryption to his mailer (specifically PGP) and he replied no, but that he was integrating MIME into it; 2) The pem-dev email list, which has been discussing threads on PGP and MIME, recently carried an interesting proposal on MIME-PEM integration (though I expect to see the other camp come out with their PEM-MIME integration plan soon!). I think this latter document is excellent reading, and I will forward it in a followup message to this one. By the way, it has a short set of six references that I consider required reading for anyone interested in doing serious work on Internet mailers. In case all this is new to you, I've included at the bottom a blurb from the RFC-index explaining how to find these RFCs and more. My $0.02. Fen ~~~ Many RFCs are available online; if not, this is indicated by (Not online). Online copies are available via FTP or Kermit from NIC.DDN.MIL as rfc/rfc####.txt or rfc/rfc####.PS (#### is the RFC number without leading zeroes). Additionally, RFCs may be requested through electronic mail from the automated NIC mail server by sending a message to SERVICE at NIC.DDN.MIL with a subject line of "rfc ####" for text versions or a subject line of "rfc ####.PS" for PostScript versions. To obtain the RFC index, the subject line of your message should read "rfc index". From fen at well.sf.ca.us Sat Nov 21 00:42:36 1992 From: fen at well.sf.ca.us (Fen Labalme) Date: Sat, 21 Nov 92 00:42:36 PST Subject: The Cypherpunks Mail Project Message-ID: <199211210841.AA20896@well.sf.ca.us> To: pem-dev at TIS.COM, ietf-822 at dimacs.rutgers.edu Subject: MIME-PEM Interaction Reply-To: ietf-822 at dimacs.rutgers.edu Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Date: Mon, 16 Nov 1992 16:41:22 -0800 From: Marshall Rose Sender: pem-dev-relay at TIS.COM ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Friends, at the request of the participants at the SAAG meeting this afternoon, I am posting a draft regarding the interaction of MIME and PEM. I believe that this draft will be presented by Ned Freed at the PEM meeting on Wednesday (which, regrettably, I will be unable to attend due to a conflict.) Although Steve, Ned and I think that the draft is fairly complete, there are likely some issues which remain to be resolved or at least given greater exposition. As such, your comments are most certainly welcome! /mtr ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-Description: mime-pem.txt draft MIME-PEM Interaction Nov 92 MIME-PEM Interaction Mon Nov 16 15:51:54 1992 Steve Crocker Trusted Information Systems crocker at tis.com Ned Freed Innosoft International, Inc. ned at innosoft.com Marshall T. Rose Dover Beach Consulting, Inc. mrose at dbc.mtview.ca.us 1. Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as a "work in progress". 2. Abstract This memo defines a framework for interaction between MIME and PEM services. Expires May 16, 1993 [Page 1] draft MIME-PEM Interaction Nov 92 3. Introduction In the Internet community, an electronic mail message has two parts: the headers and the body. The headers form a collection of field/value pairs structured according to RFC 822 [1], whilst the body, if structured, is defined according to Multipurpose Internet Mail Extensions (MIME) [2]. Privacy Enhanced Mail (PEM) [3-6] allows encryption and authentication services to be applied to an electronic mail message. This memo defines a framework whereby the services provided by MIME and PEM are used in a complementary fashion. In order to provide for MIME-PEM interaction, two content types, "multipart/pem" and "application/pem", are defined. Then, the relationship between MIME and PEM is described in terms of two functions: message composition and message delivery. Expires May 16, 1993 [Page 2] draft MIME-PEM Interaction Nov 92 4. Definiton of new Content Types 4.1. Definition of the multipart/pem Content Type (1) MIME type name: multipart (2) MIME subtype name: pem (3) Required parameters: boundary, privacy (4) Optional parameters: none (5) Encoding considerations: always 7bit (6) Security Considerations: see [3] This subtype of multipart always contains two body parts: the first is an arbitrary content; and, the second is an application/pem content which describes the privacy- enhancements which resulted in the first body part. The value of the first body part corresponds to as defined in [3]. Note that if is represented using the base64 encoding, then a a Content-Transfer-Encoding: header is present which indicates use of the base64 content encoding. Otherwise, if a Content-Transfer-Encoding: header is present, it indicates use of the 7bit content encoding. The syntax and semantics of the boundary parameter is defined in [2]. The syntax of the privacy parameter, using the ABNF notation of [1], is: privacy-value ::= "ENCRYPTED" / "MIC-ONLY" / "MIC-CLEAR" with each value conveying the intent as specified in [3]. Expires May 16, 1993 [Page 3] draft MIME-PEM Interaction Nov 92 4.2. Definition of the application/pem Content Type (1) MIME type name: application (2) MIME subtype name: pem (3) Required parameters: none (4) Optional parameters: none (5) Encoding considerations: always 7bit (6) Security Considerations: see [3] The syntax of this content type corresponds to the production defined in [3]. Expires May 16, 1993 [Page 4] draft MIME-PEM Interaction Nov 92 5. Message Composition When a user composes a message, it is the responsibility of the user agent to use the Content-Type: header. This allows the receiving user agent to unambiguously interpret the body and process it accordingly. This memo introduces a new header field, "Content-Privacy", which is used to indicate that the message should undergo privacy-enhancement prior to submission. The syntax of this header field corresponds to the production defined above. 5.1. Pre-Submission Algorithm Prior to submission, the user agent applies this algorithm: (1) If the content does not contain the Content-Privacy: header, then the user agent sees if the content is either multipart or message. If so, it then recursively applies this algorithm to the encapsulated body parts; if not, it terminates processing for this content. (2) If the content does contain the Content-Privacy: header, the content is transformed from local form to its canonical form. Note that if a Content-Transfer- Encoding: header is present, then the content encoding is reversed as a part of this process. (3) If the canonical form of the content uses octet values outside of the NVT ASCII repertoire, and if the value of the Content-Privacy: header is MIC-CLEAR, then this inconsistency is reported to the user and the algorithm aborts. (4) Otherwise, the privacy-enhancement indicated by the Content-Privacy: header is performed, constructing a new content. The Content- headers, other than Content- Transfer-Encoding: and Content-Privacy:, are taken from the original content, if any. (5) If the value of the Content-Privacy: header is not MIC- CLEAR, then the base64 content encoding is applied and a Content-Transfer-Encoding: header is added to the new Expires May 16, 1993 [Page 5] draft MIME-PEM Interaction Nov 92 content. (6) Finally, a multipart/pem content is constructed, whcih contains the new content and a corresponding application/pem content. The multipart/pem content replaces the original content. Expires May 16, 1993 [Page 6] draft MIME-PEM Interaction Nov 92 6. Message Delivery When a user receives a message containing an multipart/pem content, the user agent may transform the content back into its original content type. This operation, the post-delivery algorithm, is performed by reversing the steps performed during the pre-submission algorithm. When the original content is reconstituted into canonical form, it may use octet values outside of the NVT ASCII repertoire. If the user agent replaces the multipart/pem content with the original content, then it must select an appropriate transfer encoding and include the appropriate Content-Transfer-Encoding: header. Upon successful completion of the post-delivery algorithm for each content, the user agent adds a new header field, "Content-Annotation", which is used to indicate the privacy- enhancements that were in effect when the content was submitted. The syntax of this header field, using the ABNF notation of [1], is: content-annotation ::= "Content-Annotation" ":" annotation-value annotation-value ::= ";" with corresponding to the privacy-enhancements that was in effect during submission, and , defined in [1], indicates the date and time that the privacy- enhancements were verified by the receiving user agent. NOTE It must be strongly emphasized that the user's level of trust in the value of the Content-Annotation: header should be no higher than the user's level of trust in the message store employed by the user agent. Expires May 16, 1993 [Page 7] draft MIME-PEM Interaction Nov 92 7. An Example For example, suppose the following message was being readied for submission: Date: Thu, 12 Nov 1992 21:43:40 -0800 From: scrocker at tis.com To: ned at innosoft.com Subject: example #1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Privacy: mic-clear Hi Ned. See how much nicer this works! After applying pre-submission algorithm, the message submitted for delivery would appear as: Date: Thu, 12 Nov 1992 21:43:40 -0800 From: scrocker at tis.com To: ned at innosoft.com Subject: example #1 MIME-Version: 1.0 Content-Type: multipart/pem; boundary="next-part"; privacy=mic-clear Content-Type: text/plain; charset=us-ascii Hi Ned. See how much nicer this works! --next-part Content-Type: application/pem Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-ID-Asymmetric: ... MIC-Info: RSA-MD5,RSA, ... --next-part-- Expires May 16, 1993 [Page 8] draft MIME-PEM Interaction Nov 92 After applying the post-delivery algorithm, the resulting message would appear as: Date: Thu, 12 Nov 1992 21:43:40 -0800 From: scrocker at tis.com To: ned at innosoft.com Subject: example #1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Annotation: mic-clear; Thu, 12 Nov 1992 22:13:40 -0800 (integrity verified) Hi Ned. See how much nicer this works! Of course, as the message being submitted was only plain text, the Content-Type: header could be ommitted. In that case, after applying the pre-submission algorithm, the message submitted for delivery would appear as: Date: Thu, 12 Nov 1992 21:43:40 -0800 From: scrocker at tis.com To: ned at innosoft.com Subject: example #1 MIME-Version: 1.0 Content-Type: multipart/pem; boundary="next-part"; privacy=mic-clear Hi Ned. See how much nicer this works! --next-part Content-Type: application/pem Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-ID-Asymmetric: ... MIC-Info: RSA-MD5,RSA, ... --next-part-- Expires May 16, 1993 [Page 9] draft MIME-PEM Interaction Nov 92 8. Observations The use of the pre-submission and post-delivery algorithms exhibit several properties: (1) It allows privacy-enhancement of an arbitrary content, not just an RFC 822 message. (2) For a multipart or message content, it allows the user to decide whether the structure of the content should receive privacy-enhancement. (3) It allows a message to contain several privacy enhanced contents, thereby removing the requirement for PEM software to be able to generate or interpret a single content which intermixes both unenhanced and enhanced components. (4) It minimizes confusion when viewing a MIC-CLEAR content without a PEM-capable user agent. (5) It minimizes confusing when viewing a MIC-ONLY content with a MIME-capable user agent that is not PEM-capable. 9. Acknowledgements David H. Crocker suggested the use of a multipart structure for MIME-PEM interaction. Expires May 16, 1993 [Page 10] draft MIME-PEM Interaction Nov 92 10. References [1] D.H. Crocker. Standard for the Format of ARPA Internet Text Messages. Request for Comments 822, (August, 1982). [2] N. Borenstein, N. Freed, Multipurpose Internet Mail Extensions. Request for Comments 1341, (June, 1992). [3] J. Linn, Privacy Enhancement for Internet Electronic Mail -- Part I: Message Encryption and Authentication Procedures. Internet-Draft, (July 23, 1992). [4] S. Kent, Privacy Enhancement for Internet Electronic Mail -- Part II: Certificate-Based Key Management. Internet-Draft, (August 6, 1992). [5] D. Balenson, Privacy Enhancement for Internet Electronic Mail -- Part III: Algorithms, Modes, and Identifiers. Internet-Draft, (September 3, 1992). [6] B. Kaliski, Privacy Enhancement for Internet Electronic Mail -- Part IV: Key Certification and Related Services Internet-Draft, (September 1, 1992). Expires May 16, 1993 [Page 11] draft MIME-PEM Interaction Nov 92 Table of Contents 1 Status of this Memo ................................... 1 2 Abstract .............................................. 1 3 Introduction .......................................... 2 4 Definiton of new Content Types ........................ 3 4.1 Definition of the multipart/pem Content Type ........ 3 4.2 Definition of the application/pem Content Type ...... 4 5 Message Composition ................................... 5 5.1 Pre-Submission Algorithm ............................ 5 6 Message Delivery ...................................... 7 7 An Example ............................................ 8 8 Observations .......................................... 10 9 Acknowledgements ...................................... 10 10 References ........................................... 11 Expires May 16, 1993 [Page 12] ------- =_aaaaaaaaaa0-- [ sorry for the double spacing - my mailer's acting up and I'm too tired to fight with it anymore. What we need MORE than encrypted mailers is mailers that do the standard stuff right... The one on the WELL sux!] From gg at well.sf.ca.us Sat Nov 21 02:24:11 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Sat, 21 Nov 92 02:24:11 PST Subject: How far is to far? Message-ID: <199211211022.AA06269@well.sf.ca.us> Miron writes, "Charge for the mix services with crypto money. The crypto money could be some networking service..." Only problem is, once we start anything like a formal barter system, it comes under the IRS. The way to avoid that is to keep it a volunteer organisation with an expectation of time commitment to projects or to payment of membership dues. Not-for-profit organisations are of course regulated in a minimal way (think of your local Model Railroad Club), but the accounting isn't as strict and the membership transactions don't have to be reported in detail. -gg From gg at well.sf.ca.us Sat Nov 21 02:40:14 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Sat, 21 Nov 92 02:40:14 PST Subject: "Young Men's Crypto Association," (YMCA) Message-ID: <199211211039.AA08783@well.sf.ca.us> Tim, you raise a good point about those who'll wreck for the fun of it, and more so in reaction to any perceived ethical mainstream position. Re crypto-anarchy, at heart I'm in favor; in practice I'm in favor; and I see no contradiction in promoting an internalised sense of ethics in these areas. The underlying deep problem is we live in a society which is addicted to the emotions that go along with violent acts. Ultimately that problem needs to be addressed, and it's beyond the scope of this group to do that, except as each of us can do things in other contexst of our civic lives. The difficulty of promoting an ethic of conscience is real; but so is the difficulty of arriving at a solution to a technical problem; and difficulty by itself does not stop anyone. It is erroneous to think that technical problems are easier to solve than social ones; any of us can name ten or more areas in which technical problems have proven incredibly complex. In most of these examples, the complex problems arise when dealing with networked systems or systems involving relationships among many elements which can vary in ways that can't be controlled. You can see a straightforward parallel to social problems here: the more variable elements, the more complexity of solution. But let's not let that stop us. -gg From ittai at ans.net Sat Nov 21 08:52:59 1992 From: ittai at ans.net (Ittai Hershman) Date: Sat, 21 Nov 92 08:52:59 PST Subject: The Cypherpunks Mail Project In-Reply-To: <199211210833.AA19473@well.sf.ca.us.ans-relay> Message-ID: <199211211650.AA02274@shemesh.ans.net> I am in full agreement with Fen's comments regarding MIME. Let me add a short bit of history here. MIME came about because of an effort within the IETF (Internet Engineering Task Force) to extend Internet mail standards to support 8-bit extended character sets and (gasp) to potentially even support the sending of arbitrary binary data. A working group was formed and it took several months and literally thousands of messages before some form of consensus was reached on the technical issues (note -- not the solution, just the issues!). To make a long story short, it quickly became obvious that there was no agreed upon solution which would both provide the functionality the various camps wanted, and backwards compatability for the million or so hosts currently on the Internet. The MIME effort was a creative stroke of genius which allowed us to get out of this fix. Simply put, it allows for a) arbitrary data types to be encoded into 7-bit ASCII and transported using standard RFC-821 SMTP, and b) the structuring of chunks of different data type "parts" into a single e-mail message such that MIME-aware mail-agents/readers can intelligently display multi-media mail intelligently. In other words, the problem was moved from the protocol space to the applications space. Why is this relevant? Well, in order for MIME to be useful, the mail readers that people use have to be modified to support MIME. Fortunately, Nathaniel Borenstein of Bellcore has assembled a kit to make this much easier, and in fact provides patches for many mailers. Now, the authors of all the freebie mail readers we use are being asked to incorporate these changes into their mailers. Do we really want to give them an additional burden -- or do we want to leverage off work that is already being done? -Ittai PS: For those who are interested, these are the relevant RFC's: 1344 Implications of MIME for Internet mail gateways. Borenstein, N. 1992 June; 8 p. (Format: TXT=25872, PS=51812 bytes) 1343 User agent configuration mechanism for multimedia mail format information. Borenstein, N. 1992 June; 10 p. (Format: TXT=29295, PS=59978 bytes) 1342 Representation of non-ASCII text in Internet message headers. Moore, K. 1992 June; 7 p. (Format: TXT=15845 bytes) 1341 MIME (Multipurpose Internet Mail Extensions): Mechanisms for specifying and describing the format of Internet message bodies. Borenstein, N.; Freed, N. 1992 June; 69 p. (Format: TXT=211117, PS=347082 bytes) From donb at netcom.com Sat Nov 21 21:16:52 1992 From: donb at netcom.com (Don Bellenger) Date: Sat, 21 Nov 92 21:16:52 PST Subject: SUBSCRIBE Message-ID: <9211220512.AA07634@netcom2.netcom.com> SUBSCRIBE Please add me to your mailing list at this address. Thanks, Don Bellenger donb at netcom.com From edgar at spectrx.Saigon.COM Sun Nov 22 05:02:03 1992 From: edgar at spectrx.Saigon.COM (Edgar W. Swank) Date: Sun, 22 Nov 92 05:02:03 PST Subject: Problems with remailer Message-ID: Distribution: Hal <74076.1041 at compuserve.com> Cypherpunks Hal: I tried to test your remailer, but didn't have any luck. I can see that other people (Cassandra & Pollyanna among others) are using it. This small (and free) system does not allow me to specify network headers (except Subject), so I used the "::" convention. I tried three configurations of sending something to myself on Nov 17, 1:08am. As of my last session, Nov 19, 4:45pm, I had not received an echo from any of the three. Here is the record of the mailings. Note the sequence numbers are not part of the message. ---------------------------------------------------------------- To: Remailing Service Subject: Remail Unincrypted 1> :: 2> Request-Remailing-To: edgar at spectrx.saigon.com (Edgar W. Swank) 3> 4> This is an unencrypted test message. 5> /s (Queued for Internet delivery) To: Remailing Service Subject: Remail Encrypted c:\tlxd\spies7.msg :: Request-Remailing-To: edgar at spectrx.saigon.com (Edgar W. Swank) This is an encrypted test message. c:\tlxd\spies7.asc 1> :: 2> Encrypted: PGP 3> 4> -----BEGIN PGP MESSAGE----- 5> Version: 2.0 6> 7> hEwCG6rHcT8LtDcBAf4ime6fkvJE3hKvET5lNeG7U51cFM5B9bCRuYdgDN8gXGef 8> tXpamyWSXHDRvpb/PeebBdG/Gqxb571l54vqAO5opgAAAIepaWGSNzSfnMSOWV+a 9> VFETSI7H7i2m3ZagT/XbgVqzfVUXkkqBYXKESlcsAiUWnF8tXGwYJ/KYUvHWW/ve 10> qPvlbdYAoe+iMtR7asvPCEz+WxEmdIQqTxUPCT1tiIaaplsk5l7p80dW8NkArCH6 11> BTowA85FQrI7gBUBevSs8hq62JUAs6GH5T8= 12> =XUQk 13> -----END PGP MESSAGE----- 14> 15> /s (Queued for Internet delivery) To: Remailing Service Subject: Remail With Anon Return 1> :: 2> Encrypted: PGP 3> 4> -----BEGIN PGP MESSAGE----- 5> Version: 2.0 6> 7> hEwCG6rHcT8LtDcBAf0SgMh0C4raXWqjXytzsmpt2b8veBXZhUvez+ZI309w1Y8w 8> oiYcPjGHhL6l7ad0IXuXFUgBwxAmHbzexSLVeKvgpgAAAGuiL3psLLLJfKeDGXjD 9> hDK3KWoFGlzyzssiudBe+f5kv/1j4EnzkviyQgxCxFTYUd04Z6az1HWRWU7Fvanq 10> KZarLLBgfe8eqzIa82FyOh6CMFqg2Ou4VkaTbQma8LQk4u+7JRNxKBMmy7TrTQ== 11> =0mFO 12> -----END PGP MESSAGE----- 13> 14> This is a message using anonymous return address. 15> /s (Queued for Internet delivery) ---------------------------------------------------------------- Hope you can tell me where I went wrong, especially since you have the convenience of the remailer secret key. In one post, you said: You could post anonymously, using our current remailers, to this list or another list. This implies you now have more than one remailer. Where is (are) the other one(s)? I've since lost track of the details, but I recall reading about a gateway from E-Mail to any Usenet newsgroup. Of course, with your remailer, it's now possible to use that to anonymously post to any usenet newsgroup. Since I'm writing to you anyway, I'd be interested in knowing what (if any) records are kept by the remailer, and for how long are they retained. Where the forwarding address is encrypted, is the decryption of same erased both in memory & on disk (overlay erased on disk) as soon as the message is sent? Memory buffers of incoming net headers (which aren't encrypted) and messages (which may not be encrypted) also need to be erased promptly & not left lying around until reused. Is it possible the remailer held up forwarding my messages waiting for other messages to arrive with different destinations (to confuse traffic analysis)? To avoid long waits, you might want to send out dummy messages to a variety of addresses when traffic is low. I hereby volunteer my address to receive up to ten such messages per day. Once there are enough remailers so that most messages are being forwarded to another remailer, then all the dummy messages can be sent to the other remailers. -- edgar at spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca From tcmay at netcom.com Sun Nov 22 11:54:53 1992 From: tcmay at netcom.com (Timothy C. May) Date: Sun, 22 Nov 92 11:54:53 PST Subject: Crypto Glossary Message-ID: <9211221950.AA28744@netcom.netcom.com> Here's the glossary of crypto terms we passed out in printed form at the first Cypherpunks meeting in September 1992. Some compromises had to be made in going from the printed form to the ASCII of this transmission, so I hope you'll bear with me. I'm sending it to the entire list because nearly everyone who hears about it says "Is it online?" and wants a copy. If you don't want it, discard it. I'm not going to be maintaining the "Cypherpunks FAQ," so don't send me corrections or additions. Enjoy! --Tim May CRYPTO GLOSSARY Compiled by Tim May (tcmay at netcom.com) and Eric Hughes (hughes at soda.berkeley.edu), circa September 1992. Major Branches of Cryptology (as we see it) - (these sections will introduce the terms in context, though complete definitions will not be given) *** Encryption - privacy of messages - using ciphers and codes to protect the secrecy of messages - DES is the most common symmetric cipher (same key for encryption and decryption) - RSA is the most common asymmetric cipher (different keys for encryption and decryption) *** Signatures and Authentication - proving who you are - proving you signed a document (and not someone else) *** Untraceable Mail - untraceable sending and receiving of mail and messages - focus: defeating eavesdroppers and traffic analysis - DC protocol (dining cryptographers) *** Cryptographic Voting - focus: ballot box anonymity - credentials for voting - issues of double voting, security, robustness, efficiency *** Digital Cash - focus: privacy in transactions, purchases - unlinkable credentials - blinded notes - "digital coins" may not be possible *** Crypto Anarchy - using the above to evade government, to bypass tax collection, etc. - a technological solution to the problem of too much government *** G L O S S A R Y *** *** agoric systems -- open, free market systems in which voluntary transactions are central. *** Alice and Bob -- cryptographic protocols are often made clearer by considering parties A and B, or Alice and Bob, performing some protocol. Eve the eavesdropper, Paul the prover, and Vic the verifier are other common stand-in names. *** ANDOS -- all or nothing disclosure of secrets. *** anonymous credential -- a credential which asserts some right or privilege or fact without revealing the identity of the holder. This is unlike CA driver's licenses. *** asymmetric cipher -- same as public key cryptosystem. *** authentication -- the process of verifying an identity or credential, to ensure you are who you said you were. *** biometric security -- a type of authentication using fingerprints, retinal scans, palm prints, or other physical/biological signatures of an individual. *** bit commitment -- e.g., tossing a coin and then committing to the value without being able to change the outcome. The blob is a cryptographic primitive for this. *** blinding, blinded signatures -- A signature that the signer does not remember having made. A blind signature is always a cooperative protocol and the receiver of the signature provides the signer with the blinding information. *** blob -- the crypto equivalent of a locked box. A cryptographic primitive for bit commitment, with the properties that a blobs can represent a 0 or a 1, that others cannot tell be looking whether itUs a 0 or a 1, that the creator of the blob can "open" the blob to reveal the contents, and that no blob can be both a 1 and a 0. An example of this is a flipped coin covered by a hand. *** channel -- the path over which messages are transmitted. Channels may be secure or insecure, and may have eavesdroppers (or enemies, or disrupters, etc.) who alter messages, insert and delete messages, etc. Cryptography is the means by which communications over insecure channels are protected. *** chosen plaintext attack -- an attack where the cryptanalyst gets to choose the plaintext to be enciphered, e.g., when possession of an enciphering machine or algorithm is in the possession of the cryptanalyst. *** cipher -- a secret form of writing, using substitution or transposition of characters or symbols. *** ciphertext -- the plaintext after it has been encrypted. *** code -- a restricted cryptosystem where words or letters of a message are replaced by other words chosen from a codebook. Not part of modern cryptology, but still useful. *** coin flipping -- an important crypto primitive, or protocol, in which the equivalent of flipping a fair coin is possible. Implemented with blobs. *** collusion -- wherein several participants cooperate to deduce the identity of a sender or receiver, or to break a cipher. Most cryptosystems are sensitive to some forms of collusion. Much of the work on implementing DC Nets, for example, involves ensuring that colluders cannot isolate message senders and thereby trace origins and destinations of mail. *** computationally secure -- where a cipher cannot be broken with available computer resources, but in theory can be broken with enough computer resources. Contrast with unconditionally secure. *** countermeasure -- something you do to thwart an attacker. *** credential -- facts or assertions about some entity. For example, credit ratings, passports, reputations, tax status, insurance records, etc. Under the current system, these credentials are increasingly being cross-linked. Blind signatures may be used to create anonymous credentials. *** credential clearinghouse -- banks, credit agencies, insurance companies, police departments, etc., that correlate records and decide the status of records. *** cryptanalysis -- methods for attacking and breaking ciphers and related cryptographic systems. Ciphers may be broken, traffic may be analyzed, and passwords may be cracked. Computers are of course essential. *** crypto anarchy -- the economic and political system after the deployment of encryption, untraceable e-mail, digital pseudonyms, cryptographic voting, and digital cash. A pun on "crypto," meaning "hidden," and as when Gore Vidal called William F. Buckley a "crypto fascist." *** cryptography -- another name for cryptology. *** cryptology -- the science and study of writing, sending, receiving, and deciphering secret messages. Includes authentication, digital signatures, the hiding of messages (steganography), cryptanalysis, and several other fields. *** cyberspace -- the electronic domain, the Nets, and computer-generated spaces. Some say it is the "consensual reality" described in "Neuromancer." Others say it is the phone system. Others have work to do. *** DC protocol, or DC-Net -- the dining cryptographers protocol. DC-Nets use multiple participants communicating with the DC protocol. *** DES -- the Data Encryption Standard, proposed in 1977 by the National Bureau of Standards (now NIST), with assistance from the National Security Agency. Based on the "Lucifer" cipher developed by Horst Feistel at IBM, DES is a secret key cryptosystem that cycles 64-bit blocks of data through multiple permutations with a 56-bit key controlling the routing. "Diffusion" and "confusion" are combined to form a cipher that has not yet been cryptanalyzed (see "DES, Security of"). DES is in use for interbank transfers, as a cipher inside of several RSA-based systems, and is available for PCs. *** DES, Security of -- many have speculated that the NSA placed a trapdoor (or back door) in DES to allow it to read DES-encrypted messages. This has not been proved. It is known that the original Lucifer algorithm used a 128-bit key and that this key length was shortened to 64 bits (56 bits plus 8 parity bits), thus making exhaustive search much easier (so far as is known, brute-force search has not been done, though it should be feasible today). Shamir and Bihan have used a technique called "differential cryptanalysis" to reduce the exhaustive search needed for chosen plaintext attacks (but with no import for ordinary DES). *** differential cryptanalysis -- the Shamir-Biham technique for cryptanalyzing DES. With a chosen plaintext attack, they've reduced the number of DES keys that must be tried from about 2^56 to about 2^47 or less. Note, however, that rarely can an attacker mount a chosen plaintext attack on DES systems. *** digital cash, digital money -- Protocols for transferring value, monetary or otherwise, electronically. Digital cash usually refers to systems that are anonymous. Digital money systems can be used to implement any quantity that is conserved, such as points, mass, dollars, etc. There are many variations of digital money systems, ranging from VISA numbers to blinded signed digital coins. A topic too large for a single glossary entry. *** digital pseudonym -- basically, a "crypto identity." A way for individuals to set up accounts with various organizations without revealing more information than they wish. Users may have several digital pseudonyms, some used only once, some used over the course of many years. Ideally, the pseudonyms can be linked only at the will of the holder. In the simplest form, a public key can serve as a digital pseudonym and need not be linked to a physical identity. *** digital signature -- Analogous to a written signature on a document. A modification to a message that only the signer can make but that everyone can recognize. Can be used legally to contract at a distance. *** digital timestamping -- one function of a digital notary public, in which some message (a song, screenplay, lab notebook, contract, etc.) is stamped with a time that cannot (easily) be forged. *** dining cryptographers protocol (aka DC protocol, DC nets) -- the untraceable message sending system invented by David Chaum. Named after the "dining philosophers" problem in computer science, participants form circuits and pass messages in such a way that the origin cannot be deduced, barring collusion. At the simplest level, two participants share a key between them. One of them sends some actual message by bitwise exclusive-ORing the message with the key, while the other one just sends the key itself. The actual message from this pair of participants is obtained by XORing the two outputs. However, since nobody but the pair knows the original key, the actual message cannot be traced to either one of the participants. *** discrete logarithm problem -- given integers a, n, and x, find some integer m such that a^m mod n = x, if m exists. Modular exponentiation, the a^m mod n part, is straightforward (and special purpose chips are available), but the inverse problem is believed to be very hard, in general. Thus it is conjectured that modular exponentiation is a one- way function. *** DSS, Digital Signature Standard -- the latest NIST (National Institute of Standards and Technology, successor to NBS) standard for digital signatures. Based on the El Gamal cipher, some consider it weak and poor substitute for RSA- based signature schemes. *** eavesdropping, or passive wiretapping -- intercepting messages without detection. Radio waves may be intercepted, phone lines may be tapped, and computers may have RF emissions detected. Even fiber optic lines can be tapped. *** factoring -- Some large numbers are difficult to factor. It is conjectured that there are no feasible--i.e."easy," less than exponential in size of number-- factoring methods. It is also an open problem whether RSA may be broken more easily than by factoring the modulus (e.g., the public key might reveal information which simplifies the problem). Interestingly, though factoring is believed to be "hard", it is not known to be in the class of NP-hard problems. Professor Janek invented a factoring device, but he is believed to be fictional. *** information-theoretic security -- "unbreakable" security, in which no amount of cryptanalysis can break a cipher or system. One time pads are an example (providing the pads are not lost nor stolen nor used more than once, of course). Same as unconditionally secure. *** key -- a piece of information needed to encipher or decipher a message. Keys may be stolen, bought, lost, etc., just as with physical keys. *** key exchange, or key distribution -- the process of sharing a key with some other party, in the case of symmetric ciphers, or of distributing a public key in an asymmetric cipher. A major issue is that the keys be exchanged reliably and without compromise. Diffie and Hellman devised one such scheme, based on the discrete logarithm problem. *** known-plaintext attack -- a cryptanalysis of a cipher where plaintext-ciphertext pairs are known. This attack searches for an unknown key. Contrast with the chosen plaintext attack, where the cryptanalyst can also choose the plaintext to be enciphered. *** mail, untraceable -- a system for sending and receiving mail without traceability or observability. Receiving mail anonymously can be done with broadcast of the mail in encrypted form. Only the intended recipient (whose identity, or true name, may be unknown to the sender) may able to decipher the message. Sending mail anonymously apparently requires mixes or use of the dining cryptographers (DC) protocol. *** minimum disclosure proofs -- another name for zero knowledge proofs, favored by Chaum. *** mixes -- David Chaum's term for a box which performs the function of mixing, or decorrelating, incoming and outgoing electronic mail messages. The box also strips off the outer envelope (i.e., decrypts with its private key) and remails the message to the address on the inner envelope. Tamper-resistant modules may be used to prevent cheating and forced disclosure of the mapping between incoming and outgoing mail. A sequence of many remailings effectively makes tracing sending and receiving impossible. Contrast this with the software version, the DC protocol. *** modular exponentiation -- raising an integer to the power of another integer, modulo some integer. For integers a, n, and m, a^m mod n. For example, 5^3 mod 100 = 25. Modular exponentiation can be done fairly quickly with a sequence of bit shifts and adds, and special purpose chips have been designed. See also discrete logarithm. *** National Security Agency (NSA) -- the largest intelligence agency, responsible for making and breaking ciphers, for intercepting communications, and for ensuring the security of U.S. computers. Headquartered in Fort Meade, Maryland, with many listening posts around the world. The NSA funds cryptographic research and advises other agencies about cryptographic matters. The NSA once obviously had the world's leading cryptologists, but this may no longer be the case. *** negative credential -- a credential that you possess that you don't want any one else to know, for example, a bankruptcy filing. A formal version of a negative reputation. *** NP-complete -- a large class of difficult problems. "NP" stands for nondeterministic polynomial time, a class of problems thought in general not to have feasible algorithms for their solution. A problem is "complete" if any other NP problem may be reduced to that problem. Many important combinatorial and algebraic problems are NP-complete: the traveling salesman problem, the Hamiltonian cycle problem, the word problem, and on and on. *** oblivious transfer -- a cryptographic primitive that involves the probabilistic transmission of bits. The sender does not know if the bits were received. *** one-time pad -- a string of randomly-selected bits or symbols which is combined with a plaintext message to produce the ciphertext. This combination may be shifting letters some amount, bitwise exclusive-ORed, etc.). The recipient, who also has a copy of the one time pad, can easily recover the plaintext. Provided the pad is only used once and then destroyed, and is not available to an eavesdropper, the system is perfectly secure, i.e., it is information- theoretically secure. Key distribution (the pad) is obviously a practical concern, but consider CD-ROM's. *** one-way function -- a function which is easy to compute in one direction but hard to find any inverse for, e.g. modular exponentiation, where the inverse problem is known as the discrete logarithm problem. Compare the special case of trap door one-way functions. An example of a one-way operation is multiplication: it is easy to multiply two prime numbers of 100 digits to produce a 200-digit number, but hard to factor that 200-digit number. *** P ?=? NP -- Certainly the most important unsolved problem in complexity theory. If P = NP, then cryptography as we know it today does not exist. If P = NP, all NP problems are "easy." *** padding -- sending extra messages to confuse eavesdroppers and to defeat traffic analysis. Also adding random bits to a message to be enciphered. *** plaintext -- also called cleartext, the text that is to be enciphered. *** Pretty Good Privacy (PGP) -- Phillip ZimmermanUs implementation of RSA, recently upgraded to version 2.0, with more robust components and several new features. RSA Data Security has threatened PZ so he no longer works on it. Version 2.0 was written by a consortium of non-U.S. hackers. *** prime numbers -- integers with no factors other than themselves and 1. The number of primes is unbounded. About 1% of the 100 decimal digit numbers are prime. Since there are about 10^70 particles in the universe, there are about 10^23 100 digit primes for each and every particle in the universe! *** probabilistic encryption -- a scheme by Goldwasser, Micali, and Blum that allows multiple ciphertexts for the same plaintext, i.e., any given plaintext may have many ciphertexts if the ciphering is repeated. This protects against certain types of known ciphertext attacks on RSA. *** proofs of identity -- proving who you are, either your true name, or your digital identity. Generally, possession of the right key is sufficient proof (guard your key!). Some work has been done on "is-a-person" credentialling agencies, using the so-called Fiat-Shamir protocol...think of this as a way to issue unforgeable digital passports. Physical proof of identity may be done with biometric security methods. Zero knowledge proofs of identity reveal nothing beyond the fact that the identity is as claimed. This has obvious uses for computer access, passwords, etc. *** protocol -- a formal procedure for solving some problem. Modern cryptology is mostly about the study of protocols for many problems, such as coin-flipping, bit commitment (blobs), zero knowledge proofs, dining cryptographers, and so on. *** public key -- the key distributed publicly to potential message-senders. It may be published in a phonebook-like directory or otherwise sent. A major concern is the validity of this public key to guard against spoofing or impersonation. *** public key cryptosystem -- the modern breakthrough in cryptology, designed by Diffie and Hellman, with contributions from several others. Uses trap door one-way functions so that encryption may be done by anyone with access to the "public key" but decryption may be done only by the holder of the "private key." Encompasses public key encryption, digital signatures, digital cash, and many other protocols and applications. *** public key encryption -- the use of modern cryptologic methods to provided message security and authentication. The RSA algorithm is the most widely used form of public key encryption, although other systems exist. A public key may be freely published, e.g., in phonebook-like directories, while the corresponding private key is closely guarded. *** public key patents -- M.I.T. and Stanford, due to the work of Rivest, Shamir, Adleman, Diffie, Hellman, and Merkle, formed Public Key Partners to license the various public key, digital signature, and RSA patents. These patents, granted in the early 1980s, expire in the between 1998 and 2002. PKP has licensed RSA Data Security Inc., of Redwood City, CA, which handles the sales, etc. *** quantum cryptography -- a system based on quantum- mechanical principles. Eavesdroppers alter the quantum state of the system and so are detected. Developed by Brassard and Bennett, only small laboratory demonstrations have been made. *** reputations -- the trail of positive and negative associations and judgments that some entity accrues. Credit ratings, academic credentials, and trustworthiness are all examples. A digital pseudonym will accrue these reputation credentials based on actions, opinions of others, etc. In crypto anarchy, reputations and agoric systems will be of paramount importance. There are many fascinating issues of how reputation-based systems work, how credentials can be bought and sold, and so forth. *** RSA -- the main public key encryption algorithm, developed by Ron Rivest, Adi Shamir, and Kenneth Adleman. It exploits the difficulty of factoring large numbers to create a private key and public key. First invented in 1978, it remains the core of modern public key systems. It is usually much slower than DES, but special-purpose modular exponentiation chips will likely speed it up. A popular scheme for speed is to use RSA to transmit session keys and then a high-speed cipher like DES for the actual message text. *** Description -- Let p and q be large primes, typically with more than 100 digits. Let n = pq and find some e such that e is relatively prime to (p - 1)(q - 1). The set of numbers p, q, and e is the private key for RSA. The set of numbers n and e forms the public key (recall that knowing n is not sufficient to easily find p and q...the factoring problem). A message M is encrypted by computing M^e mod n. The owner of the private key can decrypt the encrypted message by exploiting number theory results, as follows. An integer d is computed such that ed =1 (mod (p - 1)(q - 1)). Euler proved a theorem that M^(ed) = M mod n and so M^(ed) mod n = M. This means that in some sense the integers e and d are "inverses" of each other. [If this is unclear, please see one of the many texts and articles on public key encryption.] *** secret key cryptosystem -- A system which uses the same key to encrypt and decrypt traffic at each end of a communication link. Also called a symmetric or one-key system. Contrast with public key cryptosystem. *** smart cards -- a computer chip embedded in credit card. They can hold cash, credentials, cryptographic keys, etc. Usually these are built with some degree of tamper- resistance. Smart cards may perform part of a crypto transaction, or all of it. Performing part of it may mean checking the computations of a more powerful computer, e.g., one in an ATM. *** spoofing, or masquerading -- posing as another user. Used for stealing passwords, modifying files, and stealing cash. Digital signatures and other authentication methods are useful to prevent this. Public keys must be validated and protected to ensure that others don't substitute their own public keys which users may then unwittingly use. *** steganography -- a part of cryptology dealing with hiding messages and obscuring who is sending and receiving messages. Message traffic is often padded to reduce the signals that would otherwise come from a sudden beginning of messages. *** symmetric cipher -- same as private key cryptosystem. *** tamper-responding modules, tamper-resistant modules (TRMs) -- sealed boxes or modules which are hard to open, requiring extensive probing and usually leaving ample evidence that the tampering has occurred. Various protective techniques are used, such as special metal or oxide layers on chips, armored coatings, embedded optical fibers, and other measures to thwart analysis. Popularly called "tamper-proof boxes." Uses include: smart cards, nuclear weapon initiators, cryptographic key holders, ATMs, etc. *** tampering, or active wiretapping -- interfering with messages and possibly modifying them. This may compromise data security, help to break ciphers, etc. See also spoofing. *** token -- some representation, such as ID cards, subway tokens, money, etc., that indicates possession of some property or value. *** traffic analysis -- determining who is sending or receiving messages by analyzing packets, frequency of packets, etc. A part of steganography. Usually handled with traffic padding. *** transmission rules -- the protocols for determining who can send messages in a DC protocol, and when. These rules are needed to prevent collision and deliberate jamming of the channels. *** trap messages -- dummy messages in DC Nets which are used to catch jammers and disrupters. The messages contain no private information and are published in a blob beforehand so that the trap message can later be opened to reveal the disrupter. (There are many strategies to explore here.) *** trap-door -- In cryptography, a piece of secret information that allows the holder of a private key to invert a normally hard to invert function. *** trap-door one way functions -- functions which are easy to compute in both the forward and reverse direction but for which the disclosure of an algorithm to compute the function in the forward direction does not provide information on how to compute the function in the reverse direction. More simply put, trap-door one way functions are one way for all but the holder of the secret information. The RSA algorithm is the best-known example of such a function. *** unconditional security -- same as information- theoretic security, that is, unbreakable except by loss or theft of the key. *** unconditionally secure -- where no amount of intercepted ciphertext is enough to allow the cipher to be broken, as with the use of a one-time pad cipher. Contrast with computationally secure. *** voting, cryptographic -- Various schemes have been devised for anonymous, untraceable voting. Voting schemes should have several properties: privacy of the vote, security of the vote (no multiple votes), robustness against disruption by jammers or disrupters, verifiability (voter has confidence in the results), and efficiency. *** zero knowledge proofs -- proofs in which no knowledge of the actual proof is conveyed. Peggy the Prover demonstrates to Sid the Skeptic that she is indeed in possession of some piece of knowledge without actually revealing any of that knowledge. This is useful for access to computers, because eavesdroppers or dishonest sysops cannot steal the knowledge given. Also called minimum disclosure proofs. Useful for proving possession of some property, or credential, such as age or voting status, without revealing personal information. -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at 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^756839 | PGP Public Key: by arrangement. From tcmay at netcom.com Sun Nov 22 12:15:22 1992 From: tcmay at netcom.com (Timothy C. May) Date: Sun, 22 Nov 92 12:15:22 PST Subject: The Crypto Anarchist Manifesto Message-ID: <9211222011.AA29961@netcom.netcom.com> Cypherpunks of the World, Several of you at the "physical Cypherpunks" gathering yesterday in Silicon Valley requested that more of the material passed out in meetings be available electronically to the entire readership of the Cypherpunks list, spooks, eavesdroppers, and all. Here's the "Crypto Anarchist Manifesto" I read at the September 1992 founding meeting. It dates back to mid-1988 and was distributed to some like-minded techno-anarchists at the "Crypto '88" conference and then again at the "Hackers Conference" that year. I later gave talks at Hackers on this in 1989 and 1990. There are a few things I'd change, but for historical reasons I'll just leave it as is. Some of the terms may be unfamiliar to you...I hope the Crypto Glossary I just distributed will help. (This should explain all those cryptic terms in my .signature!) --Tim May ................................................... The Crypto Anarchist Manifesto Timothy C. May tcmay at netcom.com A specter is haunting the modern world, the specter of crypto anarchy. Computer technology is on the verge of providing the ability for individuals and groups to communicate and interact with each other in a totally anonymous manner. Two persons may exchange messages, conduct business, and negotiate electronic contracts without ever knowing the True Name, or legal identity, of the other. Interactions over networks will be untraceable, via extensive re- routing of encrypted packets and tamper-proof boxes which implement cryptographic protocols with nearly perfect assurance against any tampering. Reputations will be of central importance, far more important in dealings than even the credit ratings of today. These developments will alter completely the nature of government regulation, the ability to tax and control economic interactions, the ability to keep information secret, and will even alter the nature of trust and reputation. The technology for this revolution--and it surely will be both a social and economic revolution--has existed in theory for the past decade. The methods are based upon public-key encryption, zero-knowledge interactive proof systems, and various software protocols for interaction, authentication, and verification. The focus has until now been on academic conferences in Europe and the U.S., conferences monitored closely by the National Security Agency. But only recently have computer networks and personal computers attained sufficient speed to make the ideas practically realizable. And the next ten years will bring enough additional speed to make the ideas economically feasible and essentially unstoppable. High-speed networks, ISDN, tamper-proof boxes, smart cards, satellites, Ku-band transmitters, multi-MIPS personal computers, and encryption chips now under development will be some of the enabling technologies. The State will of course try to slow or halt the spread of this technology, citing national security concerns, use of the technology by drug dealers and tax evaders, and fears of societal disintegration. Many of these concerns will be valid; crypto anarchy will allow national secrets to be trade freely and will allow illicit and stolen materials to be traded. An anonymous computerized market will even make possible abhorrent markets for assassinations and extortion. Various criminal and foreign elements will be active users of CryptoNet. But this will not halt the spread of crypto anarchy. Just as the technology of printing altered and reduced the power of medieval guilds and the social power structure, so too will cryptologic methods fundamentally alter the nature of corporations and of government interference in economic transactions. Combined with emerging information markets, crypto anarchy will create a liquid market for any and all material which can be put into words and pictures. And just as a seemingly minor invention like barbed wire made possible the fencing-off of vast ranches and farms, thus altering forever the concepts of land and property rights in the frontier West, so too will the seemingly minor discovery out of an arcane branch of mathematics come to be the wire clippers which dismantle the barbed wire around intellectual property. Arise, you have nothing to lose but your barbed wire fences! -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at 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^756839 | PGP Public Key: by arrangement. From amb at cs.columbia.edu Mon Nov 23 02:02:28 1992 From: amb at cs.columbia.edu (andrew m. boardman) Date: Mon, 23 Nov 92 02:02:28 PST Subject: The legality of PGP In-Reply-To: <9211201648.AA19486@newsu.shearson.com> Message-ID: <9211230949.AA13573@shadow.cs.columbia.edu> >I wonder--I have RSA Mailsafe. Do you think that would give me a license >to use RSA if I loaded up PGP? Keith Doubtful -- RSA tends to be licensed on a per application per copy basis, not on a per human basis. If it was licensed on a per-human basis, I would have bought a personal "unlimited use" license long ago. Well, they sell licenses for RC2 and RC4 for $100 per, which are on a per-person basis. And something said to me at Weenix Expo by an RSA salesdroid implied that $100 could get one a generic kind of RSA license. I didn't press the point, and I don't have anything in writing, but they're happy to talk at 415.595.8782 if you want better than unsubstantiated hearsay... I'd call myself if I was ever awake during PST business hours... andrew From crunch at netcom.com Mon Nov 23 02:17:59 1992 From: crunch at netcom.com (John Draper) Date: Mon, 23 Nov 92 02:17:59 PST Subject: Status on Mac PGP Message-ID: <9211231013.AA10065@netcom2.netcom.com> Greetings cypherpunks: Talked to Phiil Zimmerman on phone this evening, and he recommends that the current Mac team be devided up into teo parts. One a short term team which no doubt will be what exists already, and a long term team to do a more Mac'ish GUI. I agreed to do that, and Phil is planning to set up a phone conference call with the entire Mac PGP team to introduce the new proposals to everyone at once. this meeting will happen sometime early this week, and I'll be giving reports on what has transpired. I also sent to each of the Mac PGP members the details of the cypherspace meeting, but have not yet mentioned my proposal to help manage the team, as I want to meet everyone first. I also agreed to make up a function list of the C functions in the PGP program (Which I usually do when I study new code), and will send it to anyone who wants it. Oh!! By the way, If I start up the existing Mac PGP, running Microphone II at the same time. Then, when I encrypt a file, it hangs up the system. This only hangs up when I decrypt a file first, then I go into editor to edit a file, and save it. After saving the plaintext file, then I encrypt it, it will hang up the Mac and needs resetting. It requires a COLD boot, and not a simple reset. Has anyone else experienced this problem? I suspect that a new version of Mac PGP might soon become available. Hmmm I must start thinking of what the ICON should look like!! More later.... John D. From eichin at cygnus.com Mon Nov 23 12:17:13 1992 From: eichin at cygnus.com (Mark W. Eichin) Date: Mon, 23 Nov 92 12:17:13 PST Subject: Status on Mac PGP In-Reply-To: <9211231013.AA10065@netcom2.netcom.com> Message-ID: <9211232016.AA12371@tweedledumber.cygnus.com> >> short term team which no doubt will be what exists already, and I assume you already know that a Mac PGP exists? I didn't mention it before because the discussion seemed to be about doing a "real" version. mac.archive.umich.edu:mac/util/encryption/macpgp2.0.sit.hqx is the path. It is still there right now... _Mark_ % ftp mac.archive.umich.edu Connected to mac.archive.umich.edu. 220- 220- Welcome to 220- the U of M Software Archives 220- 220- 220 carpediem.ccs.itd.umich.edu FTP server (Version 6.9 Thu Oct 15 23:44:46 EDT 1992) ready. Name (mac.archive.umich.edu:eichin): ftp 331 Guest login ok, send e-mail address as password. Password: 230-Please read the file 00readme.txt 230- it was last modified on Tue Nov 17 22:08:12 1992 - 6 days ago 230 Guest login ok, access restrictions apply. ftp> cd mac 250- 250-Please read the files in /mac/00help if you have problems. 250- 250 CWD command successful. ftp> cd util 250 CWD command successful. ftp> cd encryption 250 CWD command successful. ftp> dir 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. total 364 drwxrwxr-x 2 20020 staff 2048 Dec 31 1991 .AppleDouble -rw-rw-r-- 1 25319 staff 54788 Oct 13 05:42 crypto1.23.cpt.hqx -rw-rw-r-- 1 20062 staff 19987 Feb 6 1991 des.hqx -rw-rw-r-- 1 25319 staff 56824 Nov 14 08:55 enigma1.1.sit.hqx -rw-rw-r-- 1 20062 staff 26227 Feb 1 1992 leescrypto1.2.cpt.hqx -rw-rw-r-- 1 23424 staff 210389 Oct 30 19:45 macpgp2.0.sit.hqx 226 Transfer complete. 439 bytes received in 0.21 seconds (2 Kbytes/s) ftp> From fnerd at smds.com Mon Nov 23 14:40:40 1992 From: fnerd at smds.com (FutureNerd Steve Witham) Date: Mon, 23 Nov 92 14:40:40 PST Subject: Hackers, Crackers Message-ID: <9211232221.AB05926@smds.com> >Let's cut out this elitist "crackers" crap altogether. >It's just a little bit too PlaySkool, a little bit too >"_I'm_ not a third grader! I'm a _fourth grader_!" The people >who put so much energy into advertising how they're different >tend not to know what the fuck they're talking about, in >my experience. Well, I don't know about this guy, but there's something similar that occurred to me during the hackers conference. Some of the people on this list heard me express it badly, and I wanted to clarify. We always used to distinguish hackers from crackers. But cracking reveals the cracks in a way that nothing else does. It makes them real, sometimes laughably or painfully so. Electronic privacy is currently a joke. It's bad. You need to know what kinds of attacks you're trying to defend against. I used to think those arguments were rationalizations. Now I'm glad there are people who know this stuff, who are actually doing it. Some of "them" are on what I think of as the good side, and "we" need that kind of knowledge, if only as an occasional splash of cold water, a spur (to switch metaphorical, er, horses in mid, um, stream). -fnerd quote me fnerd at smds.com (FutureNerd Steve Witham) From fnerd at smds.com Tue Nov 24 11:06:50 1992 From: fnerd at smds.com (FutureNerd Steve Witham) Date: Tue, 24 Nov 92 11:06:50 PST Subject: Remailer ideas Message-ID: <9211241849.AB05399@smds.com> Tom.Jennings at f111.n125.z1.FIDONET.ORG sez >Well, remailers are working, admittedly a bit clunky at the moment, Okay, here's something easy to implement: a "From: stripper" specifically for the cypherpunks address, like, cypherpunks-anon at toad.com . The point is that all you have to do to use it is to have the address. The same for the following ideas: Harder: something that takes mail to arbitrary "user ids" at its machine and remails based on them, so you could send to me at, say, sw%%smds.com at remailer.somewhere.com . Harder: take a long encrypted address as the user id. Do mail systems allow arbitrary length user ids? Anyway, you'd be mailing to things like: wjefa248hap94ghs39p8g4s9perspe98b9p08serhg9p8serh9sherp9hse9rp89sper898psexrg99p8ser989regp9ser9pys98per9pse8ry9p8sxyer9p8yser9p8ys9per8p9se8ry9pseyr8sezrpahw4pwa49nw84th9w8y34w456yuvw05536vue4w5vw38064vw306uw45 at remailer.somewhere.com I realize these things have weaknesses beyond the kazoo, but wadaya think? -fnerd fnerd at smds.com (FutureNerd Steve Witham) From tcmay Tue Nov 24 11:44:08 1992 From: tcmay (Timothy C. May) Date: Tue, 24 Nov 92 11:44:08 PST Subject: Scenario for a Ban on Cash Transactions Message-ID: <9211241944.AA16548@netcom.netcom.com> SCENARIO FOR A BAN ON CASH TRANSACTIONS The recent discussions about black markets, loss of tax revenues, and restrictions on the use of encryption lead me to speculate that moves may be afoot to ban or severely restrict the use of cash. Such talk of a "cashless society" comes up periodically, with some taking a religious/conspiratorial view (electronic bank accounts tatooed on our foreheads, fulfilling the "mark of the Beast" prophecy) and others talking about how the "international bankers" have already selected a system (to be implemented in a national emergency, perhaps an Emergency Order following a series of bank collapses). Some putative benefits of banning cash and replacing it with electronic versions (such as debit cards, either privately issued or issued by the government): 1. Faster and more complete tax collection, with the tax authorities and implicit partner in all economic transactions (save for black markets, but I'll discuss that later). The "faster" part will be a one-shot gain, just as the witholding tax system instituted in WWII as an emergency program was a one-shot benefit. But such an immediate gain may be quite attractive to planners faced with rapidly escalating national debt. ($4.5 trillion, increasing by at least $400 billion a year...more if the "IOUs" for social security are considered) The "more complete" part will be an attempt to recapture taxes now lost to the underground, or barter, economy. "Serious" black marketeers, or dealers in illegal substances, will of course not be greatly affected, but a shift to purely electronic money will hurt their ability to move money (unless they control the banks and S&Ls, as may be the case....but that's another story). 2. A general closing of the underground economy, separate from the issue of recapturing lost tax revenues. As the underground economy increases, especially to the levels seen in other countries, pressures to "close the loopholes" (= cash) may mount. The failing "War on Drugs" has already been used to justify many serious abridgements of basic rights; applying the same logic to creating a cashless society seems to be the next step. 3. "Welfare reform" by restricting the allowable expenditures that can be made. For example, a welfare, food stamp, or AFDC recipient could be barred from buying liquor with his or her "money." Electronic money need not be "fungible," in the sense that all forms are interchangeable--it is fairly easy to attach various restrictions to the electronic databases which hold the money. Such restrictions would meet with a lot of popular support, and so could undercut the protests a bit. (Support may also come from the "national identity card" aspects, as such a card would help to solve the problem of illegal immigrants and those who move to jurisdictions with better welfare benefits. I'm not _approving_ of this, merely pointing out a source of support for "welfare cards.") (Bypasses can still be done, as with food stamps which are sold in exchange for booze. Ironically, the flourishing black market in food stamps is a motivation for going to an "electronic welfare card," which is being talked about and which is an obvious precursor step to the eventual ban on paper money cash.) 4. Fears of the growing ease of counterfeiting may push this shift along. Color copiers are now so good that nearly undetectable counterfeiting of U.S. currency is straightforward. Attempts to embed conductive threads, holograms, etc., are helping, but the longterm future is not bright for physical money (excluding gold, which has its own problems that I won't discuss here). (Note that foreign printing presses can quite easily produce excellent counterfeit currency, for use in destabilizing foreign regimes, in economic warfare, etc. Apparently the U.S. has supported the flooding of Iraq with counterfeit currency. And Iraq has supposedly printed vast amounts of counterfeit U.S. and European currency. Digital money, cryptographically protected, is about the only protection against this threat.) 5. If the government controls and sets the protocols for electronic money, this gives them de facto control over encryption systems and protocols. Use of non-approved protocols may be considered ipso facto proof of money laundering, black marketeering, and tax evasion. The Dennning/Rivest key registration proposal appears to be some advance planning for creating a system in which the government is effectively a third party in all communications (= transactions). I suggest we look at all such key registration proposals in this light. 6. More speculatively, the elimination of cash may be used to prop up U.S. banks, which many feel are facing a rocky future. By making the banks the "mediators" of such a government-mandated electronic money system, this both "privatizes" the system and provides a new revenue stream for these powerful lobbying interests. For example, your local bank may issue the debit card and may take, say, 0.5% of every transaction. The government might then take, say, 3% of every transaction as its "cut." (The actual details are likely to be hideously complex, along the lines of the V.A.T. taxes of Europe, and so this example should only be taken as a rough example of what could happen.) Now it has long been clear to me that the future of money lies in electronic form, cryptographically protected. The prolific use of credit cards for mail-order purchases points to the need for a purely electronic form of usable money, as do systems like AMIX (which uses VISA-type credits and debits). The issue is who creates this system, and what controls exist. It seems unlikely that the U.S. government will allow "competing currencies" (one form of digital money, and arguably what we already have with various tradable financial instruments, which rise and fall in value depending on various forces) to spring into being, at least not in forms that are truly like cash. However, if the government creates this cashless society, then the government will have unprecedented control over nearly all aspects of our lives. All transactions, no matter how trivial, will be recorded, stored, and subject to analysis. A complete audit trail of all purchases, food preferences, entertainment choices, liasons with others, etc., will exist. This is the concern David Chaum has eloquently raised, and which he has been dealing with (partially) with his digital money and untraceable transactions systems. Furthermore, transactions which are deemed to be politically incorrect, and there are dozens of obvious examples to choose from, can be _outlawed_ by the mere typing of a few lines of instructions into the appropriate data bases. (For example, someone arrested for DUI tries to buy some beer..."Your transaction cannot be completed. Have a nice day." appears on the cash register. Or a pregnant woman--and under Clinton's computerized health care system this will all be known--tries to buy some cigarettes....) Reread John Brunner's amazingly prescient "Shockwave Rider" for some visions of a fully-computerized society. This trend toward a cashless society, controlled by the government, represents the greatest threat to our libery and our future I can imagine. We need to start planning to head this off. Those interested in "crypto anarchy" as one technological solution are encourage to get in touch with me. (I now have MacPGP, which makes things slightly easier than before, but it's still a pain to download files and decrypt them. The anonymous remailer services discussed on the "Cypherpunks" list should help as well.) Make no mistake, a government-run cashless society will be worse that Orwell's worst. --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at 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^756839 | PGP Public Key: by arrangement. From tcmay at netcom.com Tue Nov 24 11:58:48 1992 From: tcmay at netcom.com (Timothy C. May) Date: Tue, 24 Nov 92 11:58:48 PST Subject: Scenario for a Ban on Cash Transactions Message-ID: <9211241954.AA17648@netcom.netcom.com> Cypherpunks of the World, I'm relatively convinced that the various "trial balloons" for restricting the use of encryption are part and parcel of a larger, albeit not formally discussed, plan to adopt some form of a digital cash system. Before your start cheering, it is highly unlikely that this system will the "digital cash" system of the form we have been discussing (anonymous transactions, untraceability, David Chaum-style systems, etc.). My grim scenario is contained in the message below, which I just posted to another list, the "Extropians" list. --Tim May Forwarded message: From julian at panix.com Tue Nov 24 13:47:22 1992 From: julian at panix.com (Julian Dibbell) Date: Tue, 24 Nov 92 13:47:22 PST Subject: Mailing-list Message-ID: <9211242017.AA21820@panix.com> Can you add me to the cypherpunks mailing list? --Julian Dibbell, julian at panix.com (Steven Levy and/or Tim May may [or may not] vouch for my worthiness, as necessary) From UFLTAI%MEMSTVX1.bitnet at CUNYVM.CUNY.EDU Tue Nov 24 14:57:29 1992 From: UFLTAI%MEMSTVX1.bitnet at CUNYVM.CUNY.EDU (Fan Li TAI) Date: Tue, 24 Nov 92 14:57:29 PST Subject: Question about the MacPGP Message-ID: <9211242257.AA21968@toad.com> Hiya, About the MacPGP, isn't it possible to sort of write a script addon to the various telecoms software? What I mean is that when you start reading mail, you click somewhere, and all input from the modem is translated direct by the script so that you can read the plaintext. But when you reply, you will have to use the telecoms' editor and upload the text... Somewhat like that rot13 thing in news really (or the VMS implemantation of it). Ciao. -Tai From DELTORTO at AppleLink.Apple.COM Tue Nov 24 16:36:01 1992 From: DELTORTO at AppleLink.Apple.COM (Imaja, David Del Torto,PAS) Date: Tue, 24 Nov 92 16:36:01 PST Subject: virgin key Message-ID: <722650089.8392816@AppleLink.Apple.COM> Greetings CypherFolk, I'm still in Europe, researching combinations of sleep deprivation and extended train travel, but the time for return to sf.ca.us is drawing closer. I'm still temporarily off the c-punks mail alias due to technical/fiscal reasons so buzz me directly at until January 93. Appended below is my brand-spankin'-new 512-bit public key. Give it a workout so I can see if it works (out). I have an interesting keyring from over here if anyone is interested. Will attend meeting anytime in '93 if I'm notified so we can pass the baton -er- floppy. dave del torto -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQBNAisMWqcAAAECALhs0wMpfVaVFIP/pk3MouI7X8sqpbB6eKiCoVPWBAOeMhB3 bOE8gibIgx5Gg+yTTmp5WOBXzmqmN8s2NPwzoIMABRG0LkRhdmlkIERlbCBUb3J0 byA8ZGVsdG9ydG9AYXBwbGVsaW5rLmFwcGxlLmNvbT4= =cnh0 -----END PGP PUBLIC KEY----- From dkrieger at netcom.com Tue Nov 24 17:01:11 1992 From: dkrieger at netcom.com (David Krieger) Date: Tue, 24 Nov 92 17:01:11 PST Subject: One Mac feature I'd like Message-ID: <9211250057.AA08182@netcom2.netcom.com> John -- While using MacPGP yesterday, I thought of a useful feature that (I hope) wouldn't be too hard to implement -- the ability to encrypt to/ decrypt from the Clipboard. This would eliminate the need for saving one's text as a file in order to use PGP... one could Copy text from any text application, open PGP, encrypt it in the Clipboard, and switch to a terminal program to Paste it to a host for mailing... or, one could Copy ciphertext from the terminal program and decrypt it from the Clipboard. dk -- From tcmay at netcom.com Tue Nov 24 17:54:15 1992 From: tcmay at netcom.com (Timothy C. May) Date: Tue, 24 Nov 92 17:54:15 PST Subject: The List is YOURS, So Speak Up! Message-ID: <9211250150.AA12171@netcom2.netcom.com> Lurking Cypherpunks, My message earlier today on a scenario for the banning of cash led to about 10 responses mailed to me in private e-mail. Typical is the following (the author has been deleted, as he chose not to post it to the list as a whole): "I'm interested. I was considering removing myself from the cyberpunks list, because the traffic/info. ratio is too high (low?).. I'm glad I didn't, because your message is the type of thing I joined the list to read. I don't suppose there somewhere where I can get a 'condensed version' of the cyberpunks list, or something similar? "I've heard a bit about "crypto anarchy" (only from cyberpunks mailing list), and i'm interested. What's the next step?" You folks out there ARE the list! If there's something you want discussed, go ahead and start a new thread. Raise some issues, stir up some shit. It seems from some of the messages I got today that people think they either have little to add to the discussion, or are fearful of the consequences of posting their comments to a list such as ours. About the former point, all I can say is that the best learning comes from arguing a position and learning to defend it. Merely _posting_ a message generates added interest and piquancy about the list, I've discovered. So consider this an invitation to the hundred or so folks who have yet to post on this list! For those who are paranoid, well, chances are They already know who you are. They have files on you. Remember this, * It is not illegal to advocate violence. AND * it is not illegal to advocate the overthrow of the government. HOWEVER, * it _is_ illegal to advocate the overthrow of the government by violent means. If you stay away from this last item, you're relatively safe. (Even advocating drug use has not seemed to have much effect on the posters on alt.drugs.) In any case, the work being done by Eric Hughes, Hal Finney, and others, should give us fully anonymous posting capabilitites in the near future. Even with digital pseudonyms! (Check out the postings of "Cassandra" and "Pollyanna" for starters.) If the socioeconomic aspects of crypto anarchy interest you more than, say, discussions of random number generators, then clearly you should _post_ on those topics! And if all you have are _questions_, then by all means ask them! Those of us who post frequently on this list cannot try to anticipate your questions and concerns. I've been spouting this stuff for years and they haven't taken me away yet, nor have they [TRANSMISSION HALTED BY ORDER OF THE CRYPTO AUTHORITY] -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at 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^756839 | PGP Public Key: by arrangement. From eichin at cygnus.com Tue Nov 24 18:02:57 1992 From: eichin at cygnus.com (Mark W. Eichin) Date: Tue, 24 Nov 92 18:02:57 PST Subject: DC-NETS & bibliography request Message-ID: <9211250202.AA11244@tweedledumber.cygnus.com> This list is the first place I'd seen references to DC-NETS; thanks for the glossary posting explaining what the term is. Is there a published paper on them, or somewhere else I can get info on the algorithms involved? On a related note, is there a "crypto anarchy reading list" or bibliography that anyone has collected, for further delving into the terms brought up? I suspect many of the better references would only be available in electronic form, but they should still be listed... _Mark_ MIT Student Information Processing Board Cygnus Support From strat at intercon.com Tue Nov 24 18:16:51 1992 From: strat at intercon.com (Bob Stratton) Date: Tue, 24 Nov 92 18:16:51 PST Subject: The List is YOURS, So Speak Up! Message-ID: <9211242116.AA28432@horton.intercon.com> Hi all, After Tim's stirring message about the use of the list, I couldn't help but drop a line to the list myself. I'm yet another person interested in Mac implementations of PGP, and encrypted mailers. I work for a Macintosh software company as a developer, but have spent most of the last several years working with big machines, so I haven't picked up all of the bad habits that I see Macs furthering across the Net. (Most of these have to do with writing unportable code, as if no other manufacturers' hardware matters.) I'm also sort a mailer weenie, so this talk of encrypted mailers has me quite interested. I've started studying more of the fundamentals (I've only read David Kahn's book, back in 8th grade, which was a while ago :-) I'm especially interested in the MIME/PEM issues, and fervently request coredumps from anyone who's been following those to date. My company (which I DO NOT speak for) develops TCP/IP based communications software for the Mac, so needless to say, a nice RSA-encrypted Mac mailer could fall within our purview. My company is also very interested in privacy issues. In point of fact, the VP of Engineering and I recently addressed a Virginia state assembly subcommittee for purposes of having them remove SSNs from driver's licenses.. (YAY!) I'm new to tbe Mac world, but not the mailer world. I shall try to be a resource for this list's work. There's another person here who's also interested in the GUI design for a new Mac incarnation of PGP. I see a couple of possible UI features: - Live folders, for drag and drop en/decryption - Encryption to/from the clipboard (which is basically what I'm doing now, except through intermediate files) - An MPW tool implementation, with pipes. (I suspect that I'd use this mostly for testing the 'engines') I want to reiterate the sentiment posted by several to KEEP THINGS PORTABLE. I know it's not chic for a Mac developer to say that, but so be it. Bob Stratton Engineer, InterCon Systems Corp. +1 703 709 5525 "The Constitution's not perfect, but it's a damn sight better than what we have now." From tcmay at netcom.com Tue Nov 24 18:24:38 1992 From: tcmay at netcom.com (Timothy C. May) Date: Tue, 24 Nov 92 18:24:38 PST Subject: DC-NETS & bibliography request In-Reply-To: <9211250202.AA11244@tweedledumber.cygnus.com> Message-ID: <9211250220.AA14681@netcom2.netcom.com> Reading Material: > This list is the first place I'd seen references to DC-NETS; thanks > for the glossary posting explaining what the term is. Is there a > published paper on them, or somewhere else I can get info on the > algorithms involved? > On a related note, is there a "crypto anarchy reading list" or > bibliography that anyone has collected, for further delving into the > terms brought up? I suspect many of the better references would only > be available in electronic form, but they should still be listed... > > _Mark_ > MIT Student Information Processing Board > Cygnus Support The article I posted, and the article Hal Finney posted, contains references to the original DC-Net paper. It was in the Journal of Cryptology, Volume I, Number 1. Only a very large university library will carry it. (My nearest university, UC Santa Cruz, does _not_. I subscribed for a while, because of attending the Crypto '88 conference, and so I was able to include this seminal paper in the Xeroxed handout for the attendees at our first Cypherpunks meeting. I regret that I cannot mail anymore copies to people. If you are really interested in DC-Nets, read the posted articles first and then you'll surely find a way to get the journal articles.) The standard sources for modrern crypto are the proceedings each year of the "Crypto" and "EuroCrypt" conferences. Also, at least half a dozen good books have been written, some of which have been mentioned in earlier postings. And Fen Le Balme posted his won search list a few weeks ago. At some point an FAQ and bibliography list will exist (I am not maintaing the FAQ or the bibio, though). Here's a typical reference: 16. CRYPTO '91 (1991 : University of California, Santa Barbara) Advances in cryptology--CRYPTO '91 : proceedings / J. Feigenbaum (ed.). Berlin ; New York : Springer-Verlag, c1992. Series title: Lecture notes in computer science ; 576. UCB Engin QA76.9.A25 C79 1991 UCD Phys Sci QA267.A1 L43 no.576 UCI Main Lib QA76.9.A25 C79 1991 UCLA Engr/Math QA 76.9 A25 C79 1991 UCR Rivera QA76.9.A25 C79 1991 UCSB Library QA76.9.A25 C79 1991 Sci-Engrg UCSC Science QA76.9.A25C79 1991 UCSD S & E QA76.9.A25 C79 1991 The books in the "QA76.9.A25" section (Library of Congress numbering of course) will provide pointers. Sadly, there are no "Neat Crypto Ideas for the Casually Interested" books. Some of us have debated writing such a book for Loompanics Press. --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at 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^756839 | PGP Public Key: by arrangement. From tribble at xanadu.com Tue Nov 24 19:03:37 1992 From: tribble at xanadu.com (E. Dean Tribble) Date: Tue, 24 Nov 92 19:03:37 PST Subject: Hackers, Crackers We always used to distinguish hackers from crackers. But cracking reveals the cracks in a way that nothing else does. It makes them real, sometimes laughably or painfully so. Electronic privacy is currently a joke. It's bad. You need to know what kinds of attacks you're trying to defend against. I used to think those arguments were rationalizations. Now I'm glad there are people who know this stuff, who are actually doing it. Some of "them" are on what I think of as the good side, and "we" need that kind of knowledge, if only as an occasional splash of cold water, a spur (to switch metaphorical, er, horses in mid, um, stream). In-Reply-To: <9211232221.AB05926@smds.com> Message-ID: <9211250220.AA26816@xanadu.xanadu.com> And if I shoot you or poison you, I will have vividly revealed to you your pathetic lack of physical defenses. Will I have done you a service? How about if I just break your windows or doors? That rationalization for crackers is based on the idea that perfect security is feasible. Once you view this from an economic perspective, then the only things the crackers do is raise the cost of getting to a level of security such that operation can continue uninterrupted. BTW: I happen to believe that within a trusted infrastructure, perfect security is possible. Even so, consider the cost of changing operating systems, retraining all staff, reproducing familiar applications on a new substrate. Even if perfect security is possible, the use of it is still bounded by economic and social concerns. dean BTW: feel free to forward to extropians. From tribble at xanadu.com Tue Nov 24 19:03:37 1992 From: tribble at xanadu.com (E. Dean Tribble) Date: Tue, 24 Nov 92 19:03:37 PST Subject: Remailer ideas In-Reply-To: <9211241849.AB05399@smds.com> Message-ID: <9211250223.AA26837@xanadu.xanadu.com> The mail handling stuff we discussed at the last cypherpunks meeting will implement what you requested. The particular thing that hadn't occurred to me in what you said is that a mailing list supplier could provide those extra services of anonymity in a way very accessible to users of the mailing list. That could make such anonymity slightly easier to spread. dean From tcmay at netcom.com Tue Nov 24 21:12:15 1992 From: tcmay at netcom.com (Timothy C. May) Date: Tue, 24 Nov 92 21:12:15 PST Subject: An Anonymous Contribution... Message-ID: <9211250508.AA01456@netcom.netcom.com> (The following message arrive in my mailbox, with a request to repost it anonymously. Sometimes these "manual" methods work pretty well! --Tim May) Tim, I have been following your arguments in CypherPunks. The name will turn off a lot of your natural friends, but your arguments are dead on. The Crux of the matter is digital cash. And getting these anonymous remailers working. PGP is a basic enabling thing. Not that RSA hasn't been around forever, but it just wasn't useable without a standard. My deepest gratitude to you and your friends. The remailer business needs to get standardized also. My personal hack is attached below. One problem not addressed in the first crop of remailers is the problem of how do you handle return paths. There are lots of trivial ways to get anonymous outgoing mail. Most telephone systems do not identify the caller, there are lots of other ways to get this function. But the problem is getting an answer back with out unmasking. The mathematicians may be able to conjure up a better scheme, but I see the backward security to be simply a matter of tearing the connection (return path down) faster than it can be backtraced. It would be nicer if some kind of DC-net return path could be devised. But timeout control will definitely work. With a large number of the forwaring nodes, and multi-hop paths, it would become quickly very impractical to shake down the originator, So the return path could be left "up" for quite some time before having to replace it. Certainly long enough for a reasonable reply. Better yet of cource would be a completely uncrackable return path that you could leave up long enough to use institutional advertising. Eg: run a business from. Another way to leave up long lasting connections (return paths) is to select one really HARD point node. This is the one they have to shake down first. And use continuously shifting paths behind that node. (all sounds like a router ? ) If you could repost this anonymously I sure would appreciate it. I am (ahem, respectable), and have some kids left to feed. Could you tell me how to find out more about David Chaum's work? do you have an email address for him, is he on one of the mailers, or have anything published? My hunch is that this whole business could heat up fast. Within just a few years the government could be forced into "wage/price" controls. A great application for the NREN? Thanks, xxxxxxxx at yyyyyy.zzz ---------Tear off ----- This is a proposal for a simple anonymous forwarding protocol. 1> With the exception of cases 4> and 5> below: Any message addressed to the forwarding node that does not contain a valid PGP encrypted block, encrypted with the node's public key causes the forwarding node to reply to the sender with its public key, plus whatever other text the node wishes to add. 2> If a properly encrypted message is decrypted with the node's secret key; The body of the decrypted message is scanned for the following sequence: "Please forward this message to:" FORWARD.ADDRESS "Thank you." The trigger strings are what is shown above in the quote marks but not including the quote marks. No actual quote marks are used. Everything after the period of the Thank you. string is forwarded to the address specified by the FORWARD.ADDRESS string. Messages not containing the forwarding request are presumed to be addressed to the node itself. 3> The incoming RETURN.ADDRESS and the FORWARD.ADDRESS are stored by the node. ---- Clean up. 4> Receipt of a message whose RETURN.ADDRESS matches a stored FORWARD.ADDRESS will be repeated without modification to the stored RETURN.ADDRESS associated with the stored FORWARD. ADDRESS. Bounced mail is returned similarly, 5> Receipt of a message whose RETURN.ADDRESS matches a previously stored RETURN.ADDRESS will cause a message to be forwarded to the previously stored FORWARD.ADDRESS If the incomming message in this case contains a valid encrypted block, It will be decrypted and forwarded. Otherwise, whatever contents of the body found will be forwarded. Subject lines should be repeated without modification. Null bodies or subject lines should work. 6> In both cases 4> and 5>, the stored RETURN/FORWARD addresses are erased. -xxxxxxx -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at 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^756839 | PGP Public Key: by arrangement. From nobody at alumni.cco.caltech.edu Tue Nov 24 22:12:47 1992 From: nobody at alumni.cco.caltech.edu (nobody at alumni.cco.caltech.edu) Date: Tue, 24 Nov 92 22:12:47 PST Subject: Extortion Explosion Message-ID: <9211250614.AA17663@alumni.cco.caltech.edu> Here's another thought about how crypto anonymity can improve public safety. Today, a lot of police activity is based on informants and "anonymous" tips. Policemen build up relationships with underworld characters who can give them information about criminal activity. In return, the police may offer favors, immunity from arrest, perhaps even cash or contraband in some instances. Some people have claimed that "anonymous sources" are an excuse sometimes used to cover up illegal police activity. An illegal wiretap is used to acquire information, then a warrant is obtained based on this information with the claim that it was actually acquired through an anonymous informant. With the warrant in place, the wiretap is now done legally, and evidence is produced which can be used in court. One problem with anonymous tips is that the people making them are taking a risk. If word gets out that a certain person tipped off the police to some criminal act, they may be targetted for revenge. Personal meetings between police and informers are often necessary (perhaps for payoffs to occur) and these are risky for all involved. Crypto anonymity could make anonymous informing easy and safe. Of course, not all tips would be valuable, but some fraction would be helpful in preventing crimes. Crypto pseudonyms and signatures could be used for informants to develop reputations so that those who have been accurate in the past will get the most attention. Digital cash could even be used for payoffs from cops to informants "under the table", with no need for dangerous face-to-face meetings. A system could even develop in which police would have to bring to a judge not just a blanket claim that there was an anonymous informant, but more substantial evidence, in the form of a digitally signed statement by a pseudonym known to have produced useful information in the past. This could reduce the problem of imaginary informants invented to excuse illegal police activity. Polyanna -----BEGIN PGP PUBLIC KEY BLOCK----- mQA9AisGm6sAAAEBgLsub7XIi32DjNFKJmGFajDNNIeql4RBmHG/mh9Ns58aBgMv wGRi0KkZ0YIYZZnLpwAFEbQkUG9seWFubmEsIGMvbyA8Y3lwaGVycHVua3NAdG9h ZC5jb20+ -----END PGP PUBLIC KEY BLOCK----- From yanek at novavax.nova.edu Tue Nov 24 23:13:08 1992 From: yanek at novavax.nova.edu (Yanek Martinson) Date: Tue, 24 Nov 92 23:13:08 PST Subject: RS232 Crypto Dongle (idea for widely accessible crypto technology) Message-ID: <9211250712.AA03659@novavax.nova.edu> A very useful device for people who can not trust the host they are talking to such as users of multiuser unix systems, or low security BBS systems, or "public access" workstations or PC-s, (this includes almost every single person that uses e-mail, except probably for users of a high-security mainframe communications system) would be an RS232 crypto "dongle" that would sit between the terminal (or modem) and the remote system. It would contain some tamperproof (write and decrypt only, can not be read out without a great deal of trouble) memory (as someone at the midnight crypto session at Hackers was talking about) for storage of the private key, some nonvolatile memory (flash eprom?) for the public key ring, and a processor to do the encryption/decryption. It would look (if all that can be fit into a small enough space) like a null modem or a gender changer. (or an RS232 break-out box). If crypto tech ever becomes illegal, it could even be disguised as one, with some special signal combination enabling the crypto function. It should also contain some out-of-band signal such as an LED to indicate that it is actually doing the decryption, instead of the host mimicking it. If introduced now or in near future, this device could become incredibly widespread, since most everybody that is accessing any form of e-mail goes at some point through an RS-232 link (either a terminal hanging off a terminal server, or a PC connected to a modem). Also, it would not require ANY special software on the host or the pc, nor any special terminal. Thus it would work with any of the great variety of e-mail and BBS sysetems that exist, instead of having to deal with each of them individually as a purely software-based approach would have to. It would also be completely independent of the type of computer/terminal or operating system used. You would send the usual mail command to the host, type the magic sequence to the encryption device (or even better, flip a little switch), and then type your message. The device would send to the host the ciphertext, while echoing the plaintext to your terminal so you can see what you are typing. The plaintext would never travel further than the RS232 connection between your terminal and the encryption device. When you receive an encrypted message, flip the switch on your device to "decrypt", and tell the host to send you the message. The host and any intervening networks would only see the ciphertext. The only place the decrypted text appears is on your terminal. I think this is as secure as you can get (until a decryption implant can be put in your head :-). Now, to allow the use of existing tools (pagers, editors, mailers, etc) the device should be completely transparent except when performing the crypto function. Even then, careful design should make it pretty transparent. For example if it passed all control characters intact, it could be used with a text editor that uses control key sequences for movement. It could be programmed for most common arrow key sequences, and for commands for editors such as EMACS, vi, etc, to pass them through unchanged. Same thing for receiving. When decrypting, it should pass through unchanged any characters passing through the other way, and should not interfere with terminal control characters, so any mail viewing program would not be affected. Additional functions it might include are generation and verification of signatures, an echo mode with decrypt/encrypt (so you could store the encrypted texts on your local drive, and to view would just "ascii upload" them to the device while in a comm program; also you could prepare the text of a message locally, while storing the encrypted text echoed back. Then you could upload the cyphertext to the system), a simple local editor and viewer, and anything else we have the ROM space for. Once the basic hardware is developed, there is nothing to stop one from including any desired features. Is anyone here already working on something like this? If not, is anyone interested in working with me on developing this kind of a device? I have the design pretty much thought out (this post is just a summary). I also have a clear picture of the prototyping and development process, and am capable of writing the software part. I would like to work with a partner who knows the hardware part of all this. I.E. the RS232/UART control, PCB layouts, that kind of stuff. Also, I know almost nothing about the technology of tamperproof memory storage. The main objective of this is not to make loads of money (though that would not hurt either) but to increase widespread accessibility and use of good crypto technology. So I would make the schematics and code available, in case anyone wants to be SURE and build one themselves. This could probably also be made available in kit form, that could be assembled by the user. (an interesting parrallel: this is how the personal computer was first distributed... look at the prevalence of PC use today!) This way they can be more sure that it does what it says it does. So, if you have read this far you are probably interested in this. PLEASE reply to me or to the list. If you are the person I am looking for to help with the development, please contact me soon, using one of the addresses or numbers listed in the signature. If you think you would be interested in buying or using such a device when it is ready, please let me know. If you have any improvements to the idea, or other comments, or reasons why you think this device would not be useful or could not work, please let me know too. Waiting for your feedback.... -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From yanek at novavax.nova.edu Tue Nov 24 23:33:02 1992 From: yanek at novavax.nova.edu (Yanek Martinson) Date: Tue, 24 Nov 92 23:33:02 PST Subject: possibility of a reply to an anonymous message In-Reply-To: <9211250508.AA01456@netcom.netcom.com> Message-ID: <9211250732.AA03979@novavax.nova.edu> > (The following message arrive in my mailbox, with a request to repost > it anonymously. Sometimes these "manual" methods work pretty well! If the person is not on the mailing list, please forward this to him/her/it? > lots of other ways to get this function. But the problem is getting > an answer back with out unmasking. This is not difficult at all, it just costs bandwidth. The basic idea is to anonymously post or mail a message, and at the end attach a public key, and the name of a public forum such as a usenet newsgroup. Then whoever wants to reply, will encrypt the message with the public key, and posts to the appropriate newsgroup. No-one but the poster of the original message can decrypt the reply. since everyone receives all the articles in the newsgroup, it is not possible to trace back who decrypted the message. > conjure up a better scheme, but I see the backward security to be > simply a matter of tearing the connection (return path down) faster > than it can be backtraced. It would be nicer if some kind of I would NOT rely on this under any conditions. This could only provide enough security that someone who is NOT interested in you can not trace you. Hey, for that kind of security you could use something like rot13... Anyone that is in the least interested, will immediately investigate the recent traffic at nodes the message went through. > definitely work. With a large number of the forwaring nodes, and > multi-hop paths, it would become quickly very impractical to shake > down the originator, So the return path could be left "up" for Unless someone really wants to. > for a reasonable reply. Better yet of cource would be a completely > uncrackable return path that you could leave up long enough to use > institutional advertising. Eg: run a business from. What I described above can work indefinitely (at least until your private key is compromised) > Another way to leave up long lasting connections (return paths) > is to select one really HARD point node. This is the one they Again, I would not use this approach. Such a node would become the target of concentrated penetration efforts and would break down sooner or later, and probably would remain operational, while logging all data. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From dclunie at pax.tpa.com.AU Wed Nov 25 00:03:49 1992 From: dclunie at pax.tpa.com.AU (David Clunie) Date: Wed, 25 Nov 92 00:03:49 PST Subject: CypherPunks Mailing list Message-ID: <9211250803.AA01586@britt> > From yanek at novavax.nova.edu Wed Nov 25 18:20:16 1992 > There always remains the issue of trust. How can I know that your system > has not been compromised, and is logging all in/out messages, and forwarding > them to FBI. This could be happening even without you knowing, for example > if "they" tap your network connection. Absolutely. This is a problem with any system that involves forwarding. For instance the currently proposed scheme advocates encrypting the address to be forwarded too, the remailer server still could have its mail tapped and the same correlation made. Of course my system seems much weaker in the sense that if the server is compromised the database is there for all to see. Of course the other system is just as weak in that if its server is compromised then someone can get the secret key that decrypts the addresses using the pass key from the automated software that does the decryption My objective was not to provide a high grade of anonymity, rather to enhance the functionality provided by existing anonymous services with privacy enhanced mail. Specifically to avoid sysadmins reading your anonymous replies which are often unsolicited and somewhat dubious or compromising. I think it achieves the objective but is clearly not going to sustain a concerted attack on the server by a knowledgeable assailant like the NSA or FBI or their equivalents in this country. To my knowledge, being very naive when it comes to encryption, the provision of anonymity which does not depend on a particular site to do the remailing (and is hence vulnerable as described) is much less straightforward, not to mention inconvenient. Perhaps I am overlooking something obvious to someone more knowledgeable. david From gg at well.sf.ca.us Wed Nov 25 01:24:26 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Wed, 25 Nov 92 01:24:26 PST Subject: Scenario for a Ban on Cash Transactions Message-ID: <199211250923.AA21269@well.sf.ca.us> Tim refers to Brunner's Shockwave Rider as "amazingly prescient." As he says of Brunner's diagnosis, so say I of Brunner's prescription. -gg From gg at well.sf.ca.us Wed Nov 25 02:03:52 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Wed, 25 Nov 92 02:03:52 PST Subject: Question about the MacPGP Message-ID: <199211251002.AA24840@well.sf.ca.us> re Tai's item about more user-friendly decryption on the Mac version.... Seems to me we need it for encryption as well... For instance, telecom software which allows you to back out into a screen editor where you write something and then encrypt it, and then get back to telecom and transmit the ciphertext directly. In my use of email, spontaneous mail and replies are vital. Having to go offline, go into WP, compose, go to crypto and encrypt, then go back to telecom, link up again, and transmit.... Holy cow, if that were a prescription for safe sex, it would be "Start a romantic evening. Just when you and your Love are sitting by the fire holding hands, get in the car, go to the drugstore and buy condoms. Then come back to where you've left your Love waiting by the fireplace, and try to get back in the romantic mood. Then before bedtime, walk around the house to make sure all the lights are off and the oven is off and the dog is in and the cat is out. Then retire for the night, and try to get the romantic mood going again, hoping that your Love hasn't fallen asleep while you were making your rounds..." Eee-yow, we can do better than that! -gg From gg at well.sf.ca.us Wed Nov 25 02:21:46 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Wed, 25 Nov 92 02:21:46 PST Subject: Extortion Explosion Message-ID: <199211251020.AA26264@well.sf.ca.us> Polyanna's item about crypto-anonymity protecting informants and background sources is most interesting. DEspite my dislike of spying, this idea sounds pretty decent. No invasions of privacy or civil rights are necessarily involved; infiltration is somehow not quite as awful as the spectre of mass surveillance (if nothing else it's labor intensive, which limits its use to substantial cases). And it might just get a lot of results. Might also lead to a lot of whistle-blowing on white collar baddies like the S&L fraudsters. Hey, long before Michael Milliken's name was in the media, I heard about his little fraud scheme from a fellow telecom technician who worked on the PBX in his office and got a whole lot first-hand from casual chat overheard in the office. Consider all the secretaries who know their bosses are cheating, ripping off, and all that. (Consider them dead if their crooked bosses ever go through the hard discs and find fragments of cleartext or even ciphertext hanging about: we need to educate the public on crypto protocol so people don't make dumb errors that may cost them dearly!) -gg From miron at extropia.wimsey.com Wed Nov 25 02:54:15 1992 From: miron at extropia.wimsey.com (Miron Cuperman) Date: Wed, 25 Nov 92 02:54:15 PST Subject: How far is to far? In-Reply-To: <199211211022.AA06269@well.sf.ca.us> Message-ID: <1992Nov25.101452.11440@extropia.wimsey.bc.ca> gg at well.sf.ca.us (George A. Gleason) writes: >Miron writes, >"Charge for the mix services with crypto money. The crypto money could be >some networking service..." >Only problem is, once we start anything like a formal barter system, it >comes under the IRS. The way to avoid that is to keep it a volunteer How do you think the IRS is going to trace those banks and customers behind all the anon mixes? -- Miron Cuperman | NeXTmail/mime ok | Public key avail AMIX: MCuperman | immortalcybercomputinglaissezfaire | From edgar at spectrx.Saigon.COM Wed Nov 25 03:28:55 1992 From: edgar at spectrx.Saigon.COM (Edgar W. Swank) Date: Wed, 25 Nov 92 03:28:55 PST Subject: SF Bay Area Parties Message-ID: Distribution: Cypherpunks Extropians Libernet Since all the above groups, of which I am a member, are not known for sponsoring social functions, I suggest we co-opt the Pen SFA parties. Their latest "Winnie" newsletter is attached. Please note and follow "rules". I especially recommend the 12/26 party. PGPers, bring your printed public keys for exchange. If you like these parties, please sign up for free E-Mail distribution of your own copy of the newsletter, as I will not post it every month. =================Copy of Newsletter follows========================== Date: Sat, 21 Nov 92 12:51:33 PST Subject: Winnie the POO #380 Winnie the POO #380, November 21, 1992 Published for the Peninsula Science Fantasy Association by its commander, Rich McAllister, 149 Webster St, Palo Alto, CA 94301. (415)328-2741. rfm at Eng.Sun.com. Winnies are available by US Mail at 5/$2, or via electronic mail (Internet/UUCP/CompuServe/FIDONET) free. If you're mailing payment make checks to Rich McAllister, or send stamps. I prefer stamps, so I'll give you one issue for each 29 cent stamp you send, and eat the repro cost myself. The number above your name on the label is the number of the last Winnie you will receive unless you Do Something. A 999 means you get Winnie by trade. PenSFA standard party rules: bring something edible or drinkable to share, or pay the host $2. Don't smoke in the house without checking with the host first. Normal start time is 8PM. NO SECOND NOVEMBER MEETING (11/28) We will not have a second November meeting because of Silicon. NOTE: SILICON IS NOT AT THE RED LION! (This seems to be a well kept secret.) Silicon is at the Westin Santa Clara. This is the hotel between Techmart and the Santa Clara Convention Center. (It used to be the Doubletree.) Take the Great America Parkway exit from 101, go past Great America; as soon as you cross the trolley tracks, you're there. Friday, Saturday, and Sunday. I probably won't be there to organize a PenSFA event. I suggest interested folks meet at 6PM Saturday in the lobby for a dinner expedition. FIRST DECEMBER MEETING (12/12) Party at Danny Low's, 1460 San Marcos Circle, Mtn. View. (415)964-0688. Standard time, 8PM, standard rules. Easy to find with a map. SECOND DECEMBER MEETING (12/26) Potluck at the home of Keith Henson and Arel Lucas, 1794 Cardel Way, San Jose, CA. (408)978-7616. 5PM start. Standard party/potluck rules: bring dinner and munchies/drinks if you come early, or just munchies/drinks if you come at 8PM. Keith offered to fire up the BBQ, weather permitting, but I wouldn't count on it. NEW DIRECTIONS (road construction has made the old directions obsolete.) Directions: From 280, take 17 south to Camden Ave exit. Go under freeway, follow Camden east. Turn south from Camden on Leigh, go two lights south to Los Gatos Almaden road, left and almost to where it ends in a T is Elrose. Left onto Elrose and another immediate left onto Cardel Way. We are near the end at 1794. NOT A DECEMBER MEETING (12/31) Mike Ward is having a New Year's party again, and again all PenSFAns are invited. 1181 Martin Drive, San Jose. 408-298-3269. Future Meetings: NOTHING SCHEDULED until 3/6-MIke Ward. As always, contact the Commander to take a date. -- edgar at spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca From mark at coombs.anu.edu.au Wed Nov 25 05:24:15 1992 From: mark at coombs.anu.edu.au (Mark) Date: Wed, 25 Nov 92 05:24:15 PST Subject: Secure PK swapping.. what are the methods? Message-ID: <9211251323.AA27604@coombs.anu.edu.au> Below is a letter Ive sent to a person designing a communications system similar to IRC but designed with the ability to be anonymous and as secure as possible. Further details will be announced soon when it's stable. --------------------Begin letter----------Begin letter------------------- Before you get too involved with the client in the comm system I was thinking of a way of having secure privmsgs, two forms depending on how open one chose to be: Messages are exchanged via UDP to hide from the netstat junkies... When someone does a msg the first time and the client doesnt know about that user it queries the server to either get a hostname/port pair for that user and/or a public key. The data is then stored in an internal attribute bank. Format of a private message: ._________________________________________________________. | Nickname Plaintext | dest IP | dest udp port | | =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= | | =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= | | =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= | `---------------------------------------------------------' [Return host/port/public key are encrypted into the PGP? message] The above message is then sent to the delivery module of the client. The above host and port are either the recipeints or the server's depending on what type of message is being sent. Thus the same message can go to the server or the recipient direct per se: 1) Using the hostname/port + public key for that user the sender's client encrypts the message and udp transmits a message to that port on the other users host. That remote client has set up a socket to listen on that udp port for messages. The remote client unpacks the message with it's private key and extracts the message, a reply host and port and the senders public key. He can then reply to the sender and they both can talk without loading down the server. Plus, unless someone is logging the ethernet, no one can ascetain wether they are talking. There is only the initial request of the users public key from the server which each client sends in automatically when it connects. You might also have an option in the client to auto download a block/all of the users nicks and their keys so no-one can detect the initial query of a user. 2) The other, differently secure :), form is because the server has been told to hide the users username + hostname from the /who information. All there exists for that person is a nickname and a public key. The senders client gets individually/block downloads the key he wants and proceeds to udp a message to the server which has the udp port and hostname of the recipient as normal from the client connect. It acts as IRC does now, as a middle man for messages. Less secure because the server admin can ascetain that there is a message being sent between the two people and also he can slip in his *OWN* keys to basically grab and decipher messages between the two parties. i.e he sends his own key to the sender and decrypts the incoming message and then sends the message out to the recipient using their encryption key. neither user could tell there was a switch in between. (There are schemes to get past this however). Both ways have their flaws because you are relying on the non-hackedness of the server to give you the right keys and hostnames and ports. A bad admin could easily, knowing enough about coding, disrupt the entire process if we didnt from the start ensure the right protocols were used. It has to be done right the first time or not at all. I'll echo this letter to a cryptography mailing list to ask for details of schemes that will allow each user to know they have a valid, secure public key of the other. One possible solution would be to do a mass query of all the online servers at once and if they didnt report the same keys sound a Real Big Alarm (tm). Maybe an automatom could sit there randomly checking keys :) (Can hear the cries of "No Bots.. No Bots" now :). (Note this allows *someone* to know your doing a query for a user... that may or may not bother the sender/recipient. Doing a block transfer from all the servers at once isnt net.nice) Comments? ------------------End of Letter----------------End of Letter---------------- Now what Im curious about is any other methods of secure key exchange where the exchange mid point may be lying about the keys, the hosts and the ports. Assume each person knows the others 'style' etc. How does one get the real keys to each other with an unreliable "medium"? (It might slip in it's PK). Assume that they havent previously organised a key exchange. Replies to me or the list.. (but not both please.. my mbox is busy enuff :) Mark mark at coombs.anu.edu.au From yanek at novavax.nova.edu Wed Nov 25 06:08:48 1992 From: yanek at novavax.nova.edu (Yanek Martinson) Date: Wed, 25 Nov 92 06:08:48 PST Subject: Private E-mail (re: Ban on cash transactions) In-Reply-To: <9211251324.AA15058@wookumz.gnu.ai.mit.edu> Message-ID: <9211251408.AA13799@novavax.nova.edu> > I'm interested, especially if you'd be receptive to adding some > capabilities beyond those you presently have in mind. For more info on Yes, I am open to any suggestions. > these, see October Dr. Dobb's Journal, "What if there is a silver I will definitely get it. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From hughes at soda.berkeley.edu Wed Nov 25 09:08:00 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Wed, 25 Nov 92 09:08:00 PST Subject: The Cypherpunks Mail Project In-Reply-To: <199211210833.AA19473@well.sf.ca.us> Message-ID: <9211251705.AA17774@soda.berkeley.edu> I wrote: >[...] there is no one place to push on the mail system to add encryption. Let me explain. You can push on a standard, but that doesn't change any code. If everybody in the world read mail with /bin/mail, then you could rewrite that and add encryption. What certainly is the case, though, is that there are a lot of mail readers out there. It is also the case that the cypherpunks, of all people, should be using encrypted mailers. Otherwise we are hypocrites. Fen advocates MIME, and Ittai concurs. Ittai asks, relating to existing MIME development work: >Do we really want to give them an additional burden -- or do we want >to leverage off work that is already being done? It was my vision of this development that people here on the list would do the work of integration and publish the results. It is also my suspicion that simple PGP decryption support is fairly straightforward, being mostly the ability to run a command on a block and replace the block with the output of the pipe. This model works with regular mail and MIME, since it runs at the very top level of the application. Eric From fnerd at smds.com Wed Nov 25 09:17:33 1992 From: fnerd at smds.com (FutureNerd Steve Witham) Date: Wed, 25 Nov 92 09:17:33 PST Subject: Random Numbers Boxes and Cypher Processers Message-ID: <9211251629.AB05506@smds.com> >Why do encryption in the modem instead of the host cpu? A point that hasn't been made painfully clear yet: "DSP--Digital Signal Processor" chips are really just fast processors for repetitious arithmetic--just what RSA needs. Maybe some experience in programming them for that sort of purpose would be useful. -fnerd fnerd at smds.com (FutureNerd Steve Witham) From 74076.1041 at CompuServe.COM Wed Nov 25 09:17:58 1992 From: 74076.1041 at CompuServe.COM (Hal) Date: Wed, 25 Nov 92 09:17:58 PST Subject: Remailers... Message-ID: <921125165126_74076.1041_DHJ12-1@CompuServe.COM> I think the remailing idea expressed via Tim (from David?) had some nice features. It would be very easy to do replies to someone whom you didn't know but from whom you'd received some anonymous mail. As I understand it, if I send mail anonymously to David, he won't (of course) know who sent it. If he replies, the mail will bounce back to the forwarder. And the forwarder has remembered my forwarding request so that it can send the reply back to me. After that it deletes the remembered forwarding request for security. I wouldn't object to this that much on security grounds; as David pointed out, even a full implementation of Chaum's "mix" remailer would fall to infiltration. Instead, I think there are some issues involving usability. For one thing, it sounds like this system is use-once as far as the anonymous return address. If David replied to me, then thought of something he wanted to add, his second message wouldn't get through to me. Another problem is, what if two people send anonymous mail to David via the same forwarder. Then, when he replies, how does the forwarder know which of the two to forward the reply to? It's also asymmetric, in that it will only work if one of the two communicants knows the true address of the other. A lot of the interesting features of Tim's "crypto anarchy" only arise if people can communicate without either one knowing the other's true address. Let me mention a couple of other ideas which I've heard of for anonymous return addresses. One idea was posted several months ago on the Extropians list by Eric Messick. (Is he on this list?) It used a "pseudonym-based post office box". You would send a message to a remailing server saying, "Please save mail addressed to pseudonym XYZ123. I will pick it up later. Here is the public key I will use to authorize the pick-up, and here is some digital cash to pay for your trouble. Thank you." Then you send mail anonymously giving XYZ123 at remailer.com as your return address. This mail stacks up at the remailer which saves it for you. At some later date you send a signed message to the remailer saying, "OK, send XYZ123's mail to me at me.com." Eric Hughes had an idea which was somewhat like this but without the delay aspect. You would just set up an account with a remailer whereby all mail to XYZ123 would be forwarded to yourself. Then XYZ123 at remailer.com would be your return address. This could include David's idea if you asked the server to delete your pseudonym after using it once. All of these anonymous return address proposals can be enhanced by using a cascade or chain of remailers for your A.R.A. Chaum's "mix" remailer would save up a batch of cryptographically protected messages, decrypt them, rearrange their order randomly, then send them out. This way if the remailer itself is secure but the network connections to it are being monitored, the correspondance between incoming and outgoing messages is lost. The other ARA suggestions could also benefit from this enhancement. Chaum's idea for an anonymous return address was a somewhat more complicated form of the ARA I've implemented for my remailer. My ARA is simply a forwarding instruction, encrypted with the public key of the remailer. The advantage of this system is that you don't have to "register" with the remailer(s) in advance. It's less convenient than the other proposals, though, and there is the danger that the public key(s) of the remailer(s) involved would be revealed at some time in the future, which would then reveal that that old ARA really was you. Hal 74076.1041 at compuserve.com From ebrandt at jarthur.Claremont.EDU Wed Nov 25 10:30:40 1992 From: ebrandt at jarthur.Claremont.EDU (Eli Brandt) Date: Wed, 25 Nov 92 10:30:40 PST Subject: PGP on local machine (was Re: MacPGP) In-Reply-To: <199211251002.AA24840@well.sf.ca.us> Message-ID: <9211251830.AA13482@toad.com> > From: George A. Gleason > Seems to me we need it for encryption as well... For instance, telecom > software which allows you to back out into a screen editor where you write > something and then encrypt it, and then get back to telecom and transmit the > ciphertext directly. The following would require customization on both ends, but seems doable: You compose the message, using emacs or some other Turing-complete editor. You hit the "PGPify" key [sequence]. emacs echoes a special START string The local comm program recognizes it and goes into "capture" mode. emacs blats the plaintext to stdout, where it is captured. emacs echoes a STOP string. The comm program sees this, stops capturing, shells to DOS, and runs PGP. emacs kills the original text block. (emacs command ends) The comm program shoves the cyphertext into the upload stream. (comm macro reverts to lurk mode) You send the message. All of this, I think, could be implemented with available programs. Kermit won't hack it on the local end, so maybe I'll switch to Telemate. This protocol would require a clean line or EC modem; is this a problem? It might be a better move to write a [shell, Perl] script that's a drop-in replacement for Unix pgp: it goes through the whole protocol above, and looks to the outside world as if it had done the work itself. People have written emacs macros (I think) to make this work with mail; it could also be used as a unix-pgp replacement in other places. It might be nice if the plaintext were not echoed to the screen while being transferred, too. Eli ebrandt at jarthur.claremont.edu From yanek at novavax.nova.edu Wed Nov 25 10:36:01 1992 From: yanek at novavax.nova.edu (Yanek Martinson) Date: Wed, 25 Nov 92 10:36:01 PST Subject: An easy-to-reply anonymous mail scheme In-Reply-To: <199211251815.AA16797@buila.NSD.3Com.COM> Message-ID: <9211251835.AA23411@novavax.nova.edu> > >is this: Just include a public key in your post. And ask any repliers to > >post to the newsgroup, encrypted with that key. No-one else but you can > >decrypt the reply, and no-one can know that you did, since everyone receives > > all of my own and everybody elses schemes is that it requires an INVOLVED > replier. I need some way that I can send out an anonymous email, and have > the receiver of that email just hit "r" to reply to me. If they have Ok, if that is what you want, then the following procedure will let you do exactly that: post anonymously, with a reply address that people can just 'r' to. And no-one (not even the host that is handling the replies) has to know who you are. There exists a site, lets call it remailer.com. It watches the newsgroup alt.key.announce for messages with the "Subject: remailer public key notice" that contain a public key. It takes each public key, and perofmrs some sort of hash function on it, tcreate a short "key id". (note: the hash function must be cryptographically strong, i.e. it should be very difficult to construct another key with the same hash value). It stores hash and the key in a database. Then whenever it receives a mail message to reply.HASH (where HASH is the key id), it encrypts the message with the associated public key, destroys the plaintext message, and posts the ciphertext to alt.w.a.s.t.e. So to use this, you would generate a public/private key pair, and compute the hash function of the public part. Anonymously post the public key to alt.key.announce, and then send your message by whatever means you like (anon mail, anon post to a regular newsgroup, anything) using reply.HASH at remailer.com as your return address. Then watch alt.w.a.s.t.e for replies and decrypt as received... All the recipient(s) have to do is press 'r' key and type the answer. You are guaranteed anonymity because no-one can find out who decrypted the alt.w.a.s.t.e message, since everyone received it. All you need is a good way to anonymously post to a newsgroup. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From yanek at novavax.nova.edu Wed Nov 25 10:41:46 1992 From: yanek at novavax.nova.edu (Yanek Martinson) Date: Wed, 25 Nov 92 10:41:46 PST Subject: anonymous reply In-Reply-To: <199211251829.AA27022@johanna4.hsr.no> Message-ID: <9211251841.AA23551@novavax.nova.edu> > > replier. I need some way that I can send out an anonymous email, and have > > the receiver of that email just hit "r" to reply to me. If they have > Here is an example of how to use the cryptographic remailer at > to implement an anonymous return address. > But the again do you trust hal at alumni.caltech.edu... With conventional remailer schemes such as this one, you are announcing your True Name (or at least your True Internet Mailbox) to someone you must trust. With my scheme (posted earlier today) you don't need to trust anybody except yourself (to not make a dumb mistake like including a signature). -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From tcmay at netcom.com Wed Nov 25 11:08:14 1992 From: tcmay at netcom.com (Timothy C. May) Date: Wed, 25 Nov 92 11:08:14 PST Subject: Scenario for a Ban on Cash Transactions In-Reply-To: <9211251553.AA15780@wookumz.gnu.ai.mit.edu> Message-ID: <9211251903.AA05946@netcom.netcom.com> In his usual fashion, Duncan Frissell has cogently made some arguments as to why my scenario for a cashless society won't happen. I hope he's right, but I doubt it. Since many of his comments are relevant to the parallel discussion going on in the "Cypherpunks" list, I'm cc:ing that list. Duncan Frissell writes (from Britain): > Why we won't have a cashless society - > > 1) 60% of US personal transactions (by number not value) are still in cash. But here in the States nearly everyone has either a credit card or an ATM card. Most supermarkets now take plastic...ATM/credit card readers are installed in the checkout lanes. The clerks tell me they actually prefer the plastic, as so little work is needed. (Much faster than checks, which most people not using plastic use). This installed base of card readers already covers about 80% of all common transactions, I would estimate. > 2) Bribe income of the rulers would be affected. A good point, also made by Keith Henson (in e-mail). Politicians want cash for off-the-record transactions, their sexual liaisons, etc. Maybe the corruption of politicians will be our salvation! (More likely: exemptions...Congress exempts itself from many laws. Also, the various onerous financial disclosure laws directly affect politicians, and they made it into law.) > 3) The illiterate, the retarded, and those with poor management skills depend > on a cash accounting system to run their lives. They would not be able > to survive in a card-based economy. 20% of the US pop. have no checking > accounts and 40% have no plastic. I notice plenty of semi-literate folks handing their plastic to the cashier! Those without checking accounts tend to use "money orders," though, so mandating a conversion would be possible. Many of those without checking or plastic accounts simply don't "qualify." (Trend: qualification standards have been dropping every year) A government-run credit/debit card program would ensure that everyone got a card. Illiteracy is no problem, as there is virtually nothing to read or write when using plastic. (Adding voice synthesis to some of the card readers would even be seen as a selling point with the blind or physically disabled.) > 4) The destruction of the Underground Economy would be socially regressive > since it would fall most heavily on the poor. Poor households spend twice > their reported income. Possibly true, but this won't cut the mustard when it comes to passing the laws. The laws will be presented as a way to "close the loopholes" on the rich, not to soak the poor. The talk of a "welfare credit card" to deal with the theft of welfare and social security checks (a big problem in the U.S., obviously affecting mostly the poor) will likely result in some form of government-mandated card system in the next couple of years. > 5) The destruction of the Underground Economy would hurt the Gross Domestic > Product and cause recession. Probably not a concern to the planners, but perhaps. It is not politically correct to talk about this. > 6) Foreigners need to be able to participate in the system. Unless *all* > nations jointly go to an electronic payments system, there will be loopholes > that domestic residents can exploit. But foreigners already have to comply with U.S. banking laws (though of course they often don't, but that's another story). Foreigners planning to convert pounds or francs to cash dollars would simply convert them to electronic dollars, "charging" up their debit/credit/etc. card. (As a parallel, the law from 1933 to 1976 or so was that Americans could not possess gold in any form except jewelry or rare coins. Other countries had no such laws. Did we see British visitors flouting the laws by spending gold guineas?) > 7) As long as foreign practices differ, domestic residents could get overseas > Visa debit cards and ATM cards and avoid the domestic social controls. This could be a real stopper. Perhaps the U.S. and its New World Order will push for a nearly simultaneous conversion, as part of the GATT talks, the various monetary talks, etc. Also, using foreign-based cards could simply be declared illegal. Tie-ins to Immigration and Passport control could allow foreign visitors to use their foreing cards for, say, 90 days, or whatever....this would also be a way to control illegal immigrants who overstay their temporary visa. The cleanest solution would be to tie a "tempory visa" to a "temporary VISA" (pun intended), in which a visitor would receive a card upon arrival, just as he now changes his francs and marks for dollars. > 8) The vast majority of the world's population is still in a cash or barter > economy and could not be converted to plastic. This would leave overseas > cash that would be a system loophole. See above. > 9) There is now no central financial authority. Electronic payments are > transmitted to the payor banks by various networks and the banks themselves > authorize payment. A central authority would be expensive and technically > challenging. Ah, but these clearinghouses are becoming more tightly integrated. A VISA transactions costs about $0.10, and this is dropping yearly. A typical transaction can be sent out over phone lines in seconds and over high-speed ISDN lines in fractions of a second. Fiber optic lines make it ridiculously easy. Besides, it it not necessarily the case that there would be one central authority which would validate transactions (that would be too vulnerable to single-point failures and sabotage). Transactions would mostly be similar to today's transactions, with records sent periodically to the government(s). > 10)A central financial authority would exceed the institutional abilities of > current international arrangements, would be opposed by the banks (cost and > independence), would constrain the growth of the financial services industry > and would run counter to the trend of financial deregulation. Here in the U.S. the banks have acquiesced to nearly all of the onerous new reporting regulations (cash transactions over $10,000--soon to be less--and disclosure laws) resulting from the War on Drugs. Banks are now creatures of the government, jumping when told to. Also, when the various laws are seen as _profit sources_ (as in the FBI's Digital Telephony Bill, which would compensate phone companies for tapping customers) then banks will be happy to add a service charge to cover their expenses. Furthermore, and this goes to your point below as well, banks will push for legislation that forces theri competitors to do exactly the same as they are doing. There are virtually no new banks appearing in the U.S....they want a nice, safe, profitable world, not competition. Forcing all transactions to go through them would fit their fondest desires. > 11)The Iron Law of Regulation. Regulations create profits for their avoidance > and eventually break down as people take advantage of those profit > opportunities. Financial deregulation throughout the world in '80s was > *not* caused by a decision of governments to give up power. Deregulation > was an acknowledgment that old controls were dead. Banks are suffering as new alternatives have appeared. Hence the talk fo repealing the Glass-Steagall Act. Banks may see a cashless system as their way to get back into the center of things. > 12)Networks were originally thought to be centralizing. In practice they have > proven to be decentralizing. How many machines/people access Internet? Who > has central control over Internet? The Internet may be physically decentralized, but logically it is very centralized, in the sense that all messages to newgroups appear in one very large feed, albeit sent out in pieces. That is, everybody in the world is basically seeing the same "sci.crypt" group. More to the point, the credit card clearinghouses are amazing centralized (logically, if not physically...and a friend of mine who consults for VISA headquarters--located in the Bay Area--says nearly all VISA transactions flow into their facilities). I can access my credit card balances nearly anyplace in the world. How's that for centralization? > 13)An encrypted, anonymous, zero-knowledge-proof-credentialed market could be > conducted without reference to an external government-controlled payment > system. Here we agree, completely. This is my hope. If we can deploy our ideas quickly enough, the scenario I describe may be headed off. > These are just a few of the problems to be overcome. A change that massive > would upset so many apple carts in the US and abroad that I don't think it is > much of a risk. > > Duncan Frissell Thank you, Duncan, for your incisive comments, even though I disputed most of them. This is an important debate, a lot more important, I think, than debates on the rights of Martians and owls. (No offense to Extropians intended!) Our future is at stake. --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at 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^756839 | PGP Public Key: by arrangement. From shipley at tfs.COM Wed Nov 25 12:30:56 1992 From: shipley at tfs.COM (Peter Shipley) Date: Wed, 25 Nov 92 12:30:56 PST Subject: An easy-to-reply anonymous mail scheme In-Reply-To: <9211251835.AA23411@novavax.nova.edu> Message-ID: <9211252030.AA24576@edev0.TFS> > >So to use this, you would generate a public/private key pair, and compute the >hash function of the public part. Anonymously post the public key to >alt.key.announce, and then send your message by whatever means you like (anon >mail, anon post to a regular newsgroup, anything) using reply.HASH at remailer.com >as your return address. Then watch alt.w.a.s.t.e for replies and decrypt >as received... one problem is that pgp labels public/private key pairs with strings (thus I have to create a public/private key pair with a unique label string that has nothing to do with my name) the problem still exists that every message posted to alt.w.a.s.t.e with have my pgp key label string. pgp does not support unlabeled crypted test (eg: I can had it random cyphertext and have it figure out public/private key pair to use (by trying every key in my rings)( From yanek at novavax.nova.edu Wed Nov 25 12:44:36 1992 From: yanek at novavax.nova.edu (Yanek Martinson) Date: Wed, 25 Nov 92 12:44:36 PST Subject: An easy-to-reply anonymous mail scheme In-Reply-To: <9211252030.AA24576@edev0.TFS> Message-ID: <9211252044.AA28256@novavax.nova.edu> > >as your return address. Then watch alt.w.a.s.t.e for replies and decrypt > > one problem is that pgp labels public/private key pairs with strings > (thus I have to create a public/private key pair with a unique label string > that has nothing to do with my name) the problem still exists that > every message posted to alt.w.a.s.t.e with have my pgp key label string. This is not a problem at all. For every anonymous "identity" you want to maintain, you would have a key pair (public/private). The "label" part could contain anything you want, or nothing at all (a space, or a dash, or the word "anonymous") but it would be more convenient if you assigned a pseudonym. > pgp does not support unlabeled crypted test Just because (current version of) pgp does not support something does not mean it can not be done. > (eg: I can had it random cyphertext and have it figure out public/private > key pair to use (by trying every key in my rings) This would be a waste of time, and possibly imprctical if you have any significant number of keys. You should not have to try each key, because the post would contain in the Subject field the hash value of the public key, and using that you could instantly identify which private key to use. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From ghsvax!hal at uunet.UU.NET Wed Nov 25 13:04:57 1992 From: ghsvax!hal at uunet.UU.NET (Hal Finney) Date: Wed, 25 Nov 92 13:04:57 PST Subject: Electronic Banking Message-ID: <9211251953.AA01487@nano.noname> Some time back Tim May suggested that we should do some experiments with electronic cash. He offered to do some Xeroxing if people would "pay" him. There are lots of proposals for electronic cash in the literature, mostly very complex. I think one of Chaum's simpler proposals would be adequate for email "banking". This proposal, from the beginning of his paper "Untraceable Electronic Cash" in Crypto 88(?), goes like this: 1. Alice chooses a random x and r, and supplies the bank with B=r^3*f(x) mod n, where f is a one-way function (like MD5), and n is the modulus for the bank's public key. 2. The bank takes the third root of B (e.g. via an RSA decryption) and sends it back to Alice: D = r * f(x)^(1/3), and withdraws one dollar from her account. 3. Alice extracts C = f(x)^(1/3) by dividing D by r. (Note that division can be done mod n without knowing the factors of n, but it's rather complicated.) 4. To pay Bob one dollar, Alice gives him (x, C). 5. Bob can verify that C = f(x)^(1/3), but he still has to send (x, C) to the bank in order to make sure that x hasn't been used before. Otherwise Alice could spend (x, C) twice. The bank increases Bob's account by one dollar. This scheme is pretty simple and provides untraceability - the bank saw B and D but not C, so although it can verify that (x, C) is legit, it can't correlate that with Alice's withdrawal. The main disadvantage of this approach is that Bob has to send (x, C) to the bank right away (or at least before sending Alice anything in return for her cash) to verify that the cash hasn't been used before. But in email, where turnarounds of a day or more aren't unusual, this should be tolerable. Alice and Bob could be pseudonyms, using anonymous addresses to communicate with each other and with the bank. Different denominations of cash could correspond to different exponents than "3" in the example above. (That is, $1 would use C=f(x)^(1/3), $2 would use C=f(x)^(1/5), $4 would use C=f(x)^(1/7), and so on.) Technically, this would be quite easy to implement, using the code in PGP for the arithmetic, and MD5 for the one-way function. We'd need to define a few message formats. The RFC1113 ascii encoding from PGP could be used as well. The "social" problems are more challenging, it seems to me. What is the backing for this electronic money? Why do people care what their bank balances are? Is this stuff really worth anything? One possibility is to base digital cash on real money. People would open a pseudonymous account via email, then postal-mail dollars to the bank, enclosing their account number so the bank would know whom to credit with the deposit. Later, if someone wanted to withdraw "real money" from their account they would have to give a real postal address where it could be mailed. Now the electronic money is worth real dollars. Even if people didn't deposit or withdraw very often, it still has value because of the backing. Unfortunately, this approach would currently be illegal (at least, unless you actually were a real bank!). If there were some way the bank itself could be anonymous, it might survive, but I don't see how to mail it money while keeping the anonymity. Still, we could consider experimenting with this on a small scale with accounts of no more than a few dollars. As long as it was clearly an experiment I doubt that any prosecutions would result even if it attracted government attention, because the expense involved in court costs would be so disproportionate to the few dollars involved in this technically illegal act. Another approach would be not to try backing the digital cash at all, or rather backing it implicitly by the determination of various people to accept it and perform services or supply goods in return for it. Tim's offer to Xerox papers in return for digital cash would be one example. Perhaps others could provide some other services. It would be great if some shareware author would accept digital cash as a symbol of support for crypto anonymity. One problem that I see with this approach is how you determine the size of the money supply. Or, in other words, how does new digital cash get started circulating? How do people get new accounts, and how much money is in them? If these problems can be solved, a big advantage of this approach is that the banker can be anonymous. He would be known only by his anonymous address and his public key(s). This would provide some safety in the event that even a small-scale experiment like this was targetted for a crackdown. Another issue is the prospect of multiple "banks", each issuing their own (incompatible) cash. How would they compete? Perhaps in terms of rapid turnaround? Some might choose to be anonymous, others would go public. The latter would have the advantage that people might trust them more, but OTOH there is more chance of your bank account disappearing after a crackdown for a public bank than an anonymous one. Lots to think about here! Hal 74076.1041 at compuserve.com From rfm at Eng.Sun.COM Wed Nov 25 13:09:10 1992 From: rfm at Eng.Sun.COM (Richard McAllister) Date: Wed, 25 Nov 92 13:09:10 PST Subject: SF Bay Area Parties Message-ID: <9211252108.AA05130@urth.Eng.Sun.COM> Edgar Swank wrote: > Cypherpunks, > Extropians Libernet > Since all the above groups, of which I am a member, are not known > for sponsoring social functions, I suggest we co-opt the Pen SFA > parties. Their latest "Winnie" newsletter is attached. Please note > and follow "rules". I especially recommend the 12/26 party. ... Interested people are definitely invited to attend PenSFA parties (though not to "co-opt" them..), but we prefer not to post the meeting notices to random mailing lists since they include hosts' addresses and phones. [Edgar didn't know this because I failed to tell him; my fault, not his.] But please don't forward the whole Winnie on to other lists. (Especially, don't post it to USENET...) If you'd like more information on PenSFA, email me, I have a information handout to give you; also email me to get on the list for more announcements. Rich (rfm at eng.sun.com) From tcmay at netcom.com Wed Nov 25 14:23:18 1992 From: tcmay at netcom.com (Timothy C. May) Date: Wed, 25 Nov 92 14:23:18 PST Subject: Electronic Banking In-Reply-To: <9211251953.AA01487@nano.noname> Message-ID: <9211252219.AA00550@netcom.netcom.com> Hal Finney makes some very good points about anonymous banking and some experiments we may try in the near future. (First let me dispose of a minor item.) > Some time back Tim May suggested that we should do some experiments > with electronic cash. He offered to do some Xeroxing if people would > "pay" him. (A minor note: I ended up doing the Xeroxing for free, which hasn't yet been declared illegal...though I presume you'll all carefully note this on your tax returns, as such "barter exchanges" are reportable income. In theory, which shows how hopeless tax collection is becoming, all of our "mutual consulting" on this list, and on the Net in general, is _taxable income_--just as if we were plumbers and carpenters getting together to work on each other's houses. A crazy system.) Back to the important stuff. Hal continues: > There are lots of proposals for electronic cash in the literature, > mostly very complex. I think one of Chaum's simpler proposals would be > adequate for email "banking". This proposal, from the beginning of > his paper "Untraceable Electronic Cash" in Crypto 88(?), goes like > this: (Hal's excellent summary of Chaum's system elided) > Technically, this would be quite easy to implement, using the code in > PGP for the arithmetic, and MD5 for the one-way function. We'd need > to define a few message formats. The RFC1113 ascii encoding from PGP > could be used as well. This sounds great! (But I worry that the handful of you already doing the programming of PGP, new versions, MacPGP, remailers, etc., will get overloaded and/or burned out. I'd offer to help, but my programming these days is limited to fiddling with Mathematica and a little bit of Smalltalk and Scheme/LISP.) > The "social" problems are more challenging, it seems to me. What is > the backing for this electronic money? Why do people care what their > bank balances are? Is this stuff really worth anything? And the lesson we learned from PGP 2.0 is that actually getting _something_ out there for people to play around with is crucial. Getting "PGDC" ("Pretty Good Digital Cash") in use will be a harder sell than PGP deployment was, because most people don't understand the ideas, see no real pressing need, and can't do much in any case without an "economy" of users. I've long thought that a "Black Market AMIX" would be one such use, but I won't get into that here. > One possibility is to base digital cash on real money. People would > open a pseudonymous account via email, then postal-mail dollars to the > bank, enclosing their account number so the bank would know whom to > credit with the deposit. Later, if someone wanted to withdraw "real > money" from their account they would have to give a real postal > address where it could be mailed. Now the electronic money is worth > real dollars. Even if people didn't deposit or withdraw very often, > it still has value because of the backing. > > Unfortunately, this approach would currently be illegal (at least, > unless you actually were a real bank!). If there were some way the > bank itself could be anonymous, it might survive, but I don't see how > to mail it money while keeping the anonymity. Still, we could > consider experimenting with this on a small scale with accounts of no > more than a few dollars. As long as it was clearly an experiment I > doubt that any prosecutions would result even if it attracted > government attention, because the expense involved in court costs > would be so disproportionate to the few dollars involved in this > technically illegal act. Warning! Recently, a bunch of bowlers (women, no less) were busted for illegal gambling because of their "pot" they were bowling for. After much public outcry and laughter at the authorities, the charges were either dropped or reduced. I mention this because casual bowlers evoke sympathy, hackers and cypherpunks do not. > One problem that I see with this approach is how you determine the > size of the money supply. Or, in other words, how does new digital > cash get started circulating? How do people get new accounts, and how > much money is in them? We're in new territory here. The start of a new kind of economy. Lots of experimentation and trial and error work will be needed. > If these problems can be solved, a big advantage of this approach is > that the banker can be anonymous. He would be known only by his > anonymous address and his public key(s). This would provide some > safety in the event that even a small-scale experiment like this > was targetted for a crackdown. Yes. And also anonymous "escrow services" which are like banks but which serve other functions, such as holding the money in a transaction so that Alice cannot take the money from Bob and refuse to deliver on her side of the deal. All of these entities must be "pseudonymous" (a clumsy word), in that digital pseudonyms are supported (a la the work of Hughes, Finney, and Janek Martinson) and True Names cannot be traced. > Another issue is the prospect of multiple "banks", each issuing their > own (incompatible) cash. How would they compete? Perhaps in terms of > rapid turnaround? Some might choose to be anonymous, others would go > public. The latter would have the advantage that people might trust > them more, but OTOH there is more chance of your bank account > disappearing after a crackdown for a public bank than an anonymous > one. Banks, escrow services, etc. will all have "reputations" and credit ratings (from crypto versions of Standard and Poors, themselves operating only as a pseudonym!). All of this will evolve over time. > Lots to think about here! > > Hal That's for sure. Incredibly good points being made by everyone! --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at 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^756839 | PGP Public Key: by arrangement. From yanek at novavax.nova.edu Wed Nov 25 15:31:10 1992 From: yanek at novavax.nova.edu (Yanek Martinson) Date: Wed, 25 Nov 92 15:31:10 PST Subject: ease of use of encryption In-Reply-To: <199211251002.AA24840@well.sf.ca.us> Message-ID: <9211252330.AA04789@novavax.nova.edu> > re Tai's item about more user-friendly decryption on the Mac version.... > > Seems to me we need it for encryption as well... For instance, > Having to go offline, go into WP, compose, go to crypto and encrypt, > then go back to telecom, link up again, and transmit.... This is where my little Crypto-Dongle would help. To encrypt, just flip a switch and type. Same thing for decryption... flip a switch and everything received is decrypted... -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From karn at qualcomm.com Wed Nov 25 15:38:09 1992 From: karn at qualcomm.com (Phil Karn) Date: Wed, 25 Nov 92 15:38:09 PST Subject: RS232 Crypto Dongle (idea for widely accessible crypto technology) Message-ID: <9211252337.AA01494@servo> I've also been thinking about the risks of running crypto software on hackable PCs and ways of protecting against this with external special purpose devices. My thinking is to limit the external "dongle" to the one function that is truly sensitive and worthy of special protection: RSA secret key operations. It seems to me that whenever you use a PC to encrypt or decrypt something, you have to accept the risk that it might have been hacked, and whatever you do on it might be secretly recorded. But when I now run PGP (or any similar package) on a machine, I must risk much more than this every single time I type in my pass phrase, namely *everything* that ever was or will ever be encrypted with this same RSA key pair. This may well be an unacceptable risk, especially if I'm temporarily borrowing somebody else's machine or using one in a public area. I see this as THE major obstacle to our goal of routinely encrypting all communications, sensitive or otherwise, as a way of "desensitizing" the world to the use of cryptography. The way around this risk is to move the RSA secret key storage and processing operations to some external dongle. The device would have only one primary function -- the execution of an RSA secret key operation. It would not allow the secret key to be read out of the device, although it might have a "zeroize" function to destroy it. (It might also include a good random number generator for the convenience of the host computer.) Everything else (data compression and armoring, public key operations, symmetric cryptography, etc) can and should go in the PC where cycles and memory space are much more plentiful. If the dongle has a built-in keypad, then it could store your RSA secret key encrypted with a PIN that you'd have to enter to enable the device. This would protect you if the device were stolen. Of course, the best protection is to make the device so small that you can conveniently keep it with you at all times instead of having to store it someplace. I believe that "smart cards" are already available on the market that do these or similar functions, although they are much more widespread in Europe than in the US. Comments? Phil From tony at morgan.demon.co.uk Wed Nov 25 15:47:31 1992 From: tony at morgan.demon.co.uk (Tony Kidson) Date: Wed, 25 Nov 92 15:47:31 PST Subject: The Cypherpunks Mail Project Message-ID: <775@morgan.demon.co.uk> In message <9211251705.AA17774 at soda.berkeley.edu> you write: > > It is also my suspicion that simple PGP decryption support is fairly > straightforward, being mostly the ability to run a command on a block > and replace the block with the output of the pipe. I'd like to chip in here, in my _very_ newbie way, that not everybody is running a unix system with the ability to pipe things between processes in so facile a manner. I access the net through a dial up from a MS-Dos machine running KA9Q software. My PGP is of the stand alone sort. I cannot easily get a new mailer to run on this system. Whatever protocol is decided upon, it would be useful if it were not too host-system specific. [FX Crawls back under stone] Tony ------------------+-------------------------------+--------------------------+ | Tony Kidson |`morgan' is an 8MB 486/33 Cat-| Voice +44 81 466 5127 | | Morgan Towers, |Warmer with a 670 MB Hard Disk.| E-Mail | | Morgan Road, |It resides at Morgan Towers in| tony at morgan.demon.co.uk | | Bromley, |Beautiful Down Town Bromley. | tny at cix.compulink.co.uk | | England BR1 3QE | -=<*>=- | 100024.301 at compuserve.com| +=================+===============================+==========================+ From hughes at soda.berkeley.edu Wed Nov 25 15:49:42 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Wed, 25 Nov 92 15:49:42 PST Subject: RS232 Crypto Dongle (idea for widely accessible crypto technology) In-Reply-To: <9211250712.AA03659@novavax.nova.edu> Message-ID: <9211252349.AA13510@soda.berkeley.edu> Yanek writes: >Also, it would not require ANY special software on the host or the >pc, nor any special terminal. [A magical kingdom of compatibility is >described.] In practice, it will be impossible to make a device that does anything transparently. Software has to be rewritten and redesigned around crypto security. It is wise not to underestimate or overestimate the difficulty of doing this. Eric From gnu at cygnus.com Wed Nov 25 15:55:15 1992 From: gnu at cygnus.com (gnu at cygnus.com) Date: Wed, 25 Nov 92 15:55:15 PST Subject: The age of the engineers... Message-ID: <9211252354.AA12510@cygnus.com> ------- Forwarded Message To: junk Subject: quotd Date: Wed, 25 Nov 92 14:12:06 -0800 From: ambar at cygnus.com - ------- Forwarded Message Date: Wed, 25 Nov 92 17:06:28 EST From: CyberBunny This is not the age of pamphleteers. It is the age of the engineers. The spark-gap is mightier than the pen. Democracy will not be salvaged by men who talk fluently, debate forcefully and quote aptly. Lancelot Hogben Science for the Citizen (1938) From hughes at soda.berkeley.edu Wed Nov 25 15:58:26 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Wed, 25 Nov 92 15:58:26 PST Subject: How far is to far? In-Reply-To: <1992Nov25.101452.11440@extropia.wimsey.bc.ca> Message-ID: <9211252357.AA13991@soda.berkeley.edu> Miron writes: >How do you think the IRS is going to trace those banks and customers >behind all the anon mixes? Easy. This one, though, is not in the crypto literature to my knowledge. Attack by regulation. Not, mind you, that it will be enforceable without a bn on cryptography in general. Eric From gnu at cygnus.com Wed Nov 25 15:58:50 1992 From: gnu at cygnus.com (gnu at cygnus.com) Date: Wed, 25 Nov 92 15:58:50 PST Subject: Electronic Banking In-Reply-To: <9211252219.AA00550@netcom.netcom.com> Message-ID: <9211252358.AA12549@cygnus.com> > > Unfortunately, this approach would currently be illegal (at least, > > unless you actually were a real bank!). Please point out the law(s) that make it illegal. Speculation is fine, but let's do some informed speculation. John From ghsvax!hal at uunet.UU.NET Wed Nov 25 16:07:41 1992 From: ghsvax!hal at uunet.UU.NET (Hal Finney) Date: Wed, 25 Nov 92 16:07:41 PST Subject: An easy-to-reply anonymous mail scheme Message-ID: <9211252352.AA01919@nano.noname> The problem with the idea of posting anonymous mail to a newsgroup is sheer volume. Remember, we aim at a system where a large fraction of mail is potentially being done this way. Imagine if almost all email was done today by posting to newsgroups! There is probably thousands of times as much email traffic as news traffic now. It would totally swamp the system. You'd literally have to send every email message sent by any user in the world to _every_ user in the world, in effect. As Yanek says: > You are guaranteed anonymity because no-one can find out who decrypted > the alt.w.a.s.t.e message, since everyone received it. This really won't scale to large numbers of users. Yanek also writes: > > Here is an example of how to use the cryptographic remailer at > > to implement an anonymous return address. > > > But the again do you trust hal at alumni.caltech.edu... > > With conventional remailer schemes such as this one, you are announcing > your True Name (or at least your True Internet Mailbox) to someone you > must trust. With my scheme (posted earlier today) you don't need to trust > anybody except yourself (to not make a dumb mistake like including a > signature). This is why you would want to use a chain of remailers as your return address, what Chaum calls a "cascade". No single remailer sees the correspondance between your anonymous address and your real address. Only by breaking all of them can the bad guys find out who you are. Ideally, remailers would operate in a variety of countries with different laws, making it difficult to crack them all. Remailers could be designed to periodically flush themselves, deleting old keys and/or pseudonym maps. This way anonymous addresses would have a limited lifetime if desired, and the attackers would have only a finite time window to break all the remailers involved. (Different keys/pseudonyms could have different lifetimes as needed.) We could also imagine that there are lots of remailers - not just dozens, or hundreds, but millions of them. Maybe almost everyone runs a "cheap" remailer on the side, collecting a few cents in digital cash for each message they pass, enough to pay for their own messages. Putting all this together, you could have an anonymous address which passes through, say, 10 remailers which might be any of the millions of remailers in the world. It could have a limited lifetime of only a few hours for some ultra-sensitive applications, with the remailers involved flushing their databases after that time. To break this, the enemy would have to sequentially break into machines all over the world, one after another, defeat any physical barriers (locks, men with guns), overcome tamper-resistance in the computers, break the encrypted files, and find out what the next step is in the address cascade, all in a couple of hours. This doesn't seem possible. Hal 74076.1041 at compuserve.com From mark at coombs.anu.edu.au Wed Nov 25 16:23:55 1992 From: mark at coombs.anu.edu.au (Mark) Date: Wed, 25 Nov 92 16:23:55 PST Subject: Electronic Banking Message-ID: <9211260023.AA11537@coombs.anu.edu.au> >(A minor note: I ended up doing the Xeroxing for free, which hasn't >yet been declared illegal...though I presume you'll all carefully note >this on your tax returns, as such "barter exchanges" are reportable >income. In theory, which shows how hopeless tax collection is >becoming, all of our "mutual consulting" on this list, and on the Net >in general, is _taxable income_--just as if we were plumbers and carpenters >getting together to work on each other's houses. A crazy system.) So *thats* why nnacct is there :)... Does the tax office get an email from each news admin every fiscal year? :) So they can charge us for services rendered by the net? With regard to digital cash, I have yet to read (or have forgotten the definition) the implementation. What I preceive it as is a form of IOU's that if someone does something for you then you send them an applicable amount of credits. To simplify it a bank could issue credits and people could trade in them, sending them back and forth, each digitally encrypted and based on the amount of credits in each persons bank account. I assume each transaction would be validated through a bank to ensure the credit is unique and the right value? E.g: Customer gets suppliers account number from the supplier encrypted with the banks public key. They send it and the amount of cash to transfer to the bank all encrypted with the public key of the bank. The bank decrypts, gets the amount and decrypts the destination account. It then sends a message to the supplier saying that amount has been deposited in their account and the transaction between the customer and supplier can be completed. Otherwise it tells the supplier (and customer) there is a problem with insufficient funds or incorrect data. The cash may be held in ether until both parties confirm the transaction has been completed. If the commodity is electronic data the supplier may send to the bank a transaction private key encrypted with the customers public key so that the customer cant cheat the supplier as he has to ask the bank for the information to access his/her data which has been encrypted with the other half of the transaction keypair. That way the bank knows the transaction has been completed and it finishes the transfer of funds and sends the transaction private key to the customer. Each commodity, especially if it was physical might be serialized so there could be proof that the customer purchased that item with that SN. If the merchant was a crook the audit trail would catch him... the customer wouldnt be able to cheat as the merchant wouldnt have to release the goods (as is the situation now in Real Life (tm)) until the funds were paid. Issues of Big Brother spying on your transactions apply here but I guess one could always use a psuedonym for the electronic commodities and a postal box paid for with digital anonymous cash for the physical stuff.. (assuming it was mail order... you wont have to give a name for store buying, just a bank public key and your encrypted account number.) Someone might even want to set up a physical forwarding company which merely acts as a buffer for people to increase their privacy. Paid for anonymously and digitally. I havent heard of any companies specialising in this type of service to date. This make any sense? Has it been said before? Mark mark at coombs.anu.edu.au From ghsvax!hal at uunet.UU.NET Wed Nov 25 16:25:25 1992 From: ghsvax!hal at uunet.UU.NET (Hal Finney) Date: Wed, 25 Nov 92 16:25:25 PST Subject: Unlabelled PGP messages Message-ID: <9211260016.AA01923@nano.noname> Peter Shipley points out that PGP messages are labelled with an identifier of the person they are sent to. This hurts the anonymity of the messages somewhat. What PGP actually puts in the cleartext message header is the "Key ID" of the recipient. This is the low-order 64 bits of the RSA modulus "n" of his key. (PGP displays only the low-order 24 bits when it shows key ID's, but it keeps 64 bits internally.) I understand that there was some discussion during the development of PGP 2.0 of having a mode where this wouldn't be done. One possibility would be to output a key ID of all zeros for a message which wanted to hide who it was for. Then, as Peter suggests, it would either be trial-decrypted by all of the secret keys you have, or, more simply, it would just try your "default" secret key. Most people only have one secret key so both methods would be the same in most cases. Doing it the second way would be a pretty easy patch to PGP. I'm not so sure now that this feature is that helpful. First, you don't have to put your real name in the "user name" field. You could use a pseudonym. So you really don't have to give much information away about yourself the way it is now. Also, if someone is sending a message to you using encrypting remailers, they would encrypt it using your key, add remailing instructions for the last remailer in the chain, encrypt that using that remailer's keys, add remailing instructions for the next-to-last remailer, encrypt it again, and so on. (This would be done automatically by some future software - you wouldn't want to do this by hand!) The result is that the mail you send does not expose the key ID of your recipient. That information is only revealed when it comes out of the last remailer in the chain. And by that time, it's no secret, since that last remailer is using the true email address of the recipient anyway. So it's not giving anything away. For the other kind of anonymous messaging, where you just post to a newsgroup or use some other kind of "broadcast" system, the key ID is revealed and for this case it might be better to hide it. But, the key ID can be useful in this application by letting you know which messages you should decrypt. No one has to know that a particular key ID is "you". You can still download 1000 messages and only read yours without anyone knowing which ones you read. But with key ID hidden you would have to decrypt them all to see which are yours. Do you want to decrypt all 1000? This will take minutes, hours, or days, depending on your key size and computer speed. (Most of the decrypt time is spent doing the RSA step, at least for most messages, and you can't tell if it's for you without doing that step.) This still might be a good idea, but I'm not sure... Hal Finney 74076.1041 at compuserve.com From hughes at soda.berkeley.edu Wed Nov 25 16:30:25 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Wed, 25 Nov 92 16:30:25 PST Subject: RS232 Crypto Dongle (idea for widely accessible crypto technology) In-Reply-To: <9211252337.AA01494@servo> Message-ID: <9211260030.AA17523@soda.berkeley.edu> Phil K. writes: >My thinking is to limit the external "dongle" to the one function that >is truly sensitive and worthy of special protection: RSA secret key >operations. Phil's comment are right on. There is a need for you secret keys to be easily and physically relocatable. Re: key compromise >I see this as THE major obstacle to our goal of routinely >encrypting all communications, sensitive or otherwise, as a way of >"desensitizing" the world to the use of cryptography. It is my own opinion that there will be a market for personal protection devices only when data is worth money. Data will be worth money when some data _is_ money. >only one primary function -- the execution of an RSA secret key >operation. [...] >it might have a "zeroize" function to destroy it. I refer to this as WEEM: Write, Erase, Encrypt Memory >Everything else (data compression and armoring, public key operations, >symmetric cryptography, etc) can and should go in the PC where cycles >and memory space are much more plentiful. Depending on the silicon size and production volume, you could probably use this device for all modular exponentiation operations. Or a cheap version could use a DSP module from a cell library and do all the arithmetic more slowly. >If the dongle has a built-in keypad, then it could store your RSA >secret key encrypted with a PIN that you'd have to enter to enable the >device. Not only a keypad, but a full 4-function calculator with an LCD display as well! :-) >I believe that "smart cards" are already available on the market that >do these or similar functions, although they are much more widespread >in Europe than in the US. Smart cards have the disadvantage that their die size is pretty severely limited. They have to fit within the thickness of a credit card and withstand repeated flexure. Much better for this application is the PCMCIA standard, which has plenty of room for circuitry. Eric From hughes at soda.berkeley.edu Wed Nov 25 16:36:39 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Wed, 25 Nov 92 16:36:39 PST Subject: The Cypherpunks Mail Project In-Reply-To: <775@morgan.demon.co.uk> Message-ID: <9211260036.AA18162@soda.berkeley.edu> Tony writes: >I access the net >through a dial up from a MS-Dos machine running KA9Q software. My >PGP is of the stand alone sort. I myself read my own mail on an MSDOS machine acting as a terminal over a dialin. The unix host is not overly secure, and I'm not about to go putting keys on it. I've been thinking about how to solve my own encryption problem, you can be sure. But most of the people on the list are reading mail on Unix machines, and a simple piping interface is the first thing to implement. I myself may not use it at first, but it is a start. Eric From karn at qualcomm.com Wed Nov 25 16:47:49 1992 From: karn at qualcomm.com (Phil Karn) Date: Wed, 25 Nov 92 16:47:49 PST Subject: RS232 Crypto Dongle (idea for widely accessible crypto technology) Message-ID: <9211260047.AA01958@servo> >Much better for this application is the PCMCIA standard, which has >plenty of room for circuitry. I had this in mind too. But there's a problem -- if we have to depend on commercial manufacturers to build these things, how will we know if we can really trust them? I'm not impugning the manufacturers themselves, as it's entirely possible that the FBI and/or NSA wouldn't even let them build and sell a device like this if it's "too" secure. That's the paradox of freely-available crypto software like PGP. The software, including source, is open for inspection by all. But because it runs on general purpose computer hardware, it's vulnerable to all of the usual computer security attacks (viruses, modifications to secretly record or transmit keys, keystroke monitors, etc). Going to small, dedicated pieces of hardware removes these vulnerabilities, but then we're right back where we started -- with an opaque piece of commercial hardware whose secure operation we can't verify. Unless, of course, we can get the technology to build PCMCIA cards ourselves out of readily available parts... Phil From tcmay at netcom.com Wed Nov 25 17:23:22 1992 From: tcmay at netcom.com (Timothy C. May) Date: Wed, 25 Nov 92 17:23:22 PST Subject: Crypto Dongles and Tamper-Resistant Modules In-Reply-To: <9211260047.AA01958@servo> Message-ID: <9211260119.AA02600@netcom.netcom.com> Some points about the security of "crypto dongles" and other personal security devices. Phil Karn writes: > >Much better for this application is the PCMCIA standard, which has > >plenty of room for circuitry. > > I had this in mind too. But there's a problem -- if we have to depend > on commercial manufacturers to build these things, how will we know if > we can really trust them? I'm not impugning the manufacturers > themselves, as it's entirely possible that the FBI and/or NSA wouldn't > even let them build and sell a device like this if it's "too" secure. The crucial chips could be built under "open inspection" conditions, much like having source code for inspection prior to compilation on one's own--presumably trustworthy--machines. Several such vendors could be used, with independent auditors observing the processing steps throughout. (Merely the threat of a surprise inspection is probably enough to head off obvious attempts to insert hardware trapdoors and the like.) This seems like a solvable problem. The issue of whether the NSA will let such devices be built is interesting. There was the story of the "PhasorPhone," or somesuch, from some years back, with the story that the inventor, in Seattle, filed a patent application and got back a statement that the device was now classified and could not be talked about (let alone marketed). However, I've heard of no such cases recently. Other countries have excellent wafer fab facilities and could of course build the chips and the complete units. Whether Americans could buy them.... Tamper-Responding Modules (TRMs) Robert Brooks mentions using e-beam probers to read the bits out, and various etches, etc. TRMs came up several weeks ago on this list, and are mentioned in the Glossary posted a few days ago. Even if the TRMs can eventually be gotten into, probably at high cost, they will in most cases leave signs of having been opened, analyzed, probed, etc. (that's the "responding" part of TRM). The nuclear weapons people at Sandia and elsewhere (Russia, one now hopes) have been dealing with the problem for several decades. Some of their work has filtered out to the public literature. Smartcards often have basic TRM methods applied to them. If there's interest, I can summarize. --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at 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^756839 | PGP Public Key: by arrangement. From bwebster at pages.com Wed Nov 25 17:47:35 1992 From: bwebster at pages.com (Bruce F. Webster) Date: Wed, 25 Nov 92 17:47:35 PST Subject: News item Message-ID: <9211260049.AA05336@pages.com> Is this sudden flood of cypherpunk mail this afternoon mean we're all avoiding doing any work before taking off for Thanksgiving? ;-) AP news item in today's San Diego Union: Headline: "CIA chief hints change needed in ban on probing Americans" Excerpts: WASHINGTON--CIA Director Robert Gates says changes might be needed in the U.S. law that forbids the agency from collecting information about Americans or U.S. companies. Such changes might enable the CIA to better support the Justice Department and other law enforcement agencies, he said in an interview with the Associated Press. The idea grew out of a recent storm of accusations by Democrats in Congress, Justice Department officials and a federal judge that the CIA withheld information in the case of $5.5 billion lending scheme to Iraq by an Atlanta bank. ... [Gates said] the case of the Iraqi loans raises a broader issue of what the CIA is expected to do to aid law enforcement in such fields as financial crimes. Under current law, the CIA is strictly forbidden to collect information on Americans or American companies. "At some point it seems to me, very early on, we and Justice...and the Congress are going to have to...have some sort of serious discussion about whether there are changes in the law that are needed that will clarify some of the ambiguities and what we can and cannot do in support to law enforcement," Gates said. He did not elaborate. ... ---------------- From ncselxsi!drzaphod at ncselxsi.netcom.com Wed Nov 25 17:59:06 1992 From: ncselxsi!drzaphod at ncselxsi.netcom.com (DrZaphod) Date: Wed, 25 Nov 92 17:59:06 PST Subject: PGP on local machine (was Re: MacPGP) Message-ID: <58809.drzaphod@ncselxsi> In Message Wed, 25 Nov 92 10:30:09 PST, Eli Brandt writes: >You compose the message, using emacs or some other Turing-complete editor. >You hit the "PGPify" key [sequence]. >emacs echoes a special START string >The local comm program recognizes it and goes into "capture" mode. >emacs blats the plaintext to stdout, where it is captured. >emacs echoes a STOP string. >The comm program sees this, stops capturing, shells to DOS, and runs PGP. >emacs kills the original text block. >(emacs command ends) >The comm program shoves the cyphertext into the uploadt editor to write your messages then you've just lost the whole reason for encryption. TTFN! DrZaphod [AC/DC] / [DnA][HP] [drzaphod at ncselxsi.uucp] Technicolorized From gnu at cygnus.com Wed Nov 25 18:04:11 1992 From: gnu at cygnus.com (gnu at cygnus.com) Date: Wed, 25 Nov 92 18:04:11 PST Subject: RS232 Crypto Dongle (idea for widely accessible crypto technology) In-Reply-To: <9211260047.AA01958@servo> Message-ID: <9211260203.AA15805@cygnus.com> > I had this in mind too. But there's a problem -- if we have to depend > on commercial manufacturers to build these things, how will we know if > we can really trust them? ... > Unless, of course, we can get the technology to build PCMCIA cards > ourselves out of readily available parts... There's an implied assumption in the above that "we" and "commercial manufacturers" are not the same people, and that if "we" could build the cards "ourselves", then "we" could trust them. But any of "us" builds PCMCIA cards and offers them to "us" for sale, they will have to satisfy "us" that "we" truly understand its level of security. Enough pronouns? The point is that we can't trust ourselves any more than faceless manufacturers. It's more likely the manufacturers won't make some bonehead mistake that renders the system easy to break. And, as dramatized in "Sneakers", even the best people can be pressured by the government if they or their loved ones are vulnerable. John Draper was proposing to manufacture rs232 random number generators -- would you buy a used random number from this man? If you could see its design, you might. If not, probably not. There's a tradition that security software has to be made available in source form because the customers insist on it. Let's continue this trend and make sure it applies to hardware, too. John From rchilder at us.oracle.com Wed Nov 25 18:07:42 1992 From: rchilder at us.oracle.com (Richard Childers) Date: Wed, 25 Nov 92 18:07:42 PST Subject: chip verification ( Was: Tollhouse Cookies :-) Message-ID: <9211260206.AA08221@rchilder.us.oracle.com> "The crucial chips could be built under "open inspection" conditions, much like having source code for inspection prior to compilation on one's own--presumably trustworthy--machines. Several such vendors could be used, with independent auditors observing the processing steps throughout. (Merely the threat of a surprise inspection is probably enough to head off obvious attempts to insert hardware trapdoors and the like.) This seems like a solvable problem." It seems to me that an ostensibly digital device with a fixed number of pins could be regarded as a finite state system, and systematically analyzed accordingly, IE, traverse the set of possible combinations of pins and signal levels and verify that it behaves in accord with pub- -lically available specifications. I'm no circuit designer ( yet ), but it seems to me that the microchip might be subject to design to make it conform to such tests, yet still contain additional circuitry which is undocumented. It might also have analog circuitry, I suppose, although I cannot immediately conceive of a use for such a thing. ( Of course, nanotech rears its ugly head, but that sword cuts both ways and, until it manifests, is irrelevant. ) Perhaps a chip could be tested, at the cost of additional time, by a systematic profiling of the finite boundaries of the device as repre- -sented by the combination of pins being stimulated, the combination of pin input voltage levels, and the resulting pin output voltages. If you want to be fanatical, you can also profile the resulting fields. It seems to me that it would be difficult to defy such a systematic profiling. ( I guess one could also test the I:E:R ratios at each of the states to further detect bogus circuitry, as well as borderline products. ) Why quality assurance lines don't do this on a chip-by-chip level now is beyond me. I'll bet the Japanese do now, or are working on it ... -- richard ===== -- richard childers rchilder at us.oracle.com 1 415 506 2411 oracle data center -- unix systems & network administration Klein flask for rent. Inquire within. From yanek at novavax.nova.edu Wed Nov 25 19:29:33 1992 From: yanek at novavax.nova.edu (Yanek Martinson) Date: Wed, 25 Nov 92 19:29:33 PST Subject: advantages of RS-232 based crypto device Message-ID: <9211260329.AA12665@novavax.nova.edu> A number of people responded, both privately and publicly to my RS-232 dongle idea. Several offered help with the hardware/schematics design. Some thought that PCMCIA cards would be better for this. Theoretically, yes. They could contain more memory and processing power in a smaller space. There are several problems with PCMCIA. First, not nearly as many devices have PCMCIA interface as RS232. Second, you can not make a PCMCIA card yourself, nor can you easily open it and look what's inside. My proposed design would consist of only off-the-shelf parts, the schematic would be published, so anybody could build the device for himself. I might distribute it in the kit form, which would include all the parts and the PCboard, and a case. This way, you can test each component in any way you want, and then put the thing together by yourself. Even if you got the complete unit from me, you could open it up, and look inside. You could see if it actually corresponds to the schematic. Some people doubted the possibility of its second greatest advantage, the ability to work with any computer or terminal regardless of operating system, mail software, comm software, etc. Also it could be used between an ASCII terminal and a (non-trusted) host. Here is an example of a design that I think will work with any software/host/terminal/etc combination. If I am wrong, please let me know. NOTE: this is not the final design of the device, just an example. ===================================================================== Since the device needs to have a processor anyway, it may as well have a built-in simple line-mode editor that is good enough for composing mail messages. So to use the device to send mail, you would: 1. Give the mail command to your host (or BBS) using whatever command or menu selection you normally use to send mail. Then if the mail program puts you into a mode-based editor like vi, enter insert mode (press i or a). 2. Push the "encrypt" button on the device (or send a magic sequence from your terminal). 3. Type your message in a simple BBS style (in case you have not used a BBS, this is the kind of editor they usually use: You simply type text. Every line has a number. When you press return, the next line number appears. At the beginning of a line, you can issue commands for example with a slash or a dot. commands include things like DONE, ABORT, DEL LINE, INSERT, etc.) If you had the text prepared on the local machine, you could simply transfer the text, and then type the "DONE" command. All this while, the text is only stored in the memory of the crypto device, the remote host is still waiting for input. So plaintext never crosses the line or network. 4. When you are done, the text would be encrypted (you would select a public key from the keyring, or it could be automatically determined from preceding text (such as the e-mail address). You would have the option of signing the text. The device transfers the encrypted text to the host and becomes transparent. You then type the command to tell the host that you are finished typing the message, and off it goes! ========================================================================== Now, if you see any reason why the above would not work, please let me know. A number of people wondered if the tamper-proof memory for private key storage was necessary. Some other people wondered if it was in any way effective (i.e. if someone gets the device, they can just use it to decrypt/sign stuff; so what if they don't get they actual key out of it). I tend to agree. I will have to think some more about this. It would certainly make the design much simpler (and cheaper, and consistent with the desire for off-the-shelf parts) if I avoid use of such exotic hardware. The private key may be protected from use by un-authorized users by encrypting it with a key, and requiring it to be entered on a keypad on the device. Someone suggested that the key must be typed in periodically (every x minutes). The only case I could see a problems with this approach is if "they" get you while you are using the device. For the next x minutes they can decrypt any old messages they may have stored. I believe this addresses all the concerns that have been voiced about this device. If you have any other concerns, questions, or comments, please let me know. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From ebrandt at jarthur.Claremont.EDU Wed Nov 25 19:32:58 1992 From: ebrandt at jarthur.Claremont.EDU (Eli Brandt) Date: Wed, 25 Nov 92 19:32:58 PST Subject: PGP on local machine In-Reply-To: <58809.drzaphod@ncselxsi> Message-ID: <9211260332.AA23057@toad.com> > From: "DrZaphod" > >The comm program shoves the cyphertext into the uploadt editor to write your messages then > you've just lost the whole reason for encryption. I think what you're trying to say is that writing the message on an insecure machine gives it away. This is entirely true, but it sure beats giving away your secret key and passphrase. People were saying that they were unable to do their message editing locally -- if this is an insurmountable limitation, you'd do well to limit your disclosure to the one message rather than every secret you posess. If you *can* edit and encrypt locally, do it, of course. > [drzaphod at ncselxsi.uucp] Eli ebrandt at jarthur.claremont.edu From yanek at novavax.nova.edu Wed Nov 25 19:36:50 1992 From: yanek at novavax.nova.edu (Yanek Martinson) Date: Wed, 25 Nov 92 19:36:50 PST Subject: neat features that could be added to the crypto dongle Message-ID: <9211260336.AA12812@novavax.nova.edu> Here are some neat ideas: If you and me both had one of these devices, we could connect them, and exchange our public keys. We could also exchange other public keys on our keyrings. Another useful thing it could do: watch the incoming rs-232 traffic for anything that looks like a public key. When one is detected, you would have the option of storing it on your keyring. It could have an LCD display, and then it could calculate a hash function of someone's public key and display it. This would make it easy to verify keys by phone or any other means. Instead of spelling out the 130-character alphanumeric sequence you would only need to verify a short (maybe about 8 to 12 digits) number. As someone mentioned, if something has a keypad and an LCD display, it can also be a calculator. And, if it has two RS-232 ports it could be a break-out box or a line analyzer. But I think this is creeping featurism. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From gnu Wed Nov 25 19:38:08 1992 From: gnu (gnu) Date: Wed, 25 Nov 92 19:38:08 PST Subject: Steve Kent on certification trust paths Message-ID: <9211260338.AA23180@toad.com> Steve is one of the key folks in the Internet PEM project. He sent this message last month during a discussion of why PEM uses top-down key certification rather than the "mesh" style that PGP uses. I hope that our (cypherpunks) experience with mesh key exchange will teach us a lot about whether and how it works. Nobody has ever tried this before, so we are doing research! John Gilmore ------- Forwarded Message Message-Id: <9210212125.AA27956 at TIS.COM> To: Peter Williams Cc: pem-dev at TIS.COM Subject: Re: Perhaps OSI security is not possible in a liberal community! Date: Wed, 21 Oct 92 17:24:42 -0400 From: Steve Kent Peter, You have receibved replies from a couple of folks (via pem-dev) who have expressed views on why a strictly hierarchic certification system is not required. As the author of the words you cited in raising your question, and as an advocate of a strict certification hierarchy, let me respond. It is clear that one can construct a certification system which is not a tree, but rather is a mesh. The PGP approach is an example of such a scheme and X.509 permits this. However, there are a number of advantages to a hierarchy which have motivated its use in the Internet: In a pure certification mesh, one acquires certification paths by following chins of implied trust. It is not at all obvious that this approach scales well. The PGP folks do not yet have significant experience in this regard, so it will be interesting to see how the mesh develops over time. Most folks who have spent considerable time exploring this issue believe that unbounded transitive certification, with no required name relationships, is a bad idea. The rationale is that whatever trust one might accord to an entity may not apply transitively. I may give a house key to my neighbor to be able to open my house under certain circumstances, but that does not suggest that I would give the key to whomever that neighbor provides his key. It seems difficult to characterize the nature of trust in these "lateral" arrangements and applying trust transitively is even more difficult. From a user interface standpoint, it is generally agreed that most users are not capable of evaluating a certification path. In PEM we feel that a user should know the distinguished name (or an alias assigned by the user locally) of a message originator/recipient, and some indication of the policy under which the user was certified, e.g., a short-hand name for the PCA. This is about all we expect a user to be able to deal with. The though of a user really paying attention to (much less applying meaningful value judgements to) all of the DNs in a certification path boggles the mind. I won't clain to understand all the details of what PGP provides for managing key rings. However, if one were to provide a management tool for mesh certification in general, I think it ought to permit a user to construct a trust graph expressing the relationships implied by certification paths he acquires. The user might be able to express a degree of trust and a level of allowed transitive certification for each entity in the graph. Disply of this info, to allow a user to manage the graph, would be necessary. All in all, it seems to be pretty complex and it is highly questionable if most (many?) users could make use of this facility without getting confused. But, this analysis is based on reasoned speculation, not actual experience. The naming issues is a related, but somewhat indepedent topic. DNs provide many good features for use with a certification system. One wants the names to be globally unique and manageable in a distributed fashion. Being able to express a through, rich name is important if this technology is ever to expand beyond casual use in R&D environments. Note that DNS names are not great choices. Although there are close to a million DNS host names, that represents a very small portion of the population that one wants to serve with a system like PEM. Most DNS names are very short and will eventually reuslt in collisions as more individual and organizations are registered. The problem is worst in the U.S. where we have adopted a parochial scheme with GOV, EDU, COM, ORG, and MIL at the top, vs. other countries which prefix their DNS names with a country code. What's worse is that many DNS indivdiual names are not very mnemonic and thus don't offer much in the way of indentification outside of a very narrow context. There is sometimes confusion about the role of certificates. X.509 makes it clear that they serve only for identification, not authorization. This is improtant because it is difficult enough to manage them for identification purposes without overloading authorization info on them. Also, the entities who grant authorization may often be different from those who vouch for the identity of an individual (or organization) and thus this independent is appropriate. Often there seems to be a desire to bind more info into a certificate in support of authorization, but I (and many others) believe this to be a mistake. One can construct other certificates (like the PACs EMCA has defined) to use public key technology for authorization, leveraging off of certificates used for identification. Finally, there is revocation. We have adopted both a push and a pull facility for CRLs in PEM and the PEM CRL format differs slightly from that in X.509. Many folks fail to appreciate the subtleties of CRLs at first. Hot listing on a CRL says that either a key has been compromised OR a name has changed. If we have fine-grained, organizationally-related names, then these names will change with some frequency and thus CRL entries will arise. Because a certificate establishes a binding between a name and a key, it seems appropriate that only the entity which vouches for this binding (a CA of some tyep) should be able to revoke it. That is the model we use in PEM and we add the important feature of having each CA advertise when it will issue its next CRL, so that user's know when each CRL they hold is obsolete. Peter, I hope this note helps explain the very terse words I put in the PEM key management document. Steve ------- End of Forwarded Message From tcmay at netcom.com Wed Nov 25 20:07:06 1992 From: tcmay at netcom.com (Timothy C. May) Date: Wed, 25 Nov 92 20:07:06 PST Subject: Sharp Wizard as a Crypto Dongle? Message-ID: <9211260402.AA12908@netcom2.netcom.com> All the interesting discussion of building RS-232 crypto dongles, notably the proposal of Yanek Martinson, remind me of the idea kicking around of simply programming a Sharp Wizard (or Casio B.O.S.S., etc.) to do the same function. (And eventually much of our critical encryption will likely be done on more powerful devices like the Apple Newton, General Magic gizmo, and Eo thingamajig.) These devices have several advantages: 1. Cheap. $150 or less. 2. No construction required. 3. Not likely to have trapdoors or other limits, at least not in the hardware, or in the units you buy today at your local electronics superstore. 4. RS-232 connections for PCs, Macs, etc. (used to be as an add-on, now often bundled with the units). 5. LCD display, keypad, etc. (some of the features Yanek was envisioning in later models of his dongle). 6. A fairly slow CPU, but one which is well-integrated with the other features (and which saves us the effort of designing and debugging). 7. Some have PCMCIA capabilities. 8. They can be used for other thingss when not being used as a dongle. 9. New versions of the software (e.g., PGP 3.21) can be added more easily, I suspect, than in a custom-built RS-232 dongle. 10. It is unlikely the NSA, FBI, or Patent Office could "ban" such devices, as they are already widely deployed. Only the specific programs that make them act as crypto dongles would be "bannable," and I doubt this could be enforced. By the way, the same arguments could be applied to using cellular telephones as the base for building/programming portable, personal crypto devices. (An exciting talk at Hackers on mods to Oki 900 cellphones was an eye-opener.) I don't think an easy interface to RS-232 ports exists, but I know some cellphones interface to computers (the Oki 900 above sure did). --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at 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^756839 | PGP Public Key: by arrangement. From yanek at novavax.nova.edu Wed Nov 25 20:47:27 1992 From: yanek at novavax.nova.edu (Yanek Martinson) Date: Wed, 25 Nov 92 20:47:27 PST Subject: using personal organizers or palmtops for crypto Message-ID: <9211260447.AA14645@novavax.nova.edu> > notably the proposal of Yanek Martinson, remind me of the idea kicking > around of simply programming a Sharp Wizard (or Casio B.O.S.S., etc.) > to do the same function. I have thought of that before. Actually, I was thinking of using a notebook computer with 2 serial ports as a prototype/proof of concept. > These devices have several advantages: True. But there are also disadvantages: They generally don't have two serial ports. This may not seem like much, but is actually a serius problem. Since they tend to have small screens, weak keyboards, and not the greatest comm software, you might not like using it as your window into the cyberspace. The advantage of a standalone device with two rs232 ports is that you can continue to use your existing terminal, pc or a mac, along with all its conveniences. > 1. Cheap. $150 or less. I hope to make my device in this price range or less. I can not be sure yet because I don't have a definite hardware design completed, but that is the range I am aiming for. I don't know, maybe I am unrealistic, but I think that in kit form it could be significantly under $100. > 2. No construction required. If this idea ever takes off in a big way (about a hundred orders or so) then I have an electronics company that could build them for me. > 3. Not likely to have trapdoors or other limits, at least not in the > hardware, or in the units you buy today at your local electronics While they may not have any intentional trapdoors, since you don't have the full design specs, you can never be sure of everything that is going on within the machine. For example, if in my device I have a section of memory that holds the private key, and I clear it (overwrite with nulls) then I can be reasonably sure that if someone was to get the device they would not be able to retrieve the private key from anywhere. In a machine such as a Wizard, you never know where the number may end up, for example in some area of memory used for the auto-resume feature or some kind of cache. If a device was not designed with security in mind it is likely to be insecure. > 6. A fairly slow CPU, Might severely limit the length of keys you can handle, therefore the level of your security. > 7. Some have PCMCIA capabilities. See my previous post on why PCMCIA is not a very good choice of technology for this purpose. > 9. New versions of the software (e.g., PGP 3.21) can be added more > easily, I suspect, than in a custom-built RS-232 dongle. I plan to build it as a generic processor with two RS-232 ports. All the crypto stuff would be handled in software. So to cope with new formats, etc. all you would need to do is reprogram the EPROM. This is completely unrelated to the topic at hand, but: > By the way, the same arguments could be applied to using cellular > telephones as the base for building/programming portable, personal > crypto devices. (An exciting talk at Hackers on mods to Oki 900 > cellphones was an eye-opener.) I don't think an easy interface to > RS-232 ports exists, but I know some cellphones interface to computers > (the Oki 900 above sure did). What interfaced to the computer was the control functions (dial, signaling, etc.) It sure was fun and useful, but not nearly enough to make a secure telephone. The actual speech (that which you are trying to encrypt) is never actually digitized.... -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From sommerfe at orchard.medford.ma.us Wed Nov 25 21:38:50 1992 From: sommerfe at orchard.medford.ma.us (Bill Sommerfeld) Date: Wed, 25 Nov 92 21:38:50 PST Subject: Sharp Wizard as a Crypto Dongle? In-Reply-To: <9211260402.AA12908@netcom2.netcom.com> Message-ID: <9211260511.AA00154@orchard.medford.ma.us> I had the same idea, only with an HP48SX (I work for HP); the 48 is a little pricier, but cheaper than say the 95LX or similar pocket PC's. (I got as far as a DES implementation in user RPL -- I "ported" the Ferguson DES in a day or so; I haven't gotten around to slogging through converting it into system RPL or machine code). Progammable consumer products would be pretty good as *prototypes*, but not good enough for "production" use in the presence of a determined attacker due to lack of tamper-resistance. [my apologies if this came up before; I'm new to the list]. - Bill From fen at genmagic.com Wed Nov 25 21:41:23 1992 From: fen at genmagic.com (Fen Labalme) Date: Wed, 25 Nov 92 21:41:23 PST Subject: No Subject Message-ID: <9211260518.AA01581@> On the issue of digital cash and remailers tcmay writes: >Banks, escrow services, etc. will all have "reputations"... Note that a good reputation is good as gold. Now, when I get my remailer up and running, I'll run it for a while in "free mode" (while I get the bugs out) and then I'll put it into "reputation sharing mode" which works as follows: Every time I get a message to be re-mailed, I remember the sender's site name. Later, when I desire to mail something, I may choose to send it through that site. If operating in free mode, it passes through. If it is not a remailer or doesn't accept my message (via a bounce) I take it off my list of friendly mailers and and begin bouncing messages that it sends to me. This should, of course, all happen automagically. I realize that I am describing this somewhat poorly (it's late and I'm tired) but the basic concept is to get everuyone who wants to send mail through a re-mailer to become a remailer, or perhaps buy "friendship" with one through external means. This propogates remailers. The simplest form of barter is one for one. Fen From tribble at xanadu.com Wed Nov 25 22:23:39 1992 From: tribble at xanadu.com (E. Dean Tribble) Date: Wed, 25 Nov 92 22:23:39 PST Subject: An easy-to-reply anonymous mail scheme In-Reply-To: <9211252352.AA01919@nano.noname> Message-ID: <9211260605.AA04591@xanadu.xanadu.com> The only solution (and I think I mean ONLY) is positive filtering. When pseudonyms proliferate, the only way to cut down on trash is by filtering based on reputation. Since negative reputation can be avoided simply by creating another pseudonym, the only reputation that will make a difference is positive reputation: credibility. An example system would be one in which I give credibility and transitive credibility ratings to all the names whose posts I want to see. The transitive part lets me discover new people (who know people I respect who know people they respect...). Then anyone credible can introduce someone else around simply by deciding to read their mail (assuming their taste is good enough that people want to read what they're reading). This grows in several directions: AI, reputation services (magazines), etc. A public system with pseudonyms will require this very quickly. Reputation systems only work if things are digitally signed, of course (so readers and filters can't be spoofed). I will be talking about this more at the next cypherpunks meeting. dean From tribble at xanadu.com Wed Nov 25 22:38:29 1992 From: tribble at xanadu.com (E. Dean Tribble) Date: Wed, 25 Nov 92 22:38:29 PST Subject: Electronic Banking In-Reply-To: <9211252219.AA00550@netcom.netcom.com> Message-ID: <9211260619.AA04606@xanadu.xanadu.com> Currencies will almost certainly have to be backed by goods in order to be astablished. Would you want to keep your money in something that could collapse easily? There's been a lot of thought put into using things like mutual fund shares as the currency. dean From nobody at alumni.cco.caltech.edu Wed Nov 25 23:12:31 1992 From: nobody at alumni.cco.caltech.edu (nobody at alumni.cco.caltech.edu) Date: Wed, 25 Nov 92 23:12:31 PST Subject: No Subject Message-ID: <9211260713.AA01656@alumni.cco.caltech.edu> This entire business may be pretty simple. If we have anonymity both ways, (where one or neither party knows the others physical location), then who cares about the content of the message? You might as well send it in plain text, Except you need RSA just for the signitures so you know you aren't being spoofed. *RSA signatures ARE money.* Unless money (accouting, proof) is needed, you don't need RSA. What you do need is anonymity. {Of course throwing RSA on top of it with RSA encoded regular keys is a nice touch (no sense in giving anything away.)} ---- Now listen up kiddies, what you are playing with is sedition, conspiricy, and the like. In other words plain old politics. Adding mumbo-jumbo (crypto) technology doesn't change a thing. If you want to do this, it is a simple matter of building a large enough cooperative group. How big? Well bigger than the Hells Angels, Maybe a thousand people. I don't know. Depends on how rough it gets. But the proceedure is just mutual backscratching. We all accept and forward anonymous mail for each other. So long as it is coded, we can deny knowledge of the contents. That can go a long way as long as the basic activity (of forwarding) itself is not proscribed. There have been several suggestions here how this would be done. You send mail to a cooperative site, who forwards it. That same site will receive replies. You collect your mail with specific commands to dump the accumulated contents to some other node. It would be moderately tough to bug one node. A quick second skip would make it almost impossible to track, 3 quick skips to eternity. But the trick is to have a large net of standardized, cooperating sites. There have been suggestions to throw cypher-money into this equation to pay for the operation of the "MIXes" or the operators of the servicing nodes. But that won't work. In a hostile environment money won't buy civil disobedience. It's like you can't pay somebody else to go to war for you. We all have to shoulder part of the risk. We should evolve some standard "remailer/replier daemon" and run them as a common service. It is just our civic duty. The list of cooperating, volunteer sites would be published in a plain text group. You are either on the list or you aren't. Just the presence of such a cypher mob should stop the forces of darkness. -Gilbert From rebma!rebma!wmo at kksys.mn.org Thu Nov 26 00:22:10 1992 From: rebma!rebma!wmo at kksys.mn.org (rebma!rebma!wmo at kksys.mn.org) Date: Thu, 26 Nov 92 00:22:10 PST Subject: Remailer at rebma Message-ID: I've got Hal's PGP mods to the remailer code installed on rebma. The remailer is remailer at rebma.mn.org, and the PGP key to use is: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAisUI2QAAAEEAKgm07Hsje5KpmXYd5azk0R6AES+qK7LcofnVGojUs7GBghD WbwrmW8oOEOhRorlShRALKeYspV4xYIw4WDkJcJxuf1B254scz1urF/Eem3zPW9b yPAx7W/cGwvs6SouZvFcSDq4v1zApvGE9hP4szPzHeGmVr0NVNeaDK0guoCpAAUR tCBSZW1haWxlciAocmVtYWlsZXJAcmVibWEubW4ub3JnKQ== =/qHx -----END PGP PUBLIC KEY BLOCK----- See Hal's previous messages for how to use the remailer, or write me, and I'll dig his messages up. I liked Fen's idea about bartering remailers. I'm all for it. -Bill -- Bill O'Hanlon wmo at rebma.mn.org From rebma!rebma!wmo at kksys.mn.org Thu Nov 26 00:22:31 1992 From: rebma!rebma!wmo at kksys.mn.org (rebma!rebma!wmo at kksys.mn.org) Date: Thu, 26 Nov 92 00:22:31 PST Subject: MIME Message-ID: I got the metamail stuff running on my machine. I think it's a good way to get the multimedia mail job done. Does anyone on the list have a better .mailcap entry for pgp than the following....? application/pgp ; pgp < %s ; label="PGP encrypted text" ; compose="pgpcompose %s" where pgpcompose is a quick hack that looks like: #!/usr/bin/ksh rm /tmp/pgpcompose vi /tmp/pgpcompose echo What key? read key pgp -mae /tmp/pgpcompose $key mv /tmp/pgpcompose.asc $1 exit 0 I've just been fooling around with metamail for a couple days, and I don't know what the best way to include PGP is... This seems to work, but I'm guessing I'm missing something more elegant. -Bill -- Bill O'Hanlon wmo at rebma.mn.org From Postmaster at UCS.Cam.AC.UK Thu Nov 26 00:34:19 1992 From: Postmaster at UCS.Cam.AC.UK (Postmaster) Date: Thu, 26 Nov 92 00:34:19 PST Subject: Failed Fail Report Message-ID: The enclosed fail report failed to reach it's intended recipient because of the use of the unbracketed IP number. HOWEVER, surely there should be a -request address for cypherpunks to which should be in the Sender: field so that fail reports go back to the list maintainer and not the originator of the article. Tim Brooks Postmaster(@uk.ac.cam.ucs, @uk.ac.cam.phx, @uk.ac.cam.cus, @uk.ac.cam.ppsw) Postmaster(@ucs.cam.ac.uk, @phx.cam.ac.uk, @cus.cam.ac.uk, @ppsw.cam.ac.uk) University of Cambridge Computing Service Tel: 0223-334709, Int: +44 223 334709 New Museums Site Fax: 0223-334678, Int: +44 223 334678 Pembroke Street Telex: 81240 CAMSPL G CAMBRIDGE E-Mail(JNT): T.Brooks at UK.AC.Cam.UCS CB2 3QG United Kingdom "(Internet): T.Brooks at UCS.Cam.AC.UK X.400: /I=T/S=Brooks/OU=Computing-Service/O=Cambridge/PRMD=UK.AC/ADMD= /C=GB/ > Accepted: 17:57:03 25 Nov 92 > Submitted: 17:29:12 25 Nov 92 > IPMessageId: <"ppsw1.cam..157:25.10.92.17.28.53"@ppsw.cam.ac.uk> > From: MAIL-DAEMON > To: FAILREPTER at uk.ac.cam.phx > Subject: Delivery Report (failure) for fnerd at 192.9.200.3 > Received: from ppsw.cam.ac.uk by ppsw1.cam.ac.uk id <05165-0 at ppsw1.cam.ac.uk>; > Wed, 25 Nov 1992 17:29:12 +0000 > Message-Type: Delivery Report > Content-Identifier: Fail Report > > ------------------------------ Start of body part 1 > > This report relates to your message: Subject: Fail Report, > Message-ID: , > To: fnerd at 192.9.200.3 > of Wed, 25 Nov 1992 17:28:52 +0000 > > Your message was not delivered to fnerd at 192.9.200.3 > for the following reason: > Unknown Address > Unknown domain '192.9.200.3' > > ***** The following information is directed towards the local administrator > ***** and is not intended for the end user > * > * DR generated by: mta ppsw1.cam.ac.uk > * in /PRMD=UK.AC/ADMD= /C=GB/ > * at Wed, 25 Nov 1992 17:28:53 +0000 > * > * Converted to RFC 822 at uk.ac.cam.ppsw1 > * at Wed, 25 Nov 1992 17:29:12 +0000 > * > * Delivery Report Contents: > * > * Subject-Submission-Identifier: [/PRMD=UK.AC/ADMD= /C=GB/; * Content-Identifier: Fail Report > * Subject-Intermediate-Trace-Information: /PRMD=UK.AC/ADMD= /C=GB/arrival Wed, 25 Nov 1992 17:28:52 +0000 action Relayed > * Subject-Intermediate-Trace-Information: /PRMD=UK.AC/ADMD= /C=GB/arrival Wed, 25 Nov 1992 17:28:40 +0000 action Relayed > * Content-Correlator: Subject: Fail Report, > * Message-ID: , > * To: fnerd at 192.9.200.3* Recipient-Info: fnerd at 192.9.200.3, > * /RFC-822=fnerd(a)192.9.200.3/OU=PP Switch/O=Cambridge University/PRMD=UK.AC/ADMD= /C=GB/; > * FAILURE reason Unable-To-Transfer (1); > * diagnostic Unrecognised-ORName (0); > * last trace (ia5 text (2)) Wed, 25 Nov 1992 17:28:40 +0000; > * converted eits ia5 text (2); > * supplementary info "Unknown domain '192.9.200.3'"; > ****** End of administration information > > ------------------------------ Start of forwarded message 1 > > Received: from phx.cam.ac.uk by ppsw1.cam.ac.uk > with NIFTP (PP-6.0) Cambridge as ppsw.cam.ac.uk > id <05157-0 at ppsw1.cam.ac.uk>; Wed, 25 Nov 1992 17:28:53 +0000 > Date: Wed, 25 Nov 92 17:28:40 GMT > To: fnerd at 192.9.200.3 > From: Mail Server > Subject: Fail Report > Message-ID: > > Your message was not delivered to one or more of: > LI10000 at uk.ac.cam.phx > > Recipient has too many outstanding messages in message store: 'LI10000 at UK.AC.CAM.PHX' > No valid recipients in JNT header > > Failed message follows: > > Received: from relay2.UU.NET by ppsw1.cam.ac.uk > with SMTP (PP-6.0) International as ppsw.cam.ac.uk > id <05143-0 at ppsw1.cam.ac.uk>; Wed, 25 Nov 1992 17:28:32 +0000 > Received: from toad.com by relay2.UU.NET > with SMTP (5.61/UUNET-internet-primary) id AA07054; > Wed, 25 Nov 92 12:20:09 -0500 > Received: from cygnus.com by toad.com id AA12348; Wed, 25 Nov 92 09:17:33 PST > Received: from relay2.UU.NET by cygnus.com (4.1/SMI-4.1) id AA26873; > Wed, 25 Nov 92 09:17:10 PST > Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET > with SMTP (5.61/UUNET-internet-primary) id AA05539; > Wed, 25 Nov 92 12:15:15 -0500 > Received: from smds.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) > id 121431.10955; Wed, 25 Nov 1992 12:14:31 EST > Received: from waldo by smds.com (4.1/SMI-4.1) id AB05506; > Wed, 25 Nov 92 11:29:04 EST > Message-Id: <9211251629.AB05506 at smds.com> > Sender: fnerd at 192.9.200.3 > Date: Wed, 25 Nov 1992 12:40:24 -0800 > To: cypherpunks at com.toad > From: fnerd at com.smds (FutureNerd Steve Witham) > Subject: Re: Random Numbers Boxes and Cypher Processers > > >Why do encryption in the modem instead of the host cpu? > > A point that hasn't been made painfully clear yet: "DSP--Digital > Signal Processor" chips are really just fast processors for repetitious > arithmetic--just what RSA needs. Maybe some experience in > programming them for that sort of purpose would be useful. > > - -fnerd > fnerd at smds.com (FutureNerd Steve Witham) > > > ------------------------------ End of forwarded message 1 From tony at morgan.demon.co.uk Thu Nov 26 01:30:46 1992 From: tony at morgan.demon.co.uk (Tony Kidson) Date: Thu, 26 Nov 92 01:30:46 PST Subject: Electronic Banking Message-ID: <782@morgan.demon.co.uk> In message <9211252219.AA00550 at netcom.netcom.com> you write: > > Warning! Recently, a bunch of bowlers (women, no less) were busted for > illegal gambling because of their "pot" they were bowling for. After > much public outcry and laughter at the authorities, the charges were > either dropped or reduced. I mention this because casual bowlers evoke > sympathy, hackers and cypherpunks do not. Using the net, the 'banker' could easily be 'offshore' and not subject to US law in these matters. After all the internet reaches into Canada and obviously (from my point of view) to the UK. I think a more real problem with anonymous banking, is not one of 'trust' in the 'banker' but in his net access. What do you do when your banker, for whatever reason, becomes unreachable? Regards Tony ------------------+-------------------------------+--------------------------+ | Tony Kidson |`morgan' is an 8MB 486/33 Cat-| Voice +44 81 466 5127 | | Morgan Towers, |Warmer with a 670 MB Hard Disk.| E-Mail | | Morgan Road, |It resides at Morgan Towers in| tony at morgan.demon.co.uk | | Bromley, |Beautiful Down Town Bromley. | tny at cix.compulink.co.uk | | England BR1 3QE | -=<*>=- | 100024.301 at compuserve.com| +=================+===============================+==========================+ From crunch at netcom.com Thu Nov 26 01:37:40 1992 From: crunch at netcom.com (John Draper) Date: Thu, 26 Nov 92 01:37:40 PST Subject: Mac PGP report and Rander progress Message-ID: <9211260933.AA04417@netcom2.netcom.com> Mac PGP effort: After talking with Phil Zimmerman, we decided to break the MacPGP effort into two teams. A short term team as it currently stands now, with the origional members, and a long term team to change PGP into a set of C Libraries that can be used with ANY platform or API. The short term team consists of its current members who are doing current work on the Mac implementation. Next week, perhaps on Wednesday Evening at 7 pm, we will be setting up a conference call to talk about all of the details, and introduce each other. My role in this currently will be that of Email coordinator between the Mac PGP effort and the other platforms. It is obviously clear that there is still a lot of mis-trust that people have in me. I guess it's still very hard to ditch that "Once a criminal- always a criminal" attitude. Phil Karn says: >John Draper was proposing to manufacture rs232 random number >generators -- would you buy a used random number from this man? This is EXACTLY my point. So I WILL be publishing the schematic and I expect the Rander box will be put through it's paces. I have simplified the circuit immensly, and even eliminated the AD converter, but not sure the design works, but want to run the design by a few other HW types before I "breadboard" it. I think I got it down to 3 chips including the UART. Two CMOS chips, a Latch and a gate I'm using as a comparitor, and the UART plus a noise source. Gack!! All these years I try and ELIMINATE noise, and now I am LOOKING for noise. By biasing one of the gates, into the linear mode, it doubles as the amplifier for the noise source. I've gone eligantly simple with the design, I just hope it works. Perhaps this circuit can be integrated into Yanek's Dongle. Phil K. writes: >>My thinking is to limit the external "dongle" to the one function that >>is truly sensitive and worthy of special protection: RSA secret key >>operations. Eric Hughes replies: >Phil's comment are right on. There is a need for you secret keys >to be easily and physically relocatable. The Obvious, cheapest, but perhaps not the best way, is to keep your key on a floppie. More later .... From gg at well.sf.ca.us Thu Nov 26 02:43:35 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Thu, 26 Nov 92 02:43:35 PST Subject: How far is to far? Message-ID: <199211261042.AA23055@well.sf.ca.us> Miron Cuperman responds to my concerns about the IRS's claims on barter systems by saying, "How do you think the IRS is going to trace those banks and customers behind all the anon mixes?" I must really disagree here. If we start sneaking around in the shadows of legality, we will eventually bring down some nasty attention which will not help us. Privacy itself is a mainstream issue. Dumping all forms of taxes is not a mainstream issue, in fact the mainstream regards tax resisters as fringies of the worst order. This is not to debate the merits of the substantive issues involved, just to recognise the major PR problem which exists and say I believe we should stick to the main issue. I for one don't want the Feds to have an excuse to lock up the whole net or our little fragments of it. We can minimise taxation and stay completely within the law by operating as a volunteer not-for-profit network. And then if the Feds come down on us for using unregistered crypto keys, we have a new issue that the public haven't become jaded over, which can be made much of in the media. And I would also say that it's not good to give potential adversaries an excuse for saying we're doing crypto simply in order to hide illegal activities such as "tax cheating" or whatever; next it will be dope and kiddie porn and bank robbery via ISDN, eh...? -gg From gg at well.sf.ca.us Thu Nov 26 02:55:00 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Thu, 26 Nov 92 02:55:00 PST Subject: PGP on local machine (was Re: MacPGP) Message-ID: <199211261053.AA23687@well.sf.ca.us> Eli discussed some ideas regarding online encryption... it suddenly occurred to me that if you were connected to the phone line while doing your crypto processing, it's entirely possible that some signal would leak through and if your phone line was being monitored, the nastie-wasties would get the whole thing including your private key. Uh-oh, very bad. Thus the need for some kind of hardware device which isolates the line and all that. Perhaps a specifically cryptographic modem as has been proposed by others here. And perhaps a tweak in the software which requires that the user set these options manually at some point, where a warning message would occur to say, "don't do on-line crypto unless you have (one of the protected modems)." -gg From gg at well.sf.ca.us Thu Nov 26 03:17:22 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Thu, 26 Nov 92 03:17:22 PST Subject: Electronic Banking Message-ID: <199211261116.AA24529@well.sf.ca.us> Tim and others write with concern about the possible legal consequences of setting up a model digital economy. I would like to suggest that there may be very little to worry about here. This entire project constitutes a research exercise which will no doubt be written up for publication (at least online publication, which makes sense culturally given the nature of the community of interest). It's research and education. The amounts of "digital money" involved can be utterly miniscule: pennies. This is a "token economy" in the same sense as when psychiatric hospital inmates work on the ward for tokens they can trade in for snacks and so on, or a highschool economics class does a similar exercise using Monopoly-type play money. This is not illegal any more than any other social science project would be illegal if all the subjects were adults giving informed consent. Pennies are not a controlled substance nor are they a weapon (unless dropped on people from high places... :-). By analogy I'm thinking of the laws against bigamy/polygamy, and a group of adults getting together to study the question of the effects of different kinds of marital arrangements. So they have a group where they "pretend" to carry out different arrangements and then examine the social dynamics resulting from each. It's quite obvious we're all concerned about the larger social impacts of the possibility of a transition to a cashless economy; and we're hypothesising possible negative consequences and trying to work out solutions. That is entirely admirable, and can be presented as such to anyone who cares to listen to the case. If this needs any further work to develop research angles, I'll gladly come up with a bunch of surveys and other measures, and we can put them into use and harvest some nifty statistical results which might be publishable in the academic literature. -gg From gg at well.sf.ca.us Thu Nov 26 03:24:33 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Thu, 26 Nov 92 03:24:33 PST Subject: RS232 Crypto Dongle (idea for widely accessible crypto technology) Message-ID: <199211261123.AA24844@well.sf.ca.us> Re Phil's items on the Crypto-Dongle. I'm in favor of a device having a keypad for PIN entry, with a fail --> destroy function. Making it small enough to be kept on one's person all the time, virtually guarantees other manufacturing compromises which would result in degraded reliability or increased potential for physical breakage. It should not be necessary to carry it on you; in any case, possession of one might raise eyebrows in some quarters. I believe that carrying out the entire crypto operation in the dongle is preferable to having it only do the secret key RSA processing; if for no other reason, compatibility problems that might result in creation of platform-specific dongles. Better to have one Universal Dongle that needs only a platform-specific user interface. The dongle (suggested brand name: Codepack) could also be sold as a sort of blank slate into which a user would load his preferred crypto software. Now we have a generic product which can be sold over the counter without prescription, as it were. -gg From yanek at novavax.nova.edu Thu Nov 26 07:21:57 1992 From: yanek at novavax.nova.edu (Yanek Martinson) Date: Thu, 26 Nov 92 07:21:57 PST Subject: reputation In-Reply-To: <9211260605.AA04591@xanadu.xanadu.com> Message-ID: <9211261521.AA26207@novavax.nova.edu> > filtering based on reputation. Since negative reputation can be > avoided simply by creating another pseudonym, the only reputation that > will make a difference is positive reputation: credibility. What's to stop you (once you have some "reputation") from creating 250 other pseudonyms or "identitites", giving them all a "reputation", and then create another identity, and have these 250 all give this one as much as possible, in effect creating an identity with a lot of "credibility" out of thin air? -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From yanek at novavax.nova.edu Thu Nov 26 07:54:44 1992 From: yanek at novavax.nova.edu (Yanek Martinson) Date: Thu, 26 Nov 92 07:54:44 PST Subject: PGP on a multiuser system In-Reply-To: Message-ID: <9211261554.AA26688@novavax.nova.edu> > where pgpcompose is a quick hack that looks like: > #!/usr/bin/ksh > > rm /tmp/pgpcompose > vi /tmp/pgpcompose > echo What key? > read key > pgp -mae /tmp/pgpcompose $key > mv /tmp/pgpcompose.asc $1 > exit 0 This is not a very good way of doing this unless this is on a single-user linux system where youhave read all the source, and compiled it yourself. First, if on a multi-user system, what happens if two people run pgpcompose? At the very least, use code like "vi /tmp/pgpcompose.$$", which will append your process ID to the temp file name. It is NOT a good idea to keep the plain text in a disk file, even for a little while. It would be very easy for someone to set up a crontab entry which looks for files of the name /tmp/pgp*, and copies them to a hidden directory. You would never even know that it was happening. If you absolutely MUST do crypto on a multiuser machine, at least try not to keep plaintext or private keys in files. For example, you could instead rewrite the above script to call vi directly on what will become the output cyphertext file. Then the user types in plaintext, and does not save the file. The file (while still only in memory) is piped (!G) through pgp by the user. This is still not very secure, since it would be not too difficult for someone to have a version of vi that saves everything that is piped in a special file. Or pgp may be modified to do the same. Or if you compile pgp yourself every time, the C standard input routines may be modified to do the logging. You get the picture. There is no security on a multiuser system. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From yanek at novavax.nova.edu Thu Nov 26 08:04:46 1992 From: yanek at novavax.nova.edu (Yanek Martinson) Date: Thu, 26 Nov 92 08:04:46 PST Subject: Why electronic banks should be Redundant & Distributed In-Reply-To: <782@morgan.demon.co.uk> Message-ID: <9211261604.AA26880@novavax.nova.edu> > UK. I think a more real problem with anonymous banking, is not > one of 'trust' in the 'banker' but in his net access. What do you > do when your banker, for whatever reason, becomes unreachable? The best banker deamon would run multiple copies on widely separated hosts/ networks, and keep each other up to date on accounts/balances. They would be logically one entity, by sharing crypto keys. So if one is cut off from the net, or even destroyed, you just send your messages to one of the others. When it comes back up, the others update it with current info. Somewhat similar (not exactly, since they do not communicate to each other) existing system is archie. Imagine that your life or work depended on constant access to archie. When there was only one archie at quiche.mcgill.ca you could have said "What do you do when the archie, for whatever reason, becomes unreachable?". Now that there are many archies, the simple answer is use one of: archie.sura.net (USA, Mexico, etc) archie.mcgill.ca (Canada) archie.funet.fi (Finland/Mainland Europe) archie.au (Australia/New Zealand) archie.doc.ic.ac.uk (Great Britain/Ireland) How likely do you think ALL of these widely separated entities could be simultaneously destroyed/disconnected? -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From richard_mezirka at askinc.ask.com Thu Nov 26 09:24:21 1992 From: richard_mezirka at askinc.ask.com (Rich Mezirka) Date: Thu, 26 Nov 92 09:24:21 PST Subject: Electronic Banking Message-ID: <9211261718.AA28906@askinc.ask.COM> IRS regulations related to 1099-b and 1099-misc make it LEGAL providing all parties and the BANK file with the IRS. Bank MUST file when over 100 transactions per year are recirded. Individuals must file each transaction. Add some rules for mandatrory electronic filing when movre than 500 (I think that's the limit) transactions are posted. ZAdd another hassle with mandatory 20% of value must be withheld and filed with IRS inlieu of taxes... (reference 1992 IRS publication on 1099 processing, pages 10-12... pub number available on request)(I left my copy at the office). As I told Tim, this smack s of Al Capone like harassment... "We''' make it WORSE if we catch you" BUT I have personal experience with IRS in 1980, 81, 82 as they attacked barter (I designed and developed software for an electronic settlement system for Trade Systems Corporation in San Jose; we did about 4 million/year unitl the IRS audits startedf and then all big players got tax attacked). for those without experience with our IRS, remember they do not live within our regulary judiciary (innocent until proven guilty) system with open courts... they seize first and have a closed hearing system underwhich you get to negotiate a settlement to get YOUR stuff back, maybe. (references available upon request). They use local marshalls with large guns and IRS judical orededers to tsake what everthey thiink they are due. Again, as I told Tim, we should continue our public discussion of the principles we hold dear and continue our efforts at preventing further erosion. We should also be very careful about stepping on the dragons' tails until we are privacy protected... principlesa nd theorey public, practice and tactics private. spreading the sanity, quietly Rich From tcmay at netcom.com Thu Nov 26 11:44:30 1992 From: tcmay at netcom.com (Timothy C. May) Date: Thu, 26 Nov 92 11:44:30 PST Subject: Cypherpunks List (fwd) Message-ID: <9211261940.AA15763@netcom.netcom.com> Cypherpunks, Happy Thanksgiving! I sent the following message to the "Extropians" list, a list centered around discussions of politics, technology, the future, "uploading," transhumanism, and the like. (As with our list, they can be subscribed to with the "-request" form. Several requests for more information about our list prompted me to write this summary piece. Inasmuch as our existence has been publicized in Mondo, on alt.hackers, and in various references in messages, I felt it appropriate to tell them a few things about what the list is about. Our address is at the very end of the article, so there's a minor obstacle for truly casual readers to overcome. I'm forwarding it to you folks because we've had a lot of new subscribers ourselves, and they may like to hear some of this stuff. I apologize to those who are getting this twice. -Tim May Forwarded message: To: Extropians at gnu.ai.mit.edu From: tcmay at netcom.com (Timothy C. May) Subject: Cypherpunks List Date: Thu, 26 Nov 92 10:51:01 PST The Cypherpunks List -- A Thanksgiving Message I guess it's time to say a few words about the "Cypherpunks" list, which I've referred to several times in the last few months. Eric Hughes, the list administrator and initial organizer of our first meeting, has also mentioned the group in several places, and the latest "Mondo 2000" actually gives the address, so the information's pretty much out by now. We've avoided the "cattle call" form of invitation, where public announcements are made and subscribers flood in. But we also haven't gone to the other extreme of requiring some puzzle to be solved (as with posting to "alt.hackers," which usually requires some hacking of the posting software to "get in.") Cracking a cypher is not a requirement, though some probably think it should be. A few points: * The name "Cypherpunks" started out as a pun by Jude Milhon, an editor at "Mondo 2000," when she said "You guys are just a bunch of cypherpunks!" We initially debated calling our informal group something more staid like "The Cryptography Research Society," partly to protect ourselves by emphasizing the "research" aspects, but the joke name stuck. So, like it or not, it's "Cypherpunks." It turns off some, turns on others. C'est la vie. * Note that we have very little to do with the Gibsonesque vision of punked-out outlaws and virtual reality escapades, though in fact some of our members are active in Bay Area start-up companies doing VR. I would say Vernor Vinge's "True Names" is more descriptive of what we're doing. * About a hundred or so folks are on the list, including some journalists (gulp!), and even some "*.mil" sites (!!). But since what we're doing is strictly "research," we are of course safe. * The focus is on cryptology, anonymous remailers, hardware support, PGP, digital cash, "dining cryptographers" nets, and so on. Too much to recapitulate here. * By focussing on "research" into these areas, we feel we are safe against attack by government agencies. Time will tell. These issues of security, privacy, remailers, digital pseudonyms, etc., are hot topics in the crypto community, and all we are really doing is applying these ideas and doing experiments, the better to learn. (Some of the work on "webs" of trust in PGP systems, on issues with anonymous remailers, and on the development of "digital reputations" lies in uncharted territory, that is, we're doing true research.) * Several Extropians are active on the list, as you may have gathered from cross-posts and comments. * Because many of the early members live in the Bay Area (Northern California, Silicon Valley), we've had three physical meetings so far. John Gilmore, a founder of Cygnus Support, has graciously offered his facilities for our meetings, which typically happen on Saturday afternoons. The schedule gets posted on the list, of course. * Some exciting progress has already been made. Eric Hughes and Hal Finney have implemented a PERL-scripted remailer which provides anonymous forwarding (though the security is only "manual"), and 2-way remailers with digital pseudonyms seem imminent. Integrating PGP into mailers remains a problem, as those of you who use PGP already know, and several of our members are working with the PGP and MacPGP teams. * "Crypto dongles" to attach to RS-232 ports are being pursued by Yanek Martinson (an Extropian as well), George Gleason, John Draper ("Cap'n Crunch"), and others. Lots of enthusiastic debate. * FIDONet users are also involved, including Tom Jennings, the founder of FIDONet, in 1984. This brings an exciting new flavor for most Internetters. * Like the Extropians list, the Cypherpunks list is relatively free from flames and personal attacks. We all realize we're interested in roughly the same goal, even though some are Libertarians (naturally) while others are Socialist, Marxists, and Act Up! activists. (Interestingly, we've never had any real flames on politics. We almost never argue political views. This may of course be alien to readers of the Extropians list! :-} ) * So why isn't the list sent out in encrypted form? A little thought will reveal the uselessness of encrypting a widely distributed list that's essentially open to anyone who sends in a request! Still, there is some talk of encrypting in the future, partly to weed out the casual readers (for whatever reason) and partly to just get the volume of encrypted messages up. If you've read this far, and are really interested in joining the list, send a request to "cypherpunks-request at toad.com". This is standard list procedure, of course. But please don't then complain about the list volume! --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at 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^756839 | PGP Public Key: by arrangement. From yanek at novavax.nova.edu Thu Nov 26 11:57:16 1992 From: yanek at novavax.nova.edu (Yanek Martinson) Date: Thu, 26 Nov 92 11:57:16 PST Subject: your mail In-Reply-To: <9211260713.AA01656@alumni.cco.caltech.edu> Message-ID: <9211261956.AA02380@novavax.nova.edu> > If you want to do this, it is a simple matter of building a large > enough cooperative group. > > How big? Well bigger than the Hells Angels, Maybe a thousand > people. I don't know. Depends on how rough it gets. Right now the list has 168 individual subscribers. Plus, there are 6 gateways to local redistribution lists. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From jdugger at reed.edu Thu Nov 26 13:06:13 1992 From: jdugger at reed.edu (Jay Dugger) Date: Thu, 26 Nov 92 13:06:13 PST Subject: Subscription Message-ID: Sorry about the bandwidth waste, but please subscribe me. ------------------------ Jay Dugger jdugger at reed.edu ------------------------ PGP Public Key available From gnu Thu Nov 26 13:40:36 1992 From: gnu (gnu) Date: Thu, 26 Nov 92 13:40:36 PST Subject: chip verification ( Was: Tollhouse Cookies :-) In-Reply-To: <9211260206.AA08221@rchilder.us.oracle.com> Message-ID: <9211262140.AA12038@toad.com> > It seems to me that an ostensibly digital device with a fixed number > of pins could be regarded as a finite state system, and systematically > analyzed accordingly, IE, traverse the set of possible combinations of > pins and signal levels and verify that it behaves in accord with pub- > -lically available specifications. This is not useful, because devices can have internal state. For example, a device could do the same thing in response to an input for 1000 times, and then do something different when a counter reaches 1001. I've been employed writing test vectors for chips. It *is* possible to write a set of tests that will verify that a piece of hardware matches its design (which, BTW, is software, stored on a disk in a database). Every chip vendor does this on every chip they make, to detect manufacturing defects. These tests will not detect hardware that has been deliberately modified to pass the tests, but to do something different in actual operation. This is an obvious risk when the tests are necessarily publicly available. Of course, if a particular form of modification is suspected, people can write new tests that look for it. But it becomes like the virus protection game: looking for the signatures of known viruses doesn't protect you from unknown ones. There's no proven way to detect all modifications. John Gilmore PS: See also Ken Thompson's paper, "reflections on trusting trust", which was published as an ACM Turing Award lecture among other places. Your CAD software could have been modified so that it inserts a mod into your chip that doesn't appear in the chip's source code. The compiler used to build the CAD software could've been modified to insert the above mod into your CAD software binaries as they are compiled. A compiler binary used to build the *compiler* sources into binaries could have been modified to insert the compiler mod described above. Even if you have full sources, you can't trust the system -- you have to trust the people who bootstrapped it, and all the people who wrote the tools *they* used. "Proving" anything becomes very slippery here. From gg at well.sf.ca.us Thu Nov 26 15:08:58 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Thu, 26 Nov 92 15:08:58 PST Subject: chip verification ( Was: Tollhouse Cookies :-) Message-ID: <199211262305.AA20384@well.sf.ca.us> John Gilmore points out that in hardware, "proving anything becomes very slippery..." Seems to me that we can establish degrees of confidence, in much the same way as pertains to social sciences research: probabilities that a given result is accurate. So for instance, we could say that a device made with parts purchased randomly for cash over the counter at a number of different suppliers, might have a lower probability of compromise than one made with parts mail-ordered from the same large supplier to the producer's workshop every time. Over time it may be possible to quantify the measure of confidence. -gg. From phr at napa.Telebit.COM Thu Nov 26 16:04:18 1992 From: phr at napa.Telebit.COM (Paul Rubin) Date: Thu, 26 Nov 92 16:04:18 PST Subject: Mac PGP report and Rander progress In-Reply-To: <9211260933.AA04417@netcom2.netcom.com> Message-ID: <9211270003.AA20577@napa.TELEBIT.COM> Has anyone given any thought to generating random numbers by counting particle emissions from a radioactive source? This might be more reliably random than using purely electronic means. From karn at qualcomm.com Thu Nov 26 23:06:08 1992 From: karn at qualcomm.com (Phil Karn) Date: Thu, 26 Nov 92 23:06:08 PST Subject: The NSA Backs Down!! Message-ID: <9211270705.AA06258@servo> r a AM-DeclassifiedCodes 11-26 0287 ^AM-Declassified Codes,0266< ^Government Reverses Itself, Declassifies Studies On Secret Codes< SAN FRANCISCO (AP) _ The National Security Agency has reversed itself and declassified two cryptography texts it previously had insisted were secret even though they were available in public libraries. The announcement Wednesday came as a result of a lawsuit filed under the Freedom of Information Act by a Silicon Valley computer scientist who believes private companies should have more access to secret code technology. The analyst, John Gilmore, asked the spy agency to declassify the 50-year-old studies on encryption _ the science of designing codes. The U.S. Department of Justice recently had threatened to prosecute Gilmore under a 1950s espionage law if he distributed copies of the texts. In court papers, an NSA official said disclosure of the information could seriously damage national security. The agency is in charge of protecting U.S. codes and cracking foreign ones. Gilmore is a board member of the Electronic Frontier Foundation of Cambridge, Mass. The organization believes now-secret encryption technology is necessary for private companies to make modern computer and telephone systems secure from tampering. ``Why shouldn't an American citizen be able to go to the library and teach himself about encryption?'' asked Michael Godwin, a staff counsel at the foundation. Gilmore said he found copies of the once-declassified studies, made secret again by the Reagan administration, in public libraries. They presently are used as texts in military classes. He said he plans to distribute 20 or 30 copies to other libraries. The studies are about 1,000 pages long. AP-DS-11-26-92 1837EST< From cordones at IMAGE.CS.NYU.EDU Thu Nov 26 23:21:34 1992 From: cordones at IMAGE.CS.NYU.EDU (Deus Ex Machina) Date: Thu, 26 Nov 92 23:21:34 PST Subject: Returned mail: User unknown Message-ID: <9211270719.AA20772@IMAGE.CS.NYU.EDU> So..any courageous Cypherpunk that can post those papers or tell us what to look for in a library? (anonymous post, whatever). ----------- El Zorro. From tcmay at netcom.com Fri Nov 27 00:30:10 1992 From: tcmay at netcom.com (Timothy C. May) Date: Fri, 27 Nov 92 00:30:10 PST Subject: (fwd) 8052-Based Crypto Engine Message-ID: <9211270825.AA03153@netcom.netcom.com> I just found this is sci.crypt. It may be useful for the "crypto dongle" folks. --Tim May Newsgroups: sci.crypt,comp.arch Subject: 8052-Based Crypto Engine From: mmm at cup.portal.com (Mark Robert Thorson) Date: 27 Nov 92 06:50:33 GMT Here is the text from a press release which landed on my desk yesterday: A new microcontroller from Philips Semiconductors-Signetics designed for use in smart-card applications is the first to incorporate an on-chip arithmetic unit optimized to calculate public-key cryptography algorithms widely used in commercial transactions. The 83C852 CMOS microcontroller can be embedded in plastic smart cards and provides 2K bytes of on-chip EEPROM for program and data storage accessed under control of the unit's CPU. "The new microcontroller removes the barrier to smart-card use in applications where data security is a concern," said Thomas Brenner, product manager. "There is strong interest in using smart cards, for example, in medical insurance or remote banking transactions. But in such applications a high level of data security is indispensable," he said. "Likewise the need for secure access codes is a primary consideration for customer-card use in the Pay TV and cellular phone markets." The on-chip arithmetic unit running in parallel with the CPU can complete a 512-byte calculation in less than 1.5 seconds versus more than a minute to do the calculation in software. This high-speed performance makes it feasible to use highly secure and complex public-key cryptography algorithms in everyday transactions. Asymmetric, public-key cryptography uses one key to encrypt and another to decrypt so that only one of the keys need be kept secret. The other can be freely distributed. The method is thus highly applicable to commercial transactions. The 83C852 microcontroller is based on the industry-standard 8-bit 80C51 processor core and uses the same instruction set. The circuit incorporates 6 Kbytes of ROM and 256 bytes of RAM in addition to the 2 Kbytes of EEPROM. The EEPROM provides automatic hardware error correction for single-bit errors in any of the stored data bytes. After customer software is loaded, electronic fuses in the array can be blown to limit access to processor fetch commands. The address bus is mixed to provide further protection against fraudulent access and optical scanning, and a low-frequency detection circuit can guard against external tampering. The new processor operates from a single 5-volt supply at clock frequencies up to 6 MHz (1 microsecond instruction cycle). All voltages required during programming or erasure of the EEPROM are generated on chip. Nonvolatile data retention is for ten years and the circuit offers an infinite number of read cycles. The microcontroller includes a power-on/off reset circuit, and idle and power-down modes. The microcontrollers can be ordered as a wafer, die on foil or in SO-28 small-outline packages. The SO package is available for smart-card readers and can function as an embedded security module in systems such as restricted access computers. Wafer and die-on-foil versions of the 83C852 smart card microcontroller are available now at a unit price of $5.10 and $5.20 respectively in 10,000 quantites. Units in SO-28 packages will be available in first quarter 1993 priced at $6.85 in the same quantities. CONTACT: Thomas Brenner (408) 991-3552 He's with Philips-Signetics. I have no affiliation with them, so don't contact me about this part. If you call Tom, be sure to tell him you heard about the chip from MARK THORSON on USENET. If enough people do this, maybe they'll give me a free development system. (On the other hand maybe they'll tell me "Please don't post any more of our press releases on Usenet." :-) -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at 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^756839 | PGP Public Key: by arrangement. From efrem at informix.com Fri Nov 27 01:57:06 1992 From: efrem at informix.com (Efrem Lipkin) Date: Fri, 27 Nov 92 01:57:06 PST Subject: credibility & pseudonyms Message-ID: <9211270916.AA25959@godzilla.informix.com> I have this persistent image of what a great boon all these encrypted networks will be for undercover work. Currently when some species of cop or spy goes undercover they take on a nearly full time acting job. They have to work for a long time to establish their credentials and throughout the process are usually in significant physical danger. I vaguely remember (the details are probably wrong) some Isreali spy got as far as the position of Minister of Defense in Jordan before he got hung. With digital signatures a dozen secretaries could run a hundred or more pseudoagents, build a solid reputation for each over years. The same approach would work for a patient con man. Real credibility has to be tied to a physical body. Some thing at risk. --efrem From donb at netcom.com Fri Nov 27 08:30:05 1992 From: donb at netcom.com (Don Bellenger) Date: Fri, 27 Nov 92 08:30:05 PST Subject: Cypher Bank Message-ID: <9211271625.AA08403@netcom2.netcom.com> Does anyone know of a law, rule, regulation, or other restriction that would prohibit the establishment of a simple cypher based bank? I can think of 3 basic areas that would have to be satisfied: 1. Federal law and agencies, Federal Reserve, etc.. 2. State and local (California for me). 3. Internet "Appropriate Use" policy. If the bank is operated on a not-for-profit basis --as an experiment. Then that should satisfy the appropriate use requirement. I could use some comments if anyone can cite specific federal or California regulations. Please respond either to me directly, donb at netcom.com, or to this mail list. -------- The cypher bank would work like this: I would publish my physical address; and offer to accept deposits by cash, check, or what have you. With the deposit, write on it your PGP handle. Email me your public key corresponding to the handle on the deposit. I will maintain a public list showing handles vs. Amount received, in collection, and in escrow.(Set Subject = "BANK" to get the list) Funds will be paid out based on instructions encyphered with your private key. Comments would be appreciated. Don Bellenger donb at netcom.com From donb at netcom.com Fri Nov 27 08:55:12 1992 From: donb at netcom.com (Don Bellenger) Date: Fri, 27 Nov 92 08:55:12 PST Subject: ping Message-ID: <9211271651.AA09053@netcom2.netcom.com> This is a test. I am seeing mail rejected due to mail spool full @ newschool. From tony at morgan.demon.co.uk Fri Nov 27 08:56:24 1992 From: tony at morgan.demon.co.uk (Tony Kidson) Date: Fri, 27 Nov 92 08:56:24 PST Subject: Mac PGP report and Rander progress Message-ID: <842@morgan.demon.co.uk> In message <9211270003.AA20577 at napa.TELEBIT.COM> you write: > Has anyone given any thought to generating random numbers by counting > particle emissions from a radioactive source? This might be more > reliably random than using purely electronic means. > I don't think that for any given length of random bit string, you'd be practically happy carrying around a suitable source. Thermal noise, which is what you get from a diode, is just as good a random source as radioactive decay. Tony ------------------+-------------------------------+--------------------------+ | Tony Kidson |`morgan' is an 8MB 486/33 Cat-| Voice +44 81 466 5127 | | Morgan Towers, |Warmer with a 670 MB Hard Disk.| E-Mail | | Morgan Road, |It resides at Morgan Towers in| tony at morgan.demon.co.uk | | Bromley, |Beautiful Down Town Bromley. | tny at cix.compulink.co.uk | | England BR1 3QE | -=<*>=- | 100024.301 at compuserve.com| +=================+===============================+==========================+ From cordones at IMAGE.CS.NYU.EDU Fri Nov 27 09:01:18 1992 From: cordones at IMAGE.CS.NYU.EDU (Deus Ex Machina) Date: Fri, 27 Nov 92 09:01:18 PST Subject: ping Message-ID: <9211271659.AA21574@IMAGE.CS.NYU.EDU> Me too. In fact, I am insecure my message ever got through because no one has said anything about it. It was regarding "The NSA backsdown". I was asking how could point me to thse so called "secret" documents that are available at some libraries. Did that get through Boys? Thanks From donb at netcom.com Fri Nov 27 09:20:12 1992 From: donb at netcom.com (Don Bellenger) Date: Fri, 27 Nov 92 09:20:12 PST Subject: List is partially broken Message-ID: <9211271715.AA20966@netcom.netcom.com> The message below was received in response to a ping sent to this list. However I know that it got some distribution because Yanek answered it. donb at netcom.com Forwarded message: > From Mailer-Daemon Fri Nov 27 09:03:27 1992 > Message-Id: > From: Postmaster at newschool.edu > To: donb at netcom.com > Subject: Rejected Mail > Date: Fri Nov 27 12:05:03 1992 > > > Unable to deliver message because: > > @ : Insufficient Disk Space > > Returned Text follows > ------------------- > Received: From relay2.UU.NET by newschool.edu > via Charon 3.4 with SMTP id 102.921127120528.384; > 27 Nov 92 12:04:51 +0500 > Received: from toad.com by relay2.UU.NET with SMTP > (5.61/UUNET-internet-primary) id AA03427; Fri, 27 Nov 92 11:56:15 -0500 > Received: from netcom2.netcom.com ([192.100.81.108]) by toad.com id AA01076; Fri, 27 Nov 92 08:55:12 PST > Received: by netcom2.netcom.com (5.65/SMI-4.1/Netcom) > id AA09053; Fri, 27 Nov 92 08:51:00 -0800 > Date: Fri, 27 Nov 92 08:51:00 -0800 > From: donb at netcom.com (Don Bellenger) > Message-Id: <9211271651.AA09053 at netcom2.netcom.com> > To: cypherpunks at toad.com > Subject: ping > > This is a test. I am seeing mail rejected due > to mail spool full @ newschool. > > -- From yanek at novavax.nova.edu Fri Nov 27 10:22:36 1992 From: yanek at novavax.nova.edu (Yanek Martinson) Date: Fri, 27 Nov 92 10:22:36 PST Subject: list broken (NOT!) In-Reply-To: <9211271715.AA20966@netcom.netcom.com> Message-ID: <9211271734.AA24635@novavax.nova.edu> > The message below was received in response to a ping sent > > From: Postmaster at newschool.edu > > To: donb at netcom.com > > Subject: Rejected Mail > > > > Unable to deliver message because: @ : Insufficient Disk Space This does not mean that the list itself is broken, only one (or a few) recipients have problems. You would have a cause to worry if you received a rejection message from toad.com. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From yanek at novavax.nova.edu Fri Nov 27 10:25:55 1992 From: yanek at novavax.nova.edu (Yanek Martinson) Date: Fri, 27 Nov 92 10:25:55 PST Subject: comments on Don's "Cypher Bank" In-Reply-To: <9211271625.AA08403@netcom2.netcom.com> Message-ID: <9211271825.AA25349@novavax.nova.edu> > address; and offer to accept deposits by cash, check, or what have > you. With the deposit, write on it your PGP handle. Email me your > public key corresponding to the handle on the deposit. A better way would be to mail the public key itself, or a short hash of it along with your payment. That is all the information that would be required. A "handle" would be completely optional. If only the hash value is mailed, then the full key can be e-mailed or anonymously posted to a newsgroup that you montitor. If the full key is mailed, you should invest in a scanner and some simple OCR software. This way, someone may print out the public key and mail it to you. > I will maintain a public list showing handles vs. Amount received, > in collection, and in escrow.(Set Subject = "BANK" to get the list) You should not disclose someone's balance to anyone else, and certainly no to the public. Someone requesting their balance should send the request by any communications channel (anonymous mail, newsgroup, anything) and sign it with the private key corresponding to the public key used when making the deposit. Then you should encrypt your reply (the account balance & any other info) using the public key, and send it back through any channel. > Funds will be paid out based on instructions encyphered with your > private key. I would make it: funds will be transferred based on instructions _signed_ with the private key corresponding to the public key used for deposit. P.S. this would be equivalent to digital checking accounts. Do not confuse this scheme with the much more interesting Digital Cash ideas. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From yanek at novavax.nova.edu Fri Nov 27 10:46:45 1992 From: yanek at novavax.nova.edu (Yanek Martinson) Date: Fri, 27 Nov 92 10:46:45 PST Subject: ping..mailing list integrity.. In-Reply-To: <9211271659.AA21574@IMAGE.CS.NYU.EDU> Message-ID: <9211271846.AA25768@novavax.nova.edu> > Me too. In fact, I am insecure my message ever got through because no one > has said anything about it. It was regarding "The NSA backsdown". I was > asking how could point me to thse so called "secret" documents that are I have not received it. It may have just been a local network problem on your side. But it may also have been covert action (if you are paranoid enough to believe it). I have an idea how we could make it possible for eveyone to be SURE that their message to the list actually went out; and also they could be certain that they have not missed any list messages. This is very important for people with unreliable or untrusted e-mail connections. The idea is: whenever cypherpunks at toad.com receives a message, it would append the From:, Date:, and Subject: headers to a file, thus creating an index of messages passing through the list. At the end of each day, the file would be mailed out to the list. So if you posted a message, you could check in the evening if it got out or not. If you are not sure if you are receiving all the messages, you could maintain a simlar file yourself, and at the end of day compare your notes with what is received from the list. This should not be difficult to set up at all. This could be later improved in several ways. First, the message could be signed by the list administrator (in case you think your mailfeed is filtering what you receive, and is also removing these items from the index). These indexes could be kept for a week or so, and either only the lists, or maybe even any of the individual messages that may have been missed could be requested via a mailserver. This could work similarly to the CRYOMSG: facility of the Cryonix mailing list. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From hughes Fri Nov 27 10:48:33 1992 From: hughes (Eric Hughes) Date: Fri, 27 Nov 92 10:48:33 PST Subject: Welcome message for cypherpunks-announce Message-ID: <9211271848.AA03598@toad.com> We've created a secondary list, cypherpunks-announce at toad.com. If you want to keep in touch, but don't want the volume of mail the full list produces, get yourself switched over. And remember not to post such requests to the whole list. Thanks. The welcome message follows. Eric ----------------------------------------------------------------------------- Date: Fri, 27 Nov 92 10:44:31 PST From: hughes at toad.com (Eric Hughes) To: cypherpunks-announce Subject: Welcome Welcome to the cypherpunks-announce list. This is a low-volume list for announcements, news, and meeting schedules. It is not a digest. It is moderated by Eric Hughes, also the maintainer of the full list. Each of you has at some point been on the full list and asked to be dropped for mail volume. If you really don't want to be even on the announce list, send mail to cypherpunks-announce-request at toad.com and ask to be removed from the announce list. Eric From daver at tfs.COM Fri Nov 27 13:15:47 1992 From: daver at tfs.COM (Dave Robison) Date: Fri, 27 Nov 92 13:15:47 PST Subject: ... Message-ID: <9211271916.AA18212@ts2.TFS.COM> please remove me from this list. as interesting and important as i think the discussions are, i cannot keep up with the volume of mail. thanks. From donb at netcom.com Fri Nov 27 13:33:24 1992 From: donb at netcom.com (Don Bellenger) Date: Fri, 27 Nov 92 13:33:24 PST Subject: More cypher bank Message-ID: <9211272129.AA26164@netcom2.netcom.com> No one else's account would be disclosed except to the owner. Handle, hash, or the full key itself is all the same. The point is that some shortened identifer is needed. This is not a technical matter, the customer can cook up anything he wants, There is no relation to the mechanics of PGP, I don't want to bother scanning in and verifying long strings of codes, and I need some short I.D. so the owner can identify his balance for verification (checking balances). There are obviously plenty of fancy variations on this, and I would be happy to set up whatever any body wants. Maybe the easiest way is to setup mail addresses for each depositor of the form: handle_of_depositor at digibank.com. So send signed email to that address, and I will respond with your balance. A couple of other addressees would be used for overall bank status report, and current operating rules. The digital cash account is represented by the escrow balance. If Sam wants me to take his collected funds and turn them into digi-cash, I can sign a voucher that I have segregated X amount of Sam's money into an escrow account pending receipt of the digi-cash voucher and instructions to move the escrow amount elsewhere. This is all that any bank is going to do. Basically, this looks like a very good thing to do. If handled properly and within the banking regulations, it could be a great advance. Does anybody here remember pre-ATM days? Standing in line at the bank to get cash? In 3rd world countries they don't even have checking. This means you have to walk around every month and pay your bills in cash. I haven't been in a bank in years since the ATMs came in. And this is at another, much higher level of abstraction. > > > address; and offer to accept deposits by cash, check, or what have > > you. With the deposit, write on it your PGP handle. Email me your > > public key corresponding to the handle on the deposit. > > A better way would be to mail the public key itself, or a short > hash of it along with your payment. That is all the information that > would be required. A "handle" would be completely optional. > If only the hash value is mailed, then the full key can be e-mailed > or anonymously posted to a newsgroup that you montitor. If the full key > is mailed, you should invest in a scanner and some simple OCR software. > > This way, someone may print out the public key and mail it to you. > > > I will maintain a public list showing handles vs. Amount received, > > in collection, and in escrow.(Set Subject = "BANK" to get the list) > > You should not disclose someone's balance to anyone else, and certainly > no to the public. Someone requesting their balance should send the > request by any communications channel (anonymous mail, newsgroup, anything) > and sign it with the private key corresponding to the public key used > when making the deposit. Then you should encrypt your reply (the account > balance & any other info) using the public key, and send it back through > any channel. > > > Funds will be paid out based on instructions encyphered with your > > private key. > > I would make it: funds will be transferred based on instructions _signed_ > with the private key corresponding to the public key used for deposit. > > P.S. this would be equivalent to digital checking accounts. Do not confuse > this scheme with the much more interesting Digital Cash ideas. > > -- > Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek > this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred > Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood > (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 > > -- From karn at qualcomm.com Fri Nov 27 15:05:14 1992 From: karn at qualcomm.com (Phil Karn) Date: Fri, 27 Nov 92 15:05:14 PST Subject: How far is to far? Message-ID: <9211272304.AA09837@servo> I must concur with George Gleason's remarks about "sneaking around in the shadows of legality". I find myself getting a little uncomfortable with some of the more anarchistic ideas expounded in this and similar groups. My interest in cryptography is very simple. I'm not interested in overthrowing the government by force. Although I find "digital cash" to be an interesting concept worthy of pursuit at least as an academic exercise, I'm not trying to evade income taxes, establish an underground economy or conceal criminal activity. And although I do believe that drugs, gambling, prostitution and other vices ought to be legalized on both practical and philosphical grounds, I am not particularly interested in using cryptography to protect the lowlifes who inhabit these professions. I am *very* interested, however, in cryptography's enormous potential to protect individual privacy. With widely available strong cryptography, the average individual will finally have the technical means to draw a tight circle around the private aspects of his or her life. The individual need let no one, especially the government, enter without his or her permission. Until now, we have had to depend entirely on the goodwill of government to respect and obey those provisions of the Bill of Rights that deal with privacy. Often this "good will" has been sadly lacking. But now we can finally put some real teeth into the guarantees of the First, Fourth and Fifth Amendments. If you want to plot political strategy for an upcoming election, or if you want to talk to your attorney about some legal action, or even if you just want to discuss your sex life with your spouse or SO, cryptography can guarantee you an unprecedented degree of privacy. Just as good fences make good neighbors, we may well find that in the hands of the people, good cryptography will make for good government. That's why I find cryptography so interesting, and that's how we should sell it to the public. Phil From karn at qualcomm.com Fri Nov 27 15:53:20 1992 From: karn at qualcomm.com (Phil Karn) Date: Fri, 27 Nov 92 15:53:20 PST Subject: More comments on dongles Message-ID: <9211272352.AA09880@servo> George Gleason says "I believe that carrying out the entire crypto operation in the dongle is preferable to having it only do the secret key RSA processing" and argues for this position mainly on the basis of host compatibility issues. I still disagree. Even if all the crypto operations were done in the dongle, it wouldn't be a "turnkey" device that could operate totally automatically. You'd still need a way for your host computer to turn it off and on, to select a public key for encryption or signature verification, to load new public keys, etc. I.e., you'd have to run special driver software on the host anyway. So why not limit the dongle to the specific purpose for which it was designed (protecting your RSA secret key) and do the less sensitive operations where memory and cycles are far more plentiful, i.e., on the host? Limiting the dongle's function to RSA secret key operations also minimizes the dongle's communication requirements. The only data you'd have to send to it in normal operation would be short blocks to be run through your RSA secret key operation, a heavily compute-bound process. If I want to decrypt a file, I'd send the dongle the IDEA (or DES) key that had been encrypted with my public key. Once the dongle responds with the decrypted IDEA key, I can perform the actual IDEA decryption on my host computer with no further dongle interaction. Regardless of the file size, this would go at host CPU and/or disk speed, not the speed of the port that's talking to the dongle. Similarly for signing -- the MD-5 hashing of the file would proceed at near disk speed (since MD-5 is so fast) and only the resulting hash code would have to be passed to the dongle for the RSA secret key step. A palmtop DOS machine like the HP-95 or Atari Portfolio would make a good platform for a prototype dongle. Most have serial ports (standard or optional), and you could just plug them into a spare serial port on a PC (again, speed is not critical). The palmtop's keypad would be used to control the dongle, e.g., by accepting a pass phrase to decrypt the stored copy of your RSA secret key, so you wouldn't have to type it into a possibly compromised PC. And they're small enough to carry around with you, thus making it harder for somebody to hack. The only drawback I can see to all of this is that palmtops are not exactly speed demons, and RSA secret key operations are pretty slow to being with (much slower than the public key operations, which are less sensitive). But secret key operations are the heart of RSA, so you don't have much choice if you want real security. Since it is a sensitive step, RSA key generation could also be done on the palmtop (although it would probably take hours) or it could be done on an external, trusted PC and loaded into the palmtop. If your main reason for using the dongle is to limit the trust you have to place in a borrowed PC (as opposed to protecting against your own home PC being hacked), this may be a reasonable thing to do. Another idea just occurred to me. If you have a trusted machine (e.g. your home PC) available to you over the net, you could use it as a "remote dongle". You'd send it data to be run through the RSA secret key operation and it would return it. Obviously, to be secure the network exchanges would have to be encrypted in both directions, otherwise anybody could either pick up the "remote dongle's" responses or worse, send it data of his own choosing. A simple symmetric cipher (IDEA, DES) would be adequate here since you control both ends of the link. The main drawback of this approach (other than the need for network connectivity) is the physical vulnerability of your unattended home PC. Phil From VANGUARD at gribb.hsr.no Fri Nov 27 16:37:46 1992 From: VANGUARD at gribb.hsr.no (VANGUARD at gribb.hsr.no) Date: Fri, 27 Nov 92 16:37:46 PST Subject: Random numbers Message-ID: It has lately been discussed different ways to construct pure random number generators by means of radiactive decay. I must admit that this is a very good way to produce such numbers, but for a number of reasons it is impractical to use such a device. (High radiation levels are needed too produce a significant amount of data.) What I have been thinking of is a way to reduce the amount pure random data needed to produce good random sequences. The way to do this would too have a weak random number generator like: R(n+1)=(17*R(n)+1)mod256, and then inject the pure random into this function giving the result R(n+1)=(17*R(n)+1+PR(t))mod256 or something of the like. Would this constitute a sufficiently secure stream of data for use in one time pads? Has this been thought of before ? THE REST OF THIS MESSAGE CAN BE SAFELY INGNORED: A friend of mine now serving in the air force gave me a report of the cryptographic devices used for communicating on permanent lines. (Twisted pair or something dug down). The machines used till now are huge totaly outdated mostly mechanical monsters. While not transmitting data the machines produce random data to hinder traffic analysys (like how many messages are sent), these data are produced by cookiebox sized thing, and I strongly suspect it to be of a very mechanical nature. Thats how a came up with the idea of a very inexpensive way to produce random data by mechanical means: Use a contaner filled with marbles some made of conducting, and some of non- conducting material. Then mix them in some way or another (this is bound to make a lot of noise) and in the container there should be a few closely placed points of contact that would be able to send a small current through a steel ball if it where to pass over the pair of contacts, and what do we have: Random Data ! (I know this is not very practical at all) From donb at netcom.com Fri Nov 27 17:11:14 1992 From: donb at netcom.com (Don Bellenger) Date: Fri, 27 Nov 92 17:11:14 PST Subject: Random numbers Message-ID: <9211280107.AA08614@netcom2.netcom.com> > > > > It has lately been discussed different ways to construct pure > > random number generators by means of radiactive decay. I must admit > > that this is a very good way to produce such numbers, but for a > > number of reasons it is impractical to use such a device. (High > > radiation levels are needed too produce a significant amount of data.) > > > The way to make good random numbers is to take about 20 stages of flops > and feedback 2 or three terms. Clock the thing as fast as you can, Say > 50 mhz, and asychronously to your main processor clock. The shift register > needs its own crystal. The selection of feedback points is based on > Linear Congruential Method of Pseudo random numbers generated by most > machines. > > The numbers generated are very, very uniform. > > The way to test random number generators for randomness is to generate > the numbers in pairs and plot them on a scatter plot. This simple > cross check will show up many poor generators. Checking for uniform > density in higher dimensions will uncover even more subtle variations > from uniformity. There is an enormous literature on this topic. Obviously > you can screw it up, but it isnt that hard to get right either. There > is an excellent book just out on simulations that covers this. If > anyone wants the reference, I can dig it up. > > Bottom line is that you don't need anything exotic. But the 8 or simple 16 > bit methods on the small processors are no good. > > Don Bellenger > donb at netcom.com > > > > > > -- From yanek at novavax.nova.edu Fri Nov 27 18:16:47 1992 From: yanek at novavax.nova.edu (Yanek Martinson) Date: Fri, 27 Nov 92 18:16:47 PST Subject: More comments on dongles In-Reply-To: <9211272352.AA09880@servo> Message-ID: <9211280216.AA05139@novavax.nova.edu> > I still disagree. Even if all the crypto operations were done in the > dongle, it wouldn't be a "turnkey" device that could operate totally Maybe not "totally" (there are no absolutes) but if well designed, it could come VERY close. > automatically. You'd still need a way for your host computer to turn > it off and on, to select a public key for encryption or signature ... > ... I.e., you'd have to run special driver software on the host anyway. The way I envision it, the host must NOT have the ability to turn it on or off or do any of the other things you mentioned. The assumption is that you DON't trust the host. All these commands to the dongle will be given through the keypad and/or commands you type in from the terminal. So if the host does not even need to know the dongle exists, it is automatically independent of what type of computer, operating system, communications program or terminal you are using. > process. If I want to decrypt a file, I'd send the dongle the IDEA (or > DES) key that had been encrypted with my public key. Once the dongle > responds with the decrypted IDEA key, I can perform the actual IDEA > decryption on my host computer with no further dongle interaction. Again, you are trusting the host. What if the decryption program on the host has been modified to quietly write the plaintext to a hidden file. > speed, not the speed of the port that's talking to the dongle. Once the host decrypts the file (at a high speed, as you say), you want to view the file, right? That means the plaintext is transmitted from the host to you. Anywhere in the link (which could be a simple RS-232 connection, or a chain of network links, modem connections, etc., someone may be watching. With my design, the decryption takes place at the very last step, just before showing up on your screen. > A palmtop ... would make a good platform for a prototype dongle. > Most have serial ports (standard or optional) I have thought of that too. I would need one with two serial ports though. If you know of a good, cheap (can something have these two properties simultaneously? :-) notebook computer with (option of?) two serial ports, please let me know. > Since it is a sensitive step, RSA key generation could also be done on > the palmtop (although it would probably take hours) or it could be Since that is not something you do every day, I think you can tolerate it taking a while. How long it takes also depends on how much security you want (i.e. key length) > main reason for using the dongle is to limit the trust you have to > place in a borrowed PC (as opposed to protecting against your own home That is just one of the reasons. The others are convenience, lack of trust in the host or the network, use of a terminal (which can't run any software locally), use of various computers/terminals (at home, at work, any other place you happen to be) use of an environment for which no PGP implementation exists or on which you do not have the access to install any software, and I'm sure you (any of you) can think of other reasons if you take some time. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From gg at well.sf.ca.us Fri Nov 27 18:34:33 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Fri, 27 Nov 92 18:34:33 PST Subject: Random numbers Message-ID: <199211280233.AA21798@well.sf.ca.us> Vanguard's posting about a friend of his in the Air Force telling him some things about Air Force crypto devices may be of some theoretical interest, but posting it here really gets me majorly uncomfortable. Current military crypto practices are probably very highly guarded secrets. Posting that kind of thing, even in a general way, could be very dangerous; if not to national security then at least to ours. I'd like to ask we have a general agreement to not post things which may be classified. No point giving the govt a good excuse to stop our R&D projects cold. -gg From karn at qualcomm.com Fri Nov 27 18:49:41 1992 From: karn at qualcomm.com (Phil Karn) Date: Fri, 27 Nov 92 18:49:41 PST Subject: More comments on dongles Message-ID: <9211280249.AA10136@servo> >The way I envision it, the host must NOT have the ability to turn it on >or off or do any of the other things you mentioned. The assumption is >that you DON't trust the host. If you don't trust the host, then why are you running your plaintext through it? As I said earlier, my decision whether to trust a particular machine depends heavily on how much I would lose if that trust were abrogated. I might be willing to take the chance that this particular borrowed or public PC has been hacked if the worst that can happen is that the only slightly sensitive plaintext I'm working on at the moment is compromised. Heck, I might even be signing or decrypting totally public information, just to help raise the amount of encrypted traffic on the net. In this case I might not care at all if my plaintext is secretly recorded or sent somewhere. But I would probably NOT be willing to trust the same PC with my secret key, because it would compromise EVERYTHING I have ever protected (or will protect) with that secret key. Including THE most sensitive stuff I might have, the plaintext to which I might entrust only to a RAM disk on my own home PC. Do you understand the distinction here? >So if the host does not even need to know the dongle exists, it is >automatically independent of what type of computer, operating system, >communications program or terminal you are using. I seriously doubt this will be practical, even with constant interaction with the dongle's keyboard. Most palmtop keyboards are a real pain to use, so I would definitely prefer to limit my use of it to truly sensitive things, like typing in my pass phrase to decrypt my RSA secret key, or perhaps hitting a key to re-enable the device after every N secret key operation requests from the host, or to restart a timer that would otherwise exit the program and clear RAM after a timeout in the event the device is lost or stolen. >Again, you are trusting the host. What if the decryption program on >the host has been modified to quietly write the plaintext to a hidden >file. As I said earlier, your "fully-functional dongle" fails to prevent this attack. If it sits on a serial port between your possibly hacked PC and the outside world, then it clearly must pass decrypted plaintext to the PC where it could still be quietly written to disk. >Once the host decrypts the file (at a high speed, as you say), you want >to view the file, right? That means the plaintext is transmitted from >the host to you. Anywhere in the link (which could be a simple RS-232 >connection, or a chain of network links, modem connections, etc., >someone may be watching. With my design, the decryption takes place at >the very last step, just before showing up on your screen. Eh? The model I have is a local PC, possibly hacked, with a serial port connected to my personal dongle sitting right beside it. Obviously it would not do to have an insecure link between the PC and the dongle (unless you had encryption on that link, as I suggested in the case of using a remote machine in place of the dongle.) It should be fairly hard to inject your own traffic on my 1-foot RS-232 link, especially if I provide my own cable. >I have thought of that too. I would need one with two serial ports >though. If you know of a good, cheap (can something have these two >properties simultaneously? :-) notebook computer with (option of?) two >serial ports, please let me know. The "basic dongle" would only need one RS-232 port, and it would not have to be fast. This is a definite advantage. >That is just one of the reasons. The others are convenience, lack of >trust in the host or the network, use of a terminal (which can't run any ^^^^^^^^^^^^^^^^^ This is the one valid reason I can see for your approach. But dumb terminals are getting pretty rare these days, at least in the places I hang out. Phil From yanek at novavax.nova.edu Fri Nov 27 19:43:52 1992 From: yanek at novavax.nova.edu (Yanek Martinson) Date: Fri, 27 Nov 92 19:43:52 PST Subject: More comments on dongles In-Reply-To: <9211280249.AA10136@servo> Message-ID: <9211280343.AA07573@novavax.nova.edu> I think we are using different terminologies, maybe even different paradigms of how e-mail and other internet functions are accessed by people. In my terminology, "host" is the remote multiuser computer that is on the internet, and provides access to users via dial-up modems, local RS-232 terminals, and PC-s running terminal emulation programs. The host could also be a BBS system (as in the case of FidoNet) which provides mail forwarding for you. It could be an on-line service such as GENIE or Compu$erve. Local equipment is the terminal, or Pc or Mac or whatever, that you use to connect to the host. It could also be the laptop that you connect to a cellular modem and connect to the host while mobile. You could always use the same local equipment. Or you may use different types at different times (a terminal at work, a PC connected through a modem from home, a firend's Mac, a borrowed laptop using a cellular modem, etc). The connection could be direct, as in the case of a terminal or a direct dial-up by modem. Or the connection could go through multiple channels. For example you could dial up a TYMNET POP, and then connect to your host. Or, you could call up a terminal server, log in to a guest account, and then telnet or rlogin to your host. In this scheme, the dongle sits right between the local equipment and the connection. > >The way I envision it, the host must NOT have the ability to turn it on > >or off or do any of the other things you mentioned. The assumption is > >that you DON't trust the host. > > If you don't trust the host, then why are you running your plaintext > through it? In view of what I have said above, I am NOT running the plaintext through the host. I am running it through local equipment, which I may or may not trust. The host (being the multiuser system, administered by someone else) is always less trustworthy. It is directly on the network/ It could be immediately transmitting everything you type to NSA for all you know. > ... if the worst that can happen is that the only slightly sensitive > plaintext I'm working on at the moment is compromised. ... > But I would probably NOT be willing to trust the same PC with my > secret key, because it would compromise EVERYTHING I have ever ... > Do you understand the distinction here? Yes, I certainly do. That is the reason for having a portable trusted device in the first place. But, in this sense our two approaches (my smart dongle that does all the crypto functions, and yours that only stores the private key) are absolutely equivalent. None of the two exposes the private key in any way. > >So if the host does not even need to know the dongle exists, it is > >automatically independent of what type of computer, operating system, > > I seriously doubt this will be practical, even with constant > interaction with the dongle's keyboard. See my next post "STORY: scenario of use of Crypto-Dongle" for my vision on how this would work. Then, if you see any problems with it, or suggestions for improvement, please let me know, so I can improve it. > to truly sensitive things, like typing in my pass phrase to decrypt my > RSA secret key, or perhaps hitting a key to re-enable the device after That is the kind of things I intend the keypad to be used for. > Most palmtop keyboards are a real pain to use ... The dongle will have a numeric keypad, somewhat like the touch-tone phone, with letters on the number keys, and a couple of extra keys such as * and # for functions. > >Again, you are trusting the host. What if the decryption program on > > As I said earlier, your "fully-functional dongle" fails to prevent This misunderstanding is due to our differing use of the word "host". When you said the host would send the rsa-encrypted key to the dongle, receive the decrypted session key, and then decrypt the file, I understood you as meaning that the remote multiuser machine is doing all this. Now I see that you meant for the local equipment to perform the decryption. The problem with this is that you are depending on every piece of local equioment to have a copy of the decryption program, and every version of that program compatible with your dongle's commands structure and key format. Or you'd have to carry a several disks with you, with a version of your software for every platform you could encounter. > >Once the host decrypts the file (at a high speed, as you say), you want > >to view the file, right? That means the plaintext is transmitted from > >the host to you. Anywhere in the link (which could be a simple RS-232 > Eh? The model I have is a local PC, possibly hacked, with a serial > port connected to my personal dongle sitting right beside it. In this case, you would have to save the encrypted message into a file on the host, download it to your local machine, and then decrypt it using the above approach. This would be some amount of hassle, when compared to just using the mail reader software on the host. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From Tom.Jennings at f111.n125.z1.FIDONET.ORG Fri Nov 27 19:58:40 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Fri, 27 Nov 92 19:58:40 PST Subject: How far is to far? Message-ID: <3920.2B16E302@fidogate.FIDONET.ORG> U> From: karn at qualcomm.com (Phil Karn) U> I must concur with George Gleason's remarks about U> "sneaking around in the shadows of legality". I find U> myself getting a little uncomfortable with some of the U> more anarchistic ideas expounded in this and similar U> groups. I agree, even though I'm interested in uses of encryption other than privacy, implementation of privacy systems is a baseline to a lot of it, and the other stuff drags us off topic... --- ReadMail * Origin: tomj at fidosw.fidonet.org / World Power Systems (1:125/111) -- Tom Jennings - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!111!Tom.Jennings INTERNET - Tom.Jennings at f111.n125.z1.FIDONET.ORG From gnu Fri Nov 27 20:15:40 1992 From: gnu (John Gilmore) Date: Fri, 27 Nov 92 20:15:40 PST Subject: Keys & Signatures Message-ID: <9211280415.AA12997@toad.com> Here is the collection of keys and signatures from the last meeting. Feed this file into pgp to add them to your key ring. Please remember that posting "your" public key is not sufficient when you want people to believe that the key corresponds to a physical person (you). It's fine for communicating with people who you have't met or don't care to meet. But the way we can tell that the key matches the physical person who we met, is to have it signed by someone we trust. The signature indicates that "I certify that this key really does belong to the physical person identified in the name field". Don't sign someone's key unless you are sure you can make that statement (like, they're standing in the same room with you and they verify that they key ID matches their real key). Don't sign a key that you received by email or over a modem; it might be from someone impersonating your friend (when they left their keyboard unattended for a few minutes). PGP works on the model that you specify, for each person on your key ring, how much you trust them to introduce you to other people. For example, I trust Tom Jennings "most of the time", and I got Tom's key from him personally. So I know that if Tom's signature appears on someone's key, it probably really is that person. I've instructed PGP to know this, too. I also trust Phil Karn as an introducer, and got his key from him personally. PGP knows that if both Phil and Tom have signed someone's key, that I can believe it *really* is that person. The people you trust will be the people *you* trust; don't rely on trusting someone else's friends. We are trying to set up an interlocking web of trusted friends so that even if you don't know me, you will know and trust two other people who know me, and can thereby know my key is good. Making a key distribution system that works on a web of trust is research. It's never been done before. We'd like to give it a good try, among highly motivated people, to understand how it works and how to improve it. The alternative we're faced with (e.g. in PEM) is hierarchical systems in which some authority figure signs your key -- with all the attendant possibilities for misuse of power. Let's see if a looser, more flexible system can work as well or better. John Gilmore -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQBNAisOwBkAAAECAMw+W4OgXIO8E42bAT+fbwoo20aP5WBiBoLeiED3kBOSYa8F eLRU947sfn2VobobfSkg14TmPkMfDfdWhd2+DdUABRG0IkpvaG4gVC4gRHJhcGVy IDxjcnVuY2hAbmV0Y29tLmNvbT6JAFUCBRArDvZGVANHFAAi5S0BAWVRAgCidKO5 wvC9lQbMYfUZC9zOoqYbnRZF8JGDIRdHeELef78VpXydTLG09OHC0GA4zqfFrtCp kvCXKIEKsvDp5YmciQCVAgUQKw7yAa1SSlGFGX+1AQHObQP/dqMl0C4z0YxYjrAI ChV84C0pvaLVAShooyRI7c+rZO8RsmOIh44Stex+6vQcw2w2Ceh+NN7g7qGclCNf m8eHz3FKSZBUV1BFcMBKpb3+/1d/iZueaf5eqA22l5BBumy7KLJpATrM+vegMVFA MSdngyy6MMW9OhAZmN76OKuOJR+JAFUCBRArDtzezT/tLvUlcRcBAZonAfwI85gt tgoBtqZRUgVMJcXKZcERprMv8Isqcnw0oRhd/fbQBYBMJYK1cRCdfqGw+8jr4xTl dJoHm7WjvQkLzY8smQBNAisO4xwAAAECAKkyDQst9WhzHdko62Kd78+Ga8B3tLa3 Qr6zOXskoVaSYo9tLG2qo7bKs3W6SL7LgLRGaXqSC4Wyr7SLG737Hy0ABRG0IUdl b3JnZSBHbGVhc29uIDxnZ0B3ZWxsLnNmLmNhLnVzPokAVQIFECsO5fTNP+0u9SVx FwEBoOoB/17ngP0LwTFVGdxjbfB7BPz9kfYet/o2qkTfehc8WRvh/Xgx13ErY5kJ FBs8Qew75HCqBzDsGxiG8g44iHOxpDeJAJUCBRArDuPErVJKUYUZf7UBAfDmA/40 zI0SEtkE87LJJk4/d3Y2lLhBAv2YWXLckS/V/6G9n/MRILJR3s3x1staVEio3rHO bu+piG0uJm8kj2ShW1KFZrLAx5902BUM6ic+ZXDKjJ/SgCkVPr+RPc11HpqfWjpQ GiBSTmzRGjVfzDhcmbGneNq6O2oLJRlBqdaacK8DepkATQIrDsOwAAABAgDqJjAj dvu+tnRbDqmT02kwH9It43bqMd317SIGSnFQiU85b1RbfFYmA3fEOiA434Z/dASU AfFSUk4YBjePiYYxAAURtDBTY290dCBDb2xsaW5zICg1MTIpIDxTY290dF9Db2xs aW5zQGdlbm1hZ2ljLmNvbT6JAFUCBRArDvYKVANHFAAi5S0BAenEAf49x8d+g4dm 7qK3cLIPfjNngmPZqEXcQ8dD/gtPAYADx4VkuXAqhmFvg6sdfJCk9j9vUrg+ReVN LFJN2rm/hAQEiQBVAgUQKw7fJw33VoXdvg3VAQEttAH/UnzcdPIK6SopvlPVp6gS +pMGt8xkd4U7dI5XCtKNdlbczBKjSeHw/+OBBjZLoFqMrWUtyimwUCe3auLxRzup GokAVQIFECsO2arNP+0u9SVxFwEBhbEB/0QkJoNqPA8CRPnkp9yYdIcB8EiTD3qY JYKvP0fuf5gOWAyurEa6wCCxgZwFuBWA7s+lTHDJH0EkUWr/whNdZLmJAJUCBRAr DtZIrVJKUYUZf7UBAQ3CBACPs+6OSUG2GPudoyEz2ZgCU06WhitFADFTyLL2ADyw cznnt+u6/HBKTFjofC2CxFMoU1flYa927c8iRDEH5kwhbari3m68lWm82WQ41N7l nYuSV2L10elmtbpdVwtBYz/qlB+ONJma0ryahoVdRyCDXsDYnk1ch7sZd3hhvKH0 7pkATQIq1hAPAAABAf4nzLRuYjfdZYmgNbDw91ZfnS6numEF9zKHQhSPMdSgyEoV 2h/I/KAyonOvPgGrpbvySXRwfvHy2ZSNMq4JDJ1TAAURtCVFcmljIEhvbGxhbmRl ciA8aGhAc29kYS5iZXJrZWxleS5lZHU+iQBVAgUQKw72J1QDRxQAIuUtAQExNgIA pNqq5+d9cxdYphGVuZMGcHoNrxqvkMmzhgjKvFbC956m19lSF918/F+CisTNr6L/ sJkmyARrqZPivGPhYvgipYkAVQIFECsO31YN91aF3b4N1QEBtDoCAJvDbP1+ZbG/ RDXQexxvollsOBfkp5hrfY+KQ/2U4V7i8Kef3Vy5j+RzXcY7fRLjuWQLi+yykBLh mVkArKv5xvKJAFUCBRArDtn5zT/tLvUlcRcBASdWAgDaGqLltSctfJBz/cwgbAFe 7zEtZTfghFA3q8vEHsdHhFP5Vx0jHhwZozFEiLJHuoz9OKyuvxRKrKgnqlFVhSO5 iQCVAgUQKw6qUCmBKTQiZpaHAQH2pwQAsg59Mw1e9JxCD8VLOxLvtMuk4XJlHRNQ U3FW11z0zrlShLwFSqOt3h3ag/A3EFZLB1j213JbIUlUuYzJO1yC1sjV7Xryd6D7 HG2R7GbL8WOLTuoBO4XQTtKu0PulJgbiVc+4CHV2S1QSUaEeWbPRqciSAwfFSGb3 1Jqu1Xu1mV6ZAI0CKw6peAAAAQQAxAKQzN+3TQJtcn0KEKd3H2UP4mNLSvEekmNX kGxVmvEGW1yNp14cQiP+DHe7W0/ZL4mMs5+BsGmlatzIZm0lkZPPFP+mdxgmmH8y A6Qw0VttCYEAjoSEr6UZ4sPVoPktsitLUjrQMk5tWfx8JMxKV9XK8WASwVjkKYEp NCJmlocABRG0KlNjb3R0IENvbGxpbnMgPFNjb3R0X0NvbGxpbnNAZ2VubWFnaWMu Y29tPokAlQIFECsO7UatUkpRhRl/tQEBgswEAIN3cA/Wobk6EkktBBSr3ZybB8zv mA8Nze7jXLm6fgiMRGAhSB/79Q5tshc3pE7UtOzpHmTiZ/ppz2nRjkyr8CzIsEzs LVDM7ctOT7JN7MxEBUZ3D03Zs1AIA6nzn1MfKbFTol2jXm0LXXafMixdpcvfV3v1 hGagMTMtMjjumiytmQCNAirPdYEAAAEEAMoyYy8lL84DlFK4IRmYBwfSFY8IwWia 0J3cKPHKyQVligPKgUnfh+Ky6wN6eXAeZsbEjM6VMXY21mMaRec3IbzXok2UKQHy FNUnL74J4iH1+hGw0hO89bcDwFeFXvaFqcNTQRF0GJOSSIEiz970fqUOo+esZzKe azP+2tnMgvmhAAURtCFEclphcGhvZCA8ZHJ6YXBob2RAbmNzZWx4c2kudXVjcD6J AFUCBRAqz+Q0VANHFAAi5S0BAe2PAf9bKSOk76/vSFirkK/47CACCfDbkj1bvBVz fzPv8+sY6pwi7xjEneropY0i6enwBWOWSP7r9VoqF90Ib+vjEFbxmQCNAisOzWIA AAEEALLmQZNts5rAUk5NoTJcbpsNpCazDysVO89QP70nxTniGaPGx7ywfbJN3dWz CjQbpC8ZwALcI9hexxlxz0lUvnrPy1OT5+lNIU68uvDYWU7s+ZrnGLCA7vGgH3sS PQbmaOu7QUu9o/ynJc29NABMrNhAYdbZvY7HxOsAk+sCRcQ1AAURtCJEYXZlIEty aWVnZXIgPGRrcmllZ2VyQG5ldGNvbS5jb20+iQBVAgUQKw7141QDRxQAIuUtAQE/ SgH/epfSUEmghODhSeVUqdJVkpYpjZu7c5j+2LGG5CWU1jjavK7t8HpY5kcyDsUA BF56S5kQ3fiyNiWxTpKtoSjgiIkAVQIFECsO3vUN91aF3b4N1QEBn1UB/2DJjDCi jIwyjNODzLr1pjmb5UAaWFwzTyg0F+G7iQ7GgjfcuaEjd8NSaQloIaqawdRa482M LqKeFMeeSPcxrheJAJUCBRArDtegrVJKUYUZf7UBAX5sA/0ebDd2cPr3EN/RWC5/ 4Nie4275BmEo/07Ita2XytResauQLP9JcNuSxLLlNRylvzXVS0EiQL4heek140ug TSNZSp7eSvjdxWUKhNLN4/5OqIm9IkVK3usbIaC0HVSwwF9xx4BOnzwuOlbFLxT+ qKA3C72ZvqEvkEnR72svlsX5RokAVQIFECsO0ejNP+0u9SVxFwEBvGMB/jk538BE 2nV/QwBjEOXDJICNwbaZj0aLbT/kMdnW6ktGEdHUTmMHd8tyTGL4D3sauHWchUYH cGkoJXBd8ZtdyXmJAJUCBRArDs7sofVDpely8BEBAWVnBADckZz3+yOADrLxdYbE kWdl3aoc88717F7mpzi2BRCKUQPVMic6yANCvEbttb9jJ7hrLjf/J4Lhq/egY7n7 aVfYVJsgxVahtyrfXPTdVKbicrbRqctozpYoHXLEPGzl9m0YaV38EPONxLGTlgUS VFXR/SuxHe11fMxqnNx263Ydv5kAjQIrDsT9AAABBADdzlqPkaE5J9VSntGSJwPb 9XUmCUaSMOwvaxGCUdTiJjlOUVKfIoUoGgWvo2pS9II31HP3+YWBDyhYj4Cu1odb f9IrlLv6u5G5BOuYSewthAMp85n1VZLjWERKAr0883dgBJ0FE2QYWxppSSZrmtbW rSYCSXOcQX+h9UOl6XLwEQAFEbQkRS4gRGVhbiBUcmliYmxlIDx0cmliYmxlQHhh bmFkdS5jb20+iQBVAgUQKw71jlQDRxQAIuUtAQF3KwIAmVxMJUn023kdxA003HRC twXqZTY53zJbR/LdXVjgIgDDd2FUzf9vyvU7TQWKE5qJZoB4H/xbMIYozuAUuRDg m4kAVQIFECsO3n4N91aF3b4N1QEBHvQB/iGuaRAqESEPvygmwGP/a+L6MANN38nQ vZkqbbil6mKrTweplVlkWkEyC3xxj6mXQGrmuxo6dZD5mz1yMRGu9tSJAFUCBRAr DtWfThgGN4+JhjEBAc+mAgDg6eWttKQVvu7yvwdCHryImG8P4g468iCdPSIux24a PWsdtkH3v84FW6ZhDOaHe8skliFtn279HnXnR06DxtTUiQCVAgUQKw7FiK1SSlGF GX+1AQE36AP+MunJg8k3m7lwAWAiaCPQAJ7m970en78QuZq28wdubULfLkrNKE0f pXcW4RCLEP9HPgsxGHEwdUQ0uNHzQx++rdDkDUyX9n3gp8bNPI+qkFItXfwXgl/d 2y0lN9VaVAQ9F4yfn4AsMHX68qz/jfRtDEEemHXlE8JzyTapLpnsayuZAI0CKww6 ggAAAQQA1/vI2320Fw0uDvKpV6CtFAnx11BNwddQVdK4sKgA53dxAyFjZ08m7MsO 1nO0r7LyJHOB+uTMli1lOp9BDhBECoG5aSgKDsM5fxtawEv3Fi1/yv/Sfxda4uRR z8Jmelabg19dquTr8uVtfx9iyEKv1ANp24wfn1L5VmLN1FTnSD8ABRG0KlRpbW90 aHkgQy4gTWF5IDx0Y21heUBuZXRjb20uY29tPiAxMS0yMC05MokAVQIFECsO9bRU A0cUACLlLQEBbVECAI/wy6VsiYLrJTu7CYP7b7d0VGx/6tNlV428R8+4t6/TTLGl gaj4vwkqxxJvvfB/iC0mUz8R0cc8symHqyCFYCCJAFUCBRArDt6sDfdWhd2+DdUB ARdRAgDA2NCvsdWQ8un9vDO8RyUux/cRQRt8s3jbURoDfMQaxeRySiOZAfcikHlk jYv7xs/30exUdxhEM1ge/J6xkS09iQBVAgUQKw7VXk4YBjePiYYxAQEK5QIAjJ1v 7ZFDLjRHBnD5BbVmsEI771CjsvHOg7nLjpi5daB0S7mq2dIbxQP9N4N1Pktlyx4c QF5R6SjS3y9uyhNnCIkAlQIFECsOz4+h9UOl6XLwEQEBdG8D+wRPT3GD/RqlIZ4u TnbZADXZqvbv4N77YEh3h7SV8hj36E/BMY2ATNeSSlQszeMvw+Wf7qP4K8TmBNqR CynBlfGIAut2Mq2EGFXnnczpTznKO5AnuueA5B1V2LhzUnFYPQ1RYKQwI79CXE8A MHNuzj2XyhrZM7eSfSy02C7U8RkWiQBVAgUQKw7JjIxutC9MEx9XAQFbfAIArqvT ilFa/ivgvjX9yQLiMqsEYGd8JZlkQMxeDgPzEHifi7UGG6Eqqaf6jHK5uWlBX4ae OT22GOp0l+2IgI2ynIkAVQIFECsOwZTNP+0u9SVxFwEB1T8CAJH+YlhjFoSmUAmP 8QUXojTzrNJToYNpHgIhuYQ06ScrJXD9wokCNZKvD+xBGsruSZMNlOmfWdDDgoW7 gLGVuP6JAJUCBRArDsB6rVJKUYUZf7UBAUtcA/9deJQC4FhMrz/Y59gTXDRmFWwF ESxyMln2tbRnC0oJRle0cMgFDdC/CioiIpsBO1PVzJrIeH1sTCXU/DaQuf9b2X7s 3I7tQYw9/ZjR2OPkyYpv3rQn2Fp7POyhPy1Nv36yR4idrA/NUC7Ctt/+4jG68528 ksEvw9pbuVhNBcfn5JkATQIrCB+kAAABAgDEh5wtpV7xm0Owqgr8XYiLC+7JMot1 EaZO3nfjB/k+ckrtoZa/KHLuU7wKY69vt8RJ4exsuD0uU4xutC9MEx9XAAURtBlU aW0gT3JlbiA8b3JlbkBhcHBsZS5jb20+iQBVAgUQKw71XFQDRxQAIuUtAQGCLQH+ JVGk8iVvPLayNZWg6bSvRH3h4y3GLPFzVvA89ZMHb1xgiW29LyiscutGD8qWPpsb WzyZsqeDQ2hFJxqk3k5xm4kAVQIFECsO3kcN91aF3b4N1QEBjmkB/AvUlntcDgBp MjTm41ABJT9wVIs01v2jzDNIykcHiUURKEkYJgDyd+a+bdA4GawdaCnqechXNoLA KDplzZ/eL1SJAJUCBRArDs/9ofVDpely8BEBAas4A/9NRUFfg04khWbB7yR2HXlk W6hrPNE9ci7iVKumjV6KJ2FyyC7IwOyXbV7AUOPyo6LB1mChUY9jXjB5BpNIIR39 R5I4BhDMEPBOBwO/nNapGDiG2RYEGwOFBa40IL5KhuQR+v+5Otc0hnLaH1tS0vrA JHKM/s3n0kkMDQN8Qr0agIkAVQIFECsOwkbNP+0u9SVxFwEBK28CAJhatLqceA13 D6svwHB2XonVwzmkPt9L4zx6eIj4eAmpDqAf61KxAG9okz3BLwQa+vDZBztf6oNl pw5suRf4BPGJAJUCBRArDr/RrVJKUYUZf7UBARiRBACnY6NN4LGspnygnKd/cLjO Pu3cDxlaZRtLxoSrCduP7ANciUgYuobyInCP5qS94tBrK876mwR2KTohXxt6D1Tz qsoeyu72Yv6K2OUwF49kbcZZHj5ab4Wkd/eGEu5oYIHMAzpa7Nlu14BDE+AXKaIf dzT8qB2jEE5O10bD/8LA+pkAjQIq87YaAAABBADS19YljSbdxVnfyXLFxYTuMo+u QuDxyWux/8fq9PcKXOTdsI2d4slSQHqLauxCbZywji1Qv0f2HVvBGxbUcYfMD3DX edcRYL2LqtSOPIbvX5N2TScNkfaHnC4gYtVKCdiZfIldEY7VivXQCFAGjmpnOh7B FeQ/E6+aZmGKlWth/wAFEbQuVGltb3RoeSBKLiBXYWxscyA8dHdhbGxzQG5jYzE3 MDFkLmRlbW9uLmNvLnVrPokAlQIFECr5wtj/yyWVmRmdZwEBhSQEAIAuvgbU2XaU JTwWPCE/kMwgvL8O2PwzGMVpBT6b0pPfH9HmJizoAQgfpS2IzvT0JvMSVdd/AWis x29JKmPZwycsuL9YhC/wiS2M4kx2sTWB2qxr3qxc+nMQ6MpIgQSzxfTgfNjRFlRJ 1HKHLz61auLuaoFpSkXN/cR1dLajeWQBiQCVAgUQKvSxsG1tOFJzS5pZAQHoAwP+ L7jbSlXX9gXnC4U4nVZRWDO4uvydEWTcKNY8/IxnejhZ5FJWg2pEjzKbAyw7Ilnk 3SvdRBe322yRbstdunwoMH7pVllwoul9ubACq4j1jgCfC5GkJ3Zu3bg8fjsb6UrZ FUtpbaaCfp54I1qmsxhcPI3cppZxTENNw0hVXe36X5q0IVRpbSBXYWxscyA8Mjoy NTMvNTEzQGZpZG9uZXQub3JnPokAlQIFECr5z/T/yyWVmRmdZwEBNY8D/R0c6RN2 lX4iXO93r3h+XEnFfPHJATKlzgwY6thmAyyFoUZx/zpeg9tAcawv38KY7M8cI+MB DlmKg0wjs6vlbSGug+FlNtCyA58FgnerA4lCyKBa9vvQj1eJvXl97N/BKRrWnH0p 4+xPpITuyRszwBWjfspU+bFyluG4W46zAgAPmQCNAir42jMAAAEEAL8O8OQ1eDBh W4eiV1iF+TapS3dz3kIQE9jTArEPg+lhNRa98mm6O9ihGvue6tMmgxPxOczMllOh KlBOntvP3YdfeASz+z99kzk3wCo5o3eepUKxb7RPRtdq8AZKMHuDUhDOWeJbW6Nh itUzS80AdJdJXlkj2Sw6DTBkQouPDkHHAAURtCNKb2huIFlvdXJpbCA8MToyMDMv NDQ0QGZpZG9uZXQub3JnPpkAjQIq0o5XAAABA/4o1Wk45VOtpkHV8MY/mxDt8KnT CpGZUTbda0ovFTkpHkNBu+ymwXiDaFQkyItdmse+KuwDYSgoGvmZAcQFU530gUGV 3xYf+VzMc86pOzU9nyipWfx63+HA3fFWIEpelj4clTvhKb8mZ+R3sxiwW68hqQnJ aEpowXMHdoNaWFSIYwAFEbQsUy5FLiBCcm93biA8c2hhd25iQGNzY2locC5lY3N0 LmNzdWNoaWNvLmVkdT6ZAE0CKvQ7SAAAAQIAtwhdLpYOMc9jYuiP/HKciGbd5xf/ Ko6uE60qJpgkFrpor22K4MkaDGxnCPMNvWFRWyzlFMBLzZ+Zh6dZnnUf1QAFEbQn QXJ0aHVyIEEuIFdhcmQgPDE6MTA2Lzg4LjFARmlkb25ldC5Pcmc+iQCVAgUQKvRH b90U2ry4hanxAQH9UgP/a92Or1E/wmwL8IQ/KjaXOBK/ZZfCF+KZb8o1TAE/85am tZCI0djGdgmT/GWogiQcC+OV5kbvyJZystc7F5vck8AnVzjurVKydAlxjXTNG13g JLG7fIR4EEPu+Au+v3kOvZNXVL+RVPcGqppLb7acyJxxch60cK3Y+klSApZ17tiZ AE0CKv/a+AAAAQIAvvIzkJW7QJxSrajJ2/nbzs0cUzuRu6zlUgV1RlWbw2n3tVtq Z82m1uW3Y4xuJkAo94yGPt6ZaztFsaCuUW4XrQAFEbQ0SnVzdGluIFZhbGNvdXJ0 IDwxOjE2Ny8yMDh1c2VyQGZpZG9uZXQub3JnPiAoY2FzdWFsKZkATQIrArVNAAAB Af4zTmMzdQdmMzsZSv2W+msaDmhpT6uSOw1fRh94XBkTeTehYk+LES4Yud0nOa1H WA2vJhUHeLarxRuqx3E/C7Q3AAURtCpSZW1haWxpbmcgU2VydmljZSA8aGFsQGFs dW1uaS5jYWx0ZWNoLmVkdT6ZAI0CKukFCAAAAQQAyYMMahMpKeY7L7QkFL4t/YnM 6UgzXJR9D0CltEaVxwCaGzY5Vs8phOAZjl2b14AyQCUPj0xVlkZZG8brnUZs369f xtBpjfBTlp1b7MbWnZ+kgaDPvHot0muyZSQWGyRbTjTB4l9D+HBguAdms2aldP7E DEawR+xCZkJHNGc7GNEABRG0IURhdmUgTXVuaG9sbG9uIDwxOjEyOC84NkBmaWRv bmV0PokAlQIFECsBFxGbmjfV9XLGpwEBCTUD/0b+KIH7mflLLECq7rgGhJ9k9KYN iKhy0gN2p6QOJB4LzY4vu1Wantw5pu/VJdkCvSiWCEom0IFi0gIYWqR5aBk5LC3D eQVqEo6drJXIiY9C51rRj2P7jGh1QPjd3bK045UrOwWnFQ0ypIWLYQZkMDvXZKfJ 5XtblJ+xY7XlnidFmQCNAir6ffMAAAEEANIvssTzJGOUrwqqCwRn5RRRjMbAFovE I8wuwzHOKxqZKVWEOyshaVsDDO6dwAgtq7BOixvAKMhiGYjT1EjABdkveQmJ51pn nNkVADTW/LJg/xDG+dEbXdpoAPIsDmD52Qa4hQT73g+E3K+BxMWHSuROX0tUDugH HYrYMBOwiJinAAURtC1NaWNoZWxhbmdlbG8gSm9uZXMgPG1pa2VAcm9jaGd0ZS5m aWRvbmV0Lm9yZz6ZAE0CKv30TgAAAQIAsKjX0o394ucwqJwof00r25jeClo0Bne8 w+mIgA4fmxY5/Eq3Ru/9PQ2dQLSQav6QmxgDHt1MZzgL9HHetm47/wAFEbQmQnJh ZCBIdW50dGluZyA8aHVudHRpbmcuNTEyQGdsYXJwLmNvbT6JAEUCBRAq/fY+M2gm O1A7uw0BAdA8AX9MrWY70GmbQkK3Gpi8KKW8wRiiGUOYLqlOXpc/FWKKXxZc6zTi eSr6/Lbr5AKuB3iZAI0CKvxezQAAAQQAuyduclSPeeuo313MBAD3RWFNwoT357ZH 5PdUlzSwX9SOeOaRojkjyMuELhkzB71r38UlhzYcpmQtBPQQh0kXtpDg2fWD4pdp QQAQlR3K4KCxok/vux4Fq1qMxDoONMW0mLv5uzm3DfWxZI2PZ98gbO8+Z/c6A+PV 6jr803GUa98ABRG0HVBoaWwgS2FybiA8a2FybkBxdWFsY29tbS5jb20+iQCVAgUQ KwApU/LwEg8VF94FAQGYnAP6A+7xlUecA9TMy2yY77zNzh+Yh2qmaAADP605FzMq WpmgZfR3pC9vj4dpetpiOXpiQhPtrgWdKp9VQ8BV3ZGqSWEZqMQDQbmVNqo0zjxa dm+WbCJs+MuCmWhqwebNYB47WdStIWww91yqHfg8znUIfADjPmDkljxaaxbrXcdy SWmJAJUCBRAq/sW4JmxTO+Hhs4cBATzpA/4lNoC9awZwjAw1+LZnl6O0RIub8ngS Wkh/FO34/GbFKPWjU/boiKktzFX2pjVjLCUHhYjuTyDf9I8FkbGKVByu2RZCIe1x azjHsX6Vf8uAAkXmsVq/YZxS9rRxCqLRhdh1UCRLYy5CRpc2RnoAPLo62Se5J9uL aIFQOss2RrNR1okAVQIFECr9KbnNP+0u9SVxFwEBWEECAIiUfg2md9cLBA+SpMIV en5byuLWR7CSx3HJhQwid0IP7EjtZgA+bnmHG4XZTsHLH1kquO4mwrw4CmSxkgM7 kDKJAJUCBRAq/YGlrVJKUYUZf7UBAf4zA/4/wwJgR47BEd1k9FsAZtIjfqnqBQes Z2GgpzrbEddx13iur/qwwME2qHRwG3bM6YAmReVKDx08nccxyJ0XtS8aWdJLgy0G 163oF4olFg6pjI+eCnGvv3aLSn7ImvNQ1VRXS4wAq7ZFK+FG8XmvcEIq14esCx8+ QohKA1CmE5syJZkAjQIqwLQ/AAABA/4rPr0YYY2zZVg11tuwTcnv8Br7O0ybaaQL vFkyLR/sAHtO1bpnVK9Lrpa4ajWXrGgws3VjCKeiCEZTp+42AubMkv0mDf7aCWR/ f0doZfrRlAMWE6Y/Nrk86+57ZRETtIAu53rp6L+umiiCND/yUVjyZ34iqUwc/lmf ARRCVtnsiwAFEbQbRWQgRGVIYXJ0IDxkZWhhcnRAY2VydC5vcmc+mQBNAiquwMAA AAECALC76HwzAONUnaxlyj1TWJphHqDvZ5RB+EmFDJ7WSyEuj8tq0P8iZcRV5Ut1 W9tQO7I07DtJJq/BVQVm+k0MTuEABRG0IUplZmZyZXkgSS4gU2NoaWxsZXIgPGpp c0BtaXQuZWR1PokAVQIFECrPoHpVBWb6TQxO4QEBnZAB+wT9j331mWhg+NuLcMes EG9U1X1QZG0OTOr8tItwrA5CflpbQEIULavga6j5VJJuileTobU9Pof/LX6jpwh/ BgOJAG4CBRAqwm+lOHQrXMGwavEBAd54AsQJGC5ulF+heo2oqNCI0pF9AC9LGZCD n7EtEqzzq/6vNQndOin1yYlUJ5Bbv8rDwQ5ZtX+GrgBVgvm57eDwLtDVK7UGjS6M xAmOPOqxqb/vik85CvqjOv739pkAjQIrACgiAAABBAC/bz3yCNkLGb2BGkkuX3/j sOIrDZhkQru04o+9fnvlgsE1rpsl39d8FaM3slpzoWumLvXDEpnrtYyMQwdsei9O OybBk6F79HQ3qvFXo7GZSfLI9UArPhbxHgF4ASlOUj7wghaOYAqI16USrvGq/XbO fE8kczRRhxny8BIPFRfeBQAFEbQjSmVmZiBCZWNrbGV5IDxiZWNrbGV5QHF1YWxj b21tLmNvbT6JAJUCBRArACkN6jr803GUa98BAX79BACOgUTzwvG1eGQATSsKO7ob 8zOM5lzcQ6wFxe4RckXbySwvzwWYxuRsSpOvH6ZLf9YPDi2c3vGDSk9OYz7CPyU2 djVIMXJxy5ITuzu/Uu/wENEM9m7Zqkps0bltLpXIIch01NznTpy+YSM0aJy+i44L 5qAsuJ/vgKtsnZ8saMM1wpkATQIqu5q+AAABAgDPUfDi/la+bkvObQgiOnGjRJQX X6G1/f9AConX6f/g+zEc/OiLMn35mglqfxfMorUdRWM23u5A8R9bGnaOb/KNAAUR tC5QYXQgRmFycmVsbCAoUGF0cmljayBELikgPHBmYXJyZWxsQGNzLmdtdS5lZHU+ iQBVAgUQKuVXcxmDgsNS79YXAQEeDAH9HI0sBvKUHNcE2hyYmFFNmj/vkDHxh70Q PNNGeH9RrOXuzlsULrfB+1+XGTuWCt95CD5r2pNrjqD5OAz7sMMamokAVQIFECrd miSkkSFWWSDVNQEBH5MB/R74VxW6HxvNcR90m6n1BPW4PVRlF/XPMb+WkmMbxcC/ cy8AL//426liFpbGD0Qn5PE2UtLzsg5whuH2j9+gG5iZAI0CKrQ85QAAAQQAnyF7 QB+bkTWJ+PBTVNpa6QIP8Em1HW24UtyyHnc8cCRHV8IXab3OcPbTQzv/WcZDYogN AkzxrBwE0v81si0Ld2YikSuNCK7+K9GTWeP1k3xttQSpxSyDmK6gqM5LgpZfT8xQ LBJdt9yGCstanqWGoZYMI6VcDOOl2Mc2ZhtozJEABRG0J0pvaG4gQS4gTGltcGVy dCA8am9obmxAbjNkbWMuc3ZyLm1kLnVzPpkAjQIq85+JAAABA/42Cc61+viyUFYp 0TJfrTh7hZL9pFavKvlkQGeGML0P7QFfx9bn9mTkT0c6HuPeAOAlerjU/DIeixmt aSQkrXyduI01jCwcMXsRu2huAFZY1cbZRfgZGkV+72q3+EJYdo5H7RvDcMsobfJx r6j/i7bRrEDuF3OkDbcud4z0nEkG9wAFEbQmUGV0ZXIgSy4gQm91Y2hlciA8Ym91 Y2hlckBjc2wuc3JpLmNvbT6JAJUCBRAq+BwzXE2hr7Q1SWMBAbCgA/0bOeyDLHgD PCnPCSsPvwlLSybrlZHt9FYFxDzEK+fyyRDTn4LA3CNn0eNn6aLxqm9KwkeHcq8w JDPt65OS8yVmNQpHu/61PKbuSvuaE9UULNdiZOmSPzY0xvjaCqwVj83Yeg52Go+b xArNzisygYG6/hAoSnI1QjuswvJIKP/BU5kAjQIqwgaUAAABBAC/QxRn5G9merg0 FiL/PitJxqJoMKJDrlIzpZtKz9eKmOflIsn5N3zxBIzGgKcGDQgUCG0JEe5YppT9 PjwkMGxf6mxbrfNyQNA/eN9e2a3kdurijhg+8NfSrafZT1Zix9QIgEFaM8q5Yyy2 oYz1ShC5orOtiKsZaSKIhXGWu7M+ZQAFEbQmRGF2aWQgU3Rlcm5saWdodCA8c3Ry bmxnaHRAbmV0Y29tLmNvbT6ZAI0CKq+n3QAAAQQA7RUWyuadmGYAsM5kQbq8+VPA HmOozmzA6SEOokg4c63I26DZl8KmxBRhytUIqMazjNqK8SiJDGL7nfybA2Ev0ddA r4jcdHbERLOkkSguK/raQwhzBVsTD1AC7FjtnTUoeL5s1iFhC/MFzNpW208l05O8 2ltQLNYh4pcQz3lYg1sABRG0KFRlZCBXcmlnaHQgPHdyaWdodEBsaW1zMDEubGVy Yy5uYXNhLmdvdj6ZAE0CKrFhOQAAAQIAt94dinTILzSzVJwW8lKmPl5IIA76GKG2 d4Wuuf6+4RxJq+EABTCkhQbJXY3yf6UVM+ectzjYyz5zw8lQ9gpUjwAFEbQjTWFy YyBUaGliYXVsdCA8bWFyY0B0YW5kYS5pc2lzLm9yZz6ZAI0CKnXWfwAAAQP+NKBR j6NV8GA/na8KBlDFOSM/vbczlzPSj+0zmfk33b/Gz7fW4baamIAe0P84Xz6XqEOl WXjQQN2iueXmIp/9fR/xfJxe5LBelhRPazyNrVMD5/Hb1e93Bf8X3p0ZtkpfZnJt Mu+sSkkJzEAjYdudiNPmD8eNm7pSJmxTO+Hhs4cABRG0KFBlcnJ5IEUuIE1ldHpn ZXIgPHBtZXR6Z2VyQHNoZWFyc29uLmNvbT6JAJUCBRAq/rsN6jr803GUa98BAXPQ A/992sANN84YkupfvlynGI2R2NvVvb6tQAne0lg8CQjf6rdjTWvHE4hDJZW0mqoz G2CGmi1meXRXwqNMUaNYBQfxoAnFbaboPj0N6qdNgzhQRgppa72c73Ayj7uOOxWn wsDCsHxBgF55/E8Xo5F3m3U5r46pxsQSNn5Sos9lUPtfV4kAlQIFECp17mLidd4O /2f3CwEB85UD/0VJnzQ4JC+Kvn72XCxTVODFA4PjdnVRZQEtOR8qMKd7oixVjQQ3 DFpOYEi0ASx+Zpgf1Pja3URdtBXHpYBVxG6KlriJxFkfIUrZ4wSUoHA3cah9fm50 AT85KKRz3fwnkE4z9+nDpDW0lhfvDG+vg/KmvZJPyRSiwmM8RZQ1/Hb6iQCVAgUQ Kq5vTneU/RvzKz+ZAQGyDQP8DQo3C0Lo62K1YdMjgT1WK58qsfQS/jZnGEHyDjSY PYzb6UQ2JyWmbPsfx365Z5UrMByO0rrOiTtuHtL/4GuA2xCGRLHy7Ci4JRzTKIOi LFW19KSlo0gK3EZp0Y+I3RMK0Ne9nvkcRD3S4C6vGb3XUzANlZei8msyJjPBd44g WbyZAI0CKv2QnAAAAQQAu9hHRyLEDQrqpXhkP/uKLGRH7g/Bk0bSuxNPdTYN4c2P p+xUEYkvQ3JPX3Uhwh/QXlVFwarLPL87CfpbZcSAwWoR3x2z2yy5BXAzzS5iK5+S efBN+qd1FzEVPSwpJtlQODuSBwadH2dpQeH+HjjiHTej4ZMy/X6bhr7UV33/hTMA BRG0JXBldGVyIGhvbmV5bWFuIDxob25leUBjaXRpLnVtaWNoLmVkdT6JAJUCBRAq /ZHM6jr803GUa98BAdg/A/9a7IZVESRRqyZVNhTRQkWNiZStDWxFgH3wCzlyCHzt +H4uYFNzDMGmwCYRJ9HtOobicbPv8ZV150TkuUzmaHkAyGbnyTl4mNL05W5aVVYv FrKCaCjAHQ4+cYNfxr6PSPH83oUsb2l8cFRLov0v08tUHNGiEinzL1blfUQCb0C+ fJkAjQIq/SX4AAABBADD37Ztb6L9d7+rrxl4g60R3ggHwJT1gUK80FlEJz0AG5ac jZae6QqRrOpx83rlCIBwYabbzy3YKKo5DwENvrlPVvYhQUMoQW9xbJ+k+LXVKGWe /mp+eqt89YrKtXe8S/rvEEhljJQHl3icT7MTr4mgnSfgNOEHDEzC+a6J/vTBcQAF EbQoRnV0dXJlTmVyZCBTdGV2ZSBXaXRoYW0gPGZuZXJkQHNtZHMuY29tPokAVQIF ECr9J9HNP+0u9SVxFwEB++AB/1pymCaHy6JkUX0i4mzw0lTqDImc2L5TX6Inu77z QMHiF1u1Xx/2G4RaTbceMvozcsBKQY8KOM7ArLwODnsoEqmZAE0CKsyOTgAAAQIA q+wDIbTKjxexmByf5bjYOirUWO734ArD/8QW78yCXhgsuwE99xTL6y0nEGnJPynK zXj8SOsrhh5UA0cUACLlLQAFEbQmRXJpYyBIdWdoZXMgPGh1Z2hlc0Bzb2RhLmJl cmtlbGV5LmVkdT6JAJUCBRArDtcMrVJKUYUZf7UBAYIbA/9q13zMS22XrfMEpCpe Rv+c1ViCDcvSp+znkaKWSYY2LglUBpUvc8SlyGoeMwFtitkdoIG0RvYjL6+M7gba T+d6HkBqO4f7QOpH29ZLqnbdQi0aKIk+IrIkOEb16nsqy2ojbL86y/t4RdbVfnQf b8sFI4ormEuxUGr54wmP8eLQxokAVQIFECsO1QtOGAY3j4mGMQEBtuMB/27/Gkgl 54VwZnh6EPSoCUtDdlMFr0E1+CyaaVysmUiZtPgWyKlkdVF62L/1NlLQWNwdudWA 9pyGlN/PtPMG62iJAJUCBRArDs+5ofVDpely8BEBATCBA/4gn6k/zL1i/oeMExVu Ric4S6qRxCbVGqNEiuravaFRMtIST80yCXZmfStvXmbtOx4fMKSZyFP8bz+MImNx qN9KoJ9qa/BXNUCBcmoDpiwrTXGTIpG41Hp4oUt1PRbKgxfYO95amJZWqOK543wl sG6c8ECQ16r8k7LjFyiK7TLaNokAVQIFECsOzqWMbrQvTBMfVwEBMzMCAIfQHd9B QECckjVbLuqCjEQ4qMkTswvGxx3+r8HwPg7nXazNXouU0MuOyFMzVMxYq1HpEimK t7Yw1NxUfr3EV1mJAFUCBRAq/QWhzT/tLvUlcRcBAS+bAfoCJ09VmN3kQKTl0FiD gicnL4AdapE9Ae0PhzRicwrpsDgwRZpMWWJ3I8x45aAEIx4WbrE++635ZbsKNv09 /h/nmQBNAiq/U1cAAAECAMyx0/jdGADqY0GVjnTJU0/xVP39MH6H5PHcD7/xbmtb huvNOm+yejcX26z82kEHm5os+APY+2Reb7yMu4/P46cABRG0GEFydGh1ciBBYnJh aGFtIDxhMkB3ZWxsPokAVQIFECr9BUrNP+0u9SVxFwEBKVUCALSFLYzsX+JmonNe y88OIcfHVz6ofpwILDHNbF7aHRbI8xSsYENF46Xl3i0gX/81Yryq4EnP+45hUh3c 8+enppGJAFUCBRAqzdeLVANHFAAi5S0BAR81AgCjo9ianON2xHMtqh0CNtRX8Jlp wJkeWzHTYnZV8G3INAdCj1dxs81HeN+JhRFp2toN8zIFB+Sj8olN0bvGtF2kmQBN Air9A6oAAAECAMguSk+WTd4dFM/x2ujb61dxXacQp96qO4bzv1HakFjdntjYOsgQ dI/Q8BEBmvDKooQutKfJVwcOtFa98HfmaOsABRG0JE1pY2hhZWwgQS4gUGVycnkg PG1wZXJyeUBuZXRjb20uY29tPokAVQIFECr9BHbNP+0u9SVxFwEBRTsCAMkpIc7d QvPhEOJvIiqAeaEsv8c5GzwnF0dXzUA6yX45jRa1dp9Apb5rURSPkgKKLhCezeE1 Q5TAGlo86afa0SuZAI0CKtptOgAAAQQAz+NON0lqxUin3pW5MDURzQcJ/jOX/EYg gxprQ3iexD7A9gAj877+rlYd4k/iGU2BO4A7g7si2xOlEtxCRRIPI3i5BB4TOv69 qRoGUqvo1OxnYKeYNHqgTj1QlhX5Kxm3Bo46biqsrtbsbxJn9wD45t3SP5Y5Gn7c eBk/WAnAmfcABRG0HERhdmlkIEdvb2Rlbm91Z2ggPHBhbGxpbyFkZz60GzxkYXZp ZC5nb29kZW5vdWdoQDE6MTI1LzI4PrQcPGRnJXBhbGxpby51dWNwQGNzLnNmc3Uu ZWR1PpkATQIqxL8cAAABAgDFJCx68eiR+OQTHeG8WQzUDtx6y5oWUr7Bycyx/fvd AU27l9yr6NKUiwoffJtgG7vy7aBw4ICTisURnnvuTwxHAAURtClFZGdhciBXLiBT d2FuayA8ZWRnYXJAc3BlY3RyeC5zYWlnb24uY29tPokAlQIFECrbtYfidd4O/2f3 CwEBYJwEAI0ZSppkrwzGVFijNgUBZqahwYmgoOziyhBZ4PaWRsdqs2BwmTi/mvQN HsTfT0QLVemxJvfhfFaDhKVchd+OlycMBNXv9dyBExxYuyXfX247MPL6EBas+vV9 qfMaBC8WLakpcHzkN0uyTssseP6dOHxvyWbkSYnFWlCEZQyhyTydmQBNAirjBTwA AAECAJoHYggr0xjX0Dnxmjekwri89SlHgxvMjWHHF80xi5MXQNuL81TRDiAIsI62 /a6wfpRNXG+6vqJmq9iQOc4yVgMABRG0HEtlbiBUdWxleSA8MTozNzQvOThARmlk b25ldD6JAFUCBRAq6qj6zT/tLvUlcRcBAYRvAf0fpwQTqCmaLMcJ7x6Tlje03N/W NfFL1pBZrmyv6AppQ9/2Qxo2aGqyfaDlhwX575SLLBxxVTRJS8oBFfjdinfuiQCV AgUQKuTPZG1tOFJzS5pZAQFu+gP7BWMYR7lWYDRLf7tQCp9PAN3sixKV2mqBCAd+ cjkkS0KX2feu0MBc6vMtHxtznIvNJApMs5Vkj8ehJa+KS1mYqfxOT5u8pL2qW3X+ AqP8W80OPxvnshj5WhWc2yciSgG6FjCmJZju8u30cQjInLLi4WODDAc5ils/i7+K kLPgQOSZAI0CKtKJywAAAQQAtDyXWONtwBLEqR2UcAJ9oT56b2L33pKizyjHnQmO Fk2703qZ+3xXQCmnR5dNgAS6afP4JVUlePMxSCWgazVmfK+qRPdWFoXoLJRJQXBc jKb8hSRu6+zeqoRTnnIZOXWzaByOCKrIv/WOY4h1poxA2tDj/jHbyBo4VBgwldon 7DUABRG0LldlcyBQZXJraGlzZXIgPHdlcy5wZXJraGlzZXJAd2Vpc2Uub21haHVn Lm9yZz6JAJUCBRAq3itGbW04UnNLmlkBAW1uA/4pJo5bNCXahpE6paQ/co0mrOzX j2CzupEl0wDj6ylGJlLyc/DS5UhRqbRqk0kz+686K+1IfOwvUAG24iTZ9TIkur12 E9DaQ7K6qX5g6jvpmUuga8eheT8arfDo3WoFAOoim24Fe1z1KOR3H90R+yLLdZ5x 4kW0pecjRCl7+gnUbYkAlQIFECrUa2pKtkq8lXilFwEBheAD/iQ0GsKaQ5gLXkoS hegXtuDBqQcsWJyGEV8h6SjiHBseOUuxWTqEvphs1OFV0WBfa3h732Bp89Bho2fe tiubRSUkrqRe3HMQYpywNxGJbV/IiLn28i8KEugW9oJl+meZHw1XH375cPEalhQM MaMLOkFPFb2nS2uNAZhI71aswCIImQCNAirkL4AAAAEEANAomYnlPXopnms9RtU0 ln9CiLJljssOeflC9A+QIDujXhPTyApbL6VPqSUSoFF/e72xTJixyrwBQhw5lAvf vQPEiGIFQQYxviF+Qg/+6/JVvLCjvnGVFl9kKTEYVeONxBNGiaXuSE0VMQLx47iP 9AU+wYw62aXmTNtW1BUtX5BHAAURtDBKYW1lcyBBLiBDYW1wYmVsbCA8dWphY2Ft cGJlQG1lbXN0dngxLm1lbXN0LmVkdT6ZAI0CKuN2gAAAAQQAqsmezlzittexSL7T 2q3MtZzoGVHC6q2qShatJ3n3WxBy4mgfotY3k3UqFKnoTIt/mYgyAg8blResgagg 7K5d7TnfJiwtz3ugZFuIAouiiNl6yKW9QwinOBLHI81kpLthNJWIiwH5IeAU8M8X G06+mI/QiY1W9SSeOmAzDoV/mL0ABRO0K0RhcmluIENvd2FuIDxjb3dhbkBjZXJp YW50aHVzLnBpbmV0cmVlLm9yZz6ZAI0CKuAF9QAAAQQAzzFX9DWfy6FsVCV3/mt3 UxtMSB1vhQnym5+aLPWS8EE1f7ZaGBqJclUhKiI0uxIMbaBX4qsycjJDeaOHLcQl 7P8XASn8Iom+n3yz53M+YTSJ5MpYVLum/StGQ1eZH83aHk0dh/Eg09nt75/xjpQh qLDsyUtnKyn8J4rCvohckiEABRG0CVRlZCBSb2xsZbQTMjAxMDoxMDAvMS4wQFNE QW5ldLQSMToxMDUvMzYuMEBmaWRvbmV0mQCNAirX8PoAAAEEAMR3OWKIVB4xzN1B o/dXN/b7J7Rs0f/HB/ptEaJE+/xfxd81zXS07ph5Q/djiuIXQD1hKfsVQMoMiig6 fiwRSOCUz4cdojRC5srpuUrrCTH9RVvtpusyCv9IMzKoHdkA2+hrDLBasZQ3LZyK 8/bqmQibg9y3x47nMPUW0H0hLsVLAAUXtDpHdXkgTWFydGluIDE6MTQzLzI2OSAo Z3V5Lm1hcnRpbkBmMjY5Lm4xNDMuejEuZmlkb25ldC5vcmcpmQCNAirV5D4AAAEE ANrK4Za9zBHUPq3EL2rZy1+ZoWWrwlbsnOOBM4Z9RBv5HdL2n4Pd2ORCU6ZT68qz 3gAZrgu9kYSdpHRJ2Z7AMTvkpCc19/xZZ1cmrbu1VaLEdlnJeaS0DIWmM9GYUUaC L9RiKgJzJnA/0mwRQ6bkpM0w+DI5+0zxyaOpetHn8j2VAAURtCdNaWtlIExhc3Rl ciA8bGFzdGVybUBvaG0uZWUudXR1bHNhLmVkdT60H01pa2UgTGFzdGVyIDwxOjE3 MC8xMDlAZmlkb25ldD6ZAI0CKtz3+QAAAQQA06sFNgWhUfPlRJcrkO1V5Bp9iHFT 2WMR9aak0SOxvh05wYmmZdnU9uApEg+bju0zwD8RZdANYQ87dN3L90jHSJH2wMVs yNXcJ6NPlsuc/OKbn7WD42lwNPA3NS/KQImcw2LcfeTQQiqoq420xbjpewVAdh2K Y7/ivl6qbtuRADcABRG0MUJhcnJ5IEthcGtlIDxCYXJyeS5LYXBrZUBmMzMubjEy NS56MS5maWRvbmV0Lm9yZz6JAJUCBRAq3YSHzIbhwBREKj8BAQQeBAC79vQiqzvi lJEBuXLhC1JSukw8ky7R4uHOgv5GcmHiyYHs4hq6aKhpUzgybsmI+HClBO9hIT7h ajVjGYg15UyA7cGytDOo/QjLo3rsNLY5ad7CmCvGgA/0q+DvgmjIzNK5t0Mdgh57 QsV69BXwoH3nKeH41dX/UkKKvh9XkbzoL4kAVQIFECrtmPXNP+0u9SVxFwEBxp0B /jgy0D4FzaEMwO/yb2LYW2DMG+S0t1Gk7I3JQMmsSzGf6BWMv5h7EZRdk94yRDT/ 62ft3k5JsGUPvwa6VLEf6cWJAJUCBRAq3xMSbW04UnNLmlkBAVA+A/95zn/dHFOr D9JhL6tSsQbwKRV7kb6Itwmx3ECaJxuhH4uGVuDCwu9bkSLvILGsCu3t1yuw5Zrh ivtC5khq8MID7EuTSpcWCI125uSQRneTThuH6mJmOjj3dUWPzRZKLa1kbiPH4wca h8sMvUYNJjiPyXryLPv5s7N9VeVz7jcn+pkAjQIqwncSAAABBACvXC8GUY83UrGJ PzD2CG098ZiWfu9yMTPKz2ji+TK4e0KI5M13DWa+1bWPm+WWv0dYnJrKSmQ7sYbK K3owd/byvNIYC6QfN2Nl0C8RcNk4lduLlOlEWXzQuLKPaZhqx9uahtibSnHmf705 lDnXN4ijPAd5ooc30tf/+yHKJrNc0wAFE7QtSmFzb24gWWFub3dpdHogPGp5YW5v d2l0ekBoYW1wLmhhbXBzaGlyZS5lZHU+iQCVAgUQKtBLM//7Icoms1zTAQFkqQQA ndM0KgNy0hBQEI7QUrxMBE1nNzvg5hpoqBO0nCmlckhzB1JZfUATCU9zkNyZ9Vif FuGSnoj1HgPYl4lEDOtASZm8MUupbSb1T1JMdkM6C50t9WjPl6LIj0tldHLGefDq pOTantqCdyz8WuRqUJ7S/JKPTNQ0t5LidT1o4s3/M42ZAE0CKtrZngAAAQIA9UJP v2NsjfiajySZ3ihHPNNUA3J+pBkedcQ6JVpsB1/BS1NVx8KGKivpPXgFtYvtR4oB EZEVlLCZWKoJnH6ZvQAFEbQiUmljaCBWZXJhYSA8MToxMzUvOTA3QGZpZG9uZXQu b3JnPokAlQIFECrchQltbThSc0uaWQEB4uIEAKN+Cl7wUI/1tFckEfZc7WDbsN8F 3wP+mZVanZOeQi8KlViSsatQ7D9E1LfjNo/03BE7vDODpm3l/RHhQLwfDkMuS49E BDF0qhIn45X4v6ImUrF4Fs1MRPQE10lnoWQs2CjStPmSWhG2jvL7xMPSy1r8m4n6 dxGcyxCFML8ckyU8mQCNAiraG3wAAAEEAJuaF6NRnKvVEU3edX8OUxMdb+k3ZRfd 2KM3b7+7mahkMqTfKj/wiNpqbnnV/pKoD3jf35KjO0i+Oa5spGCc3I7VCDDcKhHV 6iZcYD0lpF2ySh5sUFsRGqWO4oo/jyzrNgzV0awrg2IYT5u7ClLXbpuZGcdIKbTN dZuaN9X1csanAAUTtDFKaW0gQ2FubmVsbCA8SmltLkNhbm5lbGxAZjIxLm4yMTYu ejEuZmlkb25ldC5vcmc+iQCVAgUQKtwvCB/LuW/nlgUBAQGbJQP9FE4TZ5Si7z/2 t9bcE46cSm6B3GmrCEO+YC6SNSfSSaVnFTLJFr4h/TgkIWj1giTXTC8+ebB3ulpf 6E4MrwyLrT4dZc3bgZ1bKHlq4w96JWnBcW7FdDxcEc/i4TUnBsZ5RgbJddt7UI/R axCOmlQJyKqtHHoMT4y9p6InZ3KUUrqJAJUCBRAq6MEy7LFLgVt3hU8BAcV7BACH N1PI9Ru5rVVIl53M7zbTpbkgE0neQEWzgiuy7THHS3+Od/aEkZqWxL5GSz9qd1TP TurvKcXXDtuF9frlWio3+z0MqNFRiU7ghex7zYBD/6sVrtRrJG+W0oekGyJ8/hJH iYSfIQuuSHJ6zvBIoIjLN9mMlYk7d8yE91aZhVttookAlQIFECrpIRgnisK+iFyS IQEBbiwEAI6YWLbWGcjUinUQ0D8Baz5te+nZG9eJSYRESrWCOBsdrP8NFj9TV3l3 FRxbSzWT1QGfaZx3u/3VIOpfnG04SrIG4RaEP/mn1PL19ShTQ1bVEQq7XKB+iXXK kInBu3DMaRXAi8Hfq3ifTz/oa6I+GxiDS8CXDda7utC2cQ1WgrSGiQCVAgUQKtpD RG1tOFJzS5pZAQHn0wP+LkupLVZYBbGPfXdkHaCxwRWEc5xBfIRO2SwpJZBBHclF uu0OxxOuilc6bAiswbPHoMSP0MnOChOa+g0BFxhRjfKVXiXhP2Oo1lqAZ41r7E9h 4oYs4YYo7fjM1lZZtezWNKIibuW57lhdyvLMbDx6oxCP55AG7zTWRzL0DQnYsjOZ AI0CKtHW8wAAAQQApMSslBzYEUQzIER/SRu3xXTdruTE0EQ4CZfa9ZNhVbTxe6jo VfUzLTSno6iwzjEJgSeL/yPIukK3hH2whUXLD87dcR+dhSuuK7ans2owRo+cCfH3 zKTyMleHZEAVoTSOaDPVVUfUaDpukr0ujXMBa8DAIuoJrsKPiJ6a6GXD6cEABRe0 JkppbSBHcnVicywgVzhHUlQgPDE6MjM0LzFARklET05FVC5PUkc+tB9KaW0gR3J1 YnMgPDE6MjM0LzFAZmlkb25ldC5vcmc+tBNKaW0gR3J1YnMgPDE6MjM0LzE+iQCV AgUQKtT1Lm1tOFJzS5pZAQEfUAQAjYXS5sbp/8ewlqx/TAa/S7n9DSgppoBEQrqp 4uFDInSWvyVz5VsGgbV7tP1Sxntvt9++xwfn2LdSPPDfBLElAiZ+Fd6yRwVd7wWV bmFml0xFxHwhR6sfovEZ9Mr0RjdeefZhTuN3jWV7EQBHxyFlUQehf7jG104Tn45S v0x7CIu0FkphbWVzIEMuIEdydWJzIDxXOEdSVD6ZAI0CKtW12AAAAQQArC5Odv3q YspAvcmybjWopLbXQJ2EINYd3xiTEnKqKkdyytTIDVIFdmd7sbaaAz9fuGZ4Gg66 Fp+Y3PeVYizkiGIMqpxqcXaLbAaO2A+ZCpmYjbB6s9ZzqcjHUsPF1gg7v1LlDPDG VA1eNxNqcjpAW1PAfN+mL1UhH8u5b+eWBQEABRG0JVBhdWwgU2NoZW5ja2UgPDE6 MTM1LzM0MEBmaWRvbmV0Lm9yZz6JAJUCBRAq1k5AbW04UnNLmlkBAS6nA/9BMkQ9 xoehzuOVyvBRqU7dIDiGR2TKp9q+XTe5tflTqfAhGDJeiUrxVt+FsflXJTQgHmu6 RLXNLyVdZv7N5EyfrQ+SRyxpmPLjsWWCk9CBQ9N0yvGOOgXJHJ/fNDRlW6Ce67qS 0czMyhVe5clvBnGg0dOWddUWOvNYN/u+9G3wxJkAjQIq0f0bAAABBADgjzogl/b8 dE3nct9bIGDrHyLFXMVvcVfK5DUsKvNrah9aGjMF2fPxu5Lujk6btTynY0IfAHuz z/7i7UMfDhLD8YBHBJJNJ28C2TogiIS9jZg+AOWtUvUA+yJ3s1r9CAWgXWFihTYW mu6f9FWBq3WnSKYqre6djqPZrd7oItiG4QAFEbQhVG9tIEFsbXkgPHRvbWFAc2Fp bC5sYWJzLnRlay5jb20+mQCNAirQwOsAAAEEAPELC7P7vLHK5hz9urWhk9BJ+2i9 U1Yzzm6MKM/SI+UAVcXsYTP5g9kGJLUpLVq7KxalB1Rqbvg9FjjIaoiQ+ze7JIPC 5X+e0uU43iLMHkgz2mCg56p9hpgkDxwM3R+cHQ1cr2qrSJb8sClbYtknbgecNM0J MusvUNwtSKqN9fslAAURtExNYXJpYW5uZSBDb3dsZXkgPDE6Mzc3LzNAZmlkb25l dC5vcmcsIG0ubG92ZUBiaXgsIDcxMzMwLjI3MjFAY29tcHVzZXJ2ZS5jb20+iQCV AgUQKtEZf21tOFJzS5pZAQHMqAP9EKg/17mW/gi0eWiUT/PpY+R+jBi0VtXAdq3H Zo+VAFEyARt/fqiOuotiC7OFtnsuTPVtarOSxRpz/5bWdIr7AGIdbnwD2dmZwvqW DBjvPDzQK1MwPPDpyqRtlEdU9LpwFkn9rVy77KShivrp4xHTVu4RjQUZ8EE58ilD yhDolZSJAJUCBRAq0MaYednIlhgdxdUBAaqkA/4gm475FKoXXM9X0/1KH7HRqAiu +VnrfvljT6GJt8c0BGtVsELLAGODAWCuzmP21IWlRznGvipnFXPoTrfi9bkjBijC KmdhB/atLi9FB+YO2B3PWtwmUnWbIa7CQO9vxe4t8jYbyDiICAv72dLJXTHgMxPJ AuFIO0ECqScYfb3ol5kAjQIq0LpgAAABBACUmiHr4bN1FBXm/zO/6Yt1bpyZrbcx Lv/0pFk7/FkaPghdXXyjMZWSnosbw/2dVMMv3R1vJB1mWGl6W+tOkqjeqteOAE5C f/iZHTGE4doS0pGdF8wa6e+mPFRZa/lV+3D9Rh0qDqoAlc0FShvd3aGUEI7eiIB7 cGF52ciWGB3F1QAFEbQ9V2VzIENvd2xleSA8MTozNzcvMTQsIDcxNDQxLjMxNTRA Y29tcHVzZXJ2ZS5jb20sIEJpeDp3Y293bGV5PokAlQIFECrQx1HcLUiqjfX7JQEB EoAD/0YzuJ4LMxKY3CunHyOHmGbAcOEXcG6jqH3GarymZgisy1s1OZB5V5ak4Czr GCj7Yj8k35KDjp+IcQHDM1JpUDUKB5p1iLblWOWmIa0Zb7SgS4gYDY042knkleCY pP39mrBC91SSFrGIWjM+wB9J1Izs8N5bWe0EEJonplR701/omQBtAirXWtcAAAED ALKH2cKuVzOuSo2NTQVwNtiysY+7piD8FZxzjvDGgOYGVJMagPP3ohPmlKVwmky6 ljqtDVaGKDNBmWQlYy4KINpcPI801PtTnqzvLGa3aVs1hMX7mt218hn/G1O2n+md CQAFEbQ5RGF2aWQgUG93ZXJzIChkdHApIDxkYXZpZC5wb3dlcnNAZjU0Lm4xMjUu ejEuZmlkb25ldC5vcmc+mQBNAirXO6sAAAECANunzqcH3SLKWFweZ3BAUXO3OuAI SoBxocBtjmgsvndahwdXFGkQzSPgf6uWt3HIksD0a6sKPOrQjUXODZuyxIMABRG0 OERhdmlkIFRyb3kgUG93ZXJzIDxkYXZpZC5wb3dlcnNAZjU0Lm4xMjUuejEuZmlk b25ldC5vcmc+mQBNAirXWbAAAAECAKOREYOarMoniJ492Q11sfFe5jNAwqb7p5Uy UCPJmcWXZ4mlHIWkmhqOXUM4VArnYKVIrddBDbkaEVBAW2UrY20ABRO0I0NodWNr IEhheW5lcyA8MTozMDgvNjBARklET05FVC5PUkc+mQCNAirUKygAAAEEALVQCans Isa6a+WfQiSOZDko678W7O4A/A7iUmJszodnQD+FVy+L2mcsL9pAjNwhAlHsBb35 FOVyD9XasQoyVFUZUrF7n6M5RruGGMrs5Pv2m1tVzkeZcSTWyPS7ovLQXRltBuS9 QbdZu5j8CzMM6g6GvvbqrK01TG5mb1FL1TGDAAURiQCVAgUgKtoRmW5mb1FL1TGD AQFOnwP+MD6LDlj4EPvT9r9ZsLMy/pYQxMa++JMnAc2Qx+cs+rw8lHU3luXbeLwk JZ2prh3YIdjHc682JGkUkFBSAWemsrAa387CNKU0K7Rsha9qCCXygswqUy1UjOIq cGwB7uP7DR6nM+hklibbMl5acEpmihCEQkjUilcfA0GdWb5yGna0C0ppbSBDYW5u ZWxsiQCVAgUQKt3s7x/LuW/nlgUBAQFOKQQAge7txev1ekLCmnBNuMcSI/r5uLJS vhocppOnvR3MeWXaFsfLw5flwIhiWk/JGiXZ9a28FSdoZZrdDsMsZCSrbqmv0YWx OGV9ojvy8UQkwdNNpJvUe8PJ6jPrHAeNheB0aWC3y5B1QFmK2efUNg9vgklVVv+E FDEC2NJXpp27VpKZAI0CKtCnhQAAAQQAu9vnkZyc27CIVPYL1xZE3Xb+PE0GNLUK AqPcWvWPKHGWmnpo0OLmam9R7tKYHEy3c9HzORS/WTjZyDSi5D/p3gB4YWNQlSwv 9cIuDaOFwlL6Fvpq1ndIDua2QhE4tfOuv6EDbZeVrbbDInJqfveeQf8uSy+epY9G lrv0AJ2yUt8ABRG0R1JpZGRsZSwgTWljaGFlbCBILiAgPG1pa2UucmlkZGxlQGlu bnMub21haHVnLm9yZyAgMToyODUvMjdAZmlkb25ldC5vcmc+iQCVAgUQKtRt1kq2 SryVeKUXAQEONQQAyiiv9L0KkmUXzWePJogB6zO4MDMZi0M53KhwuB9HYqN3Mea+ H67ZiC7W++Uv0WeXUxoZHMo/dBeGYuUvNBrz+y4EjjAK88PFsm0Fpm1okeeQ1Oic 0hBfCr190XvOVgsvJnlex8byyfWher46bXwmqamTxwDdqdABXiCSEUW9MK2ZAI0C Kqw2TAAAAQQAwpYznabkRaLShwri7VwLY8/IdPq1q+T08LdMHlcFgN6B/d2yV1Gm eMmPWv5o7TwUU75AsQj3C0Gq9/U88/mItfuwPa4hWUkfXgw+3JW2Ob1kpvwky0Jb vjTjkGC0cEL3JDdXu9c1XmMzp0TahycfgAj+kEWsYsk8qBMDr1ghTDcABRG0Jkhh bCBGaW5uZXkgPDc0MDc2LjEwNDFAY29tcHVzZXJ2ZS5jb20+iQCVAgUQKq4zVOJ1 3g7/Z/cLAQHKtQP/e6hXbL4W6Jyut3agNrCA7D0SNzHoT5PL09U+oq9+UuzTNjIZ 94VVKAFtNIM/df3U3cXryfJ2X0n1UDpBEIZ6UczVxlG6QInQBhsph+nBQ3TGMQYe wOt3aBPmJaUHe8Fm+L7phuzitKr6DJnNWbX/6hGsx6ffZ/PavQIuBS0eiTaZAD0C KtZoswAAAQGAyUkguJ/Gtcfx+QnAlt5IdcBjVD38DM/JsZXLQPH+rvQWvd0qEzpe hISBrDYTPOfZAAURtBZNYXJjIGRlIEdyb290IChjYXN1YWwptCNNYXJjIGRlIEdy b290IDxtYXJjQGtnNmtmLmFtcHIub3JnPpkAjQIq1lDiAAABBADMGAE/s57s7web wHZuIwfhCYinZ6ANRL8S/lmuC+FvUNp6dXIG5ahLx/Lje5w78vB1+eizA7uhc5Vk R5Taivc+F4EOwWCrnrzYXMch0BOfzcZSrSOaEhINdZiy1OZ0tBGfRFMBIUFjIWCO T4rb8U1TPbXCon6lvwTMhuHAFEQqPwAFEbQiU3RldmUgQ2xpZmZvcmQgPDE6MTI1 LzIwOUBmaWRvbmV0PokAlQIFECsDlf6+Xqpu25EANwEBIxED/22n8dscoVytUdSj O6MBG2tr/Cg0vBkNAuzx+b811IpDb82d9qei4znX+BBXZvaXKO2RCyZ8ECdL3Ejg DvoZ9riZYdumLaWyuzjCXqBIbMPyrHwo/DN0NVxFAUr066c2fdz0uXyoflYp4pCt FSAipfQEdPN/cn0JRf5qXbi344LmiQCVAgUQKuSfsm1tOFJzS5pZAQGTAgP+IYD0 obZ4NDWk3OWIfcI6673UhHUdK786ojzhqeb35qUozy7Go3fpLqg/qMVl6miIjSRh oad4GGGl5N5XlzJ9tdSBa9vLxK4J0bD2eZoZhFIB4ERKoHQtyW/4j3l0mEpbLBFO 4tCSV+telId5XyH58jN+GYQHZB/efNivRD5EH3KJAHUCBRAq11yc/xtTtp/pnQkB AfRXAwCa0gG1V0oAC0znEWWH0979WL1M04/5+S0qJttcLVgiByANgPxCHOb/zVZX w7QISTZ6tUcKAckL7Lz8GGHJFn3tn/S6OF6sBYyaOJJpNemdMbliSyRgfZ9+Hk+o 6Jg5gMyZAE0CKtXavQAAAQH+LvwF92SYQioq3YSF2UUAlzjisHdkzMKF7PnNVwH2 NGlTPWgxjYzYae5wZFRy8xK9l4X9qoJUge6h0N+rIZhhOQAFEbQvU2VjcmV0X1Nx dWlycmVsIDxTZWNyZXRfU3F1aXJyZWxAVHJlZWhvdXNlLkNPTT6ZAD0CKtTNtQAA AQF+MLenkI4RQwnfHOuriwkJNpTkyC/ML3i2nzLHEEl4pQajvHGAxKEEKchmn7GU WLLFAAUTtBhQZXRlciBNIFNoaXBsZXkgKGNhc3VhbCm0JlBldGVyIE0gU2hpcGxl eSA8c2hpcGxleUBiZXJrZWxleS5lZHU+mQCNAirRDBIAAAEEANSxRNwbmOKiEs2J zwsBfn3KRA3y8X0JScH8FCrlq7tKGFVgp8C4bO2UCQ+TT8p1V5cbsB7594ykIAdi 9lCefxXP0j/Id3NBV6Q1CQ4bYnFPcLalBZ6zlGIB9TIdwKxeglqlUxVcPBGpv8YZ OYJJuOxl6x7GD20IzJ1vNJwmRP/PAAURtClNYXJjb3MgUi4gRGVsbGEgPG1hcmNv c0B6aXBweS5zb25vbWEuZWR1PokAVQIFECreDGbNP+0u9SVxFwEBXToB/i/9KOQm rGOZLBDvVOeBOxIkQRyFdFsZ2AdzbZ5m6WcjUFerZj4gaklHUiRAM71qJrXuzH9t aLppjrSVEp7g3NmZAI0CKrCDXQAAAQQAxU0wjvrqWN65bTXGpcphhXmWYM+9v7p0 JArebWIFB1qfSeimbfmPUMhGndQlmiAB7l6KaxCDVMAsOFOrfXQ5mz34voH8fF5f f7gFp0gNp3iD7EiW9oVjVS3+Ex1k2TDS3M1k51Q+I7iNgjKKtF4BSIwKbqNfORNE hOPv+/HFa08ABRG0M1J1c3NlbGwgRS4gV2hpdGFrZXIgPHdoaXRha2VyQGV0ZXJu aXR5LmRlbW9uLmNvLnVrPpkATQIqu2UwAAABAgDAKv0Wo7mBFugi6yOIABpejWBv 96td5+bZzO8q9abOboBFmA6vFxYKvqhRV3l0URshsk8VrPc4mRj8NL7MGZAJAAUT tCpCcmFkIEMuIE1jQ2FydHkgPGY2MTcubjEyNS56MS5maWRvbmV0Lm9yZz6ZAI0C KraubwAAAQQAy5m8cJl3gIaF0Nx9V8mPHof9wHlQUnQWGTNqW4NnfsUruef0FeFw QJUDajdNBY+MiH/vzuzaveAVIRFojgeUVpeNa8gn/cFiCQoLFtKbM308isD9A+81 fK/+sTZcEQWhH2LFbPxb0kQSSTCNK5HejX9bzSIz+wayU4mYQzmyV98ABRG0KlNo YXduIEsuIFF1aW5uIDxmNzU1MC5uMTA2LnoxQGZpZG9uZXQub3JnPokAlQIFECrQ 19ltbThSc0uaWQEBrHMD/0a8m9ZX9jVREbX3RMDV6knJQbZFGu2KL9syqAFcofqQ RWEzOcnQz7+G4XjbXedy1kTTxHKcIGyClXFD7LqgEL8bHD1i5yLU8AHTff41kBtz twlo7GCZlfs9Lqj3qzX9GGXZEeWEOxwl30qBfXXWEsUkFrK84Uh/L0CKa3vpYW6W mQCNAirNLf4AAAEEALMyyNvisb1TJVHyhgvta9npDwFoJIOpJqrv8cr5OpeCOhkT hxhWD/dYmSZEzxlu47BUDj1KyDRemP0og0Lp2xsxJLmAiGWKd4zYlHqKhXAgJJuz KWK8O6BOfZUbFYwCCKGonbPtPPdUPp5KCluSpLBdT2BQsk0okW1tOFJzS5pZAAUR tChDaHJpc3RvcGhlciBCYWtlciA8MTozNzQvMTRAZmlkb25ldC5vcmc+iQCVAgUQ KtDGbNwtSKqN9fslAQH8/gP7B7p7z5BUmfJhZJYdMoSRSAZkVP3LvvpCZGZDdGye 6lxj+WF2X2rCXohAd2jnQJdGCFE+6Q8zP6tTbTikoIksQ0hbP5xFIfKp3Lyeyy06 Mzh2CipYHyHRByGU1q+bQsCYotMIqAntaWcYXEdj6eB6pUxselvFH9RQAV/cPJgu JOmJAJUCBRAq0LwEednIlhgdxdUBAWo3A/9yS1zOQuRHCVx77hzuvC+fue+64jmA 9WWw50Yumq2cnpwSA49iDMepby1CtN5x9RObVNO1UqSfAQ/lgPEJgNyOW8zfWf9L t+vgF5BL+5q0LEOqGj/yQUVs5bhzp961XeVqDSlE7FdaUIZghgn13NFWJK++VLhQ IeY9s3CZR1cbWIkAlQIFECrNY8oYV+Tdsba4IwEBIo4D/jWI/JWxluKBsTTjdNBz Y79dMx16rLLs/o7t/AT9D6HlC2GXSl3VJ47eSvGqNpcuCNnTukixv/7qeFTxSR8I S4V1b1gTu5w4hgfZNKcBK+/RYDnvFs2W49Vu6LyAFG2uqmgV32ojKc9uELG7Cyo4 3u2KfDBEDKCJ0TK8biVVV4SriQCVAgUQKs03K21tOFJzS5pZAQHQAAQAgT0DzRqH vx3lPvdmYe8eW5eMxgGL3o3TuLH3/A8ZrmagSgCtXVQvw5n86xVdMAsfnw+njybo D3oPPWsf656XomW703JFE1XPDiRe/l1gLz+i7sruG+AHrW6ADG1Ls/POMWui130h QN39uSY/3iVnRd4WQTfA+Uw3UmWSi3mTZfSZAI0CKsZlkQAAAQQAvpRxOtg8oVxC NOzW9NvEao3W3da8XbH03xms98grBOF88+mlReQKXobPRj+R+71ZuEOiIGcwoiu9 dO2xb6HR/YubwS31Gu0wFH0b4I2kg+z6Uk1n2Ozysi6Nfu5qcG39Ur9nSHB0ivMn xgERp9XoomDeUeZ+62d3GFfk3bG2uCMABRG0NEdLIFBhY2UgIFsxOjM3NC8yNiA8 Z2twYWNlQGYyNi5uMzc0LnoxLmZpZG9uZXQub3JnPl2JAFUCBRAqyEWZzT/tLvUl cRcBAVysAf9AzA28lwwpOWjQew7c7S2dCf1pZrsbVjvIH/NWMATysrUWE5u2Ptk9 tJYsOijH7cSy9uDIDXKcXHhSCJVWShxpiQCVAgUQKs3JC21tOFJzS5pZAQHyJAQA lMgaSBlNourM5deAGSrgqbinr/T/0nNKCfPpZ3SwKe27No+NEbFmHCpPPjrNSVJo GDN1p8ePSnZdvuqb94cJCGwkdHBWd2c0xAjU4zUY7G+ddogmXfE/7mGdWtXL7Xtg a0vpDZdQ2AubKKCRntaXGNzrqP/5e6csUAhUHd5VLLOZAI0CKrDAUAAAAQQAtjl8 7QTiBTb4jkruf5IgK7Ig01Saj/PZQu8ruZTbkJbXqkb9RN7q2bbG8RLYjJxcEzCR 6a9atG7NNteSuQf4/yu52MxmqIF0BikLD3vqtxMSLKYQpGdXjjAS3T4NhBj4Z7QS 3cijYnWpiMmhHb0egsVV1S3hOnIIZitHZ+yaIMEABRG0K0FyamVuIEcuIExlbnR6 IChMRU5UWiBTT0ZUV0FSRS1ERVZFTE9QTUVOVCmZAI0CKm3yLAAAAQQAsYqAtuUR AJ9xkSJD6MEWfDmDQH6jXoYw+yxgEojttaCMZsEOqeRCgwZqA0mlwbm1fZsqkl16 CLTVKnbZA4yllt2u/8pdFYen8mOs0sBken0H6eWixtGs8uEZlkD86DJToPYawacw NxNpw8PjfCjWD5FSkO/5SMyv4nXeDv9n9wsABRG0LFBoaWxpcCBSLiBaaW1tZXJt YW5uIDxwcnpAc2FnZS5jZ2QudWNhci5lZHU+iQCUAgUQKs04AW1tOFJzS5pZAQEr qQP4zrYEvXhV77y90m2Vew8ZbDD/pxSpVWwgM16uU7CBVlAvMqTs/24qT3qJ4Pcl 2K6P1gCVj0Y+m4PFO07UYEm5UX00BYEZxiFFT4w5CO/4BJfrIu3oIdaadSYxdBz1 uJYZouoE+kEvd35tIppVPXuGLRXdeojXuw/VOGUYgV9aU4kAlQIFECpvUjT0ygCB jeci2QEBOfsEAL90+6LOAaROuDLyKKvcG8yTSg/HbkRUrpYsX8ya2O9NRvr2sLx1 zehE5/nRUKI1Tk2pzp5J94qaS50mjlW+a7Kf5tMz9JVpDPeU8Y3k7+Pnb+DG4lhX BkyUvV3AiqK3x89ZW/jRozIHM+JdT7gyUQ3Vtf2P/4zTvlHyocusmGIgmQCNAips wZkAAAEEAMrcqvIwyKcvxWjFbUIq7/hhzWTrpeThdIxJl7T6P1sX9U6axBhSa1qE 8LxwzTZ7/fhqaUlcZbrho5WODDqge325k7c2DCiIGxG+awndQR7a6X28/U05aQXQ iMnS+IgDOLo6gCtGUFoLDoUob5AuljqHlOrQovmoIPTKAIGN5yLZAAURtCdCcmFu a28gTGFua2VzdGVyICA8bGFua2VzdGVAZndpLnV2YS5ubD6JAJUCBRAqbfKQ4nXe Dv9n9wsBAcIXA/9w7xBNQn8sTkmfBy6S6tFk7GFGHvQA/9eryxHlqjDDhBKQeSJJ GvPHmNQQ32CnVuv6M54qxT9iusopMv1RFS4ZXTB9u5KV4ajBGvkGfMsHLYgiAEcd UwndShAm6St/zRoJzQ3ae0mAFk9MYJKYcMuJYL3wCZjrrI5YNrrhSO52w5kAjQIq ezKiAAABBADWbUO71XAVqN9dlef3kGRtlsSA9gnOkoRCzVlo4hFvO792Ie/Y1p/c 5pz2YAyU+9C0beZHVWHwofAdUmdpF3iz2q+4viODLN2UbD2E7hoPjm3HLLjgiRCK y7lBjtEofLm0TU2mSuAZOR4zKaNcCRcRcSCYtAiJZA/6EarpnZl9RwAFEbQlUGV0 ZXIgR3V0bWFubiA8cGd1dDFAY3MuYXVrdW5pLmFjLm56PokAlQIFECqkeZfidd4O /2f3CwEBrsYD/AqgSbc7d3qYO5Gww2MxZX4gA04nzHbyx3XnX6xWUOU6w+Rx/X/0 0hP42og+P3Rf+pBg0y4KiIe7hY2TOb6neh3qpcpxkHQKtUkRQd6zYFNRuYoRNTge usTiiAv0cL6RYaZFWt44RzbOr3tJZrz3uPHLz2nvDvec4zPHvMoWyeVFmQBNAiqK PnYAAAECAM4DUPnxdjb43Il+yDkRUO8TgzOW/hjTs1/blllrVe8HDlABqHZMib0a NFhKRFYjvsNS3xk34N65vtlI/HoTNvUABRG0IUhhcnJ5IEJ1c2ggPEhhcnJ5QGNh c3RsZS5yaWdhLmx2PokAlQIFECqmFtb0ygCBjeci2QEBqVwD/A/8vnke2KFNyFLT OdYhiAZlbpPuo621TIYWVxPJ+D+TVkELdn7HWmDpDGQ8l/7XmuDEBrGjFiQj1Mv6 7+rnEqhA4ufKyKS57GuSZ90G99iLLimCiA9ytQyRz8Wi8GUzh2lpv7/478NvxEgy a3nVM6LwkXodv4OYPVxUnLoSNFGFmQBNAiqc8q0AAAEB/i6Q/XxMaNqWP1tY4D8v Hr5KiwFz1XvE9F5ltPVPeW2I0EORg6u7xSlreXo9OvRd0BbF+UdOAjH7Pwvhv9xi BCMABRG0IkplYW4tbG91cCBHYWlsbHkgPGpsb3VwQGNob3J1cy5mcj6JAJUCBRAq p3Bp9MoAgY3nItkBAegyA/sEwCWN7IU1T0NVNkcOcqe+lCn8P42UfX1RUKqCfErq T51BAPnSIz0naWFQII8ZE41FQQ6iuKnbfKpmIi4VelzcjzsEwdw15cdnyV8O9FXQ 25ysMe1C6LkodMU20XMjH7744n0NG15PWbNcmwNOQ2119tw+u9rRuuC6PFWFvX0w VZkATQIqxyFfAAABAgDhOocrwWVLJVToItdrune/+sjCF1+GiiEXH1d8Gv8rB5fr pXeGoAtWFvmIpmHgPv21zgcR/2Pykc0/7S71JXEXAAURtDFUb20gSmVubmluZ3Mg PHRvbWpAZmlkb3N3LmZpZG9uZXQub3JnLCAxOjEyNS8xMTE+iQBVAgUQKw7lYq+0 ixu9+x8tAQE8EQH/ekB1naYVMjS32UNxfoWzLs8Scm2mAOhTNPTdaXrFgiaLoP9Q bxLt7gS6JlU28uRU3PrzxleFl9ZlBaaoyqRdzIkAVQIFECsO3ggN91aF3b4N1QEB w5UB/3qPWHWzh9ktog9168XSPLVyKSDz5RCKfRc1Cnf2+iUUrG+kh9IFIMrOB14r AMdhOJR105MmsAzlfaYdXkwjIr+JAFUCBRArDtXmThgGN4+JhjEBAXbbAf9U8Wpa el26ikgjnHGwstsfaTUk59Lmu9K4q+hxTS9BovZnVq+Bbkmbx6dRtFhh8qR6bkT+ hAE8BrJ4BB8ZBaU9iQBVAgUQKw5c7VQDRxQAIuUtAQHk4QH7BmaPxtehZJOyQYjV aRyCtMkXdcTBk7tS8FdGK310DMCqr61mZQrVli7RmzAq8pQSJ3GjhvbYum3TEnl2 8P79GIkAlQIFECsOzyWh9UOl6XLwEQEBYCwEAJzTGLfan9mbFzNx1yubrHIofOdT LSaxyPHKd8eiYgWheIOnTTWS0en6JOSWsGfp83lTBBH5USCIxOtf+WzK0SbydKhT xbHPouryo6d1Ycmgty4rKwluEQjuytT5mz0nrlHXgrRo15WeumFNC9oPoLq/Tiu1 StGfqk/gwvntHQQBiQBVAgUQKw7JTIxutC9MEx9XAQG/kgH7Bh1HrIvqVgAWn2n0 3fpqOZTZKKQ0yJyWAtwn0fOaO6Yb7ze83IlqnylArrYB4MK/sgY09M9k7py4lAqg Xu3wdIkAlQIFECsOvwqtUkpRhRl/tQEBZPYD/j/kPMH9agh0dBP7oKUuFgAAt5Qo Wlu7KO7YHeRyDzAbwIncksQkIy+ZKA+X8EYJVNXESesdBile0/guom4d78FWQwJK mhz4JsNlfIkaz8pKrClSrmvLUh4cLThM8O8139slsQXCHoK9xoiDwOzwu/wdeD7d L9OFdWXkEvHQmPk3iQCVAgUQKv2NMuo6/NNxlGvfAQGuLgP9FaHSxeXSFv2P92ku EBCBg5Vxi044apXRITH3qaGNYMTlZ4uVrGrP3ycl/yQEwr1SJsTPGGEmXC250586 Gd59ZwAE0YS6I3HywaO7I/T/2DoJ6aN6op9r9MjfmATr0qCtAOh3iwLWH0249Wou n2pSVqlV6u9uwKW7U43M9Wan/MqJAJUCBRAq0OE2bW04UnNLmlkBAZGsA/49Wsio wQ96ICa38r2CNbbFY5VBqvlfu/74L/wGohiPyaaYZ129BrT3y17kLU7K6cxMrRe0 XPuQi9wMmF8rOan6t0jpN8ZRG9qyaKtEUA/E9336UlwhDIiceJEMBEW5vXEY5D5D Wd1expfV/Q73e/P+SNdjRKgLwhRFjQ4WE8XWlokAlQIFECrLhGIYV+Tdsba4IwEB of4D/1LcLzjP0Ir80uXVNzPPaHEbpHgLjWnA89Hj0tfXA0Np95zVHKENQ9U/fuRz 5G27rHFmy+wCTX2zsrDBgTlKn4hGwOTz5CDfnjnB8NVQ19Xt9KF/tlbe1ljbJtmn cY/dPMfwkWlCPFHLXPWw3IiFlJo1hRvxrAM364ya3zNTVJsPmQCNAir9fucAAAEE AMXg/uYJqIqJ8pr9B6QTh7NOgqSMpwJK2v2QfZ4Ur4jeCiz1vJoXsxlOwsLEqRJZ wT+8/atljTbVWepJZbgqzCJK2J5c0+p32mjUSQVZvF9CU4gPbCehUgoToHmheGQ+ kkzimXLi39XzqoyT3ORZ07cQT+1DgEBDVa1SSlGFGX+1AAURtB1Kb2huIEdpbG1v cmUgPGdudUBjeWdudXMuY29tPokAVQIFECsO9LdUA0cUACLlLQEB+PEB/2+N0xYQ Sfqepii8vJYDtAevhzkQyupPuNmhPUGi8148Dx7IckqX3qv9ZyWKdFBuWQqYAJoG 7Gnd+wEn6SVkztOJAFUCBRArDuRKr7SLG737Hy0BAbOpAgCWUETOCKU9fmj4n1Y7 WbnbSMT6w2ua8eSGIy7olVdL7r+LG82ZTOh3PhYkdZXBobwumoMzzmlJzbu+lQh7 7L+biQBVAgUQKw7dvg33VoXdvg3VAQFyKAH+KCRi9cjMCVAldkdTNW+gbXXkk0r8 55hQ4ewrP5ELRqwyvYJZDIKoxFOC61LaDNg9Xzu18jNFGmRpsCMC/LX9eIkAVQIF ECsO1LpOGAY3j4mGMQEBdj8CAMI7zD5bBXZtZ7mzikXo4/c5E6J6Jgyjwm7+FjMe zWiEEg2QWWTsqeyBCRTqE9xcG6YGJiJd/sSf0lBWM1RU9IiJAJUCBRArDs4v6wCT 6wJFxDUBAXLbA/9uz6/Ek1MH0iB2bgHELKBYH8mL0v1/WtPp13XKjFkLRkUepcsJ FqQUN5n9EVw7PxLPMkaQMsgC2o+JrLuGqAIkQd73kucr3iKHfB25ErRx0dMLrpQF A13/5P16VJNXBTW3juNl6oMq5z7Up7jfTB+RJoeUV/92DF+Qi20itrvWs4kAVQIF ECsOyK+MbrQvTBMfVwEBlE0CAMM6o1rAcb2UntVueGoBjGRYUApxhdSZD1LbQV21 B/jzbYtEDQ/cbf/b3kMv/rgZWEJQyoVL62xnTd0TXr8xwr6JAJUCBRArDsUxofVD pely8BEBAWg6A/9h8kODUzDaASOq0fdz386YKnPjId7hik1Nol66tMS0J2PdRLJr VuNyuYDwbH9iREeovQ4mow6/es7zY+Nx8/c6yNXMHQlj/OKJNJ9KrPfENkLMzd8J zkqUFVnqdEHpmZYxrysz9y72br7KTLmzAnumCERSWCNI/G8+SBMh4q+kbokAVQIF ECsOvpfNP+0u9SVxFwEBs44B/3UqcFw085h9KPigF39nI9U7MxhwdzsbLEdRL0OW XP4TQt6azApOhfKUvFHTo7dAoP3aQPVKirfA+zNIFIFC7ASJAJUCBRAq/YCy6jr8 03GUa98BATuWA/9KG5CXCoDPpthcfsbA2eYIhi7GduqSkFi2//ibeH5HTqtEUrlk PGPQuxSmMuQSaUhAGQrYpVMSpTdcv3BWf2jAUgMgoXwHkCIBqOaG0Gwjijnm8+ho x6v+9zr5KvylqreCWTWdFuxP379+gFEsN8t+gXIH9GiXHjeul4jnD+HgNw== =MUTM -----END PGP PUBLIC KEY BLOCK----- From yanek at novavax.nova.edu Fri Nov 27 20:17:26 1992 From: yanek at novavax.nova.edu (Yanek Martinson) Date: Fri, 27 Nov 92 20:17:26 PST Subject: Questionable Discussions (re: How far is too far?) In-Reply-To: <3920.2B16E302@fidogate.FIDONET.ORG> Message-ID: <9211280417.AA08200@novavax.nova.edu> > U> myself getting a little uncomfortable with some of the > U> more anarchistic ideas expounded in this and similar > I agree, even though I'm interested in uses of encryption other than > privacy, implementation of privacy systems is a baseline to a lot of Yes. Once we have privacy, we can safely discuss all the other topics... -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From rchilder at us.oracle.com Fri Nov 27 20:28:30 1992 From: rchilder at us.oracle.com (Richard Childers) Date: Fri, 27 Nov 92 20:28:30 PST Subject: Electronic Banking Message-ID: <9211280427.AA21844@rchilder.us.oracle.com> "Using the net, the 'banker' could easily be 'offshore' and not subject to US law in these matters." Feds busted some folks doing just this with modems in Puerto Rico, I think it was, within the past year ... heard it on NPR, maybe it was BBC or CBC ... -- richard ===== -- richard childers rchilder at us.oracle.com 1 415 506 2411 oracle data center -- unix systems & network administration Klein flask for rent. Inquire within. From rchilder at us.oracle.com Fri Nov 27 20:42:26 1992 From: rchilder at us.oracle.com (Richard Childers) Date: Fri, 27 Nov 92 20:42:26 PST Subject: PGP on local machine (was Re: MacPGP) Message-ID: <9211280441.AA21906@rchilder.us.oracle.com> " ... some kind of hardware device which isolates the line and all that." I believe part of the MIDI specification includes explicit decoupling of each device from the network via optical coupling. ( Ref: _MIDI systems and control_, Francis Rumsey ... "The interface incorporates an opto-iso- -lator between the MIDI IN and the device's microprocessor system. This is to assure that there is no direct electrical link between devices ..." ) Anyhow, such a component is commercially - and easily - available. -- richard ===== -- richard childers rchilder at us.oracle.com 1 415 506 2411 oracle data center -- unix systems & network administration Klein flask for rent. Inquire within. From yanek at novavax.nova.edu Fri Nov 27 21:00:47 1992 From: yanek at novavax.nova.edu (Yanek Martinson) Date: Fri, 27 Nov 92 21:00:47 PST Subject: Alternative to physically meeting In-Reply-To: <9211280415.AA12997@toad.com> Message-ID: <9211280500.AA08808@novavax.nova.edu> > person identified in the name field". Don't sign someone's key unless > you are sure you can make that statement (like, they're standing in the > same room with you and they verify that they key ID matches their real key). > Don't sign a key that you received by email or over a modem; it might > be from someone impersonating your friend (when they left their keyboard Here's an alternative method if you know the person (know them well enough to recognize the voice on the phone): You transfer the key over a non-trusted channel such as electronic mail.. Then both of you run a secure hash function (for example MD5) on the key. The result (128bits in the case of MD5) is then converted to alphanumerics using something like base64. In the case of 128bit hash, you end up with 22 character verification code. Then you call each other up on the phone, and spell out the 22 letters and verify they match what you independently computed. If they do, that means the key transferred over e-mail is correct. This is of course susceptible to the kind of attack where someone stands with a gun pointed at you and makes you give the wrong key, but that attack can also be done if meeting in person. I.e. someone tells you they are going to kill you as soon as you step out of the room if you don't give the compromised key. But at least with this attack one of the persons knows they key is no good, and you will avoid using it for sensitive material. Can you think of any other attack that this method is susceptible to? -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From norm at xanadu.com Fri Nov 27 21:35:51 1992 From: norm at xanadu.com (Norm Hardy) Date: Fri, 27 Nov 92 21:35:51 PST Subject: PGP with license Message-ID: <9211280507.AA11162@xanadu.xanadu.com> This was originally addressed to Phillip Zimmermann. Thank you for writting PGP. I have not run it on my Mac yet because my version of Stuffit is 2.0 which deems the PGP.sit file to advanced. I resist the incentives of compression program authors to produce frequent incompatible updates which cost money and delay for little apparent advantage. Compact pro is a shareware program that produces self expanding archives which presume no pre installed decompressor. It is available by ftp at sumex-aim.stanford.edu info-mac.util.compact-pro-133.hqx You may forward this to whomever does the Mac version or send me his email address. What I really am writting you about is to suggest that if you wrote "another" program compatible with PGP under a PFP license that I would pay at least $50 for it. I might pay more depending on my experience with the free version. I would accept delivery by email. From rchilder at us.oracle.com Fri Nov 27 22:00:11 1992 From: rchilder at us.oracle.com (Richard Childers) Date: Fri, 27 Nov 92 22:00:11 PST Subject: Mac PGP report and Rander progress Message-ID: <9211280559.AA22444@rchilder.us.oracle.com> "Has anyone given any thought to generating random numbers by counting particle emissions from a radioactive source? This might be more reliably random than using purely electronic means." The Exploratorium has a display - a large set of charged plates by which one can see spark trails elicited by high-energy particles as they pass through the array - which has often intrigued me as a source of noise ... what is more unpredictable and harder to spoof than a cosmic ray detector ? Especially if you use not only the timing of the particle's arrival, but also its direction through the array of plates, as inputs to the random number generator ... Air pressure, temperature and other ambient factors in the environment could also be used as sources for unpredictable inputs ( measuring very small variations, IE, millions of a degree or some such ). -- richard ===== -- richard childers rchilder at us.oracle.com 1 415 506 2411 oracle data center -- unix systems & network administration Klein flask for rent. Inquire within. From crunch at netcom.com Fri Nov 27 22:48:18 1992 From: crunch at netcom.com (John Draper) Date: Fri, 27 Nov 92 22:48:18 PST Subject: Classified info and other stuff. Message-ID: <9211280644.AA24107@netcom2.netcom.com> George Gleasin says: >I'd like to ask we have a general agreement to not post things which may be >classified. No point giving the govt a good excuse to stop our R&D projects >cold. I absolutly agree...As an ex-air force person, they can get really nasty if they want.. Oh, By the way, numerious complaints have been said about the way that the Mac PGP was stuffed when posted onto "umich'. I will be pushing for releasing it stuffed with a self extracting archive instead. I also had problems and lost significant time acquiring the new stuffit in order to extract it. John D. From rchilder at us.oracle.com Sat Nov 28 00:27:13 1992 From: rchilder at us.oracle.com (Richard Childers) Date: Sat, 28 Nov 92 00:27:13 PST Subject: comments on Don's "Cypher Bank" Message-ID: <9211280826.AA22989@rchilder.us.oracle.com> > I will maintain a public list showing handles vs. Amount received, > in collection, and in escrow.(Set Subject = "BANK" to get the list) "You should not disclose someone's balance to anyone else, and certainly no[t] to the public. Someone requesting their balance should send the request by any communications channel (anonymous mail, newsgroup, anything) and sign it with the private key corresponding to the public key used when making the deposit. Then you should encrypt your reply (the account balance & any other info) using the public key, and send it back through any channel." Maybe both options should be supported. I can see how some people would like numbered accounts, a la Switzerland. However, it's not likely. It would be abused. If you want to oppose taxes, that's one thing, but it should not be confused with the electronic trans- -fer and maintenance of funds. It might be more likely to arrange for a compromise where numbered accounts are permitted iff account balances are publically available also. This might have interesting spinoffs, such as allowing a much wider range of interested individuals, access to economic data at the level usually reserved for banking institutions. We might - as many people have noted - learn much and contribute accordingly to both economic and cryptographic theory. Personally, I think things are much more likely to remain aboveboard if they are never placed out of sight in the first place except where it is strictly necessary - and that necessity clearly documented to all. -- richard ===== -- richard childers rchilder at us.oracle.com 1 415 506 2411 oracle data center -- unix systems & network administration Klein flask for rent. Inquire within. From rchilder at us.oracle.com Sat Nov 28 00:42:52 1992 From: rchilder at us.oracle.com (Richard Childers) Date: Sat, 28 Nov 92 00:42:52 PST Subject: ping..mailing list integrity.. Message-ID: <9211280841.AA23039@rchilder.us.oracle.com> "So if you posted a message, you could check in the evening if it got out or not. If you are not sure if you are receiving all the messages, you could maintain a simlar file yourself, and at the end of day compare your notes with what is received from the list." This could be spoofed by an intermediate delivery agent also ... Generally, in netnews, I regard mail back from individuals or test sites which honor posts to *.test newsgroups as adequate confirmation. These, too, could be spoofed, I suppose, but that's a degree of duplicity that is so complicated to maintain for an indefinite period of time that it is unlikely to ever be put into practice, IMHO, since it's bound to fail in the long term, and would probably result in a backlash of disfavor towards organizations practicing, supporting or funding such behavior. Perhaps an equivalent service could be implemented where some people's systems make a point of sending mail directly to posters to verify that their posting was posted. Bitnet's LISTSERV software does this, which is very convenient when one is managing a listserver entirely by email from a few thousand miles away. Other mail servers - Home Brew Digest comes to mind - do the same thing ... Grist for the collective mill. -- richard From rchilder at us.oracle.com Sat Nov 28 01:08:42 1992 From: rchilder at us.oracle.com (Richard Childers) Date: Sat, 28 Nov 92 01:08:42 PST Subject: verification of posting Message-ID: <9211280907.AA23308@rchilder.us.oracle.com> Below is a copy of the email I received as a consequence of posting to the Home Brew Digest. Of course, the HBD is a digest, not a mail list ... but it occurs to me, it is much harder to interfere with the operation of a Digest. The Digest comes out once a day, it has ( usually ) a table of contents at the top, and, if one received email telling where in the queue one's message was, one could verify it by reading the Digest when next issued forth. As well as discussing it with individuals separately via email, which provides a redundancy of sorts to this verification process. Eternal vigiliance and all that. Freedom is not a passive process !! -- richard > From homebrew-request at hpfcmi.fc.hp.com Fri Nov 27 18:31:24 1992 > Reply-To: homebrew-request at hpfcmi.fc.hp.com > Errors-To: homebrew-request at hpfcmi.fc.hp.com > Subject: Re: A clarificatioon on clarification > > > > (This message has been generated by a program, and is for your > information only. No further action is necessary.) > > Your article has been received for publication in the Homebrew > Digest. There are currently 2 article(s) ahead of yours in > the queue that will be published first. > > Thanks for your submission and your support of the Digest! > > > Rob (program author) > > > From tony at morgan.demon.co.uk Sat Nov 28 02:43:14 1992 From: tony at morgan.demon.co.uk (Tony Kidson) Date: Sat, 28 Nov 92 02:43:14 PST Subject: Electronic Banking Message-ID: <893@morgan.demon.co.uk> In message <9211280427.AA21844 at rchilder.us.oracle.com> you write: > > "Using the net, the 'banker' could easily be 'offshore' and not > subject to US law in these matters." > > Feds busted some folks doing just this with modems in Puerto Rico, > I think it was, within the past year ... heard it on NPR, maybe it > was BBC or CBC ... > > > -- richard The 'Feds' writ does not run everywhere. After all, Puerto Rico _is_ a US colony. Tony ------------------+-------------------------------+--------------------------+ | Tony Kidson |`morgan' is an 8MB 486/33 Cat-| Voice +44 81 466 5127 | | Morgan Towers, |Warmer with a 670 MB Hard Disk.| E-Mail | | Morgan Road, |It resides at Morgan Towers in| tony at morgan.demon.co.uk | | Bromley, |Beautiful Down Town Bromley. | tny at cix.compulink.co.uk | | England BR1 3QE | -=<*>=- | 100024.301 at compuserve.com| +=================+===============================+==========================+ From ah at dunaad.co.uk Sat Nov 28 03:26:42 1992 From: ah at dunaad.co.uk (Alan Hunter) Date: Sat, 28 Nov 92 03:26:42 PST Subject: How Far is Too Far Message-ID: <2b174c79.dunaad@dunaad.co.uk> Phil Karn said: I must concur with George Gleason's remarks about "sneaking around in the shadows of legality". I find myself getting a little uncomfortable with some of the more anarchistic ideas expounded in this and similar groups. [and lots of other sensible things] Just as good fences make good neighbors, we may well find that in the hands of the people, good cryptography will make for good government. That's why I find cryptography so interesting, and that's how we should sell it to the public. And as an authentication tool. There are many things that, while I would rather they were private, the authentication aspects are more important to me. Borrowing Money from the bank, any transaction. People cotton on very fast to authentication and digital signatures, they like the idea and buy into the need. Alan From mark at coombs.anu.edu.au Sat Nov 28 04:39:57 1992 From: mark at coombs.anu.edu.au (Mark) Date: Sat, 28 Nov 92 04:39:57 PST Subject: comments on Don's "Cypher Bank" Message-ID: <9211281239.AA00261@coombs.anu.edu.au> richard childers (rchilder at us.oracle.com) : >It might be more likely to arrange for a compromise where numbered accounts >are permitted iff account balances are publically available also. > >This might have interesting spinoffs, such as allowing a much wider range >of interested individuals, access to economic data at the level usually >reserved for banking institutions. We might - as many people have noted - >learn much and contribute accordingly to both economic and cryptographic >theory. It is said information should be free... however, if someone was (and someone undoubtedly would), to monitor the bank(s) they would probably see accounts going up and down by various amounts and it should be possible to track transactions between identities. This, coupled with widespread traffic analysis (assuming no padding had occured) would allow someone to deduce that Alice had asked something of Bob and had then paid him. This probably isnt particularly inviting to the majority to know that your funds could be traced very anonymously and that patterns could be formulated... for instance three times a month various amounts are deducted from your account and those exact same amounts appear in an account known to be owned by a 1-900 phone sex number. That would have an affect on your reputation, (if not your marriage if your True Name was known), if it was published. (The 1-900's identity could be discovered simply by someone using the service and noting what psuedonym took your funds, or if that was changed, noting which account increased by your $127.30. (It was an intense call I guess :) If you wish to entertain such a testbed financial system be very careful with any decision made and work through each possible consequence. Most people I think would prefer to remain anonymous. I know I would, in the long run. Mark mark at coombs.anu.edu.au From yanek at novavax.nova.edu Sat Nov 28 06:30:11 1992 From: yanek at novavax.nova.edu (Yanek Martinson) Date: Sat, 28 Nov 92 06:30:11 PST Subject: verification of posting In-Reply-To: <9211280907.AA23308@rchilder.us.oracle.com> Message-ID: <9211281429.AA17081@novavax.nova.edu> > Of course, the HBD is a digest, not a mail list ... but it occurs to me, Digests also introduce a time-delay. You can have almost-realtime discussions with an immediate reflector. It is possible to have both. On many mailing lists (such as future-culture for example) you can "subscribe realtime" or "subscribe digest". > comes out once a day, it has ( usually ) a table of contents at the top, I suggest that even if we don't have a digest, we could still have a "table of contents" at the end of the day. > and, if one received email telling where in the queue one's message was, You would not need a receipt message, you would just check to see if you message appeared in the index. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From yanek at novavax.nova.edu Sat Nov 28 06:33:06 1992 From: yanek at novavax.nova.edu (Yanek Martinson) Date: Sat, 28 Nov 92 06:33:06 PST Subject: ping..mailing list integrity.. In-Reply-To: <9211280841.AA23039@rchilder.us.oracle.com> Message-ID: <9211281432.AA17580@novavax.nova.edu> > "So if you posted a message, you could check in the evening if it got > out or not. If you are not sure if you are receiving all the messages, > you could maintain a simlar file yourself, and at the end of day compare > your notes with what is received from the list." > > This could be spoofed by an intermediate delivery agent also ... Not if the evening "verification index" was signed with the list maintainer's private key. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From yanek at novavax.nova.edu Sat Nov 28 07:44:49 1992 From: yanek at novavax.nova.edu (Yanek Martinson) Date: Sat, 28 Nov 92 07:44:49 PST Subject: FutureCulture FAQ Message-ID: <9211281544.AA19245@novavax.nova.edu> Does anyone have a copy? Nyx seems to be down for the last couple of days so I can't get it. Don't send it to me, I don't want to have 150 copies of this fairly large document pile up in my mailbox overnight, just let me know if you have it, and I will request ONE of you to send it. Thanks. Yanek, yanek at novavax.nova.edu From yanek at novavax.nova.edu Sat Nov 28 07:53:25 1992 From: yanek at novavax.nova.edu (Yanek Martinson) Date: Sat, 28 Nov 92 07:53:25 PST Subject: Detailed Scenario of Dongle Usage Message-ID: <9211281553.AA19458@novavax.nova.edu> So, you walk up to ANY terminal directly connected to a host, or to a terminal server, or a personal computer of any kind connected through a modem, or borrow someone's laptop connected to a cellular modem. You connect your dongle in between the terminal/computer and the communications line, and punch in your secret code on the keypad (which, like phones, also has letters so you can remember fairly long ID-s). Call up, or telnet, dial up a bbs, or connect through any other means, to your host, and log in. Run your favorite mail reader, let's say _elm_. Start reading your mail as you usually would. Any time an encrypted message is displayed whose public key ID matches one of the private keys on your keyring, the dongle temporarily buffers the message it into its RAM, flashes the "decrypt" LED, while decrypting the message. Then you can view the plaintext using a simple, terminal-independent pager that lets you go forward/back one page, and search for a key word. When you are done, you press Q, and the plaintext is immediately deleted from the memory. Note that during all this, the plaintext did not appear anywhere on the host or any of the communication links connecting you to it. Let's say you want to reply to a message. Press 'r' or whatever key is used to reply in your particular mail reader. Or if you want to send a message, press 'm' and fill in the address. Then, if your editor is something like vi or ed that requires you to do something before you can input text (like press 'a') then do that. If you use an editor like EMACS or SMiLE or jove or cat or anything that lets you just type in text, you skip this step. Now, press the "encrypt" button on the dongle. It presents you with a simple line editor, that works with any terminal or terminal emulation, but is reasonably easy to use (something like most bbs-es use for composing messages). You type your message, or if it was prepared ahead of time on the local equipment, you transmit the text. NOTE: this is the simpler of the several different approaches to plaintext handling that I am considering. When you are done, you pick the public key to encrypt it with (or it can be automatically determined based on the address you typed in to your mail program previously). If you have lots of public keys, you could use a search to quickly find the one you want. Then you have the option of signing the message with any one of the private keys that you have. Finally, the dongle transmits the cyphertext to the host, and you type the _exit_ key sequence for the editor (:wq, or C-x C-c, or /done, etc). The message is sent by the mailer software on the host. Then you may want to scan a newsgroup like alt.w.a.s.t.e for any mail that may be for you. Put your dongle into "WASTE SCAN" mode (for example by pressing *WS on the keypad) and tell your newsreader something like "display all new messages". The dongle will detect a message whose key-id matches one of the keys on your key-ring decrypts and displays it, while ignoring all the other messages that are not for you. You must retrieve all the messages, so that anyone monitoring your activity has no way of knowing which one, if any, was actually addressed to you. Then you receive a "talk" request (or a chat call on a bbs, or you may be on irc or a MUD with "chat mode") from someone you know has a similar device (or software that emulates it). If you both know each other's public keys, the two devices both generate a random session key and encrypt it with the others' public key. If not, a key-exchange protocol may be used to generate a key both of you know, but that can not be later recovered by someone recording the data. Now the dongles encrypt any text (one line at at time) that you type, and decrypt anything received. Many other applications for a portable, trusted crypto engine could be thought of, given time. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From nathanf at cup.portal.com Sat Nov 28 08:54:40 1992 From: nathanf at cup.portal.com (nathanf at cup.portal.com) Date: Sat, 28 Nov 92 08:54:40 PST Subject: unsubscribe nathanf@cup.portal.com Message-ID: <9211280725.1.15557@cup.portal.com> unsubscribe nathanf at cup.portal.com From 74076.1041 at CompuServe.COM Sat Nov 28 10:23:07 1992 From: 74076.1041 at CompuServe.COM (Hal) Date: Sat, 28 Nov 92 10:23:07 PST Subject: Misc. Items Message-ID: <921128181712_74076.1041_DHJ61-1@CompuServe.COM> A few random points related to messages from the last few days. (First, a "meta" point - whenever I post to this list, I get from 3 to about 10 messages over 2 or 3 days reporting on delivery errors. It would be nicer if these went to someone else. Some of the messages include as many as 20 or 30 names of list subscribers who were apparently included in the same "outgoing batch" as the bounced mail.) On PGP key verification: I understand that Branko hopes to get version 2.1 of PGP out in a week or so. One of the new features will be a mode to display a MD5 hash of each PGP key to facilitate read-aloud over the telephone. This should make it easier to phone-verify PGP keys, so we can have more _good_ sigs. On pseudonyms and reputations: Several people have suggested that it would be easy to conjure up dozens of fake personalities who would then vouch for each other, giving the illusion of a well-founded and trusted pseudonym. This would be ideal for con men and cops. This can be defeated by the use of the is-a-person credential, which Chaum describes in a couple of his papers, including CACM Oct 1985. This is a signed document given by an organization which makes you come in and give your thumbprint. The document is "re-blinded" a la Chaums' proposals for electronic cash, so that there can be no linkage between your is-a-person document and your actual thumbprint. However, the thumbprint makes it so you can't get more than one is-a-person document. Now, when you go to apply for credit, and you say, here are signatures from dozens of people that I've done business with in the past, and I've paid them all off on time, the first thing the creditor is going to ask is, who are all these people? Are they legit? Can you at least show me is-a-person creds on them? You won't be able to. You only have one is-a-person credential, and you can't make more. Again, these credentials do _not_ hurt crypto anonymity. There is no linkage between your credential and anything else about you. On electronic banking: The interesting thing about electronic banking is digital cash. The key feature of digital cash is anonymity of payments. There is nothing subversive about this. Ordinary cash has (nearly) this property. Are you being subversive when you buy a newspaper without paying by check or credit card? Of course not. The point is, we want to use digital payments so that we can transact business over the net. But the more things get computerized, the more possible forms of monitoring there are, by businesses as well as gov- ernments. There's nothing immoral in trying to keep VISA from knowing whom I like to do business with. Digital cash is designed to allow the convenience of electronic shopping, while keeping the privacy of ordinary cash payments. Conceptually, it's a simple idea. Technically, what has to be done to turn an electronic banking proposal such as Don Bellenger's into electronic cash is some way to make it so that withdrawals can't be paired up with deposits. You also need, of course, to prevent cheating such as spending the same piece of cash twice. It's not trivial to meet these requirements. The Chaum proposal I described is the simplest one that I know of that achieves this. On remailers: I haven't yet succeeded in doing a doubly-encrypted remailer test using Bill O'Hanlon's and mine. Once this works, I'll post instructions on how to do this, and possibly a script or two to make it easier. With two encrypted anonymous remailers, you can for the first time send anonymous messages such that no one person can know whom you are sending to. Bill and I would have to collude to find out who sent a particular anonymous message. If more such remailers can start operating, such collusion will become that much more difficult. On John Draper: I just wanted to say publically that the famous "Captain Crunch" was an inspiration to me when I was in college in the 1970's. Although I did not become a "phone phreak" or "cracker" he represented to me the spirit of questioning authority and exploring beyond the accepted bounds of the system. I have followed his career to some extent over the years and I think he has more than paid for any sins he may have committed in his youth. I for one am thrilled to have the idol of my younger days on the list. Hal 74076.1041 at compuserve.com From hughes at soda.berkeley.edu Sat Nov 28 10:53:31 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Sat, 28 Nov 92 10:53:31 PST Subject: bounced mail Message-ID: <9211281853.AA06156@soda.berkeley.edu> We've made a small change to the way mail gets sent out to the list which should alleviate the bounced message problem. The change went into effect last night. It should take care of most, but perhaps not all, of the problems. So, take heart. Starting in a few days, please _do_ forward bounce reports to cypherpunks-request at toad.com. At that point I'll want them for further debugging. Eric with the list maintainer hat on From norm at xanadu.com Sat Nov 28 11:50:46 1992 From: norm at xanadu.com (Norm Hardy) Date: Sat, 28 Nov 92 11:50:46 PST Subject: John Gilmore & NSA Message-ID: <9211281912.AA12654@xanadu.xanadu.com> This Saturday's NewYork Times has a nice article on page 7 regarding NSA's declassification of some of the Friedmann works under legal pressure from John Gilmore. From yanek at novavax.nova.edu Sat Nov 28 12:00:51 1992 From: yanek at novavax.nova.edu (Yanek Martinson) Date: Sat, 28 Nov 92 12:00:51 PST Subject: CFP93 information (fwd) Message-ID: <9211282000.AA25462@novavax.nova.edu> The following message was posted to Extropians by Fred Moulton. Forwarded message: > Message-Id: <9211281835.AA05819 at geech.gnu.ai.mit.edu> > To: Extropians at gnu.ai.mit.edu > Date: Sat, 28 Nov 92 10:31:56 -0800 > From: moulton at netcom.com (Fred C. Moulton) > Subject: CFP93 information > > > Attached is some information on CFP93 which might be of interest to some > persons on this list. > > Fred > > > > CFP'93 > The Third Conference on Computers, Freedom and Privacy > Sponsored by ACM SIGCOMM, SIGCAS & SIGSAC > 9 - 12 March 1993 > San Francisco Airport Marriott Hotel, Burlingame, CA > > > SCOPE > > The advance of computer and telecommunications technologies holds > great promise for individuals and society. From convenience for > consumers and efficiency in commerce to improved public health and > safety and increased participation in democratic institutions, > these technologies can fundamentally transform our lives. > > At the same time these technologies pose threats to the ideals of > a free and open society. Personal privacy is increasingly at risk > from invasion by high-tech surveillance and eavesdropping. The > myriad databases containing personal information maintained in the > public and private sectors expose private life to constant scrutiny. > > Technological advances also enable new forms of illegal activity, > posing new problems for legal and law enforcement officials and > challenging the very definitions of crime and civil liberties. But > technologies used to combat these crimes can threaten the > traditional barriers between the individual and the state. > > Even such fundamental notions as speech, assembly and property are > being transformed by these technologies, throwing into question > the basic Constitutional protections that have guarded them. > Similarly, information knows no borders; as the scope of economies > becomes global and as networked communities transcend > international boundaries, ways must be found to reconcile > competing political, social and economic interests in the digital > domain. > > The Third Conference on Computers, Freedom and Privacy will > assemble experts, advocates and interested people from a broad > spectrum of disciplines and backgrounds in a balanced public forum > to address the impact of computer and telecommunications > technologies on freedom and privacy in society. Participants will > include people from the fields of computer science, law, business, > research, information, library science, health, public policy, > government, law enforcement, public advocacy and many others. > > Topics covered in previous CFP conferences include: > > Personal Information and Privacy > International Perspectives and Impacts > Law Enforcement and Civil Liberties > Ethics, Morality and Criminality > Electronic Speech, Press and Assembly > Who Logs On (Computer & Telecom Networks) > Free Speech and the Public Telephone Network > Access to Government Information > Computer-based Surveillance of Individuals > Computers in the Workplace > Who Holds the Keys? (Cryptography) > Who's in Your Genes? (Genetic Information) > Ethics and Education > Public Policy for the 21st Century > > INFORMATION > > For more information on the CFP'93 program and advance > registration, as it becomes available, write to: > > CFP'93 Information > 2210 Sixth Street > Berkeley, CA 94710 > > or send email to: cfp93 at well.sf.ca.us with the word > "Information" in the subject line. > > THE ORGANIZERS > > General Chair > ------------- > Bruce R. Koball > CFP'93 > 2210 Sixth Street > Berkeley, CA 94710 > 510-845-1350 (voice) > 510-845-3946 (fax) > bkoball at well.sf.ca.us > > Steering Committee > ------------------ > John Baker Mitch Ratcliffe > Equifax MacWeek Magazine > > Mary J. Culnan David D. Redell > Georgetown University DEC Systems Research > Center > Dorothy Denning > Georgetown University Marc Rotenberg > Computer Professionals > Les Earnest for Social Responsibility > GeoGroup, Inc. > C. James Schmidt > Mike Godwin San Jose State University > Electronic Frontier Foundation > Barbara Simons > Mark Graham IBM > Pandora Systems > Lee Tien > Lance J. Hoffman Attorney > George Washington University > George Trubow > Donald G. Ingraham John Marshall Law School > Office of the District Attorney, > Alameda County, CA Willis Ware > Rand Corp. > Simona Nass > Student - Cardozo Law School Jim Warren > MicroTimes > Peter G. Neumann & Autodesk, Inc. > SRI International > > Affiliations are listed for identification only. > > > -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From pozar at kumr.lns.com Sat Nov 28 12:42:31 1992 From: pozar at kumr.lns.com (Tim Pozar) Date: Sat, 28 Nov 92 12:42:31 PST Subject: John Gilmore & NSA In-Reply-To: <9211281912.AA12654@xanadu.xanadu.com> Message-ID: Norm Hardy wrote: > This Saturday's NewYork Times has a nice article on page 7 > regarding NSA's declassification of some of the Friedmann works > under legal pressure from John Gilmore. Nice picture too! Tim -- Internet: pozar at kumr.lns.com FidoNet: Tim Pozar @ 1:125/555 UUCP: ...!uunet!kumr.lns.com!pozar Snail: Tim Pozar / KKSF / 77 Maiden Lane / San Francisco CA 94108 / USA Voice: +1 415 788 2022 From tcmay at netcom.com Sat Nov 28 12:45:07 1992 From: tcmay at netcom.com (Timothy C. May) Date: Sat, 28 Nov 92 12:45:07 PST Subject: Paranoia and Cypherpunks Message-ID: <9211282040.AA02902@netcom.netcom.com> PARANOIA, THIS LIST, AND APPROPRIATE TOPICS It is inevitable that a group such as ours should have varying opinions about the nature of the group, its role in society, its approach to outsiders and journalists, and its basic attitude. Recently, several people have expressed concern that the proper message is not being conveyed, even that a subversive and seditious message is often presented on this list. Some have cited discussion of military cipher systems as being too dangerous for us to discuss, while others have expressed some discomfort at the "anarchist" flavor of some postings. Well, folks, we all have different axes to grind. Since this is an open, unmoderated list, little control of content can be expected. * Some want "cryptography" downplayed, to be replaced with "privacy" as an emphasis. Privacy is seen as more palatable to Americans, less likely to upset them into cracking down on crypto methods. In other words, privacy is an easier "sell" than secrecy. Perhaps, but why dilute our focus just to make a more digestable pill for the masses of America, who typically don't think much about abstractions anyway? Those who want to sell "privacy" are free to. (BTW, the die was mostly cast when the name "Cypherpunks" was adopted. That's already raised red flags, just by the name! If we want to downplay this "crypto-cyber-punks outlaw" image, then a name change to something more like the "Electronic Frontier Foundation" or the CPSR, nice, safe-sounding names.) * Others have expressed some concern that some minor details of how U.S. cipher machines send out padded traffic were mentioned on this list--the fear being that discussion of military matters will invite the scrutiny of the government. Well, check out sci.military some time and see the debate on such issues! Also, many details of the KG-36, KWR-37, and Autodin cipher systems--just to cite the specific military cipher machines that the posting on this list was probably referring to--have already been published, and the Walker spy ring delivered the complete specs to these and other machines in the early 1980s. It's typically only the public who lacks knowledge on these matters. The Soviets (May They Rest in Pieces) usually got the salient details fairly quickly. Since ours is a crypto education group--amongst other things--what's wrong with discussing any of the gadgets and techniques that numerous books and other postings have already dealt with? (Surely John Gilmore's lawsuit to get some critical crypto papers declassified has already "angered" the folks at NSA. Are we to censure John for stirring up trouble? Of course not. We're free individuals, able to say what we wish, meet in secret meetings without the permission of the government, and learn anything we wish to. This, at least, is the theory. Until told otherwise, I intend to act on this theory.) * Some have argued persuasively for concentrating efforts on the more palatable (to the public at large) aspects of crypto techniques, such as authentication to reduce forgeries, privacy protection against illegal eavesdroppers, and so on. This is the "selling our vision to the public" point of view. Fine, it is good for some folks to do this, to concentrate on the areas that are unlikely to upset Middle America. But some of us--and you've seen my postings--believe the _selling_ of these ideas of authentication and privacy is a lost cause, or at least is not our main interest (e.g, it's not _my_ interest). * I favor technological solutions over political solutions. Don't call it sedition, call it the natural trend of new technologies. The printing press broke the power of medieval guilds in ways a political approach could never have done. Same with steam engines, electric motors, incandescent light, copying machines, computers, modems...well, you get the point. The things we talk about on this list, the things being developed and deployed, will have revolutionary effects. I've written about these effects over the past several years, and this wonderful list is pursuing them all with gusto! The anonymous remailers alone will set off alarms throughout the law enforcement community--you're kidding yourself if you think otherwise. Are we to stop working on anonymous remailers? What about digital cash? Face it, what we're doing will have major implications. To not talk about these effects, to not speculate on the possible consequences, is to bury our heads in the sand for fear that someone reading this list will order this list shut down or have us arrested! Yes, it's true some journalists are reading this list. Yes, it's fairly likely someone is forwarding this list to various agencies (this isn't paranoia...they'd be fools to not know about this list by now, given the publicity, the reputations of some of us, etc.). I know that some of the recipients of the list are gatewaying to other systems, or are forwarding specific articles to much wider audiences (I know this partly from e-mail I get). But these are all consequences of having a public list. Anyone uncomfortable with the free discussion of ideas and technologies on this list, anyone who fears personal or professional liability for views expressed by _others_ on this list, should probably unsubscribe from the list. I certainly don't intend to stop writing about the areas that interest me. Cheers. --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at 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^756839 | PGP Public Key: by arrangement. From yanek at novavax.nova.edu Sat Nov 28 13:24:30 1992 From: yanek at novavax.nova.edu (Yanek Martinson) Date: Sat, 28 Nov 92 13:24:30 PST Subject: Crypto Dongle... In-Reply-To: <921128171942_74076.1041_DHJ49-2@CompuServe.COM> Message-ID: <9211282124.AA27769@novavax.nova.edu> > Yanek - I do think your dongle idea is promising, but there are a > couple of other problems I haven't seen you mention. The concept is by no means complete. I will continue to add improvements as people suggest them. > One problem with this is that the terminal programs I use tend not to > just blast the whole mail message out in literal form, especially > since it is likely to be longer than one screenful. Instead, it > pauses after each screen, prompting with something like "type space > for next page", It would be transparent the other way, so that you would press space or 'n' or 'return' or anything you want. > or such. Also, it may insert VT100 control sequences as it goes from > page to page in order to clear the screen, etc. It should not be too difficult to ignore any codes that are not part of the data stream. If the message is coded with something like uuencode or base64 then the uniform-length lines of data should be clearly disinguishable from any other text such as "Press N for next screen" or an escape sequence. Also, overlapping display (some pagers show you a couple of lines from the previous screenful) could be dealt with by detecting duplicate lines. >> When you are done, you press Q, and the plaintext is immediately >> deleted from the memory. > Well, I'd think you'd want the option of saving the plaintext to a > file on your PC, not always deleting it from memory. By memory I meant the RAM in the dongle. If you wanted to save it, you could have just used to "logifile" function of your communication software. > What if you wanted to do what I'm doing here, which is to quote the > message you are replying to? I have not thought about that. Right away I see several possibilities: one, if the message you are replying to is the one you just decrypted, it could have been stored in the buffer, and you can delete the irrelevant lines, and insert your comments. The other would be that as you read a message, you could write and encrypt your reply. In that case it would also be simple to automatically use the public key that was used to verify the signature. I am sure there are other ways. There is essentially no limit on possibilities once you have a CPU. I will think about it some more. Thanks for bringing this up. >> simple line editor, that works with any terminal or terminal > I think this is OK, although I'm not sure how happy I'd be with > your line editor, not being accustomed to using BBS's. You could probably download an editor of your choice into it. There could be several editors available. Maybe even a simple screen editor that recognizes several most common terminals like vt100 and ansi. > like I can always compose on my PC, so that's OK. If your comm software supperted such a feature, the dongle could transmit a magic sequence which would make the pc to automatically go into an editor and then transmit the text. I would imagine eventually the most popular communication programs would have this feature. Some might already. The point is that if you happen to be using a dumb terminal or some machine or software WITHOUT this capability you could still receive and send secure messages. >> Then you may want to scan a newsgroup like alt.w.a.s.t.e for any mail >> message whose key-id matches one of the keys on your key-ring, >> decrypts and displays it, while ignoring all the other messages > You might have a buffering problem here. A decryption takes 30 > seconds They would not be decrypted "on-the-fly". Each Subject: line would contain the MD5 hash of the public key. It would take a fraction of a second to determine if that hash matches one of your keys for which the hash values would be precomputed and stored. Then the message would be captured. Later, when the scan is complete, it would be decrypted and displayed. > reasons; first, you don't know what flow control the host uses (if > any), and second, it would expose the fact that you had found a > message you wanted to decrypt). That is true. It should not be a problem though, if there are not too many messages for you. I plan for the device to have 256k of ram, so it could hold a few messages. The ram could be expanded if necessary. > You can't really anticipate how big the buffer might need to be, > especially if this method of anonymous communication became popular. > As I said in a previous post, you could easily have thousands of > messages to sort through, with perhaps dozens for you. I envision that this method would only be used for short and important messages, mostly of the form: "Contact me by sending mail to xyzzy at anon-r-us.com, key: dfgSDFgds34DF" So they would be short, easy to buffer, quick to decrypt and hopefully not too many of them. If there WAS too many messages, more than you were able to buffer, then it would just ignore the rest, process the ones it did get, and then you would request a second scan during which the first ones (that have already been processed) would be ignored, and the rest would be received. The problem with this is that the host would know that if you scan twice you have a lot of messages. They dont know which ones though. Or maybe you just had a transmission error... > solution than just encouraging people to buy laptops and use them? Most people that use e-mail already have a computer, They may not want to buy another one. They may use the computer or terminal on their desk for other things too, and would not want the inconvenience of having to use a separate screen/keyboard anytime they receive or want to send a private message. Laptop will cost more. Why buy a screen, keyboard, disk drive if you already have it. Hopefully my device will be cheap. It should be cheaper than any laptop. All I have is two serial ports, a cpu, some RAM and support cirquitry. I don't have a full-fledged keyboard, display, disk (or card) drive, and all the other stuff that goes in a laptop. Laptops are bigger. Or if they are small, they have lousy screens/keyboards. I hope to make my device smaller than even the so-called "palmtops". It would be easier to carry with you, in your pocket. It would be easier to hide if necessary. You can't make a laptop. You cant easily open it up, or if you can, it is complex enough that you can not completely understand its design. You can make a dongle from a kit, testing each part before you assemble it. You could make one from scratch. You can design one if you don't trust the schematics. Or you could show it to a competent electronics engineer and he could tell you if it does what it says it will. A laptop is not designed with security in mind. If you find that someone has just learned your secret code (that you used to encrypt your private key) and are going to seize your laptop in 15 seconds, you can't immediately destroy the key (you need to turn it on, boot or resume, exit from whatever program you were running or create a new window, CD to the directory where you store your private key, delete the file, run some program that makes sure the sectors are cleared.) And you still can't be sure that the key is not stored in some buffer or disk or cpu cache or a temporary file. Compare this with punching in a short "DESTRUCT" sequence on the keypad; if you have the device in your pocket, you can even do it without taking it out of your pocket, if you know the keypad well; And be absolutely sure that all information is completely gone. > Despite my negative comments here, I think there is room for plenty > of different approaches to making crypto easier to use. Absolutely. I am not saying that a hardware device designed specifically for cryptography is the ONLY way to go, what I do believe is that it is just a very good way to make easy access to cryptography widespread. A person that does not even know enough to be able to download, uncompress and install a software package could get one of these devices and make use of it. And there is no limit as to what a knowledgeable person could do with such a device. >If the dongle really could be made available at the price level you >mentioned, there might be some interest ... and if there was one for >$200 or less that would definately be interesting to me. Right now I hope to make it available for about $100. I don't know if I can yet, but will find out soon. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From tribble at xanadu.com Sat Nov 28 13:48:31 1992 From: tribble at xanadu.com (E. Dean Tribble) Date: Sat, 28 Nov 92 13:48:31 PST Subject: PGP on a multiuser system In-Reply-To: <9211261554.AA26688@novavax.nova.edu> Message-ID: <9211282123.AA12941@xanadu.xanadu.com> You get the picture. There is no security on a multiuser system. It is possible to get security on a multiuser system (there are at least B3 rated systems out there), you just can't currently get them with Windows or Mac interfaces :-) dean From yanek at novavax.nova.edu Sat Nov 28 14:00:11 1992 From: yanek at novavax.nova.edu (Yanek Martinson) Date: Sat, 28 Nov 92 14:00:11 PST Subject: security on a multiuser system In-Reply-To: <9211282123.AA12941@xanadu.xanadu.com> Message-ID: <9211282159.AA28597@novavax.nova.edu> > You get the picture. There is no security on a multiuser system. > > It is possible to get security on a multiuser system (there are at > least B3 rated systems out there), That is fine as long as you trust all the entities that designed, built, (modified :-), programmed, installed, and administer the system. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From tribble at xanadu.com Sat Nov 28 14:20:26 1992 From: tribble at xanadu.com (E. Dean Tribble) Date: Sat, 28 Nov 92 14:20:26 PST Subject: reputation In-Reply-To: <9211261521.AA26207@novavax.nova.edu> Message-ID: <9211282205.AA13176@xanadu.xanadu.com> What's to stop you (once you have some "reputation") from creating 250 other pseudonyms or "identitites", giving them all a "reputation", and then create another identity, and have these 250 all give this one as much as possible, in effect creating an identity with a lot of "credibility" out of thin air? Even in the simple system I described, there's probably sufficient feedback to discourage that. If the identity you went to so much trouble to promote turns out to be a bozo, then the original identity loses credibility as a source of recommendation. Further, the positive recommendations aren't just for filtering, they're also for sorting. By spreading the credibility of the first identity out over 250 others, those 250 identities just don't carry much weight when my mailer is ordering messages for me to read. If reputation is a conserved capital, for instance, they together carry only as much weight as the first identity that recommended them. dean From tribble at xanadu.com Sat Nov 28 14:48:26 1992 From: tribble at xanadu.com (E. Dean Tribble) Date: Sat, 28 Nov 92 14:48:26 PST Subject: security on a multiuser system > You get the picture. There is no security on a multiuser system. > > It is possible to get security on a multiuser system (there are at > least B3 rated systems out there), In-Reply-To: <9211282159.AA28597@novavax.nova.edu> Message-ID: <9211282230.AA13299@xanadu.xanadu.com> That is fine as long as you trust all the entities that designed, built, (modified :-), programmed, installed, and administer the system. You can inspect the design, the code, the installation, and probablyu even the administration of the system. That would typically be economically infeasible, however, so to reduce your expense, you'll have to trust someone (preferably someone who stands to lose a lot if they defect). dean From tribble at xanadu.com Sat Nov 28 14:48:27 1992 From: tribble at xanadu.com (E. Dean Tribble) Date: Sat, 28 Nov 92 14:48:27 PST Subject: credibility & pseudonyms With digital signatures a dozen secretaries could run a hundred or more pseudoagents, build a solid reputation for each over years. In-Reply-To: <9211270916.AA25959@godzilla.informix.com> Message-ID: <9211282227.AA13290@xanadu.xanadu.com> The same approach would work for a patient con man. Real credibility has to be tied to a physical body. Some thing at risk. Real credibility has to be tied to assets. The credibility is equivalent to the amount of assets at risk. In a positive reputation system, the asset is reputation capital, it is the respect granted by others. It embodied in the settings of their sorters that order your messages before those of other people. In the farther-out world of nanotech with duplicate bodies and backups, having a body at risk is worthless because bodies would be cheap :-) If the operators of an escrow service are anonymous, then either their accessible assets had better be enough that you can recover losses if they walk with your goods, or their opportunity cost of defecting on their clients had better be high enough (in terms of lost revenue, lost opportunity on outstanding customer goodwill, name recognition, channels, etc.) that they are sufficiently unlikely to that you will take the risk. Scary prospect, and one which many people will estimate wrongly, so the simplest strategy would be to only use escrow companies with an accessible person responsible for them. dean From hh at soda.berkeley.edu Sat Nov 28 17:59:17 1992 From: hh at soda.berkeley.edu (Eric Hollander) Date: Sat, 28 Nov 92 17:59:17 PST Subject: Electronic Banking In-Reply-To: <199211261116.AA24529@well.sf.ca.us> Message-ID: <9211290158.AA22750@soda.berkeley.edu> I think we should set up a digital money system, and just take the legal risks. I volunteer. On a related note, I noticed an article on electronic money in a recent issue of _the_Futurist_. It kept on coming back to the big advantage of cryptomoney: it is completely traceable. The main point was that cryptomoney would eliminate black marketeering (including the drug trade). The author said it would be wonderful for the federal government to run this new system, for several reasons. First, it would allow them to monitor all activity, so there could be no tax evasion or black marketeering. Second, we would all be safe knowing that the government kept the information confidential, so it couldn't be used imporoperly. This was a scary article. e From hh at soda.berkeley.edu Sat Nov 28 18:25:32 1992 From: hh at soda.berkeley.edu (Eric Hollander) Date: Sat, 28 Nov 92 18:25:32 PST Subject: comments on Don's "Cypher Bank" In-Reply-To: <9211271825.AA25349@novavax.nova.edu> Message-ID: <9211290225.AA24130@soda.berkeley.edu> >If only the hash value is mailed, then the full key can be e-mailed >or anonymously posted to a newsgroup that you montitor. If the full key >is mailed, you should invest in a scanner and some simple OCR software. I have been thinking about this. I think that pgp should have a postscript output module, so you can print your public key on the back of business cards and hand them out to people you meet. Or businesses could put it on thier flyers. Or many other uses for times when you don't want to have to have your computer there to exchange keys and you don't want to exchange disks because they're expensive and big and have lots of different incompatible formats (and some people, like me for instance, don't have any disk drives). I think the best font for this would be a font like OCRA, the font used at the bottom of checks. This font allows for very reliable scanning. Does anyone know where I can get a postscript version of this font? If someone can find it, I'll write a program that outputs a public key in that font in the right size for a business card. e From rchilder at us.oracle.com Sat Nov 28 20:01:51 1992 From: rchilder at us.oracle.com (Richard Childers) Date: Sat, 28 Nov 92 20:01:51 PST Subject: credibility and banking Message-ID: <9211290400.AA00660@rchilder.us.oracle.com> "If the operators of an escrow service are anonymous, then either their accessible assets had better be enough that you can recover losses if they walk with your goods, or their opportunity cost of defecting on their clients had better be high enough (in terms of lost revenue, lost opportunity on outstanding customer goodwill, name recognition, channels, etc.) that they are sufficiently unlikely to that you will take the risk." It seems to me that there are many parallels between this state of affairs and that which prevailed in the American West of the 1800s, with respect to banking .... there were no agencies insuring deposits, and only the rep- -utation of the bank's president - usually a leader of the community - was guarantee upon the funds. Bank robberies were not uncommon, depositors were few, runs on the bank, I speculate, may not have been unknown in those cir- -cumstances where the community of bank depositors lost confidence in the bank or its officers. Another parallel which occurs to me is that of the computerized trading that occurred when programs controlled trading in, um, was it October of 1987 that the stock market shuddered ? 1989 ? ... it suggests the inevitability of software shuttling funds around at cyberspace speeds to take advantage of ebbs and flows in the economic tides of the human race, around the world ... It would be interesting to further study the origins of banking, as I expect such a study would provide many such parallels by which the case for digi- -tized banking could be made stronger ... -- richard From rchilder at us.oracle.com Sat Nov 28 20:08:47 1992 From: rchilder at us.oracle.com (Richard Childers) Date: Sat, 28 Nov 92 20:08:47 PST Subject: Electronic Banking Message-ID: <9211290407.AA00714@rchilder.us.oracle.com> "On a related note, I noticed an article on electronic money in a recent issue of _the_Futurist_. It kept on coming back to the big advantage of cryptomoney: it is completely traceable. The main point was that cryptomoney would eliminate black marketeering (including the drug trade)." I don't think cash will _ever_ be eliminated. If it is, someone will make their own ( banks did this for many decades in North America ) and these will fill the role. There will always be transactions which will not justify the cost of the overhead in hardware and transaction processing, and market pressures will reward those whom develop a way to avoid this overhead, IMHO. -- richard From yanek at novavax.nova.edu Sat Nov 28 20:46:59 1992 From: yanek at novavax.nova.edu (Yanek Martinson) Date: Sat, 28 Nov 92 20:46:59 PST Subject: Governmental Economic Control In-Reply-To: <9211290407.AA00714@rchilder.us.oracle.com> Message-ID: <9211290446.AA07027@novavax.nova.edu> > I don't think cash will _ever_ be eliminated. > There will always be transactions which will not justify the cost of the > overhead in hardware and transaction processing, and market pressures will > reward those whom develop a way to avoid this overhead, IMHO. You can not depend on this. The government may subsidize the transactions, reducing or elimintating the overhead. For example it may issue "free" (paid for by money extorted from you) Personal Identitiy Cards, and install "public" Funds Transfer Terminals in most public locations. It may pass laws requiring every business to accept it (just write "This Card is a Legal Tender..." on the card). Then the only incentive for bypassing the system would be desire for privacy, which, for the average American, is much weaker than the economic incentive. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From gnu Sat Nov 28 23:40:54 1992 From: gnu (John Gilmore) Date: Sat, 28 Nov 92 23:40:54 PST Subject: George Gleason speaks out about cryptography: Today 2PM Berkeley. Message-ID: <9211290740.AA13833@toad.com> BMUG, Inc. Computer Professionals for Social Responsibility . . . . . . . Berkeley Chapter _______________________________________________________________ FOR IMMEDIATE RELEASE Contact: Judi Clark, 549-2684 (BMUG), 261-1869 (direct), fax: 261-4836 (direct), or e-mail judic at netcom.com November 27, 1992 Special Interest Group on Freedom, Privacy and Technology A public forum co-sponsored by BMUG and CPSR/Berkeley For those that need a brief break from Thanksgiving, the CPSR/BMUG Special Interest Group will explore cryptography with a brief overview and discussion lead by George Gleason. Gleason is founder of a telecommunications contracting firm in Berkeley. He is also professionally involved in psychological research on interpersonal communication and state variables (i.e. perception, cognition, etc.). Gleason's overview will be followed by a video taken from the Second Conference on Computers, Freedom and Privacy in Washington DC last March. The video is entitled: "Who Holds the Keys? Cryptography & Control: National Security vs. Personal Privacy." You are encouraged to join us on November 29, 1992 at 2:00 pm for a look into cryptography and personal privacy. The Special Interest Group's next meeting is Sunday, Nov. 29, 1992, at 2:00 pm. The monthly meetings are free and open to the public. The group meets on the last Sunday of the month at the BMUG office, 2055 Center Street, Berkeley -- a half block from the Berkeley Bart station. From gnu Sat Nov 28 23:56:27 1992 From: gnu (John Gilmore) Date: Sat, 28 Nov 92 23:56:27 PST Subject: Detailed Scenario of Dongle Usage In-Reply-To: <9211281553.AA19458@novavax.nova.edu> Message-ID: <9211290756.AA14123@toad.com> Yanek's scenario might have been great for 1980, but in 1993, if your electronic mail doesn't come right down into the computer in front of you, that you trust, I want to know why not. It works this way for millions of Internet users, AppleLink users, and users of "offline edit" programs for MCI Mail, ATT Mail, compuserve, AOL, Prodigy, etc. It's cheaper to buy computers these days than terminals! Seriously! John Gilmore PS: Don't tell the list -- we've had more than enough traffic recently. Tell *me* (gnu at toad.com) why you use your computer like a terminal instead of like a computer. I'll be gone for a week, so lack of speedy replies doesn't mean I'm not listening. From gg at well.sf.ca.us Sun Nov 29 00:52:05 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Sun, 29 Nov 92 00:52:05 PST Subject: Electronic Banking Message-ID: <199211290850.AA03386@well.sf.ca.us> "...and just take the legal risks..." Wellll, what is there to gain by taking legal risks, as opposed to doing a research gig where we're trading in pennies for fictitious goods & services...? Please spell it out explicitly; there would have to be a very significant advantage to convince me to agree. Like maybe that the govt is about to pull all cash out of circulation and this is our last hope.... -gg From gg at well.sf.ca.us Sun Nov 29 01:01:10 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Sun, 29 Nov 92 01:01:10 PST Subject: "gleason speaks at CPSR..." Message-ID: <199211290859.AA04170@well.sf.ca.us> Just a quick note of reassurance here. Someone at BMUG saw something I posted about crypto and education and values, and suggested I give a short talk on that to get discussion going. I will definitely Not 1) be a "spokesperson" for anything or anyone other than my own views, and 2) say anything likely to arouse premature publicity regarding things going on in the group or on the list. So in other words I intend to play it way careful, low-key, stick to social issues, and make it clear that there are many people far more qualified than I to discuss technical aspects in detail, and make it clear that there is wide debate and difference of opinion on the subjects of discussion. Now also, apologies for not contacting other folks on the list here when this was just getting set up. Actually it surprised the heck out of me to find out how fast the date came up; I was expecting at least another week. Properly, there are at least ten or twenty people on our list who could be addressing other groups on these issues. Any feedback, email back to me quick, because it's about 12 hours from now...! -gg From barrus at tree.egr.uh.edu Sun Nov 29 07:38:56 1992 From: barrus at tree.egr.uh.edu (Karl L. Barrus) Date: Sun, 29 Nov 92 07:38:56 PST Subject: crypto banking Message-ID: <9211291538.AA23755@tree.egr.uh.edu> I'd like to see a digital bank go up as well - just to be able to work through the protocol, at first. I took a cryptography course last summer at the university, and learned a lot (and had some fun!) working through various protocols: coin flipping, poker, subliminal channels, number comparison without giving away the numbers involved, signatures, etc., and more recently since joining this group: dc-nets. It doesn't have to be fancy: this list or maybe just email between various participants at first, maybe then a fancier system with transactions posted or made public for study, then a more advanced system with telnet or mail to the digital bank and transactions kept private. We could make everybody's account balance public and then study ways to avoid traffic analysis on account fluctuations (maybe the only way to do this is to keep balances secret) - maybe everyone can have more than one account and pay off transactions with a little bit from each account (this would be inconvenient though...) Anyway, I'm just rambling on... :-) /-----------------------------------\ | Karl L. Barrus | | barrus at tree.egr.uh.edu (NeXTMail) | | elee9sf at menudo.uh.edu | \-----------------------------------/ From edgar at spectrx.Saigon.COM Sun Nov 29 07:56:20 1992 From: edgar at spectrx.Saigon.COM (Edgar W. Swank) Date: Sun, 29 Nov 92 07:56:20 PST Subject: Remailer followup Message-ID: <7DgyuB6w165w@spectrx.saigon.com> No-one has replied to my request for help using the remailer at Remailing Service Am I the only person having trouble making this thing work?? Recall I had to use the "::" convention since I can't specify network headers (except subject) from this system. -- edgar at spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca From edgar at spectrx.Saigon.COM Sun Nov 29 07:56:36 1992 From: edgar at spectrx.Saigon.COM (Edgar W. Swank) Date: Sun, 29 Nov 92 07:56:36 PST Subject: Secure key exchange Message-ID: On Nov 26, Mark inquired about "secure" methods of exchanging public keys. Apparently the only really secure method is a physical transfer face-to-face with someone you know; or to have a key certified by someone you trust whose key you trust. [PGP has key certification built-in; for other implementations, just digitally sign some form of the key to be certified]. There is no secure method of exchanging public keys using only the net. As far as you know all your messages, both incoming and outgoing, are being intercepted by a "spoofer" who will substitute his public key for yours in all outgoing messages and another public key of his for each unique public key intercepted in incoming mail. A few methods were discussed on Extropians of trying to get a genuine public key distributed by outsmarting the spoofer. But if the spoofer is smarter than you, these methods will fail. That leaves methods which exchange, or at least verify, keys by other means than the network. I proposed a service to verify keys by paper mail and (optionally) telephone. Here is an update of what I posted. The offer is still good. ================================================================ I'd like to announce the opening of the Swank Public Key Verification Service. To become a customer, do the following. 1)On a piece of paper put: a)Your name and Network address. b)The "armored" ASCii form of your PGP 2.0 Public Key. c)(optional) Any other information you want to certify about yourself, such as: Home address. Mailing address (if different). Home phone number. Occupation-Work Phone-Work Address. "I am not a law enforcement officer or agent." d)"I certify the above to be true under penalty of perjury". e)A photocopy of your driver's license or other picture ID with signature. Actually this is a photocopy of all of the above with the ID on top of the original. [note: if you don't want to reveal your home address, you can cover that portion of your photo ID. Your name, photo, and signature must show] f)Your signature. (NOT photocopied) g)(optional). have the paper notarized. 2)E-mail to me edgar at spectrx.saigon.com (Edgar W. Swank) An ASCII message containing Items a) through d). You may encrypt this with my public key (optional). 3)Mail to me at Edgar W. Swank 5515 Spinnaker Dr., #4 San Jose, CA 95123 Via U.S. Mail or alternate such as FedEx: a)The paper prepared as specified above. b)A self-addressed, stamped envelope. This could also be a pre-paid FedEx envelope. It could be addressed to a trusted friend if you're concerned your own mail may be intercepted. c)$1.00 cash (preferred), check, money order, etc. Payment by check will delay processing until check clears. If you don't enclose a self-addressed stamped envelope, enclose an extra $1.00. That all you have to do. Then what I will do for you: I will visually verify that the public key on the paper matches the key I received via E-mail and that the signature on your photocopied ID matches your original signature on the paper. (I do not claim to be a handwriting expert). I will send to you by return E-Mail your public key signed with my public key. I will send to you in the evelope you supplied (or to the address you specify) a paper about myself constructed as described above (but not notarized - if you want notarized send an extra $10). This will give you a verification independent of the network that my public key is really mine. I will post your machine-readable ASCII record that you E-mailed to me to Extropians and Cypherpunks (optional, specify if you DON'T want this). This feature is subject to no objection from Extropians and Cypherpunks list management. I will keep your paper on file for at least one year. Anyone may request a photocopy of your paper (and up to three others) by sending me $1 and a self-addressed, stamped envelope. I will also send your machine-readable ASCII record to his network address, if supplied. Any customer may also phone me directly at (408)227-3471 during reasonable hours and I will verify your/others public key(s) by reading them over the phone. Edgar W. Swank 5515 Spinnaker Dr., #4 San Jose, CA 95123 edgar at spectrx.saigon.com (Edgar W. Swank) (408)227-3471 (listed) Cal. Drivers License MO531219 Retired from IBM -- Employee #788281 I am not a law enforcement officer or agent Here is my PGP 2.0 Public Key: --Type bits/keyID Date User ID --pub 1024/87C0C7 1992/10/17 Edgar W. Swank --sig 67F70B Philip R. Zimmermann -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.03 mQCNAirfypkAAAEEAKe2jziPeFw6hY19clR2GtQ4gtGCSSVOTgPKEJzHfuC74Scf 9PEuu1kebLhHk43A9wo1vr52o4jpH/P/tnFmRtBQOMzLUzAt5rMucswtSVviMQS2 hBuc9yGJKWHVcyfA79EARKEYTdhx+2qKI+hFJcPE+rmD8wVoF94nNf3ah8DHAAUR tClFZGdhciBXLiBTd2FuayA8ZWRnYXJAc3BlY3RyeC5zYWlnb24uY29tPokAlQIF ECsRFxzidd4O/2f3CwEBsmID/2qXL/VdjGxxYFNIZdA+DC6howUXlHw66MUArILE 2/9J69VvcpbQTKmD4A+04SwH9q8SDzWxsg+1VANuy08EE0up9pm7ZBzrxkFcOydh sEwOt9fRn9EJ3tDNYe1SVoxV9Fc47of55Om7cTNrky0hdp1LA13uf/TeV3nrBYa2 1zaz =IFW+ -----END PGP PUBLIC KEY BLOCK----- ====================================================================== Other Options: If you have a listed phone number and request it, I will verify your number through information and call you (collect) to verify the public key you sent me. I will add this as a notation to your electronic and paper record. No extra charge! Another possible option is to use a full color photocopy of your photo ID. This costs about $1.00 at photocopy centers such as Photo Drive-Up as opposed to 5 or 10 cents for an ordinary photocopy. I will also note this on your electronic and paper record. ====================================================================== So far I have zero (0) customers. Philip Zimmerman, in e-mail to me, endorsed the idea, but he has declined to become a customer himself even though I waived the fee for him. Plan B is to exchange/verify public keys face-to-face at parties, such as the PenSFA parties I previously posted info about. Rather than bringing diskettes, I would think printed copies of (armored form) public keys would be easy to handle. I have printed up business-card size copies of *fragments* of my public keys with the 6-hex-digit "Key ID". I think it would be very difficult to generate a valid new key pair where the public key matched the key ID and key fragment. -- edgar at spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca From pmetzger at shearson.com Sun Nov 29 10:38:53 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Sun, 29 Nov 92 10:38:53 PST Subject: comments on Don's "Cypher Bank" In-Reply-To: <9211290225.AA24130@soda.berkeley.edu> Message-ID: <9211291813.AA23423@newsu.shearson.com> >>If only the hash value is mailed, then the full key can be e-mailed >>or anonymously posted to a newsgroup that you montitor. If the full key >>is mailed, you should invest in a scanner and some simple OCR software. >I have been thinking about this. I think that pgp should have a postscript >output module, so you can print your public key on the back of business >cards and hand them out to people you meet. Is anything preventing you from building seperate tools to do this? PGP will happily put out your key into a file, from whence you can do anything you like. Why add bloody postscript generation capability to an encryption program, fercrissake. Perry From pmetzger at shearson.com Sun Nov 29 11:07:39 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Sun, 29 Nov 92 11:07:39 PST Subject: the list In-Reply-To: <199211290859.AA04170@well.sf.ca.us> Message-ID: <9211291832.AA23438@newsu.shearson.com> >From: George A. Gleason >Just a quick note of reassurance here. Someone at BMUG saw something I >posted about crypto and education and values, and suggested I give a short >talk on that to get discussion going. I will definitely Not 1) be a >"spokesperson" for anything or anyone other than my own views, and 2) say >anything likely to arouse premature publicity regarding things going on in >the group or on the list. "Premature" publicity? This list isn't exactly a private club -- I bet the government folks know exactly what it is we are discussing and in great detail. Posting something to a list like this means it isn't a secret any longer. Not that we are much of a threat -- the average subscriber here seems to have far more opinions than knowledge. If you have something you want to see done, just go out and do it. Don't form a committee to discuss the matter. Things that get discussed on this list immediately enter my list of things I'm unlikely to see anyone else build any time soon. Sorry for lashing out, but the drivel is getting thick enough to cut with a chainsaw. Repeating, if you want to do something, just go out and do it, don't talk. Perry From phr at napa.Telebit.COM Sun Nov 29 11:13:33 1992 From: phr at napa.Telebit.COM (Paul Rubin) Date: Sun, 29 Nov 92 11:13:33 PST Subject: Electronic Banking In-Reply-To: <199211290850.AA03386@well.sf.ca.us> Message-ID: <9211291912.AA07318@napa.TELEBIT.COM> "...and just take the legal risks..." Wellll, what is there to gain by taking legal risks, as opposed to doing a research gig where we're trading in pennies for fictitious goods & services...? Please spell it out explicitly; there would have to be a very significant advantage to convince me to agree. Like maybe that the govt is about to pull all cash out of circulation and this is our last hope.... How about a crypto poker game, or crypto diplomacy (with fictitious money)? This would allow us to try some coin flip protocols, zero knowledge proofs etc. as well as crypto banking. Of course, cheating (trying to rig the coin tosses, spoof messages etc.) would be encouraged! That would allow us to find weak spots in the protocols, which are supposed to prevent this from happening. Then, at the next physical meeting, people could describe what kinds of things they did, and maybe the winner could get a small prize (e.g. be treated to dinner by the rest of the players). From marc at MIT.EDU Sun Nov 29 13:27:17 1992 From: marc at MIT.EDU (Marc Horowitz) Date: Sun, 29 Nov 92 13:27:17 PST Subject: crypto dongle design problems Message-ID: <9211292126.AA22394@deathtongue.MIT.EDU> A few comments on "Detailed Scenario of Dongle Usage": >> So, you walk up to ANY terminal directly connected to a host, or to a >> terminal server, or a personal computer of any kind connected through a >> modem, or borrow someone's laptop connected to a cellular modem. As several people have pointed out, terminals are passe'. In general, my mail never goes over a serial line. Here at MIT, most people have unix machines on their desks. Mail is composed on the unix machine, sent via ethernet to the mail hub, and received via POP or NFS from the mailhub. To make life worse, often, the machines are in public clusters where anyone can log in. And, (sit down here), the root password for these public machines is well known. (The servers' root passwords are a closely guarded secret.) So, for me, the crypto-dongle is almost completely useless. >> Call up, or telnet, dial up a bbs, or connect through any other means, >> to your host, and log in. Except IP. One of my machine at work runs SLIP over its serial port. What am I supposed to do now? >> Any time an encrypted message is displayed whose public key ID matches >> one of the private keys on your keyring, the dongle temporarily buffers >> the message it into its RAM, flashes the "decrypt" LED, while >> decrypting the message. Someone else mentioned this, but I didn't understand your response. I read mail in emacs, a full-screen editor. it displays the first screenfull, and I hit space to scroll down. Does the dongle recognize emacs and hit space, or what? >> Now, press the "encrypt" button on the dongle. It presents you with a >> simple line editor, that works with any terminal or terminal emulation, >> but is reasonably easy to use (something like most bbs-es use for >> composing messages). You type your message, or if it was prepared >> ahead of time on the local equipment, you transmit the text. So, I'm trusting the local equipment with my private message. Even if I'm only "typing directly to the serial port", how do I know if my friend's borrowed laptop has been (maybe unknowingly) modified to store the data? Similar problems arise with all the other sample applications you describe. More personal comments: I've had several years of experience designing large-scale systems incorporating security features. One of the most valuable lessons learned is that security and privacy must be designed into a system from the beginning, not added later. Ease of use comes from design, not hacks, which inevitably fail. My view of a useful crypto-dongle is more like Phil's. A device with one serial port, which stores my private keyring. It has functions to list the keys it has (names and hashes, not keys), to decrypt a message (while displaying some external indication of having done so), and to sign a message (again, with display). Programs would have to be modified to use the dongle to do the appropriate very sensitive crypto stuff, and I can do the DES or other work on my desktop machine. I forsee the dongle being made of a well-known CPU or MCU (easily verifiable), an EPROM (software), a static RAM (long-term, encrypted storage of keys), a DRAM (short-term cleartext storage and buffering), a UART, an input keypad of some sort, a small (say 1x20 LCD display for simple output, and perhaps a special chip for the math. Sources to the EPROM would be available, of course. Paranoid people could burn their own chip (assuming they trusted the programmer :-). Yeah, this isn't much use on a dumb terminal, but dumb terminals aren't of much use nowadays, anyway. Marc From marc at MIT.EDU Sun Nov 29 13:43:41 1992 From: marc at MIT.EDU (Marc Horowitz) Date: Sun, 29 Nov 92 13:43:41 PST Subject: No Subject Message-ID: <9211292143.AA22427@deathtongue.MIT.EDU> >> This entire business may be pretty simple. If we have anonymity >> both ways, (where one or neither party knows the others physical >> location), then who cares about the content of the message? >> >> You might as well send it in plain text, Except you need RSA >> just for the signitures so you know you aren't being spoofed. Very good reasons. "Here is my plan to kill President Foo: ...." Just because you and your hired gun are anonymous, you don't want anyone, especially the government, to read your message. It could throw a wrench into your plans. Marc From karn at qualcomm.com Sun Nov 29 14:04:10 1992 From: karn at qualcomm.com (Phil Karn) Date: Sun, 29 Nov 92 14:04:10 PST Subject: Secure key exchange Message-ID: <9211292203.AA17336@servo> How byzantine! PGP 2.1 will have a much more convenient facility for verifying public keys that you receive over the network. If you say "pgp -kvc karn", for example, it will display the MD-5 hash of karn's public key as 16 hex bytes. If you know the sound of my voice, you can call me on the phone and have me read off the hash code that I compute here on my key so you can compare it to the value you computed. If they match, you can sign my key with reasonable confidence. About the only way to defeat this system is for the bad guy who feeds you the bogus key in my name to come to my house and hold a gun to my head as I receive your phone call. I would much rather trust a simple verification procedure based on redundancy and close personal relationships than a single, complex, impersonal process involving people I don't know. This is not to impugn your integrity, of course -- I'm simply speaking on principle. People need to be very selective about the signatures they sign, otherwise they will become meaningless. I've already had people sign my public key without any verification that it is legit. This is a no-no. I am bothered by the message that PGP currently generates when it reads in some new public keys asking if you'd like to certify each new key. Even though the default is "no", it makes it too easy to sign a key without really verifying its authenticity. Phil From marc at MIT.EDU Sun Nov 29 14:08:03 1992 From: marc at MIT.EDU (Marc Horowitz) Date: Sun, 29 Nov 92 14:08:03 PST Subject: thoughts on digital cash Message-ID: <9211292207.AA22455@deathtongue.MIT.EDU> I've thought a bit about digital cash since the thread started here, and I have a bunch of thoughts. I hope I'll be coherent. ** For production use, you want a real, live bank or other entity to issue the "money". Assuming the digital cash is backed by gold, or securities, or something else tangible, you don't want the bank to go away with all your money. Or, if you read in the newspaper "Feds seize First National Bank", you want to know if they've just seized *your* bank, and therefore will be able to watch your deposits and withdrawals. If you don't know who your bank really is, you won't know. ** All of the above applies to your escrow agent (who may be your bank) for similar reasons. Public key systems provide non-repudiability, but knowing provably that a pseudonym just stole money or goods from you doesn't help you get it back. Sure, it tarnishes their reputation, but if they steal a whole lot of money all at once, they won't care. ** Anonymity in banking is a well-known concept. If I transfer money from my numbered swiss bank account to your numbered swiss bank account, nobody knows anything, except who the bank is. And I don't see Switzerland giving up their enviable position in the international banking community willingly. All we need to do is convince a swiss bank to do some digital cash banking. Easier said than done. ** Legality of starting our own anonymous electronic bank: what do the laws say, anyway? As long as I pay taxes on any profit, I can form a sole proprietorship to freely buy and sell purple widgets with very little government interaction. Would it still be legal if I got a whole lot of people to accept purple widgets instead of cash? Would it be legal if we called it "digital purple widgets" instead of "digital cash"? I'd really like to see some sort of digital cash system set up. My feeling is that there would be a stronger demand than most people think for such a thing, even if it weren't anonymous and untraceable and all that. But if it has those features, too, and we do it first, it will get used. And de facto standards are hard to get rid of. Marc From mark at coombs.anu.edu.au Sun Nov 29 14:20:56 1992 From: mark at coombs.anu.edu.au (Mark) Date: Sun, 29 Nov 92 14:20:56 PST Subject: Secure PK swapping.. what are the methods? Message-ID: <9211292219.AA28149@coombs.anu.edu.au> Since Im not sure this got through to the list last time I'll resend. Certainly I havent had any pointers to where to find the information I need.... ------------------------------------------------------------------------ Below is a letter Ive sent to a person designing a communications system similar to IRC but designed with the ability to be anonymous and as secure as possible. Further details will be announced soon when it's stable. --------------------Begin letter----------Begin letter------------------- Before you get too involved with the client in the comm system I was thinking of a way of having secure privmsgs, two forms depending on how open one chose to be: Messages are exchanged via UDP to hide from the netstat junkies... When someone does a msg the first time and the client doesnt know about that user it queries the server to either get a hostname/port pair for that user and/or a public key. The data is then stored in an internal attribute bank. Format of a private message: ._________________________________________________________. | Nickname Plaintext | dest IP | dest udp port | | =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= | | =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= | | =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= =PGP MESSAGE= | `---------------------------------------------------------' [Return host/port/public key are encrypted into the PGP? message] The above message is then sent to the delivery module of the client. The above host and port are either the recipeints or the server's depending on what type of message is being sent. Thus the same message can go to the server or the recipient direct per se: 1) Using the hostname/port + public key for that user the sender's client encrypts the message and udp transmits a message to that port on the other users host. That remote client has set up a socket to listen on that udp port for messages. The remote client unpacks the message with it's private key and extracts the message, a reply host and port and the senders public key. He can then reply to the sender and they both can talk without loading down the server. Plus, unless someone is logging the ethernet, no one can ascetain wether they are talking. There is only the initial request of the users public key from the server which each client sends in automatically when it connects. You might also have an option in the client to auto download a block/all of the users nicks and their keys so no-one can detect the initial query of a user. 2) The other, differently secure :), form is because the server has been told to hide the users username + hostname from the /who information. All there exists for that person is a nickname and a public key. The senders client gets individually/block downloads the key he wants and proceeds to udp a message to the server which has the udp port and hostname of the recipient as normal from the client connect. It acts as IRC does now, as a middle man for messages. Less secure because the server admin can ascetain that there is a message being sent between the two people and also he can slip in his *OWN* keys to basically grab and decipher messages between the two parties. i.e he sends his own key to the sender and decrypts the incoming message and then sends the message out to the recipient using their encryption key. neither user could tell there was a switch in between. (There are schemes to get past this however). Both ways have their flaws because you are relying on the non-hackedness of the server to give you the right keys and hostnames and ports. A bad admin could easily, knowing enough about coding, disrupt the entire process if we didnt from the start ensure the right protocols were used. It has to be done right the first time or not at all. I'll echo this letter to a cryptography mailing list to ask for details of schemes that will allow each user to know they have a valid, secure public key of the other. One possible solution would be to do a mass query of all the online servers at once and if they didnt report the same keys sound a Real Big Alarm (tm). Maybe an automatom could sit there randomly checking keys :) (Can hear the cries of "No Bots.. No Bots" now :). (Note this allows *someone* to know your doing a query for a user... that may or may not bother the sender/recipient. Doing a block transfer from all the servers at once isnt net.nice) Comments? ------------------End of Letter----------------End of Letter---------------- Now what Im curious about is any other methods of secure key exchange where the exchange mid point may be lying about the keys, the hosts and the ports. Assume each person knows the others 'style' etc. How does one get the real keys to each other with an unreliable "medium"? (It might slip in it's PK). Assume that they havent previously organised a key exchange. Replies to me or the list.. (but not both please.. my mbox is busy enuff :) Mark mark at coombs.anu.edu.au From mcmahonm at wybbs.mi.org Sun Nov 29 14:51:00 1992 From: mcmahonm at wybbs.mi.org (Mike McMahon) Date: Sun, 29 Nov 92 14:51:00 PST Subject: UNSUBSCRIBE Message-ID: <9211291635.AA01230@wybbs.mi.org> unsubcribe mcmahonm at wybbs.mi.org From S950272 at slvaxa.umsl.edu Sun Nov 29 15:19:41 1992 From: S950272 at slvaxa.umsl.edu (S950272 at slvaxa.umsl.edu) Date: Sun, 29 Nov 92 15:19:41 PST Subject: Please... Message-ID: <01GRQCRO6QHG8WW8IZ@slvaxa.umsl.edu> Please delete me from the mailing list, the mail volume is too great for me. From marc at MIT.EDU Sun Nov 29 15:25:14 1992 From: marc at MIT.EDU (Marc Horowitz) Date: Sun, 29 Nov 92 15:25:14 PST Subject: unsubscribe messages Message-ID: <9211292324.AA22516@deathtongue.MIT.EDU> If you don't want to be on this list, that's fine. BUT PLEASE STOP CLUTTERING MY INBOX WITH THE UNSUBSCRIBE REQUESTS!!! I AND MOST OF THE OTHER RECIPIENTS OF THIS LIST CANNOT DO ANYTHING ABOUT IT!! There is a convention on the Internet that if there is a list called foo at bar.domain, the maintainers of this list will be on a much smaller list called foo-request at bar.domain. Send requests there to get added or removed, not to the whole list. If you get a bounce, then, and ONLY THEN, should you send to the whole list. So, if you want to get off the list, send mail to cypherpunks-request at toad.com. It's not hard. And it will keep large numbers of people from wanting to kill you. Flame off. Marc From cmr!cmrp!berry_k at mailer.cc.fsu.edu Sun Nov 29 15:53:56 1992 From: cmr!cmrp!berry_k at mailer.cc.fsu.edu (Kevin Berry) Date: Sun, 29 Nov 92 15:53:56 PST Subject: UNSUBSCRIBE Message-ID: <9211292336.AA19892@cmrp.cmr.uucp> unsubscribe berry_k at cmr.fsu.edu From wmo at rebma.rebma.mn.org Sun Nov 29 20:24:59 1992 From: wmo at rebma.rebma.mn.org (Bill O'Hanlon) Date: Sun, 29 Nov 92 20:24:59 PST Subject: Some hacked scripts for the remailers Message-ID: Here's a couple of real rough Bourne shell scripts to get some mail to go to both Hal's and my remailers. Not too helpful if you don't have a unix machine around--sorry. Nothing fancy, but it'll keep the mental confusion down when trying to put a message together. First is twohop... ------ Cut here ------ #!/bin/sh # Two hop anonymous remailer hal's first, then rebma ... if [ $# != 2 ] then echo Usage: twohop message-file-name destination-address exit 1 fi message=$1 dest=$2 t1=twohop.1 t2=twohop.2 # if the "remailing" and "remailer" names look odd--well, that's what hal's # and my respective keys for the remailers are named... encap $message $dest remailer $t1 encap $t1 remailer at rebma.mn.org remailing $t2 elm hal at alumni.caltech.edu < $t2 rm -f $t1 $t2 ----- Cut here ----- twohop calls encap twice. Encap is a more general and useful script. ------ Cut here ------ #!/bin/sh # # usage: encap message-file destination remailer resultfile # if [ $# != 4 ] then echo Usage: encap message-file-name destination remailer-key-name outputfile exit 1 fi mfile=$1 dest=$2 remailer=$3 result=$4 t1=encap.1 t2=encap.2 echo :: > $t1 echo Request-Remailing-To: $dest >> $t1 echo "" >> $t1 cat $mfile >> $t1 pgp -ea $t1 $remailer echo :: > $t2 echo Encrypted: PGP >> $t2 echo "" >> $t2 cat $t1.asc >> $t2 mv $t2 $result rm -f $t1 ---- Cut here ----- These seem to work for me... At least, a couple messages now have gotten back to me from them. They helped me get a couple problems out of the remailer. -Bill -- Bill O'Hanlon wmo at rebma.mn.org From gg at well.sf.ca.us Mon Nov 30 00:33:34 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Mon, 30 Nov 92 00:33:34 PST Subject: Secure key exchange Message-ID: <199211300832.AA16031@well.sf.ca.us> Edgar- Two possible points of critique in an otherwise good idea. 1) HOME Address?! As I've said before, that's arguably your most secure datum since it's where you keep your soft, squishy body, and where the baddies and black-baggers and so on would just looove to know where to find you. Let's not make it any easier for them. 2) "I certify that I'm not a cop or spy." That doesn't and hasn't ever held up in any court in the land. Plenty of precedent in drug case law. "I want to buy some pot." "Okay, first tell me under oath that you're not a nark." Result: nark laughs all the way to the police station, with fresh catch in handcuffs. We can't keep them out, and at some future time might want to open up a dialog with the LE community on various issues. No point looking like a conspiracy if we aren't one. -gg From strat at intercon.com Mon Nov 30 01:30:00 1992 From: strat at intercon.com (Bob Stratton) Date: Mon, 30 Nov 92 01:30:00 PST Subject: Secure key exchange In-Reply-To: <9211292203.AA17336@servo> Message-ID: <9211300930.AA00855@intercon.com> >>>>> On Sun, 29 Nov 92 14:03:25 -0800, karn at qualcomm.com (Phil Karn) said: Phil> People need to be very selective about the signatures Phil> they sign, otherwise they will become meaningless. I've Phil> already had people sign my public key without any Phil> verification that it is legit. This is a no-no. I am Phil> bothered by the message that PGP currently generates Phil> when it reads in some new public keys asking if you'd Phil> like to certify each new key. Even though the default is Phil> "no", it makes it too easy to sign a key without really Phil> verifying its authenticity. I have to echo Phil's comments here. One of the things that might be worth a few minutes is for this group to hash out (pun intended) a set of guidelines for "when it's o.k. to sign a key". I have been talking to some people about personal applications of cryptographic technology, and I'm frequently surprised when even people with a DP security background want to rush to certify keys they've received via email, etc. I'm thinking something along the lines of "If I'm in a real-time communications mechanism, and on the phone at the same time, and I receive their key at the moment when they told me they hit the return key - then it's probably theirs"...It would be prohibitive to list all of the possible permutations, but it might go a long way toward building the right habits if we brainstormed about a few firm guidelines for the uninitiated as to what constitutes responsible key management. I confess to some personal bias, because I know the PEM folks are watching to see how robust our key distribution "web" becomes over the course of its evolution, and I'd like to be able to show them a convincing argument against centralized key management, empirically... --Strat From pfarrell at cs.gmu.edu Mon Nov 30 05:33:16 1992 From: pfarrell at cs.gmu.edu (Pat Farrell) Date: Mon, 30 Nov 92 05:33:16 PST Subject: Secure Key exchange Message-ID: <9211301332.AA10244@cs.gmu.edu> Bob Stratton suggests we hash out ideas on key signing prorocols. Ok, here is what I do: I sign keys only when I am certian that the key belongs to the human who claims to have the name on the key. There are not a lot of keys signed by me floating arround, maybe six total. My sig does not mean that the key is not owned by a cop or NSA/CIA/KGB agent (Unlike Edgar's service) because I can't tell. So if you care about that stuff, start your own web of trust with "higher" standards. My sign doesn't mean that the person is really who they claim to be, I can't tell that either. I've signed the key of a guy claiming to be "Ray Kaplan" because I believe that he uses that name reegularly. But I don't know that his name isn't really Boris Badinov. You won't find my sig on Phil Zimmermann's key, even tho that is a popular activity. Phil is a Net/Ether person to me. My sig means that there is a real person with that name. I was at NCSC and exchanged keys there. I'll be at CFP-3 and exchange keys there too. And if you are in my area, (suburban Wash DC) we can meet and exchange keys. I see no reason to hurry. A slowly growing web of trust that is strong is far more useful than an exploding web of trash. Pat Pat Farrell, Grad Student pfarrell at cs.gmu.edu Department of Computer Science, George Mason University, Fairfax, VA PGP key available via finger or request #include standard.disclaimer Write PKP. Offer money for a personal use license for RSA. From pmetzger at shearson.com Mon Nov 30 06:10:54 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Mon, 30 Nov 92 06:10:54 PST Subject: thoughts on digital cash In-Reply-To: <9211292207.AA22455@deathtongue.MIT.EDU> Message-ID: <9211301400.AA05557@newsu.shearson.com> >From: Marc Horowitz >** Anonymity in banking is a well-known concept. If I transfer money >from my numbered swiss bank account to your numbered swiss bank >account, nobody knows anything, except who the bank is. Such accounts do not exist in Switzerland -- there is no such thing as a Swiss account for which the bank does not possess information on who the account holder is. Such things may have existed at one point -- but emphatically do not exist today. There are a few such things in existance in odd corners of the world -- but they aren't well publicized. >** Legality of starting our own anonymous electronic bank: what do the >laws say, anyway? As long as I pay taxes on any profit, I can form a >sole proprietorship to freely buy and sell purple widgets with very >little government interaction. Would it still be legal if I got a >whole lot of people to accept purple widgets instead of cash? Would >it be legal if we called it "digital purple widgets" instead of >"digital cash"? The law is a slippery thing -- however, anonymous bank accounts, no matter what you call them, are almost certainly illegal in the United States. Most computer people don't seem to understand that the law is interpreted not by a computer but by humans -- and they won't care what "hacks" you use. If it smells like a bank, they will likely convict you if it comes to that point. Perry From lasterm at ohm.ee.utulsa.edu Mon Nov 30 08:13:16 1992 From: lasterm at ohm.ee.utulsa.edu (Mike Laster 664-5510) Date: Mon, 30 Nov 92 08:13:16 PST Subject: PGP on local machine (was Re: MacPGP) Message-ID: <9211301610.AA05451@ohm.ee.utulsa.edu> folders a From hughes at soda.berkeley.edu Mon Nov 30 08:18:40 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Mon, 30 Nov 92 08:18:40 PST Subject: Electronic Banking In-Reply-To: <9211251953.AA01487@nano.noname> Message-ID: <9211301618.AA14930@soda.berkeley.edu> [Hal Finney describes Chaum's blind signature scheme.] >The "social" problems are more challenging, it seems to me. One such social problem that Hal does not mention is that the blind signature is a patented algorithm. You'd have to get a signature from Chaum. Since any such company which wanted to deploy with blind signatures whould be competing with Chaum's own company, DigiCash, there might be a problem here. >One possibility is to base digital cash on real money. >Unfortunately, this approach would currently be illegal (at least, >unless you actually were a real bank!). If you wanted to do this as a business, you can start a bank with (roughly) a million dollars in capital or you can buy an existing one with at minimum (roughly) fifty thousand. These minimum investments are for bank regulation purposes, not operating costs. So, if you really want to _be_ a bank, it's not that hard. Your greatest startup expense will most likely be attorney's fees for a specialist in bank regulation law. Eric From jwn2 at qualcomm.com Mon Nov 30 09:07:42 1992 From: jwn2 at qualcomm.com (John W Noerenberg) Date: Mon, 30 Nov 92 09:07:42 PST Subject: The Cypherpunks Mail Project Message-ID: <9211301706.AA27590@harvey> At 8:07 PM 11/25/92 +0000, Tony Kidson wrote: > >I'd like to chip in here, in my _very_ newbie way, that not >everybody is running a unix system with the ability to pipe >things between processes in so facile a manner. Good point. My vision for the Mac is to have a PGP service with an AppleEvent suite defined so that any other AE-aware program can use the services. This isn't trivial, but it is the right thing to do, imho :-). john noerenberg jwn2 at qualcomm.com noerenberg.j (Applelink) =========================================================== Do not uselessly lament your luck that is giving way, your work that has failed, your life's plans that have all ended in despair. Like a man long prepared, like a man of courage, bid her farewell, the Alexandria that leaves you. -- "The God Abandons Anthony", Constantine Peter Cavafy [1911] =========================================================== From hughes at soda.berkeley.edu Mon Nov 30 09:22:03 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Mon, 30 Nov 92 09:22:03 PST Subject: Secure key exchange In-Reply-To: Message-ID: <9211301721.AA17060@soda.berkeley.edu> >There is no secure method of exchanging public keys using only the >net. [spoofing, etc.] As mentioned by Hal, the new PGP 2.1 (imminent) has a feature to create an hash or a public key which can be read over the telephone to make sure that a key transmitted electronically has not been altered in transmission. >[long business description deleted] There's really no need for a physical authentication service with the telephone verfication ability. >Plan B is to exchange/verify public keys face-to-face at parties, There is just such a plan underway to have a PGP key exchange table at Usenix in January. >I have printed up business-card >size copies of *fragments* of my public keys with the 6-hex-digit >"Key ID". What could easily be printed is the hash function of the key. That would be even harder to duplicate. Eric From hughes at soda.berkeley.edu Mon Nov 30 09:37:45 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Mon, 30 Nov 92 09:37:45 PST Subject: Secure Key exchange In-Reply-To: <9211301332.AA10244@cs.gmu.edu> Message-ID: <9211301737.AA17617@soda.berkeley.edu> Pat Farrell write: >A slowly growing web of trust that >is strong is far more useful than an exploding web of trash. I urge everybody to go out and quote this! It's a great aphorism. Eric From hughes at soda.berkeley.edu Mon Nov 30 09:43:34 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Mon, 30 Nov 92 09:43:34 PST Subject: thoughts on digital cash In-Reply-To: <9211301400.AA05557@newsu.shearson.com> Message-ID: <9211301743.AA17881@soda.berkeley.edu> >>** Legality of starting our own anonymous electronic bank: what do the >>laws say, anyway? Perry write: >The law is a slippery thing -- however, anonymous bank accounts, no >matter what you call them, are almost certainly illegal in the United >States. OK, Perry, time to quote sources. Exactly what laws _do_ prohibit such bank accounts? >Most computer people don't seem to understand that the law is >interpreted not by a computer but by humans -- and they won't care >what "hacks" you use. If it smells like a bank, they will >likely convict you if it comes to that point. Most political dissidents don't seem to understand that the law is interpreted accurately, for the most part. There exist clear statutory definitions on what a bank is. If you don't meet those criteria, you're not a bank. Eric From tribble at xanadu.com Mon Nov 30 10:03:02 1992 From: tribble at xanadu.com (E. Dean Tribble) Date: Mon, 30 Nov 92 10:03:02 PST Subject: Secure key exchange I have to echo Phil's comments here. One of the things that might be worth a few minutes is for this group to hash out (pun intended) a set of guidelines for "when it's o.k. to sign a key". I have been In-Reply-To: <9211300930.AA00855@intercon.com> Message-ID: <9211301720.AA19058@xanadu.xanadu.com> An excellent suggestion. Can you start writing such a thing? (This is not a facetious request). I imagine there will be two or three strategies for approving a key, and if we write them up well, we will be able to ask people which protocol they have engaged in: 1) Only people I know personally and whose keys I receive in person. 2... n) Any key received throuhg any medium. This could have lots of educational value. dean From tytso at ATHENA.MIT.EDU Mon Nov 30 10:37:21 1992 From: tytso at ATHENA.MIT.EDU (Theodore Ts'o) Date: Mon, 30 Nov 92 10:37:21 PST Subject: Secure Key exchange In-Reply-To: <9211301332.AA10244@cs.gmu.edu> Message-ID: <9211301836.AA20482@tsx-11.MIT.EDU> Date: Mon, 30 Nov 92 08:32:45 EST From: pfarrell at cs.gmu.edu (Pat Farrell) I sign keys only when I am certian that the key belongs to the human who claims to have the name on the key. There are not a lot of keys signed by me floating arround, maybe six total..... Ah, but how do we know that it's really you making this statement, and not some evil NSA spoofer? What people need to do is to make their key-signinging policies available _signed_ with their private key; that way at least we would know that the entity signing the keys and the entity claiming that this is its policy are the same. This helps, but we would then still need to trust that the entity is telling the truth insofar as its key-signing policy is concerned. - Ted From pfarrell at cs.gmu.edu Mon Nov 30 11:11:12 1992 From: pfarrell at cs.gmu.edu (Pat Farrell) Date: Mon, 30 Nov 92 11:11:12 PST Subject: Secure Key exchange Message-ID: <9211301910.AA11750@cs.gmu.edu> tytso at ATHENA.MIT.EDU (Theodore Ts'o) wrote: quoting: pfarrell at cs.gmu.edu (Pat Farrell) I sign keys only when I am certian that the key belongs to the human who claims to have the name on the key. There are not a lot of keys signed by me floating arround, maybe six total..... tt> tt> Ah, but how do we know that it's really you making this statement, and tt> not some evil NSA spoofer? What people need to do is to make their tt> key-signinging policies available _signed_ with their private key; that tt> way at least we would know that the entity signing the keys and the tt> entity claiming that this is its policy are the same. Exellent point. I'll put a signed statement of my policy in my .plan. It won't add many characters, and anyone can find it by fingering me. (and I've never claimed I don't work for NSA/CIA/...) tt> This helps, but tt> we would then still need to trust that the entity is telling the truth tt> insofar as its key-signing policy is concerned. I can't solve this one so easily. I have two ideas that can help: 1. change PGP in future versions (starting with 2.1?) so it doesn't ask for confirmation every time a key is added to the ring. Make the user do an active action, rather than a half-asleep y to sign a key. 2. store a comment in my secret ring that is captured each time I sign a key. Thus I could store the "reason/justification" for the signature to jog my memory. I know whose key's I've signed now, but as the number gets bigger, then I'll need a memory aid. I suggest the secret ring, as I share my public ring, and don't think that why I chose to sign a key should be generally available. If this were supported, you could then send me a msg asking "why did you sign John Doe's key?" You would have to compare my answer to my published policy and make your own judgement as to whether I follow it. I could keep track of this manually, and should. But PGP already requires me to have a lot of files arround. Pat Pat Farrell, Grad Student pfarrell at cs.gmu.edu Department of Computer Science, George Mason University, Fairfax, VA PGP key available via finger or request #include standard.disclaimer Write PKP. Offer money for a personal use license for RSA. From tribble at xanadu.com Mon Nov 30 11:15:21 1992 From: tribble at xanadu.com (E. Dean Tribble) Date: Mon, 30 Nov 92 11:15:21 PST Subject: credibility and banking It seems to me that there are many parallels between this state of affairs and that which prevailed in the American West of the 1800s, with respect to banking .... there were no agencies insuring deposits, and only the rep- -utation of the bank's president - usually a leader of the community - was guarantee upon the funds. Bank robberies were not uncommon, depositors were In-Reply-To: <9211290400.AA00660@rchilder.us.oracle.com> Message-ID: <9211301831.AA19785@xanadu.xanadu.com> Our mechanisms for estimating credibility of a guarantor partly assume that life can be made difficult for the guarantor if they renege. Those intuitions are often completely wrong if the guarantor is anonymous. That's the main point of what I was saying. few, runs on the bank, I speculate, may not have been unknown in those cir- -cumstances where the community of bank depositors lost confidence in the bank or its officers. My understanding of the history of banking is that there are ZERO documented cases of runs on banks before the gov't started mucking with the banking industry. They started that mucking based on some economists projection that such a run could happen, so the gov't had to protect the pipul from it. It would be interesting to further study the origins of banking, as I expect such a study would provide many such parallels by which the case for digi- -tized banking could be made stronger ... It also has strong arguments for free banking, which is consequence of cryptographic electronic banking. dean From ghsvax!hal at uunet.UU.NET Mon Nov 30 11:19:02 1992 From: ghsvax!hal at uunet.UU.NET (Hal Finney) Date: Mon, 30 Nov 92 11:19:02 PST Subject: Electronic Banking Message-ID: <9211301830.AA23870@nano.noname> Eric Hughes points out that the blind signatures used to provide anonymity in Chaum's digital cash schemes are patented (by Chaum himself). This is a problem for an official, legal, profit-making business which wants to engage in electronic banking. However, such a business would face many other problems. Chaum's digital cash system could be construed as using the RSA algorithms, since it is in effect an RSA signature which makes the cash unforgeable. So a license for RSA would have to be obtained as well. (RSA licensing would also be needed for secure communication between the bank and its customers.) In addition, the acceptable use policies of NSFNET, which would probably have to be involved in most communications with the bank, are inconsistent with this kind of commercial activity, from what I understand. I believe new policies are in the works to allow commercial activities on the net, but these again will involve licensing costs. There is also the question of the legality of private cash in any form, electronic or otherwise. Nobody seems to have hard evidence on this. On the one hand, people can legally exchange certain types of securities, and they could perform services for each other in return for such exchanges. This is legal, but they are supposed to report the income on their tax returns. Our digital cash would seem to fit this model. (But are such securities transfers as untraceable as digital cash? Perhaps not.) On the other hand, I read several years ago that casino chips in Las Vegas were starting to be used as cash substitutes, but that the government cracked down on this practice. Perhaps this was too conducive to money laundering, especially with the reputed underworld activity in that city. I do think, though, that an informal digital cash system, presented as a research project or an educational game, would be able to slip between the cracks of the legal system, much as PGP has done. And I think this presentation would be legitimate. Digital cash is new (actually, nonexistant, as far as I know), and any use of it would by its very nature be research and be educational. I would suggest that anyone who proposes to implement such a game might want to consider releasing it anonymously (actually, pseudonymously). Sign the release with a PGP or RIPEM key, and let that be your pseudonym. Let people post messages to alt.security.pgp or some other newsgroup to discuss it, so that you can read them without revealing yourself, as proposed by Yanek. Post your replies anonymously using our remailers. This way there won't be a single-point target for anyone wishing to punish users of the game. Hal 74076.1041 at compuserve.com From eichin at cygnus.com Mon Nov 30 11:25:34 1992 From: eichin at cygnus.com (Mark W. Eichin) Date: Mon, 30 Nov 92 11:25:34 PST Subject: Secure Key exchange In-Reply-To: <9211301332.AA10244@cs.gmu.edu> Message-ID: <9211301925.AA29778@tweedledumber.cygnus.com> >> I see no reason to hurry. A slowly growing web of trust that >> is strong is far more useful than an exploding web of trash. precisely. I only sign keys when I've met the person physically, and had them tell me that yes, they have a PGP key, and yes, here are the lower bits (the keyid.) (The latter is a little weak, I look forward to the MD5 output version...) I keep keyid's in my "little black book" as well as my online keyring. Also, because keys are a reasonable "proof" that one is using PGP, some people will only release their "public" keys to people they will correspond with anyhow. (At least one key on the recent cypherpunks key list was in that category.) I have at this point signed keys of 6 people (the first three over dinner at a chinese restaurant -- this didn't start a trend, unfortunately :-) I haven't signed John Gilmore's key (even though I work for him) since I haven't actually seen him in person, though I may get a chance to when I'm in California next week -- this will create a link between east-coast and west-coast signatures, though possibly not the first. _Mark_ MIT Student Information Processing Board Cygnus Support From bwebster at pages.com Mon Nov 30 11:34:34 1992 From: bwebster at pages.com (Bruce F. Webster) Date: Mon, 30 Nov 92 11:34:34 PST Subject: Paranoia and Cypherpunks Message-ID: <9211301900.AA14307@pages.com> > (Surely John Gilmore's lawsuit to get some critical crypto papers > declassified has already "angered" the folks at NSA. Are we to > censure John for stirring up trouble? Buy him a really nice dinner would be a more appropriate response. :-) 'Way to go, John! ..bruce.. --------------------------------------------------------------------- Bruce F. Webster | We hackers linger by our leading edge Chief Technical Officer | Forgetting what is pending in the cache Pages Software Inc | Till practice hurtles past us, bwebster at pages.com | and we crash. -- Jeff Duntemann --------------------------------------------------------------------- From eichin at cygnus.com Mon Nov 30 11:37:42 1992 From: eichin at cygnus.com (Mark W. Eichin) Date: Mon, 30 Nov 92 11:37:42 PST Subject: Secure Key exchange In-Reply-To: <9211301836.AA20482@tsx-11.MIT.EDU> Message-ID: <9211301937.AA29781@tweedledumber.cygnus.com> allegedly (:-) writes: >> key-signinging policies available _signed_ with their private key; that I noticed in the pgp docs that there is a "signature classification field" which has a (rather small) set of reserved values, only one of which is actually implemented: 10 - Key certification, generic. Only version of key certification supported by PGP 2.0. Material signed is public key pkt and User ID pkt. 11 - Key certification, persona. No attempt made at all to identify the user with a real name. Material signed is public key pkt and User ID pkt. 12 - Key certification, casual identification. Some casual attempt made to identify user with his name. Material signed is public key pkt and User ID pkt. 13 - Key certification, positive ID. Heavy-duty identification efforts, photo ID, direct contact with personal friend, etc. Material signed is public key pkt and User ID pkt. >> we would then still need to trust that the entity is telling the truth I think we probably need a similar "web" certifying operational procedures. (That is, I believe, one thing that the PEM hierarchy claims to provide -- the institutional signature providers are auditted, etc. to guarantee that they provide the claimed level of security.) Some people trust my signatures more than other signatures because I'm already known to be somewhat "paranoid" w.r.t. security matters... _Mark_ MIT Student Information Processing Board Cygnus Support From pfarrell at cs.gmu.edu Mon Nov 30 11:44:28 1992 From: pfarrell at cs.gmu.edu (Pat Farrell) Date: Mon, 30 Nov 92 11:44:28 PST Subject: my key signing policy, signed Message-ID: <9211301943.AA11949@cs.gmu.edu> As suggested, here is a PGP signed copy of my policy. It and my public key is available via finger -----BEGIN PGP MESSAGE----- Version: 2.0 owGVVL9rFEEUToKKnm5nIWl8YBPxcjGJIkERlaBoQAKayiLM7b69G252Zp2ZvXOx FTGI/gmKdgER7PwBFnY2YiWCWIggImihqIUSfW/2Ek8E0eVgj5n343vf971dGloY WT+8azST28+Mdq+aj1eGh9+/HBm6e3OufHxh6fu968+e7vi05cGj+5e+fLt96/Om pdnl84cfPpk5sfD6xcSG6MfbrRdXGl8vb96/be7DtSMv36y0b8w+f3dned0rv9HJ ls6V0EP0wP8/J00XsyZamN5dh8mZmamodrotHdAvKyE3SsYlpMYC95G6BfPH5qGD pasDpinGXnYRUmsyDk+ldR4Kh2BSDmxEteOQiRLittAtBOlBavBtyih8YbEOQifQ k0qtRnju3e/qvPCYofacoakWVzNalQFLAAE9uoHjsNhEJbGLixQqQjxf8xCx0d4a pTCBZhkucrTO6KjWaxsCqkWGE9Q7UcjhRq8mN6isxbOFtIRWxDjuzTi/aQIqmBQ0 OQVTYlTDc330NHXeLp2MhQrwuEZbEEEMmBD4nqlgjxHjWqI9FIusYWxrZyCCqTeZ cHCY8Oo6HNg3tXd6X2Nycs/0odhkORFru9igvwdBpJ5EEzyNNAl3ZhwedUJ9BgGh jm2ZezrN0DnRQlLOaSEVCSNVpUDeNhqBUCuCzCz36Vxlk4kKuOnckAe8gXm64FRG TDy5vLKCKoPmQVJtgKPRDuolqVrh12iqB265YHgPAI9qv1EJY8EabKYmQiJdB8iU uaD5d/atEZjORILcWXjyTu65cpcoSstfzqgMQKBp3hIUtsLb9LSLanzPlliLJu8q ITNWMvmjVElFWoUSlvLZ9QEip0c18nleNMnH/UxtPHS06YFMq0xBvqoiQvuesR1e r4IEJF3JWc4VGZK7uN7fisTWmA6JGpucpc15NR3GFkmgFm0Pb6qPK11FVi1QjNbT INzwt4Wp9HXM2gBTtCk8nuOzPp6o9q8fGDbKUWEtKvXvSaeqfWG3rH5wgsg/AQ== =mxji -----END PGP MESSAGE----- From wcs at anchor.ho.att.com Mon Nov 30 11:45:58 1992 From: wcs at anchor.ho.att.com (Bill Stewart) Date: Mon, 30 Nov 92 11:45:58 PST Subject: cypherpunks mailing list structure Message-ID: <9211301944.AA03295@anchor.ho.att.com> It's nice to have cypherpunks-announce existing. A couple questions: - will all the cypherpunks-announce traffic be gatewayed to cypherpunks? (alternatively, have all the cypherpunks subscribers been added to -announce?) - will the new list be announced to sci.crypt, etc.? - we've already lost a number of subscribers from cypherpunks due to volume, so folks may have missed the announcement. I've been getting swamped by the number of postings coming in through the day, and we seem to have been losing a lot of people. It's getting hard to find my "real" mail in the clutter. An alternative structure, which libernet uses, is to have both batch and reflection subscriptions - batch folks get one digest a day, (produced automatically rather than by-hand as with some digest), which has the articles in alphabetic-by-Subject order to provide some continuity. Would it be possible for cypherpunks to do the same? Thanks; Bill Stewart, somewhere over New Jersey. From pfarrell at cs.gmu.edu Mon Nov 30 11:47:51 1992 From: pfarrell at cs.gmu.edu (Pat Farrell) Date: Mon, 30 Nov 92 11:47:51 PST Subject: My key policy signed. Message-ID: <9211301947.AA11983@cs.gmu.edu> As suggested, here is my key policy signed (not encrypted). It has minor rewordings from my clear text posting of this morning. It and my public key are available via finger. -----BEGIN PGP MESSAGE----- Version: 2.0 owGVVL9rFEEUToKKnm5nIWl8YBPxcjGJIkERlaBoQAKayiLM7b69G252Zp2ZvXOx FTGI/gmKdgER7PwBFnY2YiWCWIggImihqIUSfW/2Ek8E0eVgj5n343vf971dGloY WT+8azST28+Mdq+aj1eGh9+/HBm6e3OufHxh6fu968+e7vi05cGj+5e+fLt96/Om pdnl84cfPpk5sfD6xcSG6MfbrRdXGl8vb96/be7DtSMv36y0b8w+f3dned0rv9HJ ls6V0EP0wP8/J00XsyZamN5dh8mZmamodrotHdAvKyE3SsYlpMYC95G6BfPH5qGD pasDpinGXnYRUmsyDk+ldR4Kh2BSDmxEteOQiRLittAtBOlBavBtyih8YbEOQifQ k0qtRnju3e/qvPCYofacoakWVzNalQFLAAE9uoHjsNhEJbGLixQqQjxf8xCx0d4a pTCBZhkucrTO6KjWaxsCqkWGE9Q7UcjhRq8mN6isxbOFtIRWxDjuzTi/aQIqmBQ0 OQVTYlTDc330NHXeLp2MhQrwuEZbEEEMmBD4nqlgjxHjWqI9FIusYWxrZyCCqTeZ cHCY8Oo6HNg3tXd6X2Nycs/0odhkORFru9igvwdBpJ5EEzyNNAl3ZhwedUJ9BgGh jm2ZezrN0DnRQlLOaSEVCSNVpUDeNhqBUCuCzCz36Vxlk4kKuOnckAe8gXm64FRG TDy5vLKCKoPmQVJtgKPRDuolqVrh12iqB265YHgPAI9qv1EJY8EabKYmQiJdB8iU uaD5d/atEZjORILcWXjyTu65cpcoSstfzqgMQKBp3hIUtsLb9LSLanzPlliLJu8q ITNWMvmjVElFWoUSlvLZ9QEip0c18nleNMnH/UxtPHS06YFMq0xBvqoiQvuesR1e r4IEJF3JWc4VGZK7uN7fisTWmA6JGpucpc15NR3GFkmgFm0Pb6qPK11FVi1QjNbT INzwt4Wp9HXM2gBTtCk8nuOzPp6o9q8fGDbKUWEtKvXvSaeqfWG3rH5wgsg/AQ== =mxji -----END PGP MESSAGE----- Pat Farrell, Grad Student pfarrell at cs.gmu.edu Department of Computer Science, George Mason University, Fairfax, VA PGP key available via finger or request #include standard.disclaimer Write PKP. Offer money for a personal use license for RSA. From pmetzger at shearson.com Mon Nov 30 11:49:21 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Mon, 30 Nov 92 11:49:21 PST Subject: Secure key exchange In-Reply-To: <9211301721.AA17060@soda.berkeley.edu> Message-ID: <9211301806.AA08378@newsu.shearson.com> >From: Eric Hughes >>There is no secure method of exchanging public keys using only the >>net. [spoofing, etc.] >As mentioned by Hal, the new PGP 2.1 (imminent) has a feature to >create an hash or a public key which can be read over the telephone to >make sure that a key transmitted electronically has not been altered >in transmission. Just to point out, though, this is not foolproof. A good impressionist can fool people, especially if they are extremely skilled. A person with Rich Little's or Peter Sellers' level of skill can sound astonishingly like the original person (although a sound spectrograph isn't fooled, other humans can be). Perry From jwn2 at qualcomm.com Mon Nov 30 11:54:14 1992 From: jwn2 at qualcomm.com (John W Noerenberg) Date: Mon, 30 Nov 92 11:54:14 PST Subject: Classified info and other stuff. Message-ID: <9211301953.AA02873@harvey> At 10:44 PM 11/27/92 -0800, John Draper wrote: >Oh, By the way, numerious complaints have been said about the way that >the Mac PGP was stuffed when posted onto "umich'. I will be pushing for >releasing it stuffed with a self extracting archive instead. I also had >problems and lost significant time acquiring the new stuffit in order to >extract it. > >John D. Aladdin makes a freely available unstuffer which reads all their current formats, including self-extracting archives. I found it on their applelink bboard. john noerenberg jwn2 at qualcomm.com noerenberg.j (Applelink) =========================================================== Do not uselessly lament your luck that is giving way, your work that has failed, your life's plans that have all ended in despair. Like a man long prepared, like a man of courage, bid her farewell, the Alexandria that leaves you. -- "The God Abandons Anthony", Constantine Peter Cavafy [1911] =========================================================== From phr at napa.Telebit.COM Mon Nov 30 11:54:35 1992 From: phr at napa.Telebit.COM (Paul Rubin) Date: Mon, 30 Nov 92 11:54:35 PST Subject: Secure Key exchange In-Reply-To: <9211301925.AA29778@tweedledumber.cygnus.com> Message-ID: <9211301954.AA13674@napa.TELEBIT.COM> I have at this point signed keys of 6 people (the first three over dinner at a chinese restaurant -- this didn't start a trend, unfortunately :-) I haven't signed John Gilmore's key (even though I work for him) since I haven't actually seen him in person, though I may get a chance to when I'm in California next week -- this will create a link between east-coast and west-coast signatures, though possibly not the first. If you meet someone claiming to be John Gilmore, how will you know he's not an impostor? From eichin at cygnus.com Mon Nov 30 12:09:44 1992 From: eichin at cygnus.com (Mark W. Eichin) Date: Mon, 30 Nov 92 12:09:44 PST Subject: Secure Key exchange In-Reply-To: <9211301954.AA13674@napa.TELEBIT.COM> Message-ID: <9211302009.AA29816@tweedledumber.cygnus.com> allegedly asks: >> If you meet someone claiming to be John Gilmore, >> how will you know he's not an impostor? 1) I've met him before. (I wouldn't, for example, sign Tim Jennings' key after meeting him for the first time at a cypherpunks meeting, since I'd have no other way of identifying him. You, on the other hand, may be someone I've met before (do you think so?) so I might...) I've interacted with him to a reasonable extend, both socially and technically (including one interview with John Markoff.) 2) He signs my paychecks -- which is "good enough", since the checks clear :-) _Mark_ MIT Student Information Processing Board Cygnus Support From fen at genmagic.com Mon Nov 30 12:19:33 1992 From: fen at genmagic.com (Fen Labalme) Date: Mon, 30 Nov 92 12:19:33 PST Subject: remailers Message-ID: <9211301903.AB08401@> [ Marc Horowitz writes: ] >People who want to use remailers don't necessarily have the access to >turn their site into one. Far more people use email than are >sysadmins, or friendly with one. [ mark at coombs.anu.edu.au (Mark) agrees: ] >What if for instance the user is sending from a student account or some >other limited system (such as a PC) and they either arent allowed to run >nohupped unattended processes or are unable to. Will you deny them the use >of your remailer simply because they cant, or havent the technical knowledge >on how to, install their own remailer? That sounds a bit odd to me.... First, things are changing. More and more people are owning their own machines and setting up their own mail. Heck, I'm planning on having my own internet node at home! Second, we need to proliferate remailers. Get the students running the system to install the code (perhaps for credit!). Or, if you're at a company, explain to the sysadmin that you need to have access to information that is only availble from sources on the other side of remailers, or, perhaps more generally, just indicate that you need connectivity and that not being a remailer cuts down on the number of sites that you can connect to. Finally, perhaps a "student" rating can be added (in addition to "free" and "reputation-based"). Keeping track of the reputations of remailers is a first step to being able to keep track of the reputations of signatures (whether real or pseudonymous). The next step is the active filtering based on such info. Fen From pmetzger at shearson.com Mon Nov 30 12:38:24 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Mon, 30 Nov 92 12:38:24 PST Subject: thoughts on digital cash In-Reply-To: <9211301743.AA17881@soda.berkeley.edu> Message-ID: <9211301957.AA10429@newsu.shearson.com> >From: Eric Hughes >>>** Legality of starting our own anonymous electronic bank: what do the >>>laws say, anyway? >Perry write: >>The law is a slippery thing -- however, anonymous bank accounts, no >>matter what you call them, are almost certainly illegal in the United >>States. >OK, Perry, time to quote sources. Exactly what laws _do_ prohibit >such bank accounts? I know securities law much better than commercial banking law -- I can't quote commercial banking law or the UCC for the most part, so I've got no idea precisely where in the codes such accounts are prohibited. However, I'm so certain that the law in the U.S. requires that the bank have full information on the holders of all accounts that I'm willing to bet $150 right now with anyone who believes otherwise. The law not only requires that the bank know who you are, but may even require that ID be presented when you open an account (I know that this is now routine practice, although its possible that its only implied from the standards used to determine non-compliance rather than directly required by the law.) I don't have any incentive to find the precise place in the books where it says you can't have an anonymous account in the US, but for a few hundred bucks in easy money I'd find it fairly quickly. If you don't believe me, well, have fun. >>Most computer people don't seem to understand that the law is >>interpreted not by a computer but by humans -- and they won't care >>what "hacks" you use. If it smells like a bank, they will >>likely convict you if it comes to that point. >Most political dissidents don't seem to understand that the law is >interpreted accurately, for the most part. There exist clear >statutory definitions on what a bank is. If you don't meet those >criteria, you're not a bank. If you take deposits and allow people to write drafts against those deposits you are going to fall under the commercial banking or securities laws no matter what you do, Eric. I'm sorry that you don't like this, but its the truth. The best you can hope for is to be classified as a mutual fund or the like and not as a commercial bank -- in which case the reporting requirements are just as tight and you fall under the even more restrictive securities laws. The securities laws are EXTRAORDINARILY tight when it comes to reporting. Other than brokerages holding securities in street name, nominee and other anonymous arangements of any sort are not merely prohibited under the securities laws but actual criminal offenses. Perry From deboni at diego.llnl.gov Mon Nov 30 12:53:42 1992 From: deboni at diego.llnl.gov (Tom DeBoni) Date: Mon, 30 Nov 92 12:53:42 PST Subject: tutorial needed Message-ID: <9211302051.AA25066@diego.llnl.gov> Howdy! I'm in need of a tutorial text that will bring me up to date on the current methods and terminology in the crypto arena. Any and all suggetions are welcome, and since this is probably an old and tired topic on this list, feel free to mail them to me directly. Thanks! Tom deBoni deboni at diego.llnl.gov From tom.jennings at f111.n125.z1.FIDONET.ORG Mon Nov 30 13:58:28 1992 From: tom.jennings at f111.n125.z1.FIDONET.ORG (tom jennings) Date: Mon, 30 Nov 92 13:58:28 PST Subject: USSC Cases Available Message-ID: <3939.2B1A8DA6@fidogate.FIDONET.ORG> Cross posted from a local net 125 echo... net access not availble for this system. ----------------------------------------------- | To All Sysops -- You might want to leave an | | announcement advising your users of the | | following. -={lsg}=- | ----------------------------------------------- USSC CASES & Selected Other Legal Decisions Available The PC GFX Exchange BBS in San Francisco has begun building a collection of US Supreme Court and selected legal decisions (eg., Cubby v. CompuServe). The files are PKZIPed and, after their initial upload, will eventually be moved into the board's file directory #64 (Legal & USSC Case Files). The BBS can be reached at the following numbers. 415-337-5416 HST144/v.32bis (public line) 415-337-5599 HST168/v.32bis (downloading for subscribers only) 415-337-6846 HST144 (public line) 415-337-6849 HST168/v.32bis (public line) While the board is an RBBSNet node, regretfully, FREQs are not currently available. PC GFX also carries the FidoNet LAW Echo as well as the LEGAL echos from SmartNet and ILink. A special note of deep appreciation to Mike Riddle and Alec Grynspan for their generous contributions to the file base. -==- --- msgedsq 2.1 * Origin: -={The Lyceum}=- San Francisco, CA (1:125/101) -- tom jennings - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!111!tom.jennings INTERNET - tom.jennings at f111.n125.z1.FIDONET.ORG From pmetzger at shearson.com Mon Nov 30 14:03:15 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Mon, 30 Nov 92 14:03:15 PST Subject: credibility and banking In-Reply-To: <9211301831.AA19785@xanadu.xanadu.com> Message-ID: <9211302008.AA10892@newsu.shearson.com> >From: tribble at xanadu.com (E. Dean Tribble) >My understanding of the history of banking is that there are ZERO >documented cases of runs on banks before the gov't started mucking >with the banking industry. They started that mucking based on some >economists projection that such a run could happen, so the gov't had >to protect the pipul from it. Not strictly speaking the case -- there were instances of bank runs under free banking systems, but restriction clauses usually eliminated these problems immediately. Restriction clauses permitted banks to briefly suspend payments in gold, with a heavy interest penalty paid by the bank. Such clauses allowed banks to stop runs, but they could not be lightly used. In any case, runs were quite infrequent under free banking systems. In any case, I believe that digital banknote systems, when they arrive, will almost certainly involve explicit issuance banks rather than any sort of anonymous banks. Likely such banks will first appear offshore and will, at least at first, be nothing more than banks that accept cryptographically signed electronic mail in the stead of checks and bank drafts. Perry From hughes at soda.berkeley.edu Mon Nov 30 14:14:20 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Mon, 30 Nov 92 14:14:20 PST Subject: thoughts on digital cash In-Reply-To: <9211301957.AA10429@newsu.shearson.com> Message-ID: <9211302214.AA08418@soda.berkeley.edu> Perry writes: >If you take deposits and allow people to write drafts against those >deposits you are going to fall under the commercial banking or >securities laws no matter what you do, Eric. The definition of a bank is an institution that accepts demand deposits. >From Black's Law Dictionary: Demand deposits. Any bank deposit which the depositor may demand (withdraw) at any time in contrast to time deposit which requires depositor to wait the specified time before withdrawing or pay a penalty for early withdrawal. Funds accepted by bank subject to immediate withdrawal; such represent largest element in money supply of the United States. Certain mutual funds which have checks available to them do not fall under this classification. Such a mutual fund might be said to have deposits, but they are not demand deposits. You can't get them whenever you like. The fine print of such aggreements states that the mutual fund company does not have to honor the check for up to thirty days, typically. Because of the time delay, such deposits are not payable on "demand." Mutual funds, though, since they are backed by securities, do fall under securities law. Again, from Black's: For purposes of the Securities Act of 1933 and the Securities Exchange Act of 1934, the term "security" embraces all investment contracts, and the test is whether the investment is made in a common enterprise which is premised upon the reasonable expectation of profits solely from the managerial or entrepreneurial efforts of others; such test contains three elements: the investment of money; a common enterprise; and profits or returns derived soleley from efforts of others. I merely pointed out that if you're not a bank, you're not under banking regulation. This does not preclude regulation under other laws. Eric From hughes at soda.berkeley.edu Mon Nov 30 14:41:53 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Mon, 30 Nov 92 14:41:53 PST Subject: thoughts on digital cash In-Reply-To: <9211301957.AA10429@newsu.shearson.com> Message-ID: <9211302241.AA00770@soda.berkeley.edu> >However, I'm so certain that the law in the U.S. requires >that the bank have full information on the holders of all accounts >that I'm willing to bet $150 right now with anyone who believes >otherwise. You've certainly showed us that you believe this Perry, but otherwise this statement contains no educational content. This, to me, sounds like a grown-up version of "Is so!!!" backed up by "My bank account can beat up your bank account!" >[...] ID be presented when you open an account (I know that this is >now routine practice, although its possible that its only implied >from the standards used to determine non-compliance rather than >directly required by the law.) I'd really like to know if ID is required or not, for one, because that seems to affect the banks liability vis-a-vis presentation of false credentials. You made a claim of fact. I'm asking for you to provide a reference in support of your claim. Simple rational discourse. >[...] you are going to fall under the commercial banking or >securities laws no matter what you do, Eric. I'm sorry that you don't >like this, but its the truth. Now you're putting words into my mouth. I made no judgement as to whether I thought this was a good state of affairs. Eric From wcs at anchor.ho.att.com Mon Nov 30 14:47:10 1992 From: wcs at anchor.ho.att.com (Bill Stewart) Date: Mon, 30 Nov 92 14:47:10 PST Subject: Unlabelled PGP messages Message-ID: <9211302245.AA04980@anchor.ho.att.com> Hal Finney points out some problems with unlabelled messages, where the headers don't identify the public key by keyid - remailers include your email address, while newsgroups / broadcasts might have a LOT of articles, such that decrypting them to see if they're for you would be impractically slow. Some techniques that may help: - a remailer-to-newsgroup anonymous poster, which lets you send the remailer articles (presumably with unlabelled keys) to be posted to the alt.whatever group -- should be an easy combination of existing tools. - include an optional non-address label along with the unlabelled message. If you're having an ongoing secret conversation with somebody, you can secretly tell them the label to include, Subject: Unlabelled PGP message label: fnord If you don't see the fnords, you don't have to decrypt them. You don't want to use anything that can be traced to you, and you probably don't want to use labels in a sequence, or use the same label throughout a conversation, but it could help. You could also, if you're only mildly paranoid, use something like a 4-bit checksum of the PGP key or the key length as a label - it's not enough to identify which key it is, but it's enough to cut down on your decryption by a factor of 16. A longer checksum is too revealing - even 8 bits identifies 1/256th of the crypto community, which isn't very anonymous. With all these methods, if you're concerned about traffic analysis, you've still got to download the messages you don't care about to your machine before discarding them. - The Conventional Data Encryption (DEK) packet includes a checksum, which lets you know if you've successfully decrypted it using the RSA key, so you can tell quickly enough whether a message is for you, without decrypting the message itself. The RSA step probably takes most of the time for short messages, but it's still a win. (PGP does lose some security this way, since the Bad Guys can also tell if their exhaustive search of PGP keys has gotten the right one, and now they can go beat up the Key-Certifier to find out who the key really belongs to, but it's a start. If you want heavier anonymity, you have to do without the checksum. There's also an extremely small chance of an incorrect PGP key producing a correct checksum, but it's about 2**-26, and it still gives an incorrect session key.) Bill Stewart, somewhere in New Jersey From hughes at soda.berkeley.edu Mon Nov 30 15:04:22 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Mon, 30 Nov 92 15:04:22 PST Subject: Electronic Banking In-Reply-To: <9211301830.AA23870@nano.noname> Message-ID: <9211302303.AA02723@soda.berkeley.edu> Hal mentions all the problems a going concern would have with an electronic banking: patent on the blind signature, RSA license also required, acceptable use policy, underlying legality. >I do think, though, that an informal digital cash system, presented as >a research project or an educational game, would be able to slip >between the cracks of the legal system, much as PGP has done. I agree. An experimental money system should be fine, practically speaking. There will be no problem if no goods or services change hands. If everything is scored in points, then there is no concern about money at all. More generally, a digital money system is isomorphic to a conserved quantity server. For example, if I were to write a distributed multi-player simulation game, I could represent conserved quantities such as fuel and ammunition as the equivalent digital money tokens. That is, in order to fire, I have to "spend" a bullet. Eric From tribble at xanadu.com Mon Nov 30 15:20:39 1992 From: tribble at xanadu.com (E. Dean Tribble) Date: Mon, 30 Nov 92 15:20:39 PST Subject: cypherpunks mailing list structure In-Reply-To: <9211301944.AA03295@anchor.ho.att.com> Message-ID: <9211302248.AA21643@xanadu.xanadu.com> I would note that even the current remailers can double as mail-sorters to sort your crypto mail into different bins. This lets you just peruse them once a day, and keeps your higher priority mail separate. I like this solution because more people will then have built-in remailers. Right now it only is set up for UNIX, but the ideas can be reproduced elsewhere. dean From mark at coombs.anu.edu.au Mon Nov 30 15:27:53 1992 From: mark at coombs.anu.edu.au (Mark) Date: Mon, 30 Nov 92 15:27:53 PST Subject: Offshore banking.. Message-ID: <9211302309.AA12369@coombs.anu.edu.au> With respect to offshore banking, what about the legislation governing the export of money from the coutry? Here in Australia if we send an amount of money overseas then we have to pay a tax/levy of an amount based on the size of the funds being sent offshore. If we start snailmailing certified envelopes full of money overseas then someone will want to know about it so they can tax us. Im fairly sure there wouldnt be a problem (from the governemnt) with shuffling your funds from offshore bank to offshore bank. If encrypted money was going in and out all the time from a (legal) onshore bank that accepted digital transactions to an offshore one, then you would face the same export laws. How do the banks handle this when they send fifteen trillion overseas to have their money working for them while we all sleep at night....? Mark mark at coombs.anu.edu.au From hh at soda.berkeley.edu Mon Nov 30 15:45:30 1992 From: hh at soda.berkeley.edu (Eric Hollander) Date: Mon, 30 Nov 92 15:45:30 PST Subject: thoughts on digital cash In-Reply-To: <9211301957.AA10429@newsu.shearson.com> Message-ID: <9211302344.AA06143@soda.berkeley.edu> We should just write all the software to fully automate the system, get lightweight hardware for it and some solar panels and launch it into orbit. Whose jurisdiction is that? e From yanek at novavax.nova.edu Mon Nov 30 17:41:25 1992 From: yanek at novavax.nova.edu (Yanek Martinson) Date: Mon, 30 Nov 92 17:41:25 PST Subject: Unlabelled PGP messages In-Reply-To: <9211302245.AA04980@anchor.ho.att.com> Message-ID: <9212010141.AA18205@novavax.nova.edu> [talks about posting anonymous messages that only recipient can decrypt] > like a 4-bit checksum of the PGP key or the key length as a label > - it's not enough to identify which key it is, but it's enough > to cut down on your decryption by a factor of 16. > A longer checksum is too revealing - even 8 bits identifies > 1/256th of the crypto community, which isn't very anonymous. Why not generate a key just for this conversation, and then post a full 128-bit (22 base64 characters) hash in the subject. You can even have a key for each message if the conconversation is two-way then whenever you are about to send a message you can generate a new key pair and include the new public key with your message. As soon as you receive and decrypt the message for that key, destroy the private key. From pmetzger at shearson.com Mon Nov 30 18:39:37 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Mon, 30 Nov 92 18:39:37 PST Subject: thoughts on digital cash In-Reply-To: <9211302241.AA00770@soda.berkeley.edu> Message-ID: <9212010219.AA19516@newsu.shearson.com> >From: Eric Hughes >>However, I'm so certain that the law in the U.S. requires >>that the bank have full information on the holders of all accounts >>that I'm willing to bet $150 right now with anyone who believes >>otherwise. >You've certainly showed us that you believe this Perry, but otherwise >this statement contains no educational content. This, to me, sounds >like a grown-up version of "Is so!!!" backed up by "My bank account >can beat up your bank account!" I'm sorry, but I can't be troubled to spend time looking for the regulation otherwise. This is tantamount to asking me to bother spending time looking up where in the law books precisely running red lights is outlawed. I'm certain its illegal, but have very little interest without a monetary incentive to go and look up precisely where it says so -- I'd gain no interesting information personally. I'd have to take time off of work and go to a law library to determine precisely where in the mass of regulations and laws this particular practice is prohibited. For $150, the hour or so of my time involved, although not well compensated for, would at least be sufficiently compensated for that I would bother. Obviously, this is not evidence of the truth, but as you have noted, it is evidence of a very strong belief. If you have evidence to the contrary, here is your chance not only to make $150 but to have me do all the work required for you to get your $150. >You made a claim of fact. I'm asking for you to provide a reference >in support of your claim. Simple rational discourse. You don't have to believe me if you don't want to. As I've said, I have very little incentive to track down the specific place that the practice of permitting anonymous accounts is outlawed -- but I'm as certain of it as I am that driving a car requires a license in all 50 states. If I asserted that fact, and you desired evidence, I would have a similar lack of desire to go and look up where specifically in the law books of all the states that driving without a license was listed as a violation. Doing legal research of this kind is not entirely unpleasant, but it is tedious and would put me out of my way, little or no reward. Perry From jthomas at access.digex.com Mon Nov 30 18:46:33 1992 From: jthomas at access.digex.com (Joe Thomas) Date: Mon, 30 Nov 92 18:46:33 PST Subject: Rumors of your existence Message-ID: As a follower of sci.crypt and comp.org.eff.talk, I felt I had to check up on the owners, if any, of this e-mail mailbox that was listed at the end of St. Jude's "Cypherpunk Movement" article in Mondo 2000 Issue 8. How "patently false" are the rumors you can be contacted here? Joe From mark at coombs.anu.edu.au Mon Nov 30 19:38:20 1992 From: mark at coombs.anu.edu.au (Mark) Date: Mon, 30 Nov 92 19:38:20 PST Subject: Why not just do it? Message-ID: <9212010337.AA21322@coombs.anu.edu.au> With all the talk of banking regulations etc with regard to messing with the monetary system, why dont we just create a test system where everyone emails in an amount that they are prepared to coughup if they really had to, but at the moment dont (have to). Then we can go ahead with the digital "cash" scenario and not be governed by the banking/security laws of any country because no real money is involved. The object is to get a system going, find flaws, create software and protocols and basically experiment with it. The issue of actual cold hard cash is, to me, a not important. After all it's just numbers. Eric volunteered to do this earlier and, if he still wishes to, I'd be willing to participate in it. Maybe he doesnt have the benefit of a big cushy bank trust account earning him intrest for his work, but I dont think that was a consideration for him anyway. Mark mark at coombs.anu.edu.au From ghsvax!hal at uunet.UU.NET Mon Nov 30 19:50:44 1992 From: ghsvax!hal at uunet.UU.NET (Hal Finney) Date: Mon, 30 Nov 92 19:50:44 PST Subject: remailers Message-ID: <9212010311.AA24273@nano.noname> Fen Labalme quotes some messages with concerns about people needing permission from the sysadmins to run remailers. The current remailers, based on Eric Hughes' approach, don't have this problem. I don't even know who the sysadmin is on the system where I run the remailer. They don't know anything about it. Eric's remailers don't require continual processes to be run, root privileges, hacking the mail tables, or anything special. All you need is to be on a Unix system which supports the ".forward" file. This is typically implemented by the mail programs which deliver mail to the user's mail file. The programs check to see if a file called .forward exists in the user's home directory, and if so they treat its contents as either a program to pipe the incoming mail into, or a user name or list of user names to send the mail to. This is the hook by which Eric's remailers operate. The .forward file is set up so that mail is piped to a program which sorts the mail based on its headers, using the mh utility slocal or, in my case, a perl script which provides some of the same functions. Each message is checked like this, and if it doesn't contain any of the special stuff which activates the remailer software, it is simply deposted in the user's mailbox file as usual. Otherwise the remailers run and forward it as requested. With this solution, there's no need for anybody to be aware that you are running a remailer, as long as it's not too much of a load in terms of extra message traffic. Hal 74076.1041 at compuserve.com From shawnb at ecst.csuchico.edu Mon Nov 30 20:18:21 1992 From: shawnb at ecst.csuchico.edu (S.E. Brown) Date: Mon, 30 Nov 92 20:18:21 PST Subject: 386des wanted Message-ID: <9212010418.AA02687@toad.com> Does anyone possess a copy of the des package 386des? I've heard that it is incredibly fast, and would like to look at a copy. I have been unable to find it on any of the regular crypto haunts on the inet. Thanks in advance Shawn From marc at Athena.MIT.EDU Mon Nov 30 21:13:48 1992 From: marc at Athena.MIT.EDU (Marc Horowitz) Date: Mon, 30 Nov 92 21:13:48 PST Subject: Chaum's DigiCash Message-ID: <9212010513.AA05283@steve-dallas.MIT.EDU> Does anybody have any contact information for David Chaum or DigiCash? I think it's worthwhile to find out if any of the problems we've been discussing have been previously solved. It's possible that our experiment could increase visibility of digital cash to the point that a real commercial venture could work, in which case he may even be interested in helping us. Email me personally, I'll summarize. Marc From tcmay at netcom.com Mon Nov 30 22:48:00 1992 From: tcmay at netcom.com (Timothy C. May) Date: Mon, 30 Nov 92 22:48:00 PST Subject: John Gilmore on CNN Message-ID: <9212010643.AA01350@netcom2.netcom.com> Our own John Gilmore's fame in the NSA-tweaking community continues. I just saw John interviewed by CNN for a report on crypto, the recent case involving the Friedman papers, and RSA Data Security's problems getting export licenses for its products. The piece ran on "Headline News," and possibly on the main CNN channel as well (as is typical). John spoke about crypto and the need for private individuals to have secure communications, a woman from CPSR spoke about recent threats to further limits communications privacy, and Jim Bidzos from RSA spoke about licensing for exports. The NSA had no substantive comment. All in all, no surprises for any of us. It was too brief, of course, but seemed fairly done. Reports like this will gradually get the word out. By the way, you should all check out John's excellent articles he wrote in sci.crypt about the declassification of the Friedman papers. If you don't have Usenet access, I'll mail them to the first several people who request them. (I'd just post them here, but John's in Japan and I can't get his permission.) --Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at 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^756839 | PGP Public Key: by arrangement.