From postmastuh at dawkmastuh.guv Thu Oct 1 14:35:52 1992 From: postmastuh at dawkmastuh.guv (postmastuh at dawkmastuh.guv) Date: Thu, 1 Oct 92 14:35:52 PDT Subject: Secure IRC Message-ID: <9210012143.AA00610@atdt.org> How about the idea of a secure Internet Relay Chat? A central server might maintain the list of everybody's Public Keys. If you wanted to broadcast a 'public' yet secure msg in a particular room making sure only participants in that room (and not eavesdroppers somewhere else on the wire) could read the msg you could encrypt your broadcast with the server's own Public Key. Send it. The Server receives it, decrypts it, then for each of the participants currently in this particular room, the server encrypts the msg with that person's Public Key and sends it. Private IRC msgs would be treated similarly, except that they'd be re-encrypted only once, for the intended private recipient. Anyone interested on working on this? 0r 1z 1t 2 layme? -- /|n0n1mu$ From omega at spica.bu.edu Thu Oct 1 16:16:25 1992 From: omega at spica.bu.edu (The Omega) Date: Thu, 1 Oct 92 16:16:25 PDT Subject: No Subject Message-ID: <9210012324.AA01012@spica.bu.edu> FOR IMMEDIATE RELEASE Contact: Nikki Draper (415) 322-3778 Computer Public Advocacy Group To Examine FBI Wiretap Scheme at October Annual Meeting. Palo Alto, Calif., October 1, 1992 -- Computer Professionals for Social Responsibility (CPSR), the national public interest organization based here, will take an in-depth look at its recent suit against the Federal Bureau of Investigation (FBI) during CPSR's 1992 Annual Meeting, October 17th and 18th at Stanford University in Palo Alto, Calif. CPSR Legal Counsel, David Sobel, will talk about the FBI suit for the first time since it was filed and moderate a panel discussion on the politics of cryptography at the annual meeting. The CPSR annual meeting is a provactive two-day conference that addresses critical issues facing society as a result of information technology. CPSR filed suit against the FBI in September, after the Bureau failed to make public documents that would justify the need for its new wiretap proposal. The FBI proposal would redesign the telephone network to make wiretapping easier. Recognizing the importance of cryptography policy, CPSR catalyzed a national debate earlier this year, as to whether or not the FBI and National Security Agency (NSA) should be involved in setting the technical standards for the computer and communications industry. The panel discussion will include a screening and discussion of film clips from the movie, Sneakers. Panelists include, Joan Feigenbaum, Technical Staff, Computing Principles Research, ATT Bell Labs, John Gilmore, founder of Cygnus Support, and Dave Banisar, CPSR Policy Analyst. CPSR's annual meeting will bring together computer scientists from across the country to examine the relationship between politics and technology. Other topics include: * Teledemocracy & Citizen Participation: Beyond the Electronic Town Meeting, This session is an election year look at the dangers and the opportunites of electronic democracy. Speaker, Susan G. Hadden, professor in the LBJ School of Public Affairs, University of Texas at Austin, an expert on telecommunications and citizen participation. * Everything's Digital! Media Convergence: Hope, Hype or Hell? This session examines the social implications of multimedia convergence which is the merging of computer, telephone, and video technology. Panel discussion with David Bunnell, Editor, New Media, Denise Caruso, Editor, Digital Media, and Howard Rheingold, Whole Earth Review * Envisioning Technology Policy in a Democratic Society; A panel of technologists looks at the development of American technology policy. Panelists include, Gary Chapman, The 21st Century Project, Judy Stern, CPSR/Berkeley, Claire Zvanski, SEIU Local 790. President of Interval Research, Dave Liddle, will be the keynote speaker at CPSR's awards banquet Saturday evening. Liddle will be speaking on the Computing in the 21st Century. IBM researcher, Barbara Simons will be presented with the 1992 Norbert Wiener Award for Social and Professional Responsibility in Computing. Founded in 1981, CPSR is a national, non-profit, public interest organization of computer scientists and other professionals concerned with the impact of computer technology on society. With offices in Washington, D.C. and Boston, CPSR's members provide the public and policy makers with expert testimony and assessments on the power, promise, and limitations of computer technology. For more information about CPSR call 415-322-3778 or send email to cpsr at csli.stanford.edu. From gg at well.sf.ca.us Fri Oct 2 00:53:02 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Fri, 2 Oct 92 00:53:02 PDT Subject: Secure IRC Message-ID: <199210020800.AA21035@well.sf.ca.us> Interesting ideas so far... Hey, anyone see the Quantum Crypto article in October Scientific AMerican? Of course the approach isn't practical at this point, and doing it over fiber optics won't be any better since the amplification along the way would raise the quantum process to the classical level and destroy its value... but even so, interesting as theory... -gg From omega at spica.bu.edu Fri Oct 2 10:35:43 1992 From: omega at spica.bu.edu (The Omega) Date: Fri, 2 Oct 92 10:35:43 PDT Subject: No Subject Message-ID: <9210021743.AA04199@spica.bu.edu> Hacking ingenuity... =================[ Cut Here ]==================== The /etc/passwd cracker service Have you ever been troubled by those DES encrypted passwords in the /etc/passwd file of your favourite machine ? Worry no more ! What's up ? Utopia now has a unique, probably the first in the world, password-hacking mailserver. This server compares the encrypted string in the /etc/passwd with a 3Mb dictionary, the gecos-field and username. The dictionary consists of +- 50.000 english words, +-50.000 dutch words, sf-authors, girlnames and some other stuff that people tend to use as passwords. The dictionary check is done by the very fast HADES hacking engine. I was surprised by the speed of hades ! The gecos and username scanning is done by the adapted berkeley hacker , this one also appends 0-9 to the end of the guess, and checks upper/lower case and words without vowels. How it works: You need access to some form of uucp/internet mail facilities to use the server. Fidonet-users can use the fido <-> internet gateway, a helpfile for this gateway can be found somewhere on utopia, and on many other systems in cyberspace. send your /etc/passwd to: cracker at utopia.hacktic.nl The cracker will automagically try to guess the passwords in the passwd file, and send you back any results it found to the E-mail adress the file came from. Illegal ? Ofcourse you yourselfe are entirely responsible for your actions, I really don't care what you do with any passwords from any hacked account. I trust you to only use this server for 'educational purposes' :) Read the boiler-plate on Utopia to have deeper insight in any legal-issues. Furthermore you should read the disclaimer that comes with the HADES password hacker. Thanks: Thanks go to Zakbar & Remote for making the HADES hacker, to ITSME for the msdos-berkeley hacker, to Rop for the original idea and to the cockroaches in my house for entertaining me in those early hours. ====================================================================== From Tom.Jennings at f111.n125.z1.FIDONET.ORG Fri Oct 2 22:26:14 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Fri, 2 Oct 92 22:26:14 PDT Subject: Secure IRC Message-ID: <2554.2ACD2FF0@fidogate.FIDONET.ORG> U> How about the idea of a secure Internet Relay Chat? I'm fairly interested... version 2 of PGP is generating some interest here in the FidoNet, though it has some serious problems, design problems. (It's "ASCII armor" method (ala UUENCODE) is delicate and fussy, for example). I am considering becoming and "introducer" for parts of FidoNet. I can't seem to get past the problems of how to assign reliability to public keys I receive over an unsecured email channel to begin with. No other method is practical. Alas, I can't take part in much it seems, the UFGATE was hobbled to intentionally prevent us FidoNet people from entering text into message headers (For example "Request-Remailing-To:"...) because we'd take over the planet or something I guess (we are apparently contagious). U> The Server receives it, decrypts it, then for each of the participants U> currently in this particular room, the server encrypts the msg U> with that person's Public Key and sends it. Doesn't this imply that the unencrypted message would have to travel from the originator to the server? Or do you mean to send to X I'd request X's public key from the server, then encrypt, etc? --- Msg V2.8 -- 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 stjude at well.sf.ca.us Sat Oct 3 18:45:12 1992 From: stjude at well.sf.ca.us (Judith Milhon) Date: Sat, 3 Oct 92 18:45:12 PDT Subject: public vs. private Message-ID: <199210040152.AA17760@well.sf.ca.us> marc suggests: >>I *am* a little worried about publicizing the whole thing; >>perhaps it's okay to make it a showpiece but >>the real stuff needs to be done in a much more private way. Consider the phage model (which I & my roommate efrem lipkin have been considering for a longish while, since Community Memory) : The bacteriophage virus replicates itself by injecting its own information into an existing system. The more copies of the phage, the worse for the bacteria etc etc. SO: in private, the planning, the designing, the coding... for public distribution as widely as possible. If the technology is intrinsically transformative, and if the process of distribution is engaging, even exciting, the revolution is next tuesday. hughes is hoping that remailers will pop up everywhere, even before the encryption upgrades arrive... heh. And the more designers and coders we rope in, via publicizing, to produce immediate lively replicating phages, the better. Not so? If not so, I'll shut up forthwith. StJude PS: also it mindfucks the idea of conspiracy. hee hee. From Secret_Squirrel at Treehouse.ORG Sat Oct 3 22:38:36 1992 From: Secret_Squirrel at Treehouse.ORG (Secret_Squirrel at Treehouse.ORG) Date: Sat, 3 Oct 92 22:38:36 PDT Subject: Nuts & Acorns Message-ID: <9210040546.AA10254@atdt.org> To: Tom Jennings >> Doesn't this imply that the unencrypted message would have to travel from the originator to the server? Or do you mean to send to X I'd request X's public key from the server, then encrypt, etc? << Not at all. In its simplest form: We'd have a single secure-IRC-server. It would have its own public key, which ever secure-IRC-client would know. When I want to send a secure broadcast msg, I type it, my client encrypts it with the public key of the secure-IRC-server, and transmits it. The server picks it up, decrypts it in memory, then re-encrypts that original msg with the public key of each paritxxx participant in the particular room I'm in. So, if there are ten participants in the room, and I want all of them to know something, but not anyone else who might be tapping ixxx wires or catching packets somewhere in the ether, then I'd send a single broadcast msg to the server; the server would end up sending ten differently encrypted msgs -- one to each participant, encrypted with each of the participants' public keys (which the secure-irc-server would have to maintain; it would function as a key-server.) To send a private msg across the secure-IRC, I'd indicate that it was a "/msg", the recipeixxx recipient, and again, encrypt it with the public key of the server. The server would learn who the recipient was, and rebroadcast my message to that person, in that person's public key. >> I am considering becoming and "introducer" for parts of FidoNet. I can't seem to get past the problems of how to assign reliability to public keys I receive over an unsecured email channel to begin with. No other method is practical. << Huh? I don't understand what you're pointing out. If I send you my public key -- even if I cc: dockmaster -- what does it matter that the NSA knows my public key (unoless they want to send me msgs, too)? The key itself is inherantly secure. Let your users decide on their public keys and register those keys with your key server. Not the other way around. Course, there's always the Kandinsky-Ogorov method of key exchange. To: St. Jude >> The bacteriophage virus replicates itself by injecting its own information into an existing system. The more copies of the phage, the worse for the bacteria etc etc. SO: in private, the planning, the designing, the coding... for public distribution as widely as possible. If the technology is intrinsically transformative, and if the process of distribution is engaging, even exciting, the revolution is next tuesday. << Providing the numbe r of cells you have access to and can anticipate influencyxxx incxxx influencing is large enough, and it isn't. Anyway, look, let's put our words into action. What makes code (programming, I mean) didxxx different from spoken language? The fact that you can communicate with a machine, and it will _act_ on what you say, no matter what. Theres beauty and there's magic in that. (And some of us have the same effect on people that we have on machines. ;-)) Instead of talking about all this, let's start doing it. What did I read the other day? "Hackers go where Angels fear to tread"? Let's have more ideas. This hopping remailer is exciting. So is passive encryption of electronic communications. When are we going totart xxx to start effecting de facto standards here? Once we start encrypting everything, then what? What do we do with this new tool? Communication of any kind (especially encrypted communication) presupposs that there are messages to be exchanged -- _ideas_! More ideas and less chatter. How can we have a revolution if we don't even know what we're trying to bring about? Maybe I was out of the loop. Maybe I was attending an Army/Navy game that day, but I don't know what we're trying to do here, exactly. What is this "revolution"? -- $33kr1t $kwurl. K.R.A.P. (K-Rad. A.SCII P.Ossee) From Tom.Jennings at f111.n125.z1.FIDONET.ORG Sun Oct 4 14:46:44 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Sun, 4 Oct 92 14:46:44 PDT Subject: PGP echo conference... Message-ID: <2573.2ACF6745@fidogate.FIDONET.ORG> Date: 03 Oct 92 17:22:42 From: Christopher Baker on 374/14 To: Tom Jennings on 125/111 Subj: PUBLIC_KEYS Echo announcement * Forwarded from 1:374/14, Rights On! in Titusville FL * Originally to All in the ECHO_REQ echo. attention all public-key encryption buffs: a new Echo has been started for discussion and distribution of public-key encryption info. since it was only born a couple hours ago, it is being distributed privately from 1:374/14 [9600+ HST/V32] and 1:374/26 [2400]. here are the details from the EListing: area PUBLIC_KEYS title Public-Key Encryption and Distribution Echo desc Provides a technical forum for discussion of public-key desc encryption techniques and programs and for the distribution desc of public-keys in FidoNet and other BBS and e-mail networks. desc PUBLIC_KEYS is Moderated by Christopher Baker at 1:374/14 desc [KeyID: 1024/4B9A59] and GK Pace at 1:374/26 [KeyID: desc 1024/B6B823]. The messages entered into the Echo are the sole desc responsibility of the person entering the messages. When in desc doubt about public-keys, contact the poster directly via Netmail. desc The Echo is open to anyone with an interest in public-key desc encryption issues and methods. The Echo Guidelines are contained desc in PUBKEYS.RUL available in ELRUL???.LZH as of 11/92. mod C.Baker/GK.Pace, 1:374/14 tot 2 vol 10/week dist LOCAL, ZONE1 SEEN 374/14 374/26 PATH 374/14 374/26 -30- here's the info from the .RUL file to be found in ELRUL as of 11/92: This is the PUBLIC_KEYS Echo. The purpose of the Echo is to provide a place to post and find public-keys for data encryption within FidoNet and elsewhere and to discuss data and software encryption and the various schemes thereof. This is a technical Echo with very few rules. Those very few rules are: 1. Stay on-topic. Topics of keys and encryption are welcome. Others are not. 2. No politics [except as it relates to privacy issues] and no religion. 3. No personal attacks, slurs or innuendo. Stick to issues not personalities. 4. No Private flagged messages in Echomail! Encrypted traffic using public-keys is permitted for the exercise so long as it is on-topic. 5. This Echo may be traveling around the world so try to be concise. Avoid excessive quoting for one-liner responses. 6. Be aware that Echomail is NOT secure. Don't take anything at face value. 7. The posts in this Echo are the sole responsiblity of the poster. If you need verification, use Netmail. 8. The Moderators will deal with off-topic traffic. Don't respond for them. Links to this Echo will only be curtailed when absolutely necessary so please don't make it necessary. [grin] The Moderators are Christopher Baker [KeyID: 1024/4B9A59 1992/10/03] and GK Pace [KeyID: 1024/B6B823 1992/09/28] at 1:374/14 and 1:374/26, respectively. It is recommended that public-keys be made available via Netmail or by file-request with the magic filename: PGPKEY and that the public-key provided for that request by given a distinctive filename using part or all of each provider's name and address. For example, on my system, a file-request of PGPKEY will give BAK37414.ASC to the requesting system. This will avoid duplicate overwriting and make it easier to track the keys. Using a standard magic filename will make it easier to find keys on different systems. This Echo is not currently on the Zone 1 Backbone distribution list but that is expected to change as soon as the word gets out. This Echo will be EListed in ELIST211 next month. Please feel free to announce and distribute this Echo to all interested participants in your area. Thanks. TTFN. Christopher Baker & GK Pace Moderators -30- any questions? anyone with Areafix already set for this system or for 1:374/26 may link in remotely. all others need to send a Netmail request. the Echo will be distributed privately until it is large enough for moving to the Zone 1 Backbone [or any other Backbones who want to get into it]. thanks. TTFN. Chris & GK * Origin: Rights On! - Announcing ANOTHER Echo? - Titusville_FL (1:374/14) * Forwarded by Christopher Baker on 1:374/14, Rights On! in Titusville FL -- 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 hughes at soda.berkeley.edu Sun Oct 4 18:59:32 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Sun, 4 Oct 92 18:59:32 PDT Subject: Secure IRC In-Reply-To: <9210012143.AA00610@atdt.org> Message-ID: <9210050206.AA20902@soda.berkeley.edu> The problem with central servers is that they are prone to single point failure. That failure may be computer down or key compromise. A good criterion for this kind of design is not to use central servers. This is almost always possible. (Or always possible, depending on who you ask.) There is also the question about getting permission to enter a room, which corresponds to an authentication or a key distribution or a voting algorithm or some sort. You need to know how you want that _social_ interaction to work before you design protocols. You should implement that sociality and test it without encryption to make sure it's what you want. Is this sounding familiar? Eric From hughes at soda.berkeley.edu Sun Oct 4 19:15:03 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Sun, 4 Oct 92 19:15:03 PDT Subject: introducing public keys In-Reply-To: <2554.2ACD2FF0@fidogate.FIDONET.ORG> Message-ID: <9210050222.AA21567@soda.berkeley.edu> >I am considering becoming and "introducer" for parts of FidoNet. I >can't seem to get past the problems of how to assign reliability to >public keys I receive over an unsecured email channel to begin with. >No other method is practical. Building a key distribution system takes time. Start off by having people mail you diskettes. Or if you don't mind typing, printouts. Carry copies of your public key to give to people in person. Get good security is not free, especially in terms of time. If you can personally receive via out-of-band channels the public key of another introducer, you can exchange all the certified keys you each possess. And then exchange those with another introducer you know. Introducers are not a special breed. Most people should certify others public keys, if only for redundancy. Remember, no one has ever set up a non-hierarchical public key distribution system to the general public. This is research. Eric From hughes at soda.berkeley.edu Sun Oct 4 19:17:52 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Sun, 4 Oct 92 19:17:52 PDT Subject: Mail headers In-Reply-To: <2554.2ACD2FF0@fidogate.FIDONET.ORG> Message-ID: <9210050225.AB21620@soda.berkeley.edu> >Alas, I can't take part in much it seems, the UFGATE was hobbled to >intentionally prevent us FidoNet people from entering text into >message headers (For example "Request-Remailing-To:"...) because we'd >take over the planet or something I guess (we are apparently >contagious). You aren't the only one Tom. Apparently lots of Unix mail interfaces don't let you arbitrarily edit the header or add lines. I'm going to add a facility to make this possible for everyone. The design I have in mind uses only the message body. No need to touch the header. Announcements when it's finished. Eric From hughes at soda.berkeley.edu Sun Oct 4 19:51:17 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Sun, 4 Oct 92 19:51:17 PDT Subject: introducers In-Reply-To: <9210040546.AA10254@atdt.org> Message-ID: <9210050258.AA22363@soda.berkeley.edu> >If I send you my public key -- even if I cc: dockmaster -- what does >it matter that the NSA knows my public key (unoless they want to send >me msgs, too)? The key itself is inherantly secure. Let your users >decide on their public keys and register those keys with your key >server. Not the other way around. Let's make this short. The basic problem with public key systems is to make sure that what _I_ think is my public key is the same thing as what _you_ think is my public key. If these are not the same, something is wrong. At worst, an interposer is getting all your mail, decrypting with one public key and encrypting with a different one. Servers, generally, are not desirable because they are too prone to communications filters of the above sort. For a more detailed reference, read the excellent introduction to the whole topic of public key distribution in the PGP 2.0 documentation. >Course, there's always the Kandinsky-Ogorov method of key exchange. Please elaborate. Eric From hughes at soda.berkeley.edu Mon Oct 5 00:14:29 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Mon, 5 Oct 92 00:14:29 PDT Subject: A statement of purpose Message-ID: <9210050721.AA01865@soda.berkeley.edu> I've had a bunch of people ask me about the group and what it's up to. Accordingly, I drafted a small statement of purpose to send to folks. Please comment. Eric ---------------------- The cypherpunks list is a forum for discussion about technological defenses for privacy in the digital domain. Cypherpunks assume privacy is a good thing and wish there were more of it. Cypherpunks acknowledge that those who want privacy must create it for themselves and not expect governments, corporations, or other large, faceless organizations to grant them privacy out of beneficence. Cypherpunks know that people have been creating their own privacy for centuries with whispers, envelopes, closed doors, and couriers. Cypherpunks do not seek to prevent other people from speaking about their experiences or their opinions. The most important means to the defense of privacy is encryption. To encrypt is to indicate the desire for privacy. But to encrypt with weak cryptography is to indicate not too much desire for privacy. Cypherpunks hope that all people desiring privacy will learn how best to defend it. Cypherpunks are therefore devoted to cryptography. Cypherpunks wish to learn about it, to teach it, to implement it, and to make more of it. Cypherpunks know that cryptographic protocols make social structures. Cypherpunks know how to attack a system and how to defend it. Cypherpunks know just how hard it is to make good cryptosystems. Cypherpunks love to practice. They love to play with public key cryptography. They love to play with anonymous and pseudonymous mail forwarding and delivery. They love to play with DC-nets. They love to play with secure communications of all kinds. Cypherpunks write code. They know that someone has to write code to defend privacy, and since it's their privacy, their going to write it. Cypherpunks publish their code so that their fellow cypherpunks may practice and play with it. Cypherpunks realize that security is not built in a day and are patient with incremental progress. Cypherpunks don't care if you don't like the software they write. Cypherpunks know that software can't be destroyed. Cypherpunks know that a widely dispersed system can't be shut down. Cypherpunks will make the networks safe for privacy. From hughes at soda.berkeley.edu Mon Oct 5 01:23:23 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Mon, 5 Oct 92 01:23:23 PDT Subject: Meeting Sat. Oct. 10, noon, Mt. View Message-ID: <9210050830.AA03692@soda.berkeley.edu> ANNOUNCEMENT ============ Second Meeting Saturday, October 10, 1992 12:00 noon - 6:00 p.m. Cygnus Support offices 1937 Landings Drive Mountain View The second meeting of the cypherpunks will be Saturday at noon. John Gilmore has graciously provided us with a meeting space at the new Cygnus Support offices. These offices are so new, in fact, that Cygnus will not have moved in yet. This meeting will be bring-your-own-pillow (or chair), since it will be held in largely empty space. Directions are at the end of the message. Attendance is transitive trust, arbitrarily deep. Invite whoever you want, and let them do so also, and so on. Invite them also to join the mailing list. Do not, however, just post the announcement. Time for that will come. I'd like everyone who plans on attending the meeting to send me, hughes at soda.berkeley.edu, a message telling me so. I'd like to get a rough head count before Saturday for game planning. We are starting at noon because of popular demand. Eat beforehand or bring a burrito or something. It will be fine to eat during the first segment; it won't be any more disruptive than the game is. Bring your PGP public key for in-person key distribution, preferably on diskette. We'll need a portable PC or three to do key distribution; if you have one you can bring, post to the list and tell people. We realized after the first meeting that a strict schedule was nonsense. This meeting has a very informal schedule. Schedule -------- Starting at noon, we're going to play session two of the crypto-anarchy game, in which players try to conduct business under the watchful eyes of others. We want to play for two hours and then have discuss experiences afterward for about an hour. Some of the improvements over last time will be flatter denominations of money, wider distribution of commodities, more watchers (governmental and otherwise), and perhaps some pre-printed forms. We'll take a break to regroup for about ten or twenty minutes. For the second half we'll talk about the security of remailers. I'll lead the discussion. We'll be designing protocols and analyzing attacks and defenses. I've done this with DigiCash for electronic money protocols, and remailers are much easier, but still probably more than an afternoon's discussion. We'll do this until six or so, when people will have to start leaving. Everyone who wants to will go out for dinner. I don't know the restaurants down there; perhaps someone could suggest one? Directions ---------- It's at 1937 Landings Drive, Mt. View. 101 to Amphitheatre Parkway (the bay side of Rengstorff Ave), go right at the first light, pass a right turn, and just before the road crests a tiny hill, turn right into the Landings complex. We're in Building H. -- Eric From fen at genmagic.com Mon Oct 5 12:39:37 1992 From: fen at genmagic.com (Fen Labalme) Date: Mon, 5 Oct 92 12:39:37 PDT Subject: A statement of purpose Message-ID: <9210051947.AA29863@relay1.UU.NET> Subject: RE>A statement of purpose I am way excited to see this all coming together! It's like a 13-year- old dream-come-true! This is a great statement of purpose, though I might leave "DC-nets" out (since many won't know what that means) and perhaps replace it with the only slightly-less-cryptic "information-theoretically-secure networks", or some such. $0.02 From fen at genmagic.com Mon Oct 5 14:13:51 1992 From: fen at genmagic.com (Fen Labalme) Date: Mon, 5 Oct 92 14:13:51 PDT Subject: SEIZING THE MEDIA Message-ID: <9210052121.AA03803@relay2.UU.NET> Subject: SEIZING THE MEDIA [ this is a resend I originally sent this to cypherpunks at toad.com on 28 Sep, but I haven't seen it yet, so apologies up front if you see it twice... Fen ~~~ ] FYI... from PeaceNet ACTIV-L: Date: Sat, 26 Sep 1992 23:33:10 CDT Sender: Activists Mailing List >From: "(Rich Winkel)" Subject: PAX: SEIZING THE MEDIA: A NETWORKER CONGRESS To: Multiple recipients of ACTIV-L /** gen.media: 141.0 **/ ** Topic: SEIZING THE MEDIA: NETWORKER CONGR ** ** Written 6:39 pm Sep 25, 1992 by openmedia in cdp:gen.media ** SEIZING THE MEDIA: A NETWORKER CONGRESS A weekend of activity to discuss, self-educate, and put into practice the creation of subversive media. 1:30pm Saturday 24 October to 6pm Sunday 25 October 1992 Media and resource exchange; slides, fax, posters, pamphlets, computer files, ideas, proposals, tactics Practical action on billboard improvement and removal; Big Art and postering E-mail and fax facility to receive material to be discussed and implemented during the weekend Documentation to all participants Materials supplied: photocopier reproduction/enlargement and the streets of Oxford Bloomin Arts, Princes Street, Cowley Road, Oxford, OX4, U.K. If you can't make it in person, you can take part in the Seizing the Media Congress by post, fax, E-mail. Send documents, comments, proposals, art, ideas, and posters. Post to: BM Jed, London WC1N 3XX, United Kingdom Fax to: (011 441) 0865 72 4317 E-Mail to: Eastoxcomcen at GN.APC.ORG Accommodation and other information are available from Friday night onwards. To make arrangements or get more information, get in touch with Oxfin between 1-4pm Mondays to Fridays at: (0865) 240545 >From the United States: 011 41865 240 545 Background: SEIZING THE MEDIA is the title of pamphlet written by the Immediast Underground and first released in Amsterdam , New York City, and Seattle in early 1992. The 26 pamphlet combines theory, graphics, research and proposals that examine: * Information control * Propaganda and advertising * CIA * Mind control * Immediast counter-offensives * tactics, subversive networking, public empowerment * multi-media * Public production libraries * the liberation of public space ...Just when Jesse Helms thought he made the world safe from poetic terrorism, along come the Immediasts, a cadre of media hackers who are fed up with the ecology of coercion that surrounds them. Their booklet SEIZING THE MEDIA proposes an all-out artistic assault on coercive communication, cultural monologue, and media control. They want all media insurgents to take back the airwaves with pirate radio, cable access TV, altering ads and billboards, and otherwise hacking the datasphere to break the spell of State/corporate media control. . . . from Gareth Branwyns STREET NOISE, Issue 7 of Mondo 2000 SEIZING THE MEDIA Version 1.1 is available for $3 from Open Media PO Box 2726 Westfield New Jersey 07091 USA THE IMMEDIAST UNDERGROUND is a centerless network of artists, writiers, hackers, culture jammers, pirate broadcasters, and posterists who connect with one another through information systems, mail art, networker congresses, and the underground press, and who communicate with the public through actions against all forms of coercive communication, space infringement, and media control. For more info contact: Immediast U. PO Box 2726 Westfield New Jersey 07091 USA DECENTRALIZED WORLD-WIDE NETWORKER CONGRESSES Since the beginning of the year, members of alternative info-nets, artists, insurgents, and cultural workers have been holding networker congresses, transnational engagements in cultural production, dialogue, collaborations, open exchange, subversive brainstorming, and collective disruptions of dominant culture. THE NETWORKER, A NEW PERCEPTION In societies where information is money and media is power, public access is as controlled as the corporate states grip on communication law, censorship, commerce, covert action and surveillance. In this context, uninhibited public communication, expression, and cultural production are acts of freedom, sovereignty, and defiance. Rooted in the drive to connect and exchange with others, Networker Congress engage in culture and media as the battleground for greater openness and freedom. MORE INFORMATION about NETWORKER CONGRESSES contact: H.R. Fricker Buro fur kunsterische Umtriebe CH 9043 Trogen Switzerland Retrofuturism PO Box 2278 Iowa City, Iowa 52244 Face of the Congress FaGaGaGa Po Box 1382 Youngstown, Ohio 44501 Peter Kaufman Bergenwissenstrasse 11 CH-8123 EbmatigenDecentralized Networker Congresses Switzerland Decentralized Networker Congresses Netshaker PO Box 978 Hanover, New Hampshire 03766 ** End of text from cdp:gen.media ** From Secret_Squirrel at Treehouse.COM Mon Oct 5 21:40:53 1992 From: Secret_Squirrel at Treehouse.COM (Secret_Squirrel at Treehouse.COM) Date: Mon, 5 Oct 92 21:40:53 PDT Subject: List Message-ID: <9210060448.AA02547@atdt.org> comp-privacy at pica.army.mil I am the moderator of the Computer Privacy Digest. The computer Privacy Digest is an Internet mailing list that is dedicated to the discussion of how technology impacts privacy. This list is gatewayed into the moderated USENET newsgroup comp.society.privacy. In lot of ways it is a subsection on the risks digest but it concentrates on the risks of technology on privacy. The charter is: comp.society.privacy Effects of technology on privacy (Moderated) This newsgroup is to provide a forum for discussion on the effect of technology on privacy. All too often technology is way ahead of the law and society as it presents us with new devices and applications. Technology can enhance and detract from privacy. This newsgroup will be gatewayed to an internet mailing list. Submissions go to: comp-privacy at pica.army.mil and administrative requests go to comp-privacy-request at pica.army.mil. Moderator: Dennis G. Rears MILNET: drears at pica.army.mil UUCP: ...!uunet!cor5.pica.army.mil!drears INTERNET: drears at pilot.njin.net USPS: Box 210, Wharton, NJ 07885 Phone(home): 201.927.8757 Phone(work): 201.724.2683/(DSN) 880.2683 USPS: SMCAR-FSS-E, Bldg 94, Picatinny Ars, NJ 07806 ----------------------[ Cut Here ]------------------ I , Secret Squirrel, am merely cross-posting the above. I have nothing to do with it, and am in now xxx no way connected with comp-privacy. Just thought it might interest someone here. Quakka! From Tom.Jennings at f111.n125.z1.FIDONET.ORG Tue Oct 6 15:11:44 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Tue, 6 Oct 92 15:11:44 PDT Subject: Nuts & Acorns Message-ID: <2654.2AD20C59@fidogate.FIDONET.ORG> > To: Tom Jennings tj>> I am considering becoming and "introducer" for parts of FidoNet. I can't seem to get past the problems of how to assign reliability to public keys I receive over an unsecured email channel to begin with. No other method is practical. << >>?? Huh? I don't understand what you're pointing out. If I send you my public key -- even if I cc: dockmaster -- what does it matter that the NSA knows my public key (unoless they want to send me msgs, too)? << Not my worry. What I meant was, how do I know htat the keyfile I received from "John Smith @ net address" really is his, and not some faker. Short of physically getting key disks from someone face to face (flatly im-possible here), I don't know. The assurance of course is the social system: if someone sends me a message and keyfile, "here's my file, my name is Eric Hughes", and I distribute it... I can think of no way to prevent this, other than let a social system detect and repair -- "HEY THATS NOT ME!!!" form the 'real' you would raise a flag... and an audit trail at the introducers site (dangerous...!) might help. Anyhoo, that's what I meant. --- RM version 0.-1 (watch out) -- 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 Tue Oct 6 15:59:23 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Tue, 6 Oct 92 15:59:23 PDT Subject: Nuts & Acorns In-Reply-To: <2654.2AD20C59@fidogate.FIDONET.ORG> Message-ID: <9210062244.AA07304@newsu.shearson.com> >From: Tom.Jennings at f111.n125.z1.fidonet.org (Tom Jennings) >Not my worry. What I meant was, how do I know htat the keyfile I >received from "John Smith @ net address" really is his, and not some >faker. Short of physically getting key disks from someone face to >face (flatly im-possible here), I don't know. This is like asking "how do I get a bullet to stop in mid air and launch itself back into the bullet casing in the breech of the gun". You don't. Obviously, the only way to trust a key enough to certify it is to actually get it in person and verify identity. This is often impractical, but so what? If people want to communicate and the only assurance your signature gives them is that you got a copy of the keys by email, they might as well just email each other they keys and live knowing that the messages they are sending are to possibly non-securely identified people. Signed introduced keys should be reserved for times when you can actually add real information by claiming the key is really owned by the person who claims it. This does mean that a lot of the time until people have built up catenative assembleges of keys sufficent to form a "chain of trust" for unknown people that they will simply have to do without certification of the other person's identity. Isn't that the way life usually is, though? Perry From tribble at xanadu.com Tue Oct 6 17:44:27 1992 From: tribble at xanadu.com (tribble at xanadu.com) Date: Tue, 6 Oct 92 17:44:27 PDT Subject: Nuts & Acorns In-Reply-To: <9210062244.AA07304@newsu.shearson.com> Message-ID: <9210062358.AA08087@xanadu.xanadu.com> In the future I imagine several companies that seel public keys for individuals. Depending on how much risk of forgery you can tolerate, you just buy an individuals public key from several of these companies. Then they must all collude to fool you. dean From fen at genmagic.com Tue Oct 6 18:15:28 1992 From: fen at genmagic.com (Fen Labalme) Date: Tue, 6 Oct 92 18:15:28 PDT Subject: crypto bibliography Message-ID: <9210070123.AA01922@relay2.UU.NET> Subject: crypto bibliography By anonymous ftp from rsa.com: Fen ~~~ @inproceedings{agnew, author = "Agnew, G.B. and Mullin, R.C. and Vanstone, S.A.", year = 1988, title = "A secure public key protocol based on discrete exponentiation", booktitle = "Advances in Cryptology --- Eurocrypt '88", publisher = "Springer-Verlag", address = "Berlin"} @book{bamford, author = "Bamford, J.", year = 1982, title = "The Puzzle Palace", publisher = "Houghton Mifflin", address = "Boston"} @article{barlow, author = "Barlow, J.P.", year = 1992, month = "July", title = "Decrypting the puzzle palace", journal = "Communications of the ACM", volume = 35, number = 7, pages = "25--31"} @article{beauchemin, author = "Beauchemin, P. and Brassard, G. and Crepeau, C. and Goutier, C. and Pomerance, C.", year = 1988, title = "The generation of random numbers that are probably prime", journal = "J. of Cryptology", volume = 1, pages = "53--64"} @inproceedings{berson, author = "Berson, T.A.", year = 1992, title = "Differential cryptanalysis mod $2^{32}$ with applications to {MD5}", booktitle = "Advances in Cryptology --- Eurocrypt '92", publisher = "Springer-Verlag", address = "Berlin", note = "To appear"} @inproceedings{biham-feal, author = "Biham, E. and Shamir, A.", year = 1991, title = "Differential cryptanalysis of {F}eal and {N}-hash", booktitle = "Advances in Cryptology --- Eurocrypt '91", publisher = "Springer-Verlag", address = "Berlin"} @inproceedings{biham-full-des, author = "Biham, E. and Shamir, A.", year = 1993, title = "Differential cryptanalysis of the full 16-round {DES}", booktitle = "Advances in Cryptology --- Crypto '92", publisher = "Springer-Verlag", address = "New York", note = "To appear"} @article{bishop, author = "Bishop, M.", year = 1991, title = "Privacy-enhanced electronic mail", journal = "Internetworking: Research and Experience", volume = 2, pages = "199--233"} @inproceedings{blum-g, author = "Blum, M. and Goldwasser, S.", year = 1985, title = "An efficient probabilistic public-key encryption scheme which hides all partial information", booktitle = "Advances in Cryptology --- Crypto '84", pages = "289--299", publisher = "Springer-Verlag", address = "New York"} @inproceedings{brandt, author = "Brandt, J. and Damgard, I.", year = 1993, title = "On generation of probable primes by incremental search", booktitle = "Advances in Cryptology --- Crypto '92", publisher = "Springer-Verlag", address = "New York", note = "To appear"} @book{brassard, author = "Brassard, G.", year = 1988, title = "Modern Cryptology", publisher = "Springer-Verlag"} @book{bressoud, author = "Bressoud, D.M.", year = 1989, title = "Factorization and Primality Testing", publisher = "Springer-Verlag", address = "New York"} @article{brickell-survey, author = "Brickell, E.F. and Odlyzko, A.M.", year = 1988, title = "Cryptanalysis: {A} survey of recent results", journal = "Proceedings of the IEEE", volume = 76, pages = "578--593"} @inproceedings{brickell-rsa-hardware, author = "Brickell, E.F.", year = 1989, title = "A survey of hardware implementations of {RSA}", booktitle = "Advances in Cryptology --- Crypto '89", publisher = "Springer-Verlag", address = "New York", pages = "368--370"} @unpublished{buhler, author = "Buhler, J.P. and Lenstra, H.W. and Pomerance, C.", year = 1992, title = "Factoring integers with the number field sieve", note = "To appear"} @article{burmester, author = "Burmester, M.V.D. and Desmedt, Y.G. and Beth, T.", year = 1992, title = "Efficient zero-knowledge identification schemes for smart cards", journal = "Computer Journal", volume = 35, pages = "21--29"} @inproceedings{campbell, author = "Campbell, K.W. and Wiener, M.J.", year = 1993, title = "Proof that {DES} is not a group", booktitle = "Advances in Cryptology --- Crypto '92", publisher = "Springer-Verlag", address = "New York", note = "To appear"} @article{canfield, author = {Canfield, E.R. and Erd\"{o}s, P. and Pomerance, C.}, year = 1983, title = "On a problem of Oppenheim concerning `Factorisatio Numerorum'", journal = "J. Number Theory", volume = 17, pages = "1--28"} @manual{X.509, author = "{CCITT (Consultative Committee in International Telegraphy and Telephony)}", year = 1988, title = "Recommendation X.509: The Directory---Authentication Framework"} @manual{etebac, author = "{Comit\'{e} Fran\c{c}ais d'Organisation et de Normalisation Bancaire}", year = 1989, title = "Echanges T\'{e}l\'ematiques entre les Banques et leurs Clients, Standard ETEBAC 5, v1.1", address = "Paris"} @manual{gao-edi, author = "{Comptroller General of the United States}", year = 1991, month = "December 13,", title = "Matter of {National Institute of Standards and Technology} --- {Use} of Electronic Data Interchange Technology to Create Valid Obligations", note = "File B-245714"} @article{coppersmith-o-s, author = "Coppersmith, D. and Odlyzko, A.M. and Schroeppel, R.", year = 1986, title = "Discrete logarithms in {GF(p)}", journal = "Algorithmica", volume = 1, pages = "1--15"} @article{coppersmith, author = "Coppersmith, D.", year = 1987, title = "Cryptography", journal = "IBM J. Res. Develop.", volume = 31, number = 2, month = "March", pages = "244--248"} @techreport{improving-security-UNIX, author = "Curry, David A.", year = 1990, title = "Improving the Security of Your {UNIX} System", institution = "{SRI} International", number = "ITSTD-721-FR-90-21", address = "Menlo Park, CA", month = "April"} @techreport{davida, author = "Davida, G.", year = 1982, title = "Chosen signature cryptanalysis of the RSA public key cryptosystem", number = "TR-CS-82-2", institution = "Dept of EECS, University of Wisconsin, Milwaukee"} @book{davies-and-price, author = "Davies, D.W. and W.L. Price", year = 1984, title = "Security for Computer Networks: {An} Introduction to Data Security in Teleprocessing and Electronic Funds Transfer", publisher = "John Wiley \& Sons", address = "New York"} @manual{green-book, author = "{Department of Defense}", title = "{CSC-STD-002-85}: Department of Defense ({DoD}) Password Management Guidelines", year = 1985} @manual{orange-book, author = "{Department of Defense}", title = "{DoD 5200.28-STD}: Department of Defense ({DoD}) Trusted Computer System Evaluation Criteria ({TCSEC})", year = 1985} @article{diffie-hellman, author = "Diffie, W. and Hellman, M.E.", year = 1976, title = "New directions in cryptography", journal = "IEEE Transactions on Information Theory", volume = "IT-22", pages = "644--654"} @article{diffie-hellman-des, author = "Diffie, W. and Hellman, M.E.", year = 1977, title = "Exhaustive cryptanalysis of the {NBS Data Encryption Standard}", journal = "Computer", volume = 10, pages = "74--84"} @article{Diffie-Hellman-Intro, author = "Diffie, W. and M.E. Hellman", year = 1979, month = "March", title = "Privacy and authentication: {An} introduction to cryptography", journal = "Proceedings of the IEEE", volume = 67, number = 3, pages = "397--427"} @article{diffie-10yrs, author = "Diffie, W.", year = 1988, title = "The first ten years of public-key cryptography", journal = "Proceedings of the IEEE", volume = 76, pages = "560--577"} @article{elgamal, author = "ElGamal, T.", year = 1985, title = "A public-key cryptosystem and a signature scheme based on discrete logarithms", journal = "IEEE Transactions on Information Theory", volume = "IT-31", pages = "469--472"} @inproceedings{fiat, author = "Fiat, A. and Shamir, A.", year = 1987, title = "How to prove yourself: {Practical} solutions to identification and signature problems", booktitle = "Advances in Cryptology --- Crypto '86", pages = "186--194", publisher = "Springer-Verlag", address = "New York"} @article{goldwasser, author = "Goldwasser, S. and Micali, S.", year = 1984, title = "Probabilistic encryption", journal = "J. of Computer and System Sciences", volume = 28, pages = "270--299"} @inproceedings{gordon, author = "Gordon, D.M. and McCurley, K.S.", year = 1993, title = "Massively parallel computation of discrete logarithms", booktitle = "Advances in Cryptology --- Crypto '92", publisher = "Springer-Verlag", address = "New York", note = "To appear"} @inproceedings{haber, author = "Haber, S. and Stornetta, W.S.", year = 1991, title = "How to time-stamp a digital document", booktitle = "Advances in Cryptology --- Crypto '90", publisher = "Springer-Verlag", address = "New York", pages = "437--455"} @article{hastad, author = "Hastad, J.", year = 1988, title = "Solving simultaneous modular equations of low degree", journal = "SIAM J. Computing", volume = 17, pages = "336--241"} @article{hellman, author = "Hellman, M.E.", year = 1980, title = "A cryptanalytic time-memory trade off", journal = "IEEE Transactions on Information Theory", volume = "IT-26", pages = "401--406"} @manual{iso9796, author = "{International Standards Organization}", title = "IS 9796: Information technology, security techniques: digital signature scheme giving message recovery", address = "Geneva, Switzerland"} @book{kahn, author = "Kahn, D.", year = 1967, title = "The Codebreakers", publisher = "Macmillan Co.", address = "New York"} @article{kaliski, author = "Kaliski Jr., B.S. and Rivest, R.L. and Sherman, A.T.", year = 1988, title = "Is the Data Encryption Standard a group?", journal = "J. of Cryptology", volume = 1, pages = "3--36"} @article{Kaliski-one-way-permutations, author = "{Kaliski Jr.}, Burton S.", year = 1991, title = "One-Way Permutations on Elliptic Curves", journal = "Journal of Cryptology", volume = 3, pages = "187--199"} @manual{MD2, author = "Kaliski, B.", year = 1992, month = "April", title = "RFC 1319: The {MD2 Message-Digest Algorithm}", organization = "Internet Activities Board"} @manual{rfc1114, author = "Kent, S. and J. Linn", year = 1989, month = "August", title = "RFC 1114: Privacy Enhancement for Internet Electronic Mail: Part {II} -- Certificate-Based Key Management", organization = "Internet Activities Board"} @book{knuth, author = "Knuth, D.E.", year = 1981, title = "The Art of Computer Programming", edition = "2nd", volume = 2, publisher = "Addison-Wesley", address = "Reading, Mass."} @article{koblitz-ecc, author = "Koblitz, N.", year = 1987, title = "Elliptic curve cryptosystems", journal = "Mathematics of Computation", volume = 48, pages = "203--209"} @book{koblitz, author = "Koblitz, N.", year = 1987, title = "A Course in Number Theory and Cryptography", publisher = "Springer-Verlag", address = "New York"} @inproceedings{lai, author = "Lai, X. and Massey, J.L.", year = 1991, title = "A proposal for a new block encryption standard", booktitle = "Advances in Cryptology --- Eurocrypt '90", pages = "389--404", publisher = "Springer-Verlag", address = "Berlin"} @article{lamacchia, author = "LaMacchia, B.A. and Odlyzko, A.M.", year = 1991, title = "Computation of discrete logarithms in prime fields", journal = "Designs, Codes and Cryptography", volume = 1, pages = "47--62"} @article{landau, author = "Landau, S.", year = 1988, title = "Zero knowledge and the {Department of Defense}", journal = "Notices of the American Mathematical Society", volume = 35, pages = "5--12"} @article{lenstra-ecm, author = "Lenstra Jr., H.W.", year = 1987, title = "Factoring integers with elliptic curves", journal = "Ann. of Math.", volume = 126, pages = "649--673"} @incollection{lenstra-survey, author = "Lenstra, A.K. and Lenstra Jr., H.W.", year = 1990, title = "Algorithms in number theory", editor = "van Leeuwen, J.", booktitle = "Handbook of Theoretical Computer Science", volume = "A", publisher = "MIT Press/Elsevier", address = "Amsterdam"} @inproceedings{lenstra-nsf, author = "Lenstra, A.K. and Lenstra Jr., H.W. and Mannasse, M.S. and Pollard, J.M.", year = 1990, title = "The number field sieve", booktitle = "Proc. of the 22nd Annual ACM Symposium on the Theory of Computing", publisher = "ACM Press"} @inproceedings{lenstra-ppmpqs, author = "Lenstra, A.K. and Manasse, M.S.", year = 1991, title = "Factoring with two large primes", booktitle = "Advances in Cryptology --- Eurocrypt '90", pages = "72--82", publisher = "Springer-Verlag", address = "Berlin"} @manual{RFC-1113, author = "Linn, J.", year = 1989, month = "August", title = "RFC 1113: Privacy Enhancement for Internet Electronic Mail: Part {I} -- Message Encipherment and Authentication Procedures", organization = "Internet Activities Board"} @manual{RFC-1115, author = "Linn, J.", year = 1989, month = "August", title = "RFC 1115: Privacy Enhancement for Internet Electronic Mail: Part {III} -- Algorithms, Modes and Identifiers", organization = "Internet Activities Board"} @article{merkle-hellman, author = "Merkle, R.C. and Hellman, M.E.", year = 1978, title = "Hiding information and signatures in trapdoor knapsacks", journal = "IEEE Transactions on Information Theory", volume = "IT-24", pages = "525--530"} @article{merkle-hellman-multiple, author = "Merkle, R.C. and Hellman, M.E.", year = 1981, title = "On the security of multiple encryption", journal = "Communications of the ACM", volume = 24, pages = "465--467", month = "July"} @article{messmer, author = "Messmer, E.", year = 1992, title = "{NIST} stumbles on proposal for public-key encryption", journal = "Network World", volume = 9, number = 30, month = "July 27,"} @inproceedings{miller, author = "Miller, V.S.", year = 1986, title = "Use of elliptic curves in cryptography", booktitle = "Advances in Cryptology --- Crypto '85", pages = "417--426", publisher = "Springer-Verlag", address = "New York"} @manual{des-77, author = "{National Bureau of Standards}", year = 1977, month = "January", title = "FIPS Publication 46: Announcing the Data Encryption Standard"} @manual{des-modes, author = "{National Bureau of Standards}", year = 1980, title = "FIPS Publication 81: {DES} Modes of Operation", month = "December"} @manual{des-88, author = "{National Bureau of Standards}", year = 1988, month = "January", title = "FIPS Publication 46-1: Data Encryption Standard"} @manual{nist-dss, author = "{National Institute of Standards and Technology (NIST)}", year = 1992, title = "Publication {XX}: Announcement and Specifications for a Digital Signature Standard (DSS)", month = "August 19,"} @manual{nist-shs, author = "{National Institute of Standards and Technology (NIST)}", year = 1992, title = "Publication {YY}: Announcement and Specifications for a {Secure Hash Standard} (SHS)", month = "January 22,"} @article{dss-discuss, author = "{National Institute of Standards and Technology (NIST)}", year = 1992, title = "The {Digital Signature Standard}, proposal and discussion", journal = "Communications of the ACM", volume = 35, number = 7, pages = "36--54", month = "July"} @book{computers-at-risk, author = "National Research Council, System Security Study Committee and others", year = 1991, title = "Computers at Risk: {Safe} Computing in the Electronic Age", publisher = "National Academy Press", address = "Washington, DC"} @inproceedings{odlyzko, author = "Odlyzko, A.M.", year = 1984, title = "Discrete logarithms in finite fields and their cryptographic significance", booktitle = "Advances in Cryptology --- Eurocrypt '84", pages = "224--314", publisher = "Springer-Verlag", address = "Berlin"} @manual{oiw, author = "{OSI Implementors' Workshop}", year = 1992, title = "Draft Working Implementation Agreements For Open Systems Interconnection Protocols", publisher = "NIST", address = "Gaithersburg, Maryland", month = "June"} @article{pohlig-hellman-dlog, author = "Pohlig, S.C. and Hellman, M.E.", year = 1978, title = "An improved algorithm for computing logarithms over $GF(p)$ and its cryptographic significance", journal = "IEEE Transactions on Information Theory", volume = "IT-24", pages = "106--110"} @article{pollard1, author = "Pollard, J.", year = 1974, title = "Theorems of factorization and primality testing", journal = "Proc. Cambridge Philos. Soc.", volume = 76, pages = "521--528"} @article{pollard2, author = "Pollard, J.", year = 1975, title = "{Monte Carlo} method for factorization", journal = "BIT", volume = 15, pages = "331--334"} @techreport{rabin, author = "Rabin, M.O.", year = 1979, title = "Digitalized signatures as intractable as factorization", institution = "MIT", number = "MIT/LCS/TR-212"} @article{rsa, author = "Rivest, R.L. and A. Shamir and L. Adleman", year = 1978, month = "February", title = "A method for obtaining digital signatures and public-key cryptosystems", journal = "Communications of the ACM", volume = 21, number = 2, pages = "120--126"} @inproceedings{rivest-md4, author = "Rivest, R.L", year = 1991, title = "The {MD4} message digest algorithm", booktitle = "Advances in Cryptology --- Crypto '90", pages = "303--311", publisher = "Springer-Verlag", address = "New York"} @inproceedings{rivest-prob-prime, author = "Rivest, R.L.", year = 1990, title = "Finding four million random primes", booktitle = "Advances in Cryptology --- Crypto '90", pages = "625--626", publisher = "Springer-Verlag", address = "New York"} @incollection{rivest-survey, author = "Rivest, R.L.", year = 1990, title = "Cryptography", editor = "van Leeuwen, J.", booktitle = "Handbook of Theoretical Computer Science", volume = "A", publisher = "MIT Press/Elsevier", address = "Amsterdam"} @manual{rfc-md5, author = "Rivest, R.L.", year = 1992, title = "{RFC} 1321: The {MD5 Message-Digest Algorithm}", month = "April", organization = "Internet Activities Board"} @article{rivest-dss-response, author = "Rivest, R.L.", year = 1992, title = "Response to {NIST}'s Proposal", journal = "Communications of the ACM", volume = 35, pages = "41--47", month = "July"} @manual{PKCS-5, author = "{RSA Data Security, Inc.}", year = 1991, month = "June", title = "PKCS \#5: Password-Based Encryption Standard", note = "Version 1.4"} @book{computer-security-basics, author = "Russell, Deborah and G.T. Gangemi Sr.", year = 1991, title = "Computer Security Basics", publisher = "O'Reilly and Associates", address = "Sebastopol, CA"} @inproceedings{schnorr, author = "Schnorr, C.P.", year = 1990, title = "Efficient identification and signatures for smart cards", booktitle = "Advances in Cryptology --- Crypto '89", pages = "239--251", publisher = "Springer-Verlag", address = "New York"} @book{protecting-information, author = "Schweitzer, James A.", year = 1983, title = "Protection Information in the Electronic Workplace: A Guide for Managers", publisher = "Prentice-Hall", address = "Reston, VA"} @article{silverman, author = "Silverman, R.D.", year = 1987, title = "The multiple polynomial quadratic sieve", journal = "Math. Comp.", volume = 48, pages = "329--339"} @article{smid-des, author = "Smid, M.E. and Branstad, D.K.", year = 1988, title = "The {Data Encryption Standard}: {Past} and future", journal = "Proceedings of the IEEE", volume = 76, pages = "550--559"} @inproceedings{smid, author = "Smid, M.E. and Branstad, D.K.", year = 1993, title = "Response to comments on the {NIST} proposed {Digital Signature Standard}", booktitle = "Advances in Cryptology --- Crypto '92", publisher = "Springer-Verlag", note = "To appear"} @manual{australia, author = "{Standards Australia}", year = 1990, title = "AS 2805.6.5.3: Electronic Funds Transfer --- Key Management"} @book{cuckoo's-egg, author = "Stoll, Cliff", year = 1989, title = "The Cuckoo's Egg: Tracing a Spy Through the Maze of Computer Espionage", publisher = "Doubleday", address = "New York"} @article{wiener, author = "Wiener, M.J.", year = 1990, title = "Cryptanalysis of short {RSA} secret exponents", journal = "IEEE Trans. Information Theory", volume = 36, pages = "553--558"} From hughes at soda.berkeley.edu Tue Oct 6 18:30:07 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 6 Oct 92 18:30:07 PDT Subject: Nuts & Acorns In-Reply-To: <9210062244.AA07304@newsu.shearson.com> Message-ID: <9210070137.AA15880@soda.berkeley.edu> Perry: >This does mean that a lot of the time until people have built up >catenative assembleges of keys sufficent to form a "chain of trust" >for unknown people that they will simply have to do without >certification of the other person's identity. Isn't that the way life >usually is, though? In large part the electronic environment is already pseudonymous. I don't know most Usenet posters personally and never will. I have no need to personally verify their identities; in fact, I don't even want to. But for someone I'm going to deal with over a period of time, I do want to make sure that it's the same person I'm dealing with each time. And if I never happen to meet this person face to face, or need to know anything about this person as a physical being, so be it. All I really care about is persistence, not identity. In the elctronic world, all you have are persistent pseudonyms. Most of them, true, are still linked to physical people, but there is no particular reason why that need continue. I think the changeover point will be this. As soon as there is money flowing through the networks which is tied only to pseudonyms and not to physical people, then you'll see a _lot_ more virtual-only identities. When you can conduct business and get paid for it, there's a big difference. When some of your data has negotiable cash value, you'll see privacy and security get *important*. And most of these identities will have regular sounding names. Handles, a la the underground, are more a mark of social identity than of anonymity. The best camouflage is not to draw attention to yourself. When most of the world is personal, look personal. Who will ever know? Eric From hh at soda.berkeley.edu Tue Oct 6 22:34:13 1992 From: hh at soda.berkeley.edu (Eric Hollander) Date: Tue, 6 Oct 92 22:34:13 PDT Subject: Nuts & Acorns In-Reply-To: <9210070137.AA15880@soda.berkeley.edu> Message-ID: <9210070541.AA23855@soda.berkeley.edu> >In the elctronic world, all you have are persistent pseudonyms. Most >of them, true, are still linked to physical people, but there is no >particular reason why that need continue. Instead of thinking of keys as things belonging to people, we can think of people as things associated with keys. In fact, we just need to shift the focus to be entirely on the keys, and leave the people out of it. e From Tom.Jennings at f111.n125.z1.FIDONET.ORG Wed Oct 7 16:46:07 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Wed, 7 Oct 92 16:46:07 PDT Subject: introducers Message-ID: <2715.2AD37337@fidogate.FIDONET.ORG> U> Detection of tampering is plenty good enough, I think, for U> a _network_ policy of key distribution. For most people, U> it will work fine. I guess I had to come at this from the backside. You are right. Accepting keys over the network will provide reasonably well-sealed envelopes. It won't provide notarized, hand-delivered security, but that's not what's needed *usually*. U> For personal use, for people I know, I'm going to rely on U> personally U> exchanged keys. Exactly. * Origin: World Power Systems / FidoNews (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 whitaker at eternity.demon.co.uk Thu Oct 8 01:04:18 1992 From: whitaker at eternity.demon.co.uk (Russell E. Whitaker) Date: Thu, 8 Oct 92 01:04:18 PDT Subject: Hammill on public key Message-ID: <1439@eternity.demon.co.uk> FROM CROSSBOWS TO CRYPTOGRAPHY: THWARTING THE STATE VIA TECHNOLOGY Given at the Future of Freedom Conference, November 1987 You know, technology--and particularly computer technology--has often gotten a bad rap in Libertarian cir- cles. We tend to think of Orwell's 1984, or Terry Gilliam's Brazil, or the proximity detectors keeping East Berlin's slave/citizens on their own side of the border, or the so- phisticated bugging devices Nixon used to harass those on his "enemies list." Or, we recognize that for the price of a ticket on the Concorde we can fly at twice the speed of sound, but only if we first walk thru a magnetometer run by a government policeman, and permit him to paw thru our be- longings if it beeps. But I think that mind-set is a mistake. Before there were cattle prods, governments tortured their prisoners with clubs and rubber hoses. Before there were lasers for eavesdropping, governments used binoculars and lip-readers. Though government certainly uses technology to oppress, the evil lies not in the tools but in the wielder of the tools. In fact, technology represents one of the most promis- ing avenues available for re-capturing our freedoms from those who have stolen them. By its very nature, it favors the bright (who can put it to use) over the dull (who can- not). It favors the adaptable (who are quick to see the merit of the new( over the sluggish (who cling to time- tested ways). And what two better words are there to de- scribe government bureaucracy than "dull" and "sluggish"? One of the clearest, classic triumphs of technology over tyranny I see is the invention of the man-portable crossbow. With it, an untrained peasant could now reliably and lethally engage a target out to fifty meters--even if that target were a mounted, chain-mailed knight. (Unlike the longbow, which, admittedly was more powerful, and could get off more shots per unit time, the crossbow required no formal training to utilize. Whereas the longbow required elaborate visual, tactile and kinesthetic coordination to achieve any degree of accuracy, the wielder of a crossbow could simply put the weapon to his shoulder, sight along the arrow itself, and be reasonably assured of hitting his tar- get.) Moreover, since just about the only mounted knights likely to visit your average peasant would be government soldiers and tax collectors, the utility of the device was plain: With it, the common rabble could defend themselves not only against one another, but against their governmental masters. It was the medieval equivalent of the armor- piercing bullet, and, consequently, kings and priests (the medieval equivalent of a Bureau of Alcohol, Tobacco and Crossbows) threatened death and excommunication, respec- tively, for its unlawful possession. Looking at later developments, we see how technology like the firearm--particularly the repeating rifle and the handgun, later followed by the Gatling gun and more advanced machine guns--radically altered the balance of interpersonal and inter-group power. Not without reason was the Colt .45 called "the equalizer." A frail dance-hall hostess with one in her possession was now fully able to protect herself against the brawniest roughneck in any saloon. Advertise- ments for the period also reflect the merchandising of the repeating cartridge rifle by declaring that "a man on horseback, armed with one of these rifles, simply cannot be captured." And, as long as his captors were relying upon flintlocks or single-shot rifles, the quote is doubtless a true one. Updating now to the present, the public-key cipher (with a personal computer to run it) represents an equiv- alent quantum leap--in a defensive weapon. Not only can such a technique be used to protect sensitive data in one's own possession, but it can also permit two strangers to ex- change information over an insecure communications channel--a wiretapped phone line, for example, or skywriting, for that matter)--without ever having previously met to exchange cipher keys. With a thousand-dollar com- puter, you can create a cipher that a multi-megabuck CRAY X-MP can't crack in a year. Within a few years, it should be economically feasible to similarly encrypt voice communi- cations; soon after that, full-color digitized video images. Technology will not only have made wiretapping obsolete, it will have totally demolished government's control over in- formation transfer. I'd like to take just a moment to sketch the mathemat- ics which makes this principle possible. This algorithm is called the RSA algorithm, after Rivest, Shamir, and Adleman who jointly created it. Its security derives from the fact that, if a very large number is the product of two very large primes, then it is extremely difficult to obtain the two prime factors from analysis of their product. "Ex- tremely" in the sense that if primes p and q have 100 digits apiece, then their 200-digit product cannot in gen- eral be factored in less than 100 years by the most powerful computer now in existence. The "public" part of the key consists of (1) the prod- uct pq of the two large primes p and q, and (2) one fac- tor, call it x , of the product xy where xy = {(p-1) * (q-1) + 1}. The "private" part of the key consists of the other factor y. Each block of the text to be encrypted is first turned into an integer--either by using ASCII, or even a simple A=01, B=02, C=03, ... , Z=26 representation. This integer is then raised to the power x (modulo pq) and the resulting integer is then sent as the encrypted message. The receiver decrypts by taking this integer to the (secret) power y (modulo pq). It can be shown that this process will always yield the original number started with. What makes this a groundbreaking development, and why it is called "public-key" cryptography," is that I can openly publish the product pq and the number x , while keeping secret the number y --so that anyone can send me an encrypted message, namely x a (mod pq) , but only I can recover the original message a , by taking what they send, raising it to the power y and taking the result (mod pq). The risky step (meeting to exchange cipher keys) has been eliminated. So people who may not even trust each other enough to want to meet, may still reliably ex- change encrypted messages--each party having selected and disseminated his own pq and his x , while maintaining the secrecy of his own y. Another benefit of this scheme is the notion of a "dig- ital signature," to enable one to authenticate the source of a given message. Normally, if I want to send you a message, I raise my plaintext a to your x and take the result (mod your pq) and send that. However, if in my message, I take the plaintext a and raise it to my (secret) power y , take the result (mod my pq), then raise that result to your x (mod your pq) and send this, then even after you have normally "decrypted" the message, it will still look like garbage. However, if you then raise it to my public power x , and take the result (mod my public pq ), so you will not only recover the ori- ginal plaintext message, but you will know that no one but I could have sent it to you (since no one else knows my secret y). And these are the very concerns by the way that are to- day tormenting the Soviet Union about the whole question of personal computers. On the one hand, they recognize that American schoolchildren are right now growing up with com- puters as commonplace as sliderules used to be--more so, in fact, because there are things computers can do which will interest (and instruct) 3- and 4-year-olds. And it is pre- cisely these students who one generation hence will be going head-to-head against their Soviet counterparts. For the Soviets to hold back might be a suicidal as continuing to teach swordsmanship while your adversaries are learning ballistics. On the other hand, whatever else a personal computer may be, it is also an exquisitely efficient copying machine--a floppy disk will hold upwards of 50,000 words of text, and can be copied in a couple of minutes. If this weren't threatening enough, the computer that performs the copy can also encrypt the data in a fashion that is all but unbreakable. Remember that in Soviet society publicly ac- cessible Xerox machines are unknown. (The relatively few copying machines in existence are controlled more inten- sively than machine guns are in the United States.) Now the "conservative" position is that we should not sell these computers to the Soviets, because they could use them in weapons systems. The "liberal" position is that we should sell them, in the interests of mutual trade and cooperation--and anyway, if we don't make the sale, there will certainly be some other nation willing to. For my part, I'm ready to suggest that the Libertarian position should be to give them to the Soviets for free, and if necessary, make them take them . . . and if that doesn't work load up an SR-71 Blackbird and air drop them over Moscow in the middle of the night. Paid for by private sub- scription, of course, not taxation . . . I confess that this is not a position that has gained much support among members of the conventional left-right political spectrum, but, af- ter all, in the words of one of Illuminatus's characters, we are political non-Euclideans: The shortest distance to a particular goal may not look anything like what most people would consider a "straight line." Taking a long enough world-view, it is arguable that breaking the Soviet govern- ment monopoly on information transfer could better lead to the enfeeblement and, indeed, to the ultimate dissolution of the Soviet empire than would the production of another dozen missiles aimed at Moscow. But there's the rub: A "long enough" world view does suggest that the evil, the oppressive, the coercive and the simply stupid will "get what they deserve," but what's not immediately clear is how the rest of us can escape being killed, enslaved, or pauperized in the process. When the liberals and other collectivists began to at- tack freedom, they possessed a reasonably stable, healthy, functioning economy, and almost unlimited time to proceed to hamstring and dismantle it. A policy of political gradualism was at least conceivable. But now, we have patchwork crazy-quilt economy held together by baling wire and spit. The state not only taxes us to "feed the poor" while also inducing farmers to slaughter milk cows and drive up food prices--it then simultaneously turns around and sub- sidizes research into agricultural chemicals designed to in- crease yields of milk from the cows left alive. Or witness the fact that a decline in the price of oil is considered as potentially frightening as a comparable increase a few years ago. When the price went up, we were told, the economy risked collapse for for want of energy. The price increase was called the "moral equivalent of war" and the Feds swung into action. For the first time in American history, the speed at which you drive your car to work in the morning be- came an issue of Federal concern. Now, when the price of oil drops, again we risk problems, this time because Ameri- can oil companies and Third World basket-case nations who sell oil may not be able to ever pay their debts to our grossly over-extended banks. The suggested panacea is that government should now re-raise the oil prices that OPEC has lowered, via a new oil tax. Since the government is seeking to raise oil prices to about the same extent as OPEC did, what can we call this except the "moral equivalent of civil war--the government against its own people?" And, classically, in international trade, can you imag- ine any entity in the world except a government going to court claiming that a vendor was selling it goods too cheaply and demanding not only that that naughty vendor be compelled by the court to raise its prices, but also that it be punished for the act of lowering them in the first place? So while the statists could afford to take a couple of hundred years to trash our economy and our liberties--we certainly cannot count on having an equivalent period of stability in which to reclaim them. I contend that there exists almost a "black hole" effect in the evolution of nation-states just as in the evolution of stars. Once free- dom contracts beyond a certain minimum extent, the state warps the fabric of the political continuum about itself to the degree that subsequent re-emergence of freedom becomes all but impossible. A good illustration of this can be seen in the area of so-called "welfare" payments. When those who sup at the public trough outnumber (and thus outvote) those whose taxes must replenish the trough, then what possible choice has a democracy but to perpetuate and expand the tak- ing from the few for the unearned benefit of the many? Go down to the nearest "welfare" office, find just two people on the dole . . . and recognize that between them they form a voting bloc that can forever outvote you on the question of who owns your life--and the fruits of your life's labor. So essentially those who love liberty need an "edge" of some sort if we're ultimately going to prevail. We obvi- ously can't use the altruists' "other-directedness" of "work, slave, suffer, sacrifice, so that next generation of a billion random strangers can live in a better world." Recognize that, however immoral such an appeal might be, it is nonetheless an extremely powerful one in today's culture. If you can convince people to work energetically for a "cause," caring only enough for their personal welfare so as to remain alive enough and healthy enough to continue working--then you have a truly massive reservoir of energy to draw from. Equally clearly, this is just the sort of ap- peal which tautologically cannot be utilized for egoistic or libertarian goals. If I were to stand up before you tonight and say something like, "Listen, follow me as I enunciate my noble "cause," contribute your money to support the "cause," give up your free time to work for the "cause," strive selflessly to bring it about, and then (after you and your children are dead) maybe your children's children will actu- ally live under egoism"--you'd all think I'd gone mad. And of course you'd be right. Because the point I'm trying to make is that libertarianism and/or egoism will be spread if, when, and as, individual libertarians and/or egoists find it profitable and/or enjoyable to do so. And probably only then. While I certainly do not disparage the concept of poli- tical action, I don't believe that it is the only, nor even necessarily the most cost-effective path toward increasing freedom in our time. Consider that, for a fraction of the investment in time, money and effort I might expend in try- ing to convince the state to abolish wiretapping and all forms of censorship--I can teach every libertarian who's in- terested how to use cryptography to abolish them unilaterally. There is a maxim--a proverb--generally attributed to the Eskimoes, which very likely most Libertarians have al- ready heard. And while you likely would not quarrel with the saying, you might well feel that you've heard it often enough already, and that it has nothing further to teach us, and moreover, that maybe you're even tired of hearing it. I shall therefore repeat it now: If you give a man a fish, the saying runs, you feed him for a day. But if you teach a man how to fish, you feed him for a lifetime. Your exposure to the quote was probably in some sort of a "workfare" vs. "welfare" context; namely, that if you genuinely wish to help someone in need, you should teach him how to earn his sustenance, not simply how to beg for it. And of course this is true, if only because the next time he is hungry, there might not be anybody around willing or even able to give him a fish, whereas with the information on how to fish, he is completely self sufficient. But I submit that this exhausts only the first order content of the quote, and if there were nothing further to glean from it, I would have wasted your time by citing it again. After all, it seems to have almost a crypto-altruist slant, as though to imply that we should structure our ac- tivities so as to maximize the benefits to such hungry beggars as we may encounter. But consider: Suppose this Eskimo doesn't know how to fish, but he does know how to hunt walruses. You, on the other hand, have often gone hungry while traveling thru walrus country because you had no idea how to catch the damn things, and they ate most of the fish you could catch. And now suppose the two of you decide to exchange information, bartering fishing knowledge for hunting knowledge. Well, the first thing to observe is that a transaction of this type categorically and unambiguously refutes the Marxist premise that every trade must have a "winner" and a "loser;" the idea that if one person gains, it must necessarily be at the "expense" of another person who loses. Clearly, under this scenario, such is not the case. Each party has gained some- thing he did not have before, and neither has been dimin- ished in any way. When it comes to exchange of information (rather than material objects) life is no longer a zero-sum game. This is an extremely powerful notion. The "law of diminishing returns," the "first and second laws of thermodynamics"--all those "laws" which constrain our possi- bilities in other contexts--no longer bind us! Now that's anarchy! Or consider another possibility: Suppose this hungry Eskimo never learned to fish because the ruler of his nation-state had decreed fishing illegal. Because fish contain dangerous tiny bones, and sometimes sharp spines, he tells us, the state has decreed that their consumption--and even their possession--are too hazardous to the people's health to be permitted . . . even by knowledgeable, willing adults. Perhaps it is because citizens' bodies are thought to be government property, and therefore it is the function of the state to punish those who improperly care for govern- ment property. Or perhaps it is because the state gener- ously extends to competent adults the "benefits" it provides to children and to the mentally ill: namely, a full-time, all-pervasive supervisory conservatorship--so that they need not trouble themselves with making choices about behavior thought physically risky or morally "naughty." But, in any case, you stare stupefied, while your Eskimo informant re- lates how this law is taken so seriously that a friend of his was recently imprisoned for years for the crime of "pos- session of nine ounces of trout with intent to distribute." Now you may conclude that a society so grotesquely oppressive as to enforce a law of this type is simply an affront to the dignity of all human beings. You may go far- ther and decide to commit some portion of your discretion- ary, recreational time specifically to the task of thwarting this tyrant's goal. (Your rationale may be "altruistic" in the sense of wanting to liberate the oppressed, or "egoistic" in the sense of proving you can outsmart the oppressor--or very likely some combination of these or per- haps even other motives.) But, since you have zero desire to become a martyr to your "cause," you're not about to mount a military campaign, or even try to run a boatload of fish through the blockade. However, it is here that technology--and in particular in- formation technology--can multiply your efficacy literally a hundredfold. I say "literally," because for a fraction of the effort (and virtually none of the risk) attendant to smuggling in a hundred fish, you can quite readily produce a hundred Xerox copies of fishing instructions. (If the tar- geted government, like present-day America, at least permits open discussion of topics whose implementation is re- stricted, then that should suffice. But, if the government attempts to suppress the flow of information as well, then you will have to take a little more effort and perhaps write your fishing manual on a floppy disk encrypted according to your mythical Eskimo's public-key parameters. But as far as increasing real-world access to fish you have made genuine nonzero headway--which may continue to snowball as others re-disseminate the information you have provided. And you have not had to waste any of your time trying to convert id- eological adversaries, or even trying to win over the unde- cided. Recall Harry Browne's dictum from "Freedom in an Unfree World" that the success of any endeavor is in general inversely proportional to the number of people whose persua- sion is necessary to its fulfilment. If you look at history, you cannot deny that it has been dramatically shaped by men with names like Washington, Lincoln, . . . Nixon . . . Marcos . . . Duvalier . . . Khadaffi . . . and their ilk. But it has also been shaped by people with names like Edison, Curie, Marconi, Tesla and Wozniak. And this latter shaping has been at least as per- vasive, and not nearly so bloody. And that's where I'm trying to take The LiberTech Project. Rather than beseeching the state to please not en- slave, plunder or constrain us, I propose a libertarian net- work spreading the technologies by which we may seize freedom for ourselves. But here we must be a bit careful. While it is not (at present) illegal to encrypt information when government wants to spy on you, there is no guarantee of what the fu- ture may hold. There have been bills introduced, for exam- ple, which would have made it a crime to wear body armor when government wants to shoot you. That is, if you were to commit certain crimes while wearing a Kevlar vest, then that fact would constitute a separate federal crime of its own. This law to my knowledge has not passed . . . yet . . . but it does indicate how government thinks. Other technological applications, however, do indeed pose legal risks. We recognize, for example, that anyone who helped a pre-Civil War slave escape on the "underground railroad" was making a clearly illegal use of technology--as the sovereign government of the United States of America at that time found the buying and selling of human beings quite as acceptable as the buying and selling of cattle. Simi- larly, during Prohibition, anyone who used his bathtub to ferment yeast and sugar into the illegal psychoactive drug, alcohol--the controlled substance, wine--was using technol- ogy in a way that could get him shot dead by federal agents for his "crime"--unfortunately not to be restored to life when Congress reversed itself and re-permitted use of this drug. So . . . to quote a former President, un-indicted co- conspirator and pardoned felon . . . "Let me make one thing perfectly clear:" The LiberTech Project does not advocate, participate in, or conspire in the violation of any law--no matter how oppressive, unconstitutional or simply stupid such law may be. It does engage in description (for educa- tional and informational purposes only) of technological processes, and some of these processes (like flying a plane or manufacturing a firearm) may well require appropriate li- censing to perform legally. Fortunately, no license is needed for the distribution or receipt of information it- self. So, the next time you look at the political scene and despair, thinking, "Well, if 51% of the nation and 51% of this State, and 51% of this city have to turn Libertarian before I'll be free, then somebody might as well cut my goddamn throat now, and put me out of my misery"--recognize that such is not the case. There exist ways to make your- self free. If you wish to explore such techniques via the Project, you are welcome to give me your name and address--or a fake name and mail drop, for that matter--and you'll go on the mailing list for my erratically-published newsletter. Any friends or acquaintances whom you think would be interested are welcome as well. I'm not even asking for stamped self- addressed envelopes, since my printer can handle mailing la- bels and actual postage costs are down in the noise compared with the other efforts in getting an issue out. If you should have an idea to share, or even a useful product to plug, I'll be glad to have you write it up for publication. Even if you want to be the proverbial "free rider" and just benefit from what others contribute--you're still welcome: Everything will be public domain; feel free to copy it or give it away (or sell it, for that matter, 'cause if you can get money for it while I'm taking full-page ads trying to give it away, you're certainly entitled to your capitalist profit . . .) Anyway, every application of these principles should make the world just a little freer, and I'm certainly willing to underwrite that, at least for the forseeable fu- ture. I will leave you with one final thought: If you don't learn how to beat your plowshares into swords before they outlaw swords, then you sure as HELL ought to learn before they outlaw plowshares too. --Chuck Hammill THE LIBERTECH PROJECT 3194 Queensbury Drive Los Angeles, California 90064 310-836-4157 [The above LiberTech address was updated June 1992, with the permission of Chuck Hammill, by: 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) [.sig revised 11 September 1992 /// Send mail to eternity node] -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAiqwg10AAAEEAMVNMI766ljeuW01xqXKYYV5lmDPvb+6dCQK3m1iBQdan0no pm35j1DIRp3UJZogAe5eimsQg1TALDhTq310OZs9+L6B/HxeX3+4BadIDad4g+xI lvaFY1Ut/hMdZNkw0tzNZOdUPiO4jYIyirReAUiMCm6jXzkTRITj7/vxxWtPAAUR tDNSdXNzZWxsIEUuIFdoaXRha2VyIDx3aGl0YWtlckBldGVybml0eS5kZW1vbi5j by51az4= =LOCL -----END PGP PUBLIC KEY BLOCK----- From whitaker at eternity.demon.co.uk Thu Oct 8 07:04:56 1992 From: whitaker at eternity.demon.co.uk (Russell E. Whitaker) Date: Thu, 8 Oct 92 07:04:56 PDT Subject: Subscribe Message-ID: <1480@eternity.demon.co.uk> SUBSCRIBE To human overseer: Please subscribe me to the cypherpunks list... Thanks, 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) [.sig revised 1 October 1992 /// Send mail to eternity node] -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAiqwg10AAAEEAMVNMI766ljeuW01xqXKYYV5lmDPvb+6dCQK3m1iBQdan0no pm35j1DIRp3UJZogAe5eimsQg1TALDhTq310OZs9+L6B/HxeX3+4BadIDad4g+xI lvaFY1Ut/hMdZNkw0tzNZOdUPiO4jYIyirReAUiMCm6jXzkTRITj7/vxxWtPAAUR tDNSdXNzZWxsIEUuIFdoaXRha2VyIDx3aGl0YWtlckBldGVybml0eS5kZW1vbi5j by51az4= =LOCL -----END PGP PUBLIC KEY BLOCK----- From hughes Thu Oct 8 08:41:35 1992 From: hughes (Eric Hughes) Date: Thu, 8 Oct 92 08:41:35 PDT Subject: Subscribe In-Reply-To: <1480@eternity.demon.co.uk> Message-ID: <9210081541.AA03134@toad.com> You are subscribed. Next time, please use the cypherpunks-request at toad.com address for administrative matters. Tell your friends this as well. Your request got sent out to the whole list, not a tragedy, but an annoyance. I met Max More at a party about a month ago. I suspect he might be interested in the list. Do you have an e-mail address for him? Eric From hughes at soda.berkeley.edu Thu Oct 8 08:57:23 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Thu, 8 Oct 92 08:57:23 PDT Subject: Subscriptions, etc. In-Reply-To: <9210081541.AA03134@toad.com> Message-ID: <9210081604.AA15870@soda.berkeley.edu> Yow! I'm a hypocrite! Now _I_ forgot to look at the reply line. Damn. Diligence, diligence. -------------------------------------------- In other news, the list membership is up to 60 people and one local newsgroup gateway. I have five more to add, some of whose addresses I have to find out. Eric From whitaker at eternity.demon.co.uk Thu Oct 8 09:15:02 1992 From: whitaker at eternity.demon.co.uk (Russell E. Whitaker) Date: Thu, 8 Oct 92 09:15:02 PDT Subject: Apologies for newbie mistake Message-ID: <1499@eternity.demon.co.uk> I apologize for having sent my SUBSCRIBE request to the list-at-large... I'm setting up a new mail client, and {{excuse}mumble}. 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) [.sig revised 1 October 1992 /// Send mail to eternity node] -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAiqwg10AAAEEAMVNMI766ljeuW01xqXKYYV5lmDPvb+6dCQK3m1iBQdan0no pm35j1DIRp3UJZogAe5eimsQg1TALDhTq310OZs9+L6B/HxeX3+4BadIDad4g+xI lvaFY1Ut/hMdZNkw0tzNZOdUPiO4jYIyirReAUiMCm6jXzkTRITj7/vxxWtPAAUR tDNSdXNzZWxsIEUuIFdoaXRha2VyIDx3aGl0YWtlckBldGVybml0eS5kZW1vbi5j by51az4= =LOCL -----END PGP PUBLIC KEY BLOCK----- From Tom.Jennings at f111.n125.z1.FIDONET.ORG Thu Oct 8 18:48:59 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Thu, 8 Oct 92 18:48:59 PDT Subject: Subscribe Message-ID: <2733.2AD49634@fidogate.FIDONET.ORG> My public key. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQBNAirHIV8AAAECAOE6hyvBZUslVOgi12u6d7/6yMIXX4aKIRcfV3wa/ysHl+ul d4agC1YW+YimYeA+/bXOBxH/Y/KRzT/tLvUlcRcABRG0MVRvbSBKZW5uaW5ncyA8 dG9takBmaWRvc3cuZmlkb25ldC5vcmcsIDE6MTI1LzExMT4= =dADc -----END PGP PUBLIC KEY BLOCK----- My public key ring, signed with my secret key: -----BEGIN PGP MESSAGE----- Version: 2.0 owF1l3VU0/v/xzeGtCBwQUJ0ICI5OqUbJEYb1IQx5tgGYwMpBamBpNJggAEoKiAq HVe6Q0pC8tKO0tH8JlcO9/zO+f7zOe/P+4/3eb8fz+erogA2VKcAol9lmDs0ViA/ L3mdBQIDmKkA47t9zTtBybMxWgRHMzFr/pgLHXIsVYQW+yWb94wbYdAYS7nw5gXk tzbBbHO1QSuNTpl6zzKU6rVWOs0L/b1mEemAWCrRwlAHAABIDWgwlYrbWbw2XoaW b3zZCgv3S3HuqqopxwsyjKNvnaK98dRo/hV6Ox7arP/466UMMPCHYzTqTKh1rbiS 1ZsgvHKm2lZ1yF6go9O90lO5hqdz74QuG6b8CnexkThg53Mdluod7XCds1a/WBp7 Xya6xBFoGMOAee6kzK4bNk3aXWtAmQNOsRYCtUpkLQne3nAPD7AeBGznjsTDUHAc WNX3z0oTjofjMEi8H8QVjsZiIC5YCAGlXggERf1GdEb0q7TgCSIoBVHmkotkeXv7 wBdZ+vc9HTNJVPM5qilvhegDL2Z7KQqkrg2KqvY62YPiIgH0LUX1U2w40Y0H7dkP 6IQU8pEIZ2u+QmBkOsCUSrQCLkWhRAWoFd3nfF4WwjkvsHSRCOBxjHXGkt84zP0z 3E4S/fmqExOsl8b8/iwnQ3WehZ0f3oKXv9ico4CslM61J1fdzp1ADzjFXgjUKxHV xsFcwToQsKmLDgyH9wOruilIK0Iw0jLyEH9piBvSFYuB4yFYHOI/j+s1en7yuBYG 4KHRaiu3KqlnBPkWqz/et99F20etH4q0Vfhp6qzazcxcSQph6Cvc1aIKK+zVi6vJ mnip4yXJHMydlhEbQtXLPdp99DiKBT69wx5ZoC290jPdNzgivHs0yK4l/nzkfq0f 1BLPyS17+2Yo4m6DWNncJsekp2Yy6Lai6an4GOI9Uufyt6oJDn5W9zjaJNvUWFTz 5f26W/QMjJy9mbJBqtG1+yCSfOD7gyIFe9ZT2RduNXjs3ezVZTOSihVLHI+9d7ND QHaXptgqKk1Hudju+5EFKHCs3GG+GPBVCNiCgMRgKGwU5eWlKHCkFChwNP8XHNUT OGZtwD0GI70XrQ9scaP9V1Bhwqki38qz/OueQwMg/PxpyQJVwj+5lLkftublBGrL B8jTaESJNXgtMcdPU13YNCMWddocUuBEAZJ/H909OIxGK1l6X824DgQWeIMO9Ssz B+x+yVuwfiTr1vYvGrVofdLjWYmWHJHJA9pn7yTowWSVW7q7aiIm74w4zOEGdPvq cVlgj/vJXjrL5c/O1PCeU7s1J/B1FdgXdCCfwOv9md592Tk9eVcNkkd+I7/PBR9m nQ27cu7Sd+OQIMIAW4MgZ3HlpOE9Sc1oVMACDJNSCAw/0q1D4uBItw8yzSNTRVVW lyzWIxhXUMMLLEB3wdB8odektdZtldT7KtzskVy2LORr6UK6XdyY6UJrZjXjZjnH tH3hUO2FEV5pwbJgIjzaN2YoyT863BMsmPlB5FbllWdmQcm8HDFUdNl5jz+sqJKt 1Z8YM9x8+KLQwdwZWmwqnHhM5Y9uwjruOKQ3HuvpTglZ7X8DV1pFVlFOUlruf6oG OlHtLjfw0PLjZG/BCzK1SI1vhjiPNnTZznJmse6cOACATdLs5ZG468ZB4Js+75TK XrTchGTiYY6XPI1hSssa5705G1GkQ3+iWodLK5fdzFjRp9KLQKBAHOhAnriXXJQy FVIkN43v9napcZDl8y8oXj6IW9mj3mfJnmWEpRo79F+OGzdee62QCqEb7is3LKo5 WLxjvWZ0ge5qOAF7jb0iSymCdlguFyhG6nFWJnF2pEz3Y+Yrg/9Cv3vtzvH99kWR LsyZogpGUaXxlehAKV2mZ1E9MpWYSzZ2YW8oqh1fTVHsxFDdAGpAiBqogyeyhm9W newGI52/mRrTCHwwHttXWkTeY+F+5/bMGPDWwVryS/reEoeDFOOFpyy58ULzLP4s aqgLS09Sc+AVfTg9dpsuZkHHAwdnSY2cH60/eCdo32KCmdBXP2x0SqNyBoP4Ncf2 y4Q0xi8h9MY5tRRrt00ULeEPH/g9gm8eG6oRnnhkqOokL5Uh1Wx7bbnlgc2R+tux A2MDlQ5Fm9+5C8jNYtSTgRsLL/VmGBwjuvQ1Enerrpfq5IARUjliVfiVImx2z/6D zDqJnzwrUn8F8U7Evghd3rE0RQwtrxdDYu/+uO2J3resQRh64qM3LjcCWXP753Oc xy3+ubuE8D0W7I+h5AyugqEwFzgYfPNfH8kogFURKE/KlqabjAIEQ9n7/+nS4chc /2JuYTzBvC5IDUhq5jHkNs1ZbJ8dDOYWncgvzX2/edjrbUy/sYDAF4qsVCjEx7IW uZ0TNVdX6TCydOeSJeQ2xRv7OFQvZpIj6ek8BPGetr4IuXq6r9PyXMvYxz5EIYc1 jR+wxzf621YCnFFXF06nQocYM4WfJT4ZSOUaXco73A7IFYfSWfON24h/OHLAke+b 9dJPfG9fADzUbD9dmcokouzeHcA8uiLxmH4f6VbBa3ul+cKGrRT1evFHTvbMT+rD aiUp4irCTSv1xb8mmk/jsuzvWNIl2xqfQx6n8sJa6JGCn5QDV6inTilsxRn/uPcQ LFYM7rPOiN8Y1iaJlSWNJKQMvtbf1x1fHP7UuMY2FJNlzy6VuPD+RgmmQ2HwYRnt 1qFY2VC7W14InkaEkSVg8TM7m/irMy8QdnFSbGPqp8O4thAlbGPNz28R8okt2XxV 5+832PRLTKrg6NzEDBDLGeC6PwqKaeFuwzFgAwjYBI7B+4OFTfTMrG+Arcz1re20 LPUkdPVs9UzMoaaUXZGTrNAkmH9CR8mXCjAAEe8dbGJY5rKaDsgwebcmEXm13yCn 9kuW7YKUbZcd5IUmKS/ANjR7dUQsq3bepF3NNfBCxCgHFxHjfy07lJPumA56XfyI TlF08KdZVsBTr0QBnfk6zkDlUM27zx0jpHbFndmIKx+fxbjVMefPaIfS3AYZvawr +xiUKfrQwZ+upF/UZxgU8zJl7N1hqwNHZO66S0Fvrat/EO3CbE5jT8H6JHeK5t68 jNWzXzx1uVKK7MgvX6YDhQdYEi0TSNuG7e+nCOPMhwgy4xEdQIk41B3pgfQEW0LA N5BoNByHhv0ud544f01vGAIOcUG4QgguMBwE7kqgJE2qKEDSka+VgCe+FssHbXV+ oq66Y0OqrOpFJwewcHtIHeb+lW/jAZZ1fGdVGGILlZR5sXyIETX3j5ogXxp6Fz8A SI7XV88Mbbhi9tXZqMwiSO5UCHcjv555jDIdaYs6dUlgZZ5/IIMgJI0/97M0hTtn kXpHS9L3Llogw0YtIEKCY8yfOFjB0q8E5wpxumF1ktiwlnKbrYCQ2DmBYSBQeZca UIPfzekEvjArlVkXfjPK2/7ImKUJo2v9LkXcqT1jiGSqv/OrsJLQMa87t90DzZE3 M83vfGJEjs64+lgozqYaVfz0nz7ZzWQkEzlpLXaGND2HnWicumZHY5JU5VAbnfO5 qev6za2e5zK0slMO5qUyFqf7P+7HH8b0VVusZ7cVpN0CUygfCe9Rl34kfOvo63Wp 5lzJBvcGtLYoaQvW4br0cmYSH2OUWrKjcfPsT7OMei5L1I2w1UrPDoWA/a3bSCN7 ePnk8+Q4JpVnAUFljz4rMAkTeVmrUfRjWue/LQRV7psqI091E1t6t4ggpXKVYDF9 6A1G5nBhbAIkRSUyabE7ZzsPfEzlj/CXKe0fBoUFm1C+cG9KSwsGq3r8WWu6+SIh BB8YBONB0Rzwhyx6PeHYPEDg32dBh56kM6ba98TNjJ7SQh4u9rguw/TPbwIOB9+0 sc6+lvoSxpbgJ2DEs9GU9vXMd+dc26Ud2SeiDRq3yltFZPYtOCDcDlJBFQ+TJ/Pq eLZpAttoJYgCAAM+K/ox4zNCC2L3OnjoO05/CzAK5jQ3cX6Y5tkW5Vy1Sp+2VBB3 TaF80vCHz5djsgEyOUdkB9A6Ff2eHHnfHZLnyAmu6JT64F/0nQ/DtDuuu0+xYq/U +PCThgaejv6T9cuZKWm3uwT9j4ENbDV7lc8SgTx758O396XVF0PFx5I81MJ+8LDE oZvESyeizkS3lWnF9QgHlpWYmr4ynuBWPi8r8tye/iyrFzithC7KlWWH9fXC4/Qg gz9kL0F/TwhgAwL+TywhCHhpTRdvCIyAImCQEJgLBOP/H64v/FJPuL5rBO0xPDP6 fMXXP+1KYuEXF2n4XTDI7HK7z3oTYc6pwBY6q/Jlxmv/3mYv+9Y3oroG3mknwbkP wkCMrAiPfaRcnevPt/iy1SsBz/DRiFVr/IOzlUVZNKu80vny+iki46ZndSLsld6N cSUDhc73AUZuleTStbYuJImZnDUt21TZytkyq3fElTJwRKv7HA0cnSDo9pqPwtZo 1N1mZVYoiT1UNuWAq++D00jKdZQNiZYZCszzMYmq4pG7Zqxre7H6i+V3bsWJ8bLq YcM9f3aFn3+48BvCcDg/sDbB2x2serTWdIF54z3gEBwSAYN4+PyHySvOgZMozrcH 7bHsVfudH8o2bbbsUx7gJ9LAMY9+PH/70SSC0469ZUvjka0Wo8/dphvOC0yuqqkH gxkT9TRFzzkFL35t2yEtzrHlaU7NtTa/KFtGPUSM0ZCHHkBE7hNZcB+ZErsaclbh spFIZE3NFukLtt5QBuXXL5uzmujPVxOapmZvnVXOJmcRfswka/0thQnwAJKwH2ji /i1F4+a1CQ3J89XGD4De/QH1m47wkp/mfmhit05i6JuKBhGUn7+ayqZDN2fDtoEZ lfSuBuNkzegt6ot/mAgYw2EYCQ8swRNsAEN6eFCmsNu//zRd3LE4gjfEDfcfKLme yBMo8zKgXeraS7HL4fLmOjYKBsy43OokkT2N2KSgIAvo6/uBxovmj7UA270X1S4j YVBwPDd7rJ4Wc05p/kjgazcBCIe//Wj8Feq6UfnZJkSLE/OmTfdIVoH0ivZ8mTC+ QaHH++KF6q2poNO8jubXP9hngsx00IRfo+oV33rKJ8pVbcKrgqRsjqE08TsdGWVS JVKsDn71kvW8wCCq3Ldmp/nvs04R0fxnL9gF8hyK0aYuvfSNeMZoy7lNfAWbUN// 2EnLeuiynnhcaY+gRJZIW2PRYGM4BoPEILzBqngs+vZR7+7t+982SxwsrUKZVSWl paXVTxqu7kmFk8KUWAA6ULvRnFfH4g8W+rxedV/+U4NLstbrbaeKgy3JPZocrviW V2kIhyqaEnKb44yEWetCu8nbsyX2uwkPRpnSnMSU83c+Gy4oNlrwfit2f6MLZakn B+1Y2vMzEbPuJDJR65VVeXHNqOtcH3NsTO3fZyYHbBwYDrro5jH+/ZdeLDMne8NA ykllagu7dTINZB+ADi1HJZW6uqP3emf7FWW73L14X9xhjEXWbvRM9w4OgnSQ5Kz+ c9mndfo17s54z6ArCrzc2papTIM+FBfWhSgbPyXq185szIC/P1GuW+2HDvavbGbf +2Q7PnBtRGg41yt+TLVpNRGprWrRZv+zcJQYnpQhH867VgBSXIrJ+C5rZZ3JQrna /wE= =irCz -----END PGP MESSAGE----- * Origin: World Power Systems / FidoNews (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 hughes at soda.berkeley.edu Thu Oct 8 19:40:31 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Thu, 8 Oct 92 19:40:31 PDT Subject: Oct. 10 RSVP's Message-ID: <9210090247.AA02476@soda.berkeley.edu> As of tonight, Thursday 10, the Saturday meeting is in two days. I'd like to get RSVP's from everyone who plans to attend, so that I know how many are going to be there. SEND ONE EVEN IF YOU THINK I KNOW THAT YOU'RE COMING! I can't keep everyone's attendance plans straight. Thanks. Eric From hughes at soda.berkeley.edu Thu Oct 8 23:56:11 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Thu, 8 Oct 92 23:56:11 PDT Subject: New feature of the remailer Message-ID: <9210090703.AA26448@soda.berkeley.edu> New! Just finished. Fidonet support. Dumb mailer support. Incoming header line pasting. Here's what's going on. There are a lot of mailers, the Fidonet gateway in particular, which don't allow you to put arbitrary header lines in your outgoing messages. Previously people using these systems couldn't use the remailer because they couldn't put the necessary "Request-Remailing-To:" in the header. Now they can. Instead of putting header lines into actual header, I now support a syntax which allows header lines to be _added_ to the header on incoming mail. These extended header lines are in the body of the message proper, but a filter on incoming mail effectively adds them to the header. This allows anybody who can send me mail with a reasonably unmangled body to use any feature of the remailer that should ever get written. Example: ------- cut here ------- To: hughes at soda.berkeley.edu From: Secret_Squirrel at treehouse.com Subject: Mrs. Tree's secret recipe for pinole :: Request-Remailing-To: Crusader_Rabbit at rocky.moosylvania.org I just paid $2600 for this recipe [etc. etc.] [...] ------- cut here ------- If "::" is on the first body line all by itself, whatever lines follow up to the first blank line will be appended to the header when it is scanned for special instruction lines. This new feature is completely modular. It doesn't (seem to) break any of the other existing features. I'll post the source with an explanation tomorrow. In the meantime, try it out. Eric From shipley at tfs.COM Fri Oct 9 00:14:13 1992 From: shipley at tfs.COM (Peter Shipley) Date: Fri, 9 Oct 92 00:14:13 PDT Subject: New feature of the remailer In-Reply-To: <9210090703.AA26448@soda.berkeley.edu> Message-ID: <9210090721.AA09749@edev0.TFS> Now what is needed is a user interface/script for submitting mail. From shipley at tfs.COM Fri Oct 9 01:42:20 1992 From: shipley at tfs.COM (Peter Shipley) Date: Fri, 9 Oct 92 01:42:20 PDT Subject: my key Message-ID: <9210090849.AA09798@edev0.TFS> Here is my casual key, for a more secure key please contact an authorized dealer near you (Eric Hughes or I). -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQA9AirUzbUAAAEBfjC3p5COEUMJ3xzrq4sJCTaU5MgvzC94tp8yxxBJeKUGo7xx gMShBCnIZp+xlFiyxQAFE7QYUGV0ZXIgTSBTaGlwbGV5IChjYXN1YWwptCZQZXRl ciBNIFNoaXBsZXkgPHNoaXBsZXlAYmVya2VsZXkuZWR1Pg== =/Dhz -----END PGP PUBLIC KEY BLOCK----- From hughes at soda.berkeley.edu Fri Oct 9 09:43:05 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Fri, 9 Oct 92 09:43:05 PDT Subject: The technical explanation of "::" incoming header pasting Message-ID: <9210091650.AA12173@soda.berkeley.edu> There's a new feature in the remailing software. Some people can't add arbitrary header fields because of mailer or gateway restrictions. This restricts them from using the remailer. I have added a facility to allow new header fields to be pasted onto the end of a header when the mail arrives. This effectively happens before processing by the remailer software. These new fields exist during transit in the message body, where they remain untouched. Only after the message is delivered to my account does this operator take effect. Syntax: If the first line of the body is the two characters "::", then the following lines are appended to the header, up to the next blank line. Here's how it works. First of all, here's my new .maildelivery file: ------- cut here ------- # # field pattern action/ string # result (quote included spaces) # Request-Remailing-To "" pipe R "perl remailer/remail.perl" Request-Remailing-To "" file R remailer/archive * "" pipe R "/usr/local/lib/mh/rcvtty -biff" * "" pipe ? "perl remailer/incoming.header.perl" ------- cut here ------- Comments are indicated by #. The Request-Remailing-To lines have been there. The second of the makes an archive for debugging purposes. It will go eventually. The third field, "*", indicates all fields, it runs 'rcvtty' on my mail; this replaces the function of biff, since mail is getting piped to slocal now, disabling biff. The last line is the important one. It says "If the mail hasn't been delivered by now, run the incoming header rewrite script on it. If that doesn't work, continue trying to deliver it." Now here's the trick. slocal has no way of taking the output of the rewrite and continuing to process it. (It should. It would make this whole job easy.) So in order to continue processing, you need to redeliver the mail. You could invoke sendmail and mail it back to yourself, but that would mangle the existing header. So the thing to do is to recursively invoke slocal from within the perl script. Here's the perl script to do all this: ------- cut here ------- # First read in the whole header. # We check for the Second-Pass: line to detect infinite loops. while (<>) { last if /^$/ ; exit 1 if /^Second-Pass:/ ; $header .= $_ ; } # We have just read the last line in the header. # Now we check to see if there is a pasting operator. if ( ( $_ = <> ) && /^::$/ ) { while (<>) { last if /^$/ ; $header .= $_ ; } } else { # There is either an empty body or no pasting operator # Thus exit with a return code of 1 to indicate that # the mail has not been delivered. exit 1 ; } # There was a header pasting operator. # So we open 'slocal' as a pipe, effectively redelivering the mail # back to ourselves. #open( OUTPUT, ">foo" ) ; open( OUTPUT, "| /usr/local/lib/mh/slocal -user hughes" ) ; select( OUTPUT ) ; # print a "From " line to satisfy slocal @weekdays = ( "Sun","Mon","Tue","Wed","Thu","Fri", "Sat" ) ; @months = ( "Jan","Feb","Mar","Apr","May", "Jun","Jul","Aug","Sep","Oct","Nov","Dec" ) ; ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime ; printf "From hughes %s %s ", @weekdays[ $wday ], @months[ $mon ] ; printf "%2d %02d:%02d:%02d 19%d\n", $mday, $hour, $min, $sec, $year ; # Now just print out the message print $header ; print "Second-Pass:\n" ; print "\n" ; while (<>) { } continue { print ; } ------- cut here ------- Here's how the perl script works. The first loop reads lines from the existing header. When it sees a blank line (regexp /^$/) it terminates the loop. If it sees a field "Second-Pass", it knows it has filtered this message before and exits with a return code indicating that the mail has not been delivered. The variable $header is appended with the current header line. $header contains the whole header when the loop terminates. Properly speaking, the Second-Pass test is not necessary to detect infinite loops. Since the pasting operator gets removed during the rewrite, the script won't return an exit status of 0 more times than the pasting operator appears. But should something get screwed up, such as a different module adding pasting commands (how? I don't know), the Second-Pass test should prevent infinite recursion. The next statement reads another line from the input file. This line is the first line of the message body. If this line is the pasting operator, then header lines are accumulated in $header as before until a blank line. The difference is that these header lines are being read from the body of the message. If there is no pasting operator, the script exits undelivered. At this point we now have to redeliver the message back to ourselves. We first open slocal as the output pipe. The next section is a kludge. It turns out that slocal strips off the out-of-band "From " (no colon) line that the mail delivery system uses. In other words, the message which slocal pipes into its pipes is not identical to the message it itself received. This means that slocal cannot be directly recursed. What this section does is to create a "From " line to make slocal happy. It calls localtime() and then formats those numbers into the proper form. It turns out that slocal will deliver this mail without the "From " line, even to /usr/spool/mail, but it doesn't do so properly. On my system, in added some delimiters which I think I've tracked down to the 'mtstailor' file, namely mmdelivery1 and mmdelivery2. Since these are not null on my system, there's some garbage added which screws up separation of the spool file into messages. Adding a "From " line fixes that. This misbehavior may not be so surprising, considering that slocal was "meant" to be invoked only in a .forward file. Now we print the variable $header which contains the whole header, including newlines. Using a single string removes the need for an array. We added the Second-Pass line and a blank line for the end of the header. The final loop prints out the rest of the message body. There is another way to proceed to get the same functionality. One could write a filter to translate the first occurrence only of \n\n::\n into \n. We could then pass the message through this filter before slocal saw it. And for now, that would do the same thing. But suppose we want more that one rewrite rule active? Then you would only be able to apply each rewrite rule exactly once in fixed order. You want to be able to rewrite a message and then apply all the rewrite rules again. At least one other rewrite rule is planned: automatic decryption. Since decrypting a message will completely change the body, and since some of the header fields may need to be hidden, you have to be able to decrypt the body and then paste on header lines. But since you need to indicate an encrypted body by a header line (well, not really, but it's more reliable), and since some people can't add these header lines, you need to paste lines before encryption as well. Thus the rewrite rules need to be applied asyncronously and hence I'm using a fairly complex slocal scheme to do a simple filter. Eventually I hope to write an equivalent to slocal which knows about message rewrites and simple filters, but that's for later. Eric From Secret_Squirrel at Treehouse.COM Fri Oct 9 10:05:09 1992 From: Secret_Squirrel at Treehouse.COM (Secret_Squirrel at Treehouse.COM) Date: Fri, 9 Oct 92 10:05:09 PDT Subject: +-=*^ Message-ID: <9210091712.AA27717@atdt.org> re: Interface for re-mailer; why not hitch it to emacs or something? re: problem with key distribution; right, OK, I hadn't thought that there might be a security problem with casually giving someone your key without them being able to authenticate that it came from you. Good point. Here's my public key. If you feel it is not secure enough, we can always use the cone of silence: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 23l1t34u -----END PGP PUBLIC KEY BLOCK----- From Tom.Jennings at f111.n125.z1.FIDONET.ORG Fri Oct 9 11:13:54 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Fri, 9 Oct 92 11:13:54 PDT Subject: +-=*^ Message-ID: <2747.2AD5CD4D@fidogate.FIDONET.ORG> U> re: problem with key distribution; right, OK, I hadn't U> thought that there might be a security problem with U> casually giving someone your key without them being able U> to authenticate that it came from you. Good point. But as Eric pointed out, and I realized later, the underlying social structure will allow detection of bum keys (presuming the scammed person or someone s/he knows notices, etc, and so on, a wholew world resides here...) U> Here's my public key. If you feel it is not secure U> enough, we can always use the cone of silence: U> U> -----BEGIN PGP PUBLIC KEY BLOCK----- U> Version: 2.0 U> U> U> 23l1t34u U> -----END PGP PUBLIC KEY BLOCK----- Now I feel very unsecure, because the above is all I got. It ain't no public key... PS: Too much anonymity? I have to reply in hte mailing list to this person cuz it's a faked From... (trust me) * Origin: World Power Systems / FidoNews / San Francisco CA (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 shipley at tfs.COM Fri Oct 9 11:16:24 1992 From: shipley at tfs.COM (Peter Shipley) Date: Fri, 9 Oct 92 11:16:24 PDT Subject: +-=*^ In-Reply-To: <9210091712.AA27717@atdt.org> Message-ID: <9210091823.AA11516@edev0.TFS> >re: Interface for re-mailer; why not hitch it to emacs or something? > that to... >re: problem with key distribution; right, OK, I hadn't thought that >there might be a security problem with casually giving someone your >key without them being able to authenticate that it came from you. Good >point. I look at it this way, by emailing my puplic key anyone can send me a secure message (I can't trust where/who it came from but we [the sender and I] can assume that noone is eavesdroping (it could have been replaced but not altered or read) For secure authenticated, where you *know* if came from me you have to contact me or someone you trust that has contacted me. -Pete From nobody at soda.berkeley.edu Fri Oct 9 12:20:07 1992 From: nobody at soda.berkeley.edu (nobody at soda.berkeley.edu) Date: Fri, 9 Oct 92 12:20:07 PDT Subject: +-=*^ Message-ID: <9210091926.AA17103@soda.berkeley.edu> Since there has been complaints about the size of my public key here is a more secure 512bit version, please discard the prevous key -Secret_Squirrel PS: please redistribute this key asap. to others. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQBNAirV2r0AAAEB/i78BfdkmEIqKt2EhdlFAJc44rB3ZMzChez5zVcB9jRpUz1o MY2M2GnucGRUcvMSvZeF/aqCVIHuodDfqyGYYTkABRG0L1NlY3JldF9TcXVpcnJl bCA8U2VjcmV0X1NxdWlycmVsQFRyZWVob3VzZS5DT00+ =Byn9 -----END PGP PUBLIC KEY BLOCK----- From Secret_Squirrel at Treehouse.COM Fri Oct 9 12:51:41 1992 From: Secret_Squirrel at Treehouse.COM (Secret_Squirrel at Treehouse.COM) Date: Fri, 9 Oct 92 12:51:41 PDT Subject: Anonymity Message-ID: <9210091959.AA02274@atdt.org> Anonymity is good. Anonymity works. >> U> 23l1t34u U> -----END PGP PUBLIC KEY BLOCK----- Now I feel very unsecure, because the above is all I got. It ain't no public key...\ << Uh... it's kind of an inside joke. Uh. Sorry. Anyway, why would you want to reply only directly to me and not to the list in general? From whitaker at eternity.demon.co.uk Fri Oct 9 14:18:54 1992 From: whitaker at eternity.demon.co.uk (Russell E. Whitaker) Date: Fri, 9 Oct 92 14:18:54 PDT Subject: *Economist* on encryption Message-ID: <1632@eternity.demon.co.uk> The following is intended for limited-distribution, educational purposes only.... Citation: The Economist, Sept 21, 1991 v320 n7725 p104(2) COPYRIGHT Economist Newspaper Ltd. (UK) 1991 ---------------------------------------------------------------------- Title: A cure for the common code: computer cryptography. ---------------------------------------------------------------------- Subjects: Public key cryptosystems_Standards Digital signatures_Standards Data encryption_Research United States. National Institute of Standards and Technology_Laws, regulations, etc. Reference #: A11286848 ====================================================================== Summary: Advances in the mathematics of prime factorization algorithms have led to a technology that, once standardized, will dramatically improve public-key cryptography. The RSA algorithm is popular in the computer industry, but the government favors an alternative. ====================================================================== ANYONE can sign a postcard, but how do you sign a piece of electronic mail? Without a "signature" to demonstrate that, say, an electronic transfer of funds really comes from someone authorised to make the transfer, progress towards all-electronic commerce is stymied. Ways of producing such signatures are available, thanks to the technology of public-key cryptography. They will not work to everyone's best advantage, though, until everyone uses the same public-key system. It is an obvious opportunity for standards-makers - but in America they have turned up their noses at all the variations on the theme currently in use. The alternative standard for digital signatures now offered by America's National Institute of Standards and Technology (NIST) has brought a long-simmering controversy back to the boil. Public-key cryptography could become one of the most common technologies of the information age, underpinning all sorts of routine transactions. Not only does it promise to provide the digital equivalent of a signature, it could also give users an electronic envelope to keep private messages from prying eyes. The idea is to create codes that have two related keys. In conventional cryptography the sender and receiver share a single secret key; the sender uses it to encode the message, the receiver to decode it. In public-key techniques, each person has a pair of keys: a disclosed public key and a secret private key. Messages encoded with the private key can only be decoded with the corresponding public key, and vice versa. The public keys are published like telephone numbers. The private keys are secret. With this technology, digital signatures are simple. Encode your message, or just the name you sign it with, using your private key. If the recipient can decode the message with your public key, he can be confident it came from you. Sending a confidential message - putting electronic mail in a tamper-proof envelope - is equally straightforward. To send a secret to Alice encode it with her public key. Only Alice (or someone else who knows her private key) will be able to decode the message. The heart of any system of public-key cryptography is a mathematical function which takes in a message and a key, and puts out a code. This function must be fairly quick and easy to use, so that putting things into code does not take forever. It must be very hard to undo, so that getting things out of code does take forever, unless the decoder has the decoding key. Obviously, there must be no easy way to deduce the private key from the public key. Finding functions that meet these criteria is "a combination of mathematics and muddle", according to Roger Needham of the Cambridge Computer Laboratory. The greatest successes to arise from the muddle so far are those using functions called prime factorisation algorithms. They are based on the mathematical insight that, while it is easy to multiply two numbers together, it is very hard to work backwards to find the particular two numbers which were multiplied together to produce some given number. If Alice chooses two large prime numbers as her private key and publishes their 150-digit product as her public key, it would probably take a code-breaker thousands of years to work backwards to calculate her private keys. A variety of schemes have been worked out which use this insight as the basis for a workable public-key code. Most popular of these is the so-called RSA algorithm, named after the three MIT professors who created it - Ronald Rivest, Adi Shamir and Len Adleman. It has been patented and is sold by a Silicon Valley company, called RSA, that employs 15 people, most of them ex-MIT graduate students. Faculty firms are to computer start-ups what family firms were to the industrial revolution. RSA has attracted both academic praise and a range of heavyweight commercial customers: Microsoft, Sun Microsystems, Digital Equipment and Lotus Development. But, despite repeated applications, it has never been endorsed by those in government. Rumours abound that the code-breakers in the National Security Agency have discouraged standard-setters from recommending RSA because they do not want to promote the use of codes they cannot break. RSA, for obvious reasons, does not discourage the rumours. Whatever the reason, the standard-setters at the NIST have side-stepped the debate over RSA with their new algorithm, DSA. As set out in the standard, DSA verifies the identity of the sender, but does not encrypt the message. It appends to the message a number calculated from the message and the sender's private key. The recipient can then use this number, the message and the sender's public key to verify that the message is what it seems. The NIST says that this technique is well suited to "smart cards" and other applications where there is not a lot of computing power available for working out codes. Because it hopes that DSA Will be used for verifying the identity of everyone from welfare recipients to military contractors, its flexibility is a boon. Meanwhile, however, more and more companies are choosing a public-key cryptography system for communicating confidentially - often RSA, sometimes something different. Someday, probably soon, governments will want to choose, too. Watch out for fireworks when they do. ------------------end forwarded article-------------------------- 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) [.sig revised 1 October 1992 /// Send mail to eternity node] -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAiqwg10AAAEEAMVNMI766ljeuW01xqXKYYV5lmDPvb+6dCQK3m1iBQdan0no pm35j1DIRp3UJZogAe5eimsQg1TALDhTq310OZs9+L6B/HxeX3+4BadIDad4g+xI lvaFY1Ut/hMdZNkw0tzNZOdUPiO4jYIyirReAUiMCm6jXzkTRITj7/vxxWtPAAUR tDNSdXNzZWxsIEUuIFdoaXRha2VyIDx3aGl0YWtlckBldGVybml0eS5kZW1vbi5j by51az4= =LOCL -----END PGP PUBLIC KEY BLOCK----- From Secret_Squirrel at Treehouse.COM Fri Oct 9 14:53:31 1992 From: Secret_Squirrel at Treehouse.COM (Secret_Squirrel at Treehouse.COM) Date: Fri, 9 Oct 92 14:53:31 PDT Subject: Ha ha Message-ID: <9210092201.AA05901@atdt.org> Whoah. That's helarious. NOT! Secret Squirrel does not cotton to imposters, and that sure as hell ain't my Public Key. So don't even bother trying to write any encrypted messages with it. My key remains: 23l1t34u -- SHRDLU From Angry_Poodle at BBQ.COM Fri Oct 9 18:47:57 1992 From: Angry_Poodle at BBQ.COM (Angry_Poodle at BBQ.COM) Date: Fri, 9 Oct 92 18:47:57 PDT Subject: PGP Key Message-ID: <9210100155.AA12001@atdt.org> If you see any msgs from 'me' saying "here's my PGP PK key," then it's an imposter! I don't have a PGP key, much less PGP! -- Angriest Dog in the World. From gg at well.sf.ca.us Sat Oct 10 01:59:50 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Sat, 10 Oct 92 01:59:50 PDT Subject: +-=*^ Message-ID: <199210100906.AA26559@well.sf.ca.us> I've seen a number of postings so far about "secure *and* authenticated" requiring advance in-person distribution of key material. This would seem to eliminate the main advantage of public key systems, i.e. open distribution of public keys. So as long as we're handling key material in person, how about one-time systems, eh? Absolutely secure, provably so, obsolescence-proof, simple & straightforward. Not particularly exciting from a theoretical point of view, but one-time systems are practical and on the bottom line, they work. What do y'all think...? -gg at well.sf.ca.us From gnu at cygnus.com Sat Oct 10 02:43:25 1992 From: gnu at cygnus.com (gnu at cygnus.com) Date: Sat, 10 Oct 92 02:43:25 PDT Subject: Better directions to the meeting on Saturday at noon Message-ID: <9210100950.AA28200@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 at kg6kf.ampr.org Sat Oct 10 03:07:47 1992 From: marc at kg6kf.ampr.org (Marc de Groot - KG6KF) Date: Sat, 10 Oct 92 03:07:47 PDT Subject: a key Message-ID: <9210100755.AA05427@kg6kf.ampr.org> A key... -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQA9AirWaLMAAAEBgMlJILifxrXH8fkJwJbeSHXAY1Q9/AzPybGVy0Dx/q70Fr3d KhM6XoSEgaw2Ezzn2QAFEbQWTWFyYyBkZSBHcm9vdCAoY2FzdWFsKbQjTWFyYyBk ZSBHcm9vdCA8bWFyY0BrZzZrZi5hbXByLm9yZz4= =LL6T -----END PGP PUBLIC KEY BLOCK----- This is a casual key for me. Perhaps a causal key for me too. -Marc de Groot From hughes at soda.berkeley.edu Sat Oct 10 07:29:03 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Sat, 10 Oct 92 07:29:03 PDT Subject: +-=*^ In-Reply-To: <199210100906.AA26559@well.sf.ca.us> Message-ID: <9210101436.AA00257@soda.berkeley.edu> George recommends one-time pads. The key distribution problem for one-time pads is *much* worse than for public key systems, or even conventional secret key ciphers for that matter. You still have to exchange keys without transmission (i.e. face to face meetings again, or mail, etc.). Anything that is secure for exchanging a one-time pad is also secure for exchanging public keys. Then you have to do this again when your pad runs out. The bandwidth required for one-time keys is much higher than for conventional keys to boot. But the biggest advantage of public key systems is that I can sign someone else's key, and if you know my key, then you know his. To put it more humorously, you will have exchanged cryptographic fluids with everyone I have as well. This is a good thing. Eric From 74076.1041 at CompuServe.COM Sat Oct 10 11:04:58 1992 From: 74076.1041 at CompuServe.COM (Hal) Date: Sat, 10 Oct 92 11:04:58 PDT Subject: Mr. Squirrel? Message-ID: <921010180751_74076.1041_DHJ61-1@CompuServe.COM> Hi, I've just joined this list. Interesting confusion about Mr. Squirrel. That's one of the problems with anonymity. How do you know you're talking to the right person? What you should do is to use a public key. The pseudonym is not really the name "Secret Squirrel"; anybody can use that. The pseudonym is the public key. Any message signed by that particular key is from that particular squirrel. Any message you encrypt in Squirrel's public key is readable only by him. If Squirrel changes his key, he should sign the message so you know it's really _that_ squirrel who's changing his key (and not some other squirrel telling people to use a new key). A pseudonym is a public key. Hal P.S. Here's my key, signed by PRZ: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.01 mQCNAiqsNkwAAAEEAMKWM52m5EWi0ocK4u1cC2PPyHT6tavk9PC3TB5XBYDegf3d sldRpnjJj1r+aO08FFO+QLEI9wtBqvf1PPP5iLX7sD2uIVlJH14MPtyVtjm9ZKb8 JMtCW74045BgtHBC9yQ3V7vXNV5jM6dE2ocnH4AI/pBFrGLJPKgTA69YIUw3AAUR tCZIYWwgRmlubmV5IDw3NDA3Ni4xMDQxQGNvbXB1c2VydmUuY29tPokAlQIFECqu M1Tidd4O/2f3CwEByrUD/3uoV2y+Fuicrrd2oDawgOw9Ejcx6E+Ty9PVPqKvflLs 0zYyGfeFVSgBbTSDP3X91N3F68nydl9J9VA6QRCGelHM1cZRukCJ0AYbKYfpwUN0 xjEGHsDrd2gT5iWlB3vBZvi+6Ybs4rSq+gyZzVm1/+oRrMen32fz2r0CLgUtHok2 =fF6Z -----END PGP PUBLIC KEY BLOCK----- From Tom.Jennings at f111.n125.z1.FIDONET.ORG Sat Oct 10 12:20:43 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Sat, 10 Oct 92 12:20:43 PDT Subject: Directions! Message-ID: <2887.2AD7240A@fidogate.FIDONET.ORG> Umm, directions never came. I think it's last minute, huh?! Can anyone tell me where Cygnus' new site is? * Origin: World Power Systems / FidoNews / San Francisco CA (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 Sat Oct 10 13:15:11 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Sat, 10 Oct 92 13:15:11 PDT Subject: Better directions to the meeting on Saturday at noon Message-ID: <2889.2AD73B41@fidogate.FIDONET.ORG> Things are not good here. I have to stay and deal with my best friend Deke who seems to be going nuts. (It's not a new story, but it heated up last night.) Now, at 1pm, I've gotta stay here another hour or so, and be back by 630, so I guess I'm gonna have to miss another. I'll see you all elsewhen (to borrow a Hugh-ism). * Origin: World Power Systems / FidoNews / San Francisco CA (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 Sat Oct 10 13:15:12 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Sat, 10 Oct 92 13:15:12 PDT Subject: +-=*^ Message-ID: <2890.2AD73B43@fidogate.FIDONET.ORG> (to: gg at well.sf.ca.us) Thank you for clarifying my particular problem: what I was worried about was *authentication* not security. I had the two tangled up. Duh. With an informal email/introducer setup for the FidoNet, we'll have a fairly secure system with a reasonable level of authentification, practically speaking, with authentification to some high level doable on an individual basis. (Using PGP.) This probably as "good as it gets" in our (email) environment. * Origin: World Power Systems / FidoNews / San Francisco CA (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 hh at soda.berkeley.edu Sat Oct 10 13:33:53 1992 From: hh at soda.berkeley.edu (Eric Hollander) Date: Sat, 10 Oct 92 13:33:53 PDT Subject: random Message-ID: <9210102041.AA04891@soda.berkeley.edu> So when are we going to start alt.crypt, where we just post a lot of uuencode'ed random data? e From d9mj at crux2.cit.cornell.edu Sat Oct 10 17:55:26 1992 From: d9mj at crux2.cit.cornell.edu (d9mj at crux2.cit.cornell.edu) Date: Sat, 10 Oct 92 17:55:26 PDT Subject: [gg@well.sf.ca.us: Re: +-=*^] Message-ID: <9210110102.AA21921@crux1.cit.cornell.edu> Look at what my mailer did to your header. Is this a result of your perl script or my screwed router? Date: Sat, 10 Oct 1992 05:06:40 -0400 Illegal-Object: Syntax error in From: address found on router.mail.cornell.edu: From: George A.Gleason ^ ^-illegal period in phrase \-phrases containing '.' must be quoted X-Ph: V3.12 at router.mail.cornell.edu >From: To: Secret_Squirrel at treehouse.com, shipley at tfs.COM Subject: Re: +-=*^ Cc: cypherpunks at toad.com [message deleted] From gg at well.sf.ca.us Sun Oct 11 00:50:52 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Sun, 11 Oct 92 00:50:52 PDT Subject: +-=*^ Message-ID: <199210110757.AA22987@well.sf.ca.us> Eric, good point about public keys and trust by association. More on OTPs. You say the key distribution problem for OTPs is "much worse" than for PKS and even other conventional ciphers. "Much worse" in what ways? The need for F2F meetings with all possible correspondents is something which exists with conventional ciphers. The cost of key storage is trivial: a fraction of the cost of the yearly (or less frequent) travel to meet each correspondent in person. Consider replaceable hard drive cartridges (30 meg for about a buck a meg), digital cassette formats including applications involving videocassettes, and so on. Yes, as you say, you have to exchange keys each time you run out of key; but you can keep ten years' with of key (error: "worth" not "with") on hand if you like, taking up less physical space than a box of cookies. "Bandwidth required is much higher..." In what way? Certainly not in terms of transmission; a stream cipher is a stream cipher. Perhaps in that each plaintext character requires one key character? This is just another formulation of the "storage" issue: and again, if you have a stack of 30MB cartridges, who cares? Not like we're talking about punched paper tape. I do agree that PKS offer convenience and features not available with conventional ciphers. However, RSA is just one mathematical breakthrough away from being obsolete, and we have no way of knowing when that breakthrough occurs. It may also be that massively parallel processors can be built through VLSI technology, allowing the cost of brute force solutions to come down to a reasonable level. All of this is not by way of getting down on PKS. I would suggest that we need a number of different systems, and need to keep them all in fairly constant use. I think we're already all in agreement that one of those systems should be RSA-based. Now I'm just suggesting that a One-Time system should be another one among the many. BTW, sorry I couldn't make today's meeting; various local tasks demanding attention; plus physical travel distance. Be back next time... -gg From hughes at soda.berkeley.edu Sun Oct 11 11:52:00 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Sun, 11 Oct 92 11:52:00 PDT Subject: one time pads In-Reply-To: <199210110757.AA22987@well.sf.ca.us> Message-ID: <9210111753.AA24487@soda.berkeley.edu> George writes: The cost of key storage is trivial: a fraction of the cost of the yearly (or less frequent) travel to meet each correspondent in person. Let me emphasize _each_ in that sentence. One time pads are very expensive on a per-link basis than public key systems for this reason only. Per-link is one person-to-person link. Consider replaceable hard drive cartridges (30 meg for about a buck a meg), digital cassette formats including applications involving videocassettes, and so on. Suppose one cartridge per link. That's $30 per link. Per link, that's a _lot_ of money. "Bandwidth required is much higher..." In what way? Whatever channel you use to transmit keys on, be it 30 Mb cartridges or what, will be more efficiently used by an exchange which requires less storage. In the case of cartridges, the UPS cost to ship one is still only about 1/5 of the cost of a cartridge. A 3 1/2 inch floppy can be shipped for one or two ounces of postage. However, RSA is just one mathematical breakthrough away from being obsolete, and we have no way of knowing when that breakthrough occurs. It is also one breakthrough away from being known to be fully secure. Not only do we not know when that will happen, we don't know which will happen. It may also be that massively parallel processors can be built through VLSI technology, allowing the cost of brute force solutions to come down to a reasonable level. Look at the figures for best know factoring algorithms. Now estimate the total amount of silicon output per annum in the US and estimate it's computational ability. I think you'll find that it would still take on the order of years to factor a single 1024 bit modulus. The difficulty of hard problems and the scale of the solar system are two things which are both extremely difficult to get any intuition about. I would suggest that we need a number of different systems, and need to keep them all in fairly constant use. [...] Now I'm just suggesting that a One-Time system should be another one among the many. Here's the bottom line: More security, more cost. Perfect security is not worth the cost in time, effort, or dollars when the marginal cost of perfection is less than the marginal benefit. Even SWIFT, the international monetary wire transfer system, does not use one time pads for link encryption. Now here is a network which breaking into would be worth billions (that's thousands of millions, let me remind you). The chief executives of SWIFT exchanges keys by post. One time pads are useful for all sorts of things, but they are very expensive to use. They are useful in protocols for blinding and key exchanges. They do not seem to be useful for end-to-end link encryption, however. Eric From hughes at soda.berkeley.edu Sun Oct 11 11:52:09 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Sun, 11 Oct 92 11:52:09 PDT Subject: [gg@well.sf.ca.us: Re: +-=*^] In-Reply-To: <9210110102.AA21921@crux1.cit.cornell.edu> Message-ID: <9210111718.AA24207@soda.berkeley.edu> There is a bit of confusion about the various lists and addresses. My main address is hughes at soda.berkeley.edu. The remailer runs from this account. All the perl scripts are there. The account I use to maintain the mailing list is on toad.com, as well as the mailing list itself. Its software is nothing but sendmail; no perl scripts. Eric From whitaker at eternity.demon.co.uk Mon Oct 12 02:29:15 1992 From: whitaker at eternity.demon.co.uk (Russell E. Whitaker) Date: Mon, 12 Oct 92 02:29:15 PDT Subject: More on packet radio encryption Message-ID: <1778@eternity.demon.co.uk> This article was forwarded to you by whitaker at demon.co.uk (Russell E. Whitaker): --------------------------------- cut here ----------------------------- Path: eternity.demon.co.uk!demon!pipex!unipalm!uknet!doc.ic.ac.uk!agate!spool.mu.edu!sgiblab!public!grady From: grady at public.BTR.COM ( ) Newsgroups: alt.privacy Subject: packet radio encryption Message-ID: <8113 at public.BTR.COM> Date: 11 Oct 92 19:41:12 GMT Organization: BTR Public Access UNIX, MtnView CA. For info contact: info at BTR.COM Lines: 52 Bill Stewart (wcs at anchor.ho.att.com) writes, in part: [...Unlike the AX.25 link protocol specified by FCC rules, the higher level protocols are not required to be plain-text...] Do you have a reference for this? And does this apply to the contents, the protocols, or both? (E.g. can you use a crypto-based presentation layer protocol and plain-text payload, or vice versa?) ---- The definitive reference is Part 97 of the FCC rules (available from the US Government Printing Office, Washington, D.C. 20402. Phone orders: 202 783 3238. Ask for "Code of Federal Regulations" 47 CFR 80 to End.) To summarize the rules, except for certain remote control operation as space or repeater machines, nothing can be transmitted with the intent that the meaning be obscured. Conversely, text compression, for example, is legal because, although the plaintext is certainly obscured, it wasn't the _intent_ of the LZ or Huffman or whatever coding to conceal the meaning. Likewise with UUencoding and a host of other compression/ error detection and correction schemes that incidentally involutes the plaintext to some more efficient transmitted form. Spread spectrum is treated somewhat more restrictively since for that mode you may be required to produced the logs and the content of the messages. But not so for narrow- band FM packet. To sum up, using cryptography in general is prohibited. (However, digital signatures are OK, even though based on MD5 or SHA as long as the intent is not to _obscure the meaning_ of part of the transmitted message.) Clearly, though, the burden of proof is upon the FCC to show that a particular message _was_ encrypted, since there is _no_ theoretical, a priori way that an encrypted data stream can be distinguished from one merely well compressed or, just for that matter, random. Of course you should verify this with an attorney if you are troubled with fears of prosecution. Grady Ward KD6ETH/AA -- Grady Ward grady at btr.com Moby Lexicons --------------------------------- cut here ----------------------------- From hughes at soda.berkeley.edu Mon Oct 12 08:20:43 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Mon, 12 Oct 92 08:20:43 PDT Subject: Next meeting: Nov. 21 Message-ID: <9210121527.AA23015@soda.berkeley.edu> The next physical cypherpunks meeting was decided on Saturday at that meeting. It will be Saturday, November 21, starting at noon at the Cygnus Support offices in Mountain View. I am announcing the date now so that you can put it on your calendar. Eric From ravi at xanadu.com Mon Oct 12 13:46:47 1992 From: ravi at xanadu.com (Ravi Pandya) Date: Mon, 12 Oct 92 13:46:47 PDT Subject: The subject of Saturday's game Message-ID: <9210121942.AA03720@xanadu.xanadu.com> I just joined the list; I've read such archives as are locally available, but I apologize if this subject has already come up. Talking to a couple of people who had been to Saturday's meeting, I was deeply disturbed by the choice of subject for the simulated privacy game - trying to purchase illegal drugs. This is a subject on which rational public discussion is essentially non-existent in this country. Let me first state that I do favor the legalization of drugs, and I am a committed libertarian (as I suspect are many of the people in this group). However, I think it is unwise to tie cryptography in with this issue. Communications privacy is *too important* to take the risk that it will get caught up in the current hysteria of the New Prohibition. There have already been enough government attacks on cryptography that we do not want to give them any more ammunition. I think that if we are committed to getting cryptographic technology in wide use, and spreading true privacy and information security throughout the world, then we need to take careful account of the political and social factors, as well as the technical. In order to be successful, this needs to be not just a development project, but also a marketing campaign. When an MIS manager at some large corporation is deciding whether to upgrade her network to privacy-enhanced mail, we want her to associate it with security and liberty, not the street corner punks who are trying to sell her kids crack. In this vein, let me suggest some subjects for future simulations: - organizing the Boston Tea Party in the face of British spies and informers - purchasing condoms or Lady Chatterley's Lover back when they were banned (these bans seem so absurd now, that trying to get around them seems sensible and ordinary, and may start people thinking about the absurdity of current interdictions) - Yeltsin/Gorbachev vs the coup leaders Furthermore, given the erosiion of constitutional protections in the Drug War, I think the participants in Saturday's game were taking a non-trivial risk to their persons and property. If the risk were necessary to help spread cryptographic privacy, I think none would begrudge it; however, I think it was not only unnecessary, but counterproductive. 'Nuff said. To life and liberty, --ravi From tribble at xanadu.com Mon Oct 12 15:09:10 1992 From: tribble at xanadu.com (E. Dean Tribble) Date: Mon, 12 Oct 92 15:09:10 PDT Subject: The subject of Saturday's game In-Reply-To: <9210121942.AA03720@xanadu.xanadu.com> Message-ID: <9210122148.AA05516@xanadu.xanadu.com> Excellent message. I agree with your points about drugs. I also like the organization topics you suggest for the game. In this vein, let me suggest some subjects for future simulations: - organizing the Boston Tea Party in the face of British spies and informers - purchasing condoms or Lady Chatterley's Lover back when they were banned (these bans seem so absurd now, that trying to get around them seems sensible and ordinary, and may start people thinking about the absurdity of current interdictions) - Yeltsin/Gorbachev vs the coup leaders On the victory conditions. Right now, the game is declared over as soon as any party accomplishes their objective. This creates the incentive to prevent other people from accomplishing their objective, even if it would help me accomplish mine. The use of topics like the above gives clearer victory conditions: One side or the other wins, even though that side only loosely includes any particular participant in the game (an informer wins if either his nominal side wins without his duplicity being revealed, or if the opposition wins). A plausible generic form of victory condition is for one 'side' to succesfully transact some secure exchange, or for the other 'side' to successfully break such a secure transaction. I don't know how to allow decoys with this model of victory. Hmmm... To life and liberty, Da. dean From hughes at soda.berkeley.edu Mon Oct 12 15:40:05 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Mon, 12 Oct 92 15:40:05 PDT Subject: Game items In-Reply-To: <9210121942.AA03720@xanadu.xanadu.com> Message-ID: <9210122247.AA01207@soda.berkeley.edu> Re: drugs and simulation games. At the meeting last Saturday, we played the second incarnation of the remailing simulation game. In a nutshell, the game is intended to teach people about how to protect their privacy by using encryption to prevent against monitoring and by using remailing to protect their identities. Since the game is also in part an economic simulation, I tried to pick game objects which someone had some interest in keeping quiet. I picked drugs, of unspecified name, as a prominent game item. This, by wide acclamation, is a mistake. Since the primary reason to pick this was a paucity of imagination, I now ask for help from the list. We want to develop a list of game items, physical objects, which will be the goods of transaction. I would like to pick objects that have been illegal in the past, but which are not anymore. They should not be primarily information, such as copies of _Ulysses_. They should not now be restricted. Nor should they be weapons, such as crossbows or samurai swords. They should, however, be objects that are known to have generated some emotional reactions in the past. There are two suggestions that meet these criteria: contraceptives and printing presses (or xerox machines). I would like to find more. Please make your suggestions. Another possibility is to use items which have been the subject of state-enforced monopolies in the past, such as pepper or nutmeg. Be creative. We'd like to get a good list of twenty or so items. Eric From efrem at spitha.informix.com Mon Oct 12 20:56:33 1992 From: efrem at spitha.informix.com (Efrem Lipkin) Date: Mon, 12 Oct 92 20:56:33 PDT Subject: drugs and simulation games. Message-ID: <9210130254.AA04987@spitha.informix.com> Unfortunately the first two things which come to mind are: coffee (a drug - actually an excuse for gathering) papers on public key cryptography (primary information) radios - illegel in Russia and I believe elsewhere during WWII East German typewriters - I had one Also a slight deviation: many medicines (and soon herbal contraptions) which are doctor monoply items here, but over the counter in most other countries. Religious artifacts of any number of banned religions. Divorce (opps, not a physical object). Really on thinking about it, I believe that the trade of ideas is always far more repressed than the trade in any kind of stuff. --Efrem Re: > We want to develop a list of game items, physical objects, which will > be the goods of transaction. I would like to pick objects that have > been illegal in the past, but which are not anymore. They should not > be primarily information, such as copies of _Ulysses_. They should > not now be restricted. Nor should they be weapons From hh at soda.berkeley.edu Mon Oct 12 21:56:16 1992 From: hh at soda.berkeley.edu (Eric Hollander) Date: Mon, 12 Oct 92 21:56:16 PDT Subject: The subject of Saturday's game In-Reply-To: <9210121942.AA03720@xanadu.xanadu.com> Message-ID: <9210130503.AA15950@soda.berkeley.edu> That was a really good point. Keep separate issues separate so as not to alienate people. e From tribble at xanadu.com Mon Oct 12 21:57:42 1992 From: tribble at xanadu.com (E. Dean Tribble) Date: Mon, 12 Oct 92 21:57:42 PDT Subject: drugs and simulation games. Really on thinking about it, I believe that the trade of ideas is always far more repressed than the trade in any kind of stuff. In-Reply-To: <9210130254.AA04987@spitha.informix.com> Message-ID: <9210130425.AA01334@xanadu.xanadu.com> --Efrem > We want to develop a list of game items, physical objects, which will > be the goods of transaction. I would like to pick objects that have > been illegal in the past, but which are not anymore. They should not > be primarily information, such as copies of _Ulysses_. They should > not now be restricted. Nor should they be weapons We definitely should have physical goods because the interface between an information world (in which privacy and anonymity can be completely protected) is where much of the complexity lies in managing things like cryptographic money. dean From gg at well.sf.ca.us Tue Oct 13 01:14:58 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Tue, 13 Oct 92 01:14:58 PDT Subject: one time pads Message-ID: <199210130821.AA03658@well.sf.ca.us> Good hard critique, Eric! Now if I might try to salvage my position... "One time pads are very (much more) expensive on a per-link basis than public key systems..." Yes, of course. However I don't envision OTPs as a standard for bulk encryption on large networks. Rather, for person-to-person communication in small networks. Examples: a group of civil rights attorneys suing the Federal govt., an international environmental organisation's main offices in the capital cities of a small number of countries, etc. Cases where the adversary is one or more powerful governments, and the number of links required is relatively small. Given the nature of the relationships between these kinds of networks and their adversaries, the expense would seem to be justified; in any case, the **incremental** cost of for instance a set of 30MB cartridges as compared to a few floppy discs, is an minor fraction of the cost of the airline tickets and other expenses for trusted couriers. (oops: "a minor fraction...") Your discussion of bandwidth can be met with a similar counter-arguement. First of all, I would reject the use of UPS or (God help us) the *Post Office* as a courier, particularly where one or more governments may be the adversaries against whom protection is needed. So your reference to those carriers is not relevant to the main point of my case. I'm assuming that key materials are transported by trusted courier and are guarded by same until they reach their intended recipient. Okay, that *really* drives up the cost, doesn't it...? Not if the key materials "hitch hike" on an existing travel plan: attorney A flies out to city B to visit attorney B... and happens to carry key material onboard in his/her shoulder bag. No added cost except for the storage devices, and that is not significant. Re mathematical breakthroughs in factoring etc, you say, "we don't know when that will happen, and we don't know which will happen." Exactly my point. *We* don't know. But the NSA and so on, most certainly do know, and they won't be telling. If the breakthrough comes, then the period between that point and the point when it is publicised, will be one of false security. Was it Kahn who said nothing is more dangerous than a bad cipher? My point here comes down to nothing more or less than the principle of caution in the face of an unknown. (Discussion of relative cost of brute force solutions, and the question of hard problems and scale.) I agree that my intuition about these things may be highly flawed. However this doesn't invalidate my point about the possibility of basic breakthroughs happening behind closed doors. Now in a way I'll admit that my arguement here sort of comes down to a black box. However, again I would assert that there are cases where the almost irrational caution is worthwhile. You say in concluding, "Perfect security is not worth the cost in time, effort, or dollars when the marginal cost of perfection is less (do you mean more?) than perfection." You cite examples of international banking systems. I would cite examples of political movements which have been sabotaged and destroyed by government covert action. One need not look far to run into COINTELPRO and the more recent French govt action of blowing up a Greenpeace vessel. Where your adversaries are the intelligence agencies of world powers, and where lives are at stake, I would say the cost of perfect security is justified. Now of course, the French terrorist bombing, the destruction of Black nationalist and student organising groups in the US, and other examples, may not (probably would not) have been prevented altogether by adoption of perfect communications security. Che Guevara after all used OTPs, and it was radio direction finding and traffic analysis (rather than cryptanalysis) which ultimately led to his murder by US-backed mercenaries. If we are promoting a tendency which is inherently political, it implicitly recognises governments as its adversaries. Our choices of cryptographic systems should reflect a wide range of applications and not exclude some a-priori on grounds of cost or convenience. -George (gg at well.sf.ca.us) From gg at well.sf.ca.us Tue Oct 13 01:49:34 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Tue, 13 Oct 92 01:49:34 PDT Subject: Game items Message-ID: <199210130856.AA05294@well.sf.ca.us> The examples I always refer to are Federal civil rights suits naming the Federal govt as defendant, and international ecological organisations conducting whatever business they may be engaged on. These may or may not fulfill the game objectives, and they do tend to suffer from being a bit mundane perhaps to the point of being unexciting. However they are historically relevant and probably will be so in the future. Another possible topic would be womens' access to abortion, though given the coming change in our govt this may be irrelevant. How about GIFs depicting sex between consenting adults? Corporate proprietary information on new technology, in an age of increasing international competition (in this case the physical prototypes as well as information about same). International intrigues are always interesting: small countries seek to combine economic power against large countries, that kind of thing. -gg From hugh at domingo.teracons.com Tue Oct 13 05:02:06 1992 From: hugh at domingo.teracons.com (Hugh Daniel) Date: Tue, 13 Oct 92 05:02:06 PDT Subject: Mr. Squirrel? Just who is whom here? In-Reply-To: <921010180751_74076.1041_DHJ61-1@CompuServe.COM> Message-ID: <9210131201.AA12086@domingo.teracons.com> Hal is somewhat right, anyone can use 'Secret Squirrel' and anyone can use any public key they want also. So, in a many-to-one scope (as in a maillist) where the sender can not use the one-on-one signed signiture method how do we have proff of who the sender really is? Maybe public forums are just not places where it is easy to verify the identity of a speaker? A second thing that Hal's comments bring up is that we were reading the From: headders and ignoreing the keys. In good crypto-mail readers the key ought to be checked against our own data base of others keys and the result added to the hedders as say: KeyCheck: FooBar Bazoid holds this key in XXX database or some such rot. I wonder what is more important, who I claim to be in a random message or what key I include... New keys ought for an ID (or new ID's for the same key) should be added to the data base as well. But all this needs to be done automaticly by the mailers and interfaces, else the system will be mis-used and folks will tire of the extra work that gets them little advantage. ||ugh Daniel From hughes at soda.berkeley.edu Tue Oct 13 08:51:51 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 13 Oct 92 08:51:51 PDT Subject: one time pads In-Reply-To: <199210130821.AA03658@well.sf.ca.us> Message-ID: <9210131558.AA25287@soda.berkeley.edu> Previously I said about one-time pads: "High security, high cost." (Well, not exactly that...) I invoked it then in order to argue that I personally didn't need to use one-time pads. Implicit also in that statement is the claim that when the worth of security is high, the cost may be relatively cheap. George and I agree on this point. When you are fighting a military battle, when you have a government pissed off at you in a serious way, you need as good as you can get. Since you can get perfect end-to-end link encryption, you use it. All cryptography is economics. Repeat after me. All cryptography is economics. I don't need one-time pads. Sendero Luminoso does. It's as easy as that. It's merely a matter of scale. Large scale, high security. Small scale, pretty good security. Re: Mathematical breakthroughs. George missed my main point here. We don't know whether factoring is "fundamentally hard." (Project your own definition here.) We should not assume that when the breakthrough comes, that is will be found "easy." It may be that factoring is hard, and that RSA is secure for that reason. (The astute reader will see that these two are not exactly the same question.) My current thinking is that factoring is hard because of various randomness properties of primes, that in fact multiplying one large prime by another is like encrypting one prime with the other as a one-time pad! But I'm no number theorist. I do, however, agree with "caution in the face of an unknown." And for high stakes, George's "irrational caution" is not irrational at all. Re: Relative security. It seems I had an editing error. What I meant to say (paraphrased) was the following. Perfect security is not worth the cost when the marginal cost of perfect security is more than the marginal benefits of such security. This encompasses both the high end and the low end. I don't need one-time pads. Abu Nidal does. Repeat after me. Cryptography is all economics. Eric From 74076.1041 at CompuServe.COM Tue Oct 13 08:55:18 1992 From: 74076.1041 at CompuServe.COM (Hal) Date: Tue, 13 Oct 92 08:55:18 PDT Subject: Mr. Squirrel Message-ID: <921013154244_74076.1041_DHJ92-2@CompuServe.COM> ||ugh Daniel raises some questions about using public keys to verify pseudonyms: > Hal is somewhat right, anyone can use 'Secret Squirrel' and anyone > can use any public key they want also. But, once person A creates public key X, nobody else can sign messages using X. So if all messages from A are signed under X, we can know that they are all from the same person, even if they are sent anonymously or under a pseudonym. > So, in a many-to-one scope (as > in a maillist) where the sender can not use the one-on-one signed > signiture method how do we have proff of who the sender really is? You can use signatures even in a many-to-one scope. Messages from a particular person could be signed and the signature appended to the message. Then anyone who has the public key can check to see who the message came from. The process is a little unwieldy now in PGP because you have to separate the signature and message into separate files and run PGP on the signature file. This should be streamlined. > [Good points about keeping track of key-pseudonym pairs] > But all this needs to be done automaticly by the mailers and > interfaces, else the system will be mis-used and folks will tire of > the extra work that gets them little advantage. Absolutely. The most crying need now, IMO, is to better integrate the cryptographic tools into mail readers and senders, so that it's not such a pain to use these things. People should be able to give a single command or press a button to decrypt an incoming message or encrypt an outgoing one. Only then will these features be used by average people. There was a message posted on alt.security.pgp describing how to use PGP with the Emacs mail reading program. I'd like to see more messages telling how to use it with other systems. Hal 74076.1041 at compuserve.com From pmetzger at shearson.com Tue Oct 13 08:58:32 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Tue, 13 Oct 92 08:58:32 PDT Subject: Mr. Squirrel? Just who is whom here? In-Reply-To: <9210131201.AA12086@domingo.teracons.com> Message-ID: <9210131550.AA03941@newsu.shearson.com> >From: hugh at domingo.teracons.com (Hugh Daniel) > A second thing that Hal's comments bring up is that we were reading >the From: headders and ignoreing the keys. In good crypto-mail >readers the key ought to be checked against our own data base of >others keys and the result added to the hedders as say: > KeyCheck: FooBar Bazoid holds this key in XXX database >or some such rot. I wonder what is more important, who I claim to be >in a random message or what key I include... Anyone can include your key in a random message. If you just sign your messages, then the whole thing goes away and everyone knows its from you. PGP allows you to sign messages without encrypting them. The problem is that most people find using PGP on routine email inconvenient. Perry From hughes at soda.berkeley.edu Tue Oct 13 09:03:14 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 13 Oct 92 09:03:14 PDT Subject: Mr. Squirrel? Just who is who here? In-Reply-To: <9210131201.AA12086@domingo.teracons.com> Message-ID: <9210131610.AA25466@soda.berkeley.edu> Hugh asks how, in a broadcast network, we may verify identity. The answer is "statistically." Not everyone needs to verify each message; only those who communicate with the sender personally (and who thus know the private keys) need to. Hugh mentions the "one-on-one signed signature method" and that it is not applicable to broadcast. Well, signing the whole message is not, but signing a message digest is. This is the whole reason for message digests, that a message may go out in cleartext, but the validating information for that message be encrypted. Thus everyone can read the message, even without knowledge of the public key, but it is possible to verify the identity if you know it, i.e. you know the private key. Eric From hughes at soda.berkeley.edu Tue Oct 13 09:15:29 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 13 Oct 92 09:15:29 PDT Subject: Mail headers In-Reply-To: <9210131201.AA12086@domingo.teracons.com> Message-ID: <9210131622.AA25597@soda.berkeley.edu> Hugh's comments brought up a idea to me. RFC 822 is the standard for the format of Internet mail messages. Anybody interested in the remailer should eventually read this thing. In it there is already a standard header field "Encrypted." It accepts two optional arguments, a decryption type and an identifier (say, for key lookup). So we have a way of automatically telling encrypted message without doing pattern recognition on the body. I propose a couple more header fields. "Digest" for signed message digests. "Key-Mgmt" for the distribution of new keys and key compromise certificates, i.e. for automatic key distribution. What else do we need to make a fairly automated crypto mail system? Eric From nowhere at bsu-cs.bsu.edu Tue Oct 13 10:04:24 1992 From: nowhere at bsu-cs.bsu.edu (Chael Hall) Date: Tue, 13 Oct 92 10:04:24 PDT Subject: Mr. Squirrel In-Reply-To: <921013154244_74076.1041_DHJ92-2@CompuServe.COM> Message-ID: <9210131710.AA20497@bsu-cs.bsu.edu> >But, once person A creates public key X, nobody else can sign messages >using X. So if all messages from A are signed under X, we can know >that they are all from the same person, even if they are sent anonymously >or under a pseudonym. Who's to say that person B sees a message signed under X by person A. He copies the signature (X) onto the bottom of one of his messages and everyone thinks they can verify that it's from A but it's really from B. (makes sense to me anyway...) Chael Hall Chael Hall | Campus Phone Number iuvax!bsu-cs!nowhere | (317) 285-3648 00CCHALL at bsuvax1.bitnet | iuvax!bsu-cs!bsu-ucs!00cchall | "I hate it when that happens!" From gnu at cygnus.com Tue Oct 13 10:53:19 1992 From: gnu at cygnus.com (gnu at cygnus.com) Date: Tue, 13 Oct 92 10:53:19 PDT Subject: Mail headers In-Reply-To: <9210131622.AA25597@soda.berkeley.edu> Message-ID: <9210131800.AA10408@cygnus.com> We have standards already for a fully encrypted email system. It's called PEM, Privacy Enhanced Mail. It'd be completely senseless to come up with a different format at this point, as PEM is on the verge of deployment. John From hh at soda.berkeley.edu Tue Oct 13 11:30:35 1992 From: hh at soda.berkeley.edu (Eric Hollander) Date: Tue, 13 Oct 92 11:30:35 PDT Subject: Mr. Squirrel In-Reply-To: <921013154244_74076.1041_DHJ92-2@CompuServe.COM> Message-ID: <9210131837.AA28968@soda.berkeley.edu> The most pressing thing is not to integrate encryptions in mail handlers, but at the level of ether. Ether is an enormous security hole. I can walk up to anything running ether with my notebook, plug in, and listen to all traffic. Therefore, ether cards need public key encryption built in, so they can communicate with eachother in a secure way. This also applies to all other low level protocols. e From hughes at soda.berkeley.edu Tue Oct 13 11:49:36 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 13 Oct 92 11:49:36 PDT Subject: Mr. Squirrel In-Reply-To: <9210131710.AA20497@bsu-cs.bsu.edu> Message-ID: <9210131856.AA29470@soda.berkeley.edu> A signature on a message is dependent on the contents of the message; it is not a free floating bit of information. You can't copy a signature, therefore, without copying the message or find another message that hashes to the same value. This is the design criterion behind one-way functions--that you can't (feasibly) find a message that hashes to a given value. Eric From gnu Tue Oct 13 12:12:29 1992 From: gnu (gnu) Date: Tue, 13 Oct 92 12:12:29 PDT Subject: one time pads In-Reply-To: <199210130821.AA03658@well.sf.ca.us> Message-ID: <9210131912.AA14835@toad.com> One time pads don't provide perfect security, George. They only provide perfect security if the opponent doesn't know the contents of the pad. Given that most small organizations are in locations that are easily burglarized, ``when lives are at stake'' it would be easy for governments to break in, copy the storage medium containing the pad, and then read all past and future traffic encrypted with that pad. All cryptography is economics. If you make it harder to tap your phone lines, but it's cheap to break in, they'll do that. There is no absolute security this side of the grave (and who knows about the other side). John From pmetzger at shearson.com Tue Oct 13 13:25:13 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Tue, 13 Oct 92 13:25:13 PDT Subject: Mail headers In-Reply-To: <9210131800.AA10408@cygnus.com> Message-ID: <9210131851.AA07309@newsu.shearson.com> >From: gnu at cygnus.com >We have standards already for a fully encrypted email system. It's >called PEM, Privacy Enhanced Mail. It'd be completely senseless to come >up with a different format at this point, as PEM is on the verge of >deployment. One might have a good reason to follow most of PEMs formatting standards and the like; I'd fully agree its foolish in the extreme to do otherwise. However, some of us don't like PEMs hierarchical key authentication concepts. Perry From 74076.1041 at CompuServe.COM Tue Oct 13 13:37:43 1992 From: 74076.1041 at CompuServe.COM (Hal) Date: Tue, 13 Oct 92 13:37:43 PDT Subject: New remailer... Message-ID: <921013203148_74076.1041_DHJ21-1@CompuServe.COM> I have been experimenting with Eric's remailing software on the Sun 4 I use at work. This is what I've found. First, Eric's descriptions of how all the different software components work together have been very helpful. The software has gone through three revisions as Eric added new features, so I implemented them in that order - first the basic remailer, then adding the "##" and "::" support for header management. (I had to get perl and slocal before I could get started. Luckily my system already uses sendmail.) Basically, I was able to put the parts together the way Eric described and have it work. I was able to send messages and have them remailed. I even did some tests bouncing mail between my remailer and Eric's. Then I tried adding a new feature to the remailer - automatic message decryption using PGP. It's not really very secure since anyone with root privileges at my site can see my pass phrase, but my site is pretty isolated (a 2400 baud modem is the only link to the outside world). For this I had to add one line to Eric's model .maildelivery file to invoke my PGP filter, and had to write about a five line shell script to run PGP in a useful way. I am still tuning this a little bit but I can send the exact scripts out when people are ready for them. One nice thing about this is that, with my remailer plus Eric's, and with the decryption option, you can now send anonymous messages for which no one person can tell that you did it. What you would do is to send the message first through Eric's remailer, so I don't know where it came from, then through my remailer, but with the message encrypted so that Eric can't tell where it's going after it leaves me. If more people will run remailers then we'll have much more security. I will now tell you how to use it, in case you want to experiment. But remember that all messages are going across an intermittently- polled 2400 baud modem, so don't expect fast turnaround and please don't send a large volume of messages. Also, please don't pass information about this remailer beyond this list, for now. The remailer is at hal at ghs.com. The basic remailing operation is as Eric has described: either put "Request-Remailing-To: " in the header of the message, or put, as the first two lines of the body of your message: :: Request-Remailing-To: And follow these two lines with a blank line, then the message to be forwarded. Decryption is just a little complicated. The thing to remember is that you want to do more than just have me decrypt the message. You want me to then remail the message after decryption. This means that you should prepare a message with remailing instructions as above, then encrypt the whole thing, including the "::" and "Request-Remailing-To:" lines. Encrypt using PGP with the public key I show below, and use the -a flag for Ascii output. This will create a PGP output file, typically with the extension .asc. The first line will be: -----BEGIN PGP MESSAGE----- Now, you can send this message to me, but you have to do one more thing. You have to mark it as an encrypted message, by putting the line "Encrypted: PGP" in the header. If you can't put stuff into the headers of messages, then use Eric's "::" feature and add the following two lines, then a blank line, before "-----BEGIN PGP MESSAGE-----": :: Encrypted: PGP Don't forget the blank line after these two. Now, this message can be sent to my remailer. It will be decrypted and then remailed to whomever you requested. I know this sounds complicated, so let me break it down into steps: 1. Create the message. 2. Add "::" and "Request-Remailing-To: " and a blank line to the top. 3. Encrypt the whole file using PGP and the public key below. 4. Add "::" and "Encrypted: PGP" and a blank line to the top of the encrypted file. 5. Send it to hal at ghs.com. That's not so bad, is it? Now, if you're really adventurous, here's how to do the double-remailing process I described above, the one which keeps any one remailer from knowing who's talking to whom. 1. Create the message. 2. Add "::" and "Request-Remailing-To: " and a blank line to the top. 3. Encrypt the whole file using PGP and the public key below. 4. Add "::" and "Request-Remailing-To: hal at ghs.com", then a blank line, then "##" then "Encrypted: PGP", then a blank line, to the top of the encrypted file. 5. Send it to hughes at soda.berkeley.edu The only complicated step is step 4, where you put in the remailing request to go from Eric's system to mine, and use the "##" line so that the outgoing message has "Encrypted: PGP" in the header. If you want real security, encrypt the message using your friend's public key after step 1 and send that. Then nobody will even know what you're saying, let alone who you're talking to. As promised, here's the public key for my remailer: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.01 mQBNAirY9EoAAAEB/iuDBqpeJ8gsNQwJNRYWBxH7uP95ApQ92CDhCmuSEJ0Tta0l oCrC+8Br+D7Nfotb7hJlI0A1CYGAlmCsRO8VEmkABRO0H1JlbWFpbGluZyBTZXJ2 aWNlIDxoYWxAZ2hzLmNvbT6JAJUCBRAq2ISQqBMDr1ghTDcBARYlBADCjkCkIDvA 7QFtpYUlYjz/2U+/oDuMZBDlmAw8BCg3sdJG7hnxPE4yVgKoH/ozsb23pbFTPB8H WNEjqTqixNybOKSKH9T8iCaRDA8+bS6xPN4YlWKD/Wg2EiyuOjD3v/vWgiZXzMR5 hpe0CYVJ6bM++hptXu+JxqDReJIot5FFbQ== =p8FS -----END PGP PUBLIC KEY BLOCK----- Hal 74076.1041 at compuserve.com P.S. Coming soon: anonymous return addresses! From gnu at cygnus.com Tue Oct 13 13:46:27 1992 From: gnu at cygnus.com (gnu at cygnus.com) Date: Tue, 13 Oct 92 13:46:27 PDT Subject: Where to get further information about PEM In-Reply-To: <9210131853.AA29373@soda.berkeley.edu> Message-ID: <9210132046.AA19146@cygnus.com> Get the latest Internet Drafts for PEM; the RFC's are out of date. By ftp to nic.ddn.mil, directory internet-drafts: -rw-r--r-- 1 gvaudre 35978 Sep 4 03:36 draft-ietf-pem-algorithms-01.txt -rw-r--r-- 1 gvaudre 16031 Sep 2 03:36 draft-ietf-pem-forms-01.txt -rw-r--r-- 1 gvaudre 85132 Aug 7 03:30 draft-ietf-pem-keymgmt-01.txt -rw-r--r-- 1 gvaudre 104515 Jul 25 03:30 draft-ietf-pem-msgproc-02.txt -rw-r--r-- 1 gvaudre 128 Sep 2 03:36 draft-ietf-pem-notary-00.txt John PS: I too think that other key certification models besides "hierarchical" are appropriate. I think we can start from PEM software and PEM message formats and evolve and experiment as appropriate. Before you ask, currently there is no PEM software widely available. It's in alpha test. It will be released in full source code, and its development was funded by DARPA. From fen at genmagic.com Tue Oct 13 15:56:27 1992 From: fen at genmagic.com (Fen Labalme) Date: Tue, 13 Oct 92 15:56:27 PDT Subject: anonymous bank accounts via Message-ID: <9210132256.AA08647@relay2.UU.NET> Mail*Link( Remote anonymous bank accounts via pem FYI: [pem-dev is a private email list for developers of the Privacy Enhanced Mail protocol additions to Internet mail, originally published as RFCs 1113 - 1115, and now updated as four draft-ietf-pem documents. To join the list, send email to pem-dev-request at tis.com. By the way, most of the discussion is not nearly as germane to our ideas as this particular posting, but this one caught my eye as of some iterest to cypherpunks.] ----------- Forwarded Message ------------ Date: Tue, 13 Oct 92 01:07:39 EDT >From: uunet!ellisun.sw.stratus.com!cme (Carl Ellison) To: pem-dev at TIS.COM Subject: Re: [Peter Williams: Perhaps OSI security is not possible in a liberal community!] Sender: uunet!TIS.COM!pem-dev-relay Let me throw in another vote against the *necessity* of hierarchical certification by arguing against the necessity of certification itself. For example, it is possible, given digital signatures, to have totally anonymous bank accounts -- identified only by public key -- with no certification of relationship between that key and any other fact about any individual or corporation. Such accounts are at least as valuable as a Swiss numbered account -- perhaps more so since no one need know the identity of the person or people with the power to withdraw funds. Such funds transfers can be made not only anonymously but untraceably. It might even be possible for them to be made without it being possible to trace the transfer at either end (eg., using digital cash techniques). I don't propose that all bank accounts be anonymous. It's just that I don't like to see us jump into an attempt to relate public keys into the physical world so that our old established notions about relationships and responsibility can carry over into this new domain when by doing that we end up avoiding research into all the possibilities which digital signatures open up. That research needs to be both technical and social -- or we could shy away from it by forcing relationships between keys and those entities to which we are already accustomed. --Carl From hugh at domingo.teracons.com Tue Oct 13 18:58:39 1992 From: hugh at domingo.teracons.com (Hugh Daniel) Date: Tue, 13 Oct 92 18:58:39 PDT Subject: Matching Text, Headders and Signatures with Crypto Hashes In-Reply-To: <9210131710.AA20497@bsu-cs.bsu.edu> Message-ID: <9210140150.AA12409@domingo.teracons.com> A genral and powerful method of makeing sure that Headders, Bodys and Signatures match is to use cyrpto-checksums. For example in NetNews I proposed changing the MessageId: headder such that part of the gobldyguk on the left side of the atsign was a crypto hash of the body of the message and some of the important sending host generated headders. With this system of MessageId:'s anyone who corrupts a message (intentionaly or otherwise) creates a bogus message, as the next machine that gets the message can see that the message does not match it MessageId: line. So, if we design the signature system right (with a field for a crypto hash, or some sort of secondarys signatures to in efect counter sign various includes such as the plain text) a plain text message can be signed in such a way that you can be sure that the text is the right text and none other. This can be sent over the airwaves as it is not hideing information but proveing that it is the right information! Systems like this would be *very* usefull right now, are simple to do (with good advice from Crypto Math types) and usefull to everybody. ||ugh From Tom.Jennings at f111.n125.z1.FIDONET.ORG Tue Oct 13 19:52:16 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Tue, 13 Oct 92 19:52:16 PDT Subject: Integrated privacy... Message-ID: <2931.2ADB225F@fidogate.FIDONET.ORG> U> Absolutely. The most crying need now, IMO, is to better U> integrate the cryptographic tools into mail readers and U> senders, so that it's not such a pain to use these things. U> People should be able to give a single command or press a U> button to decrypt an incoming message or encrypt an U> outgoing one. I just completed (well, it's in "beta") a mail-reader package for MSDOS and FidoNet. It does "rm" type stuff, and has PGP integrated reawonably well. Single character commands to decrypt, encrypt, sign, or encrypt/sign. It furnishes the distributed PGP.EXE program with it's imput (deriving it from the message itself). It'll extract keys from messages, and all that. It's MSDOS and .MSG-type FidoNet message base oriented, but it does all it's work in pure ASCII (FidoNet .MSG files are mixed binary and text). It is intentionally "RFC-822 like", and will become fully RFC-822 "soon". I was reasonably careful regarding de-cyphered plaintext laying about on disk, etc. It's available via Wazoo filerequest as magicname RM. (That's probably as obscure to you as FTP is to FidoNet.) It will be released as "copyleft" with all sources. Binaries only this week til I get it shaken down. * Origin: World Power Systems / FidoNews / San Francisco CA (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 Tue Oct 13 19:52:16 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Tue, 13 Oct 92 19:52:16 PDT Subject: PGP implementation for FidoNet Message-ID: <2932.2ADB2261@fidogate.FIDONET.ORG> There's a conference in FidoNet called PUBLIC_KEYS, devoted to PGP and surrounding issues. Most evreyone is enthusiastic but without security experience. As always, we find that the prevailing "right ways to do things" don't fit. FidoNet's main need is "privacy", not "Security". What would be considered very low "security" in traditional circles would be more than adequate. (And of course the usual ways work just fine with a for "real" security needs.) Follows is an article I ran in FidoNews, the weekly FidoNet newsletter. I hoep it makes sense. The FidoNet environment is a little different than other nets. * Security and authentication using PGP in FidoNet THOUGHTS ON SECURITY AND AUTHENTICATION FOR EMAIL SYSTEMS Tom Jennings (1:125/111) Some ideas on public key security systems. To sum up ahead of time, I assert that the public broadcasting of public keys is more than enough security and authentication for casual, privacy needs in the FidoNet or other email network. All of this article assumes the use of PGP version 2.0, the RSA double-key encryption system implemented as freeware. This is all new to most of us, this security/privacy thing. Both technologically and socially. What privacy we have we take for granted without much thought; letters in envelopes, "who is it?" to knocks on the door, etc. When we try to break down these things into their underlying assumptions, well, it's hard. We shouldn't get upset with ourselves or others if "we don't get it" right away. And we'll find some obvious things aren't, and vice versa. I will assume that if you really, really need utter absolute security, you can achieve that with PGP or whatever. If it's that sensitive, sending it over an electronic medium probably isn't recommended. This article isn't about how to achieve bank-vault security. Within the FidoNet, the most common use we all seem to talk about is PRIVACY, rather than SECURITY. I can only speak for myself, but, my netmail (not echomail) traffic is probably a reasonable example. I read about 100 messages a week, and send out about 50. There's a dozen or so people I talk with regularly, and about 50 per week that I do not know. Most of it is of the "Oh yeah, so and so said this. How's your mother. Did you get that file OK...". Even if an eavesdropper read this stuff, I would barely care. There are some times though when revealed message contents could be... personally compromising. Embarrassing. A real life example: a long time ago, a sysop in a net was having trouble with their net host. Some messages critical of that net host were intercepted by the host, some passed on, and some we each got replies to! Not Good. What *I* want is a way to ensure that sometimes, only the addressee can read a given message. I am willing to pay some penalty for this, but I won't live with a system that restrains me like a stone castle and moat. My needs and risks just aren't that great. With that as a background assumption, let's look at two separate issues that look at first to be the same -- SECURITY and AUTHENTICATION. SECURITY -- given an encrypted message, how likely is it that someone can ascertain what's inside it (assuming you're not the addressor or addressee)? As an operating assumption, I will take it for granted that PGP produces files that are secure in themselves (barring bugs, etc). Like the docs say, a frontal cryptological assault is hard, and in our casual privacy case, probably not what we've got to worry about. There are other ways to figure out what's going on. Imagine you're that net host. You've had trouble with this particular sysop before. You notice he's just sent a flurry of messages to the local RC, then the ZC. Hmmm!! Do you really need to know what's in those messages?! (This is called traffic analysis. In pre-WWII Germany, the Nazis tracked down "Jew sympathizers" with traffic analysis of telephone billing information; Europeans don't get itemized phone bills any longer... like here in the US. So I was told, the information is no longer kept. (Do I really believe that...:-)) Anyways, security is more than cryptographic strength. Turns out, there's a way around this: anonymous remailers. In a private Internet mailing list Eric Hughes came up with a trick to anonymously remail messages; you send mail destined for system X to the remailer instead; it strips off the header info and mails it to system X. Anonymity isn't really needed though in the case above, simple remailing will do. Again, our *general* FidoNet needs are modest. AUTHENTICATION is the sticky one for us. Authentication is determining: is this person really the person they say they are? But I think you'll see it isn't the fatal problem it appears to be at first. Let's get the obvious case out of the way first again: if you need utter and absolute security, you better damn well know the person ahead of time, you should get a key delivered by hand, and you should think about if you really want to conduct business over an electronic link in the first place. Authentication in this case isn't -- or shouldn't be! -- a problem. For our relatively-casual privacy use, authentication is almost moot. Some people I have already exchanged keys with, *I've never met face to face in my life* and may never. In spite of this I feel I know them. I trust or assume that they are who they say they are. This is the environment we need to work in. This, plus the fact that we've got (at the moment) some 16,000 potential keys, means we simply can't do the full-blast security thing. How much "security" can I expect, or need, with someone I've never met? Consider again the utter-security case again. But the bottom line is in fact already taken care of, PGP or not -- how do you know that "the real Tom Jennings" wrote this article? Our underlying social system, so frequently overlooked, takes care of it. You can assume I, and many people who have been in the net, are verifiable. You have a number of ways to determine if I really wrote this article. Simply asking via FidoNet will uncover most fakes. Looking at old nodelists to see what info on my name has changed. Ask people who might know me. And so on. If our public keys are scattered to the wind like plants scatter pollen, it is certainly possible that I could fake "your" public key, and gain access through all the methods discussed in detail in the literature. However, assuming the real person and the fake person(s) are both generating keys (and using them to sign and send messages), the more keyrings were passed around the chances of detecting the incompatible keys becomes almost certain. At that point, even a casual effort would be able to track it down, to at least determine that there *was* a fake. Example: Mary has been using PGP for a few months, and conversing with friends and acquaintances. Her public key is filerequestable, and probably appears on a hundred keyrings. Over the next few months, other people get messages from "Mary" making increasingly odd claims, via encrypted mail. The impostors fake key, in order to be useful at all, would also have to be widely distributed. Curious, someone sends Mary a message encrypted with what appears to be her public key, and a plaintext one telling her that the cyphertext was encrypted with her public key, and that he suggests if she can't decipher it someone may have faked her key. What Mary actually does depends on many things. If she has indeed been creating the crazy messages, well, the problem's elsewhere. If she finds she can't read the message, her recourse depends on what is available to her: if there are public key repositories, she would be advised to contact them and notify them of the alleged faked key(s), and follow whatever process is setup to generate a new key. The very knowledge of key collision would be enough to flag to users that there's a potential problem. There are more practical issues that limit our need for traditional security measures on keys. Even if you stored your private key on disk, it would take physical access of your machine to get it. This is not what I'm worried about in private FidoNet mail. If a FidoNet member tries to break into my house or system to get at my key, I've got other troubles! Practically speaking, it might even be a good idea to have two keys; a small (256 bit) one for casual, email privacy, and a big one (1024 bits) that you give to people by hand on diskette. The small key will mean better performance, more important on bulk casual email, and certainly adequate against eavesdropping. For high-security needs, which most people don't have (I certainly don't), the performance penalty probably won't matter as much. The worst part of security systems is that people will *rely* on them as absolutes. This is the only thing that makes a faked, encrypted message worse than a faked, plaintext message. Again, it's important to remember the goal (as if we could ever possibly agree to a *single* goal...) -- if it's privacy, the ability to stop eavesdroppers, then a broadcast public key system is more than adequate, and public key repositories even better. If you want a maximum-security vault, you take added precautions. No one system will solve all problems. I'm a firm believer in a broadcast public key system for email. PRACTICAL SUGGESTIONS FOR PGP USE IN FIDONET PRIVACY: * Use small (256 bit) keys for routine, low-security use, such as netmail privacy with people you don't know personally (and don't get keys from physically). * Public key encryption is most useful for email, ie. FidoNet netmail, especially when it flows through multiple hosts on its way to its destination. * The current password scheme for echomail links is proven to be adequate to safeguard what is basically a public forum, anyways. Further security doesn't seem to be needed on these links. * When adding keys received via FidoNet to your public keyring, answer "do you want to certify this key yourself" with NO, unless you received the key by hand. It doesn't hurt the usefulness of the key itself; however, if someone later uses your public keyring they won't be lulled into a false security. (Certification of keys can be done at any time.) * Passing keyrings around willy-nilly, though counter to "good security practice" in traditional uses is actually a good thing for us. "Key Repositories" scattered throughout the net (each exchanging keyrings as well as posting lists of "trouble keys") is a better idea. * Reserve large (1024 bit) keys for people who you know, and can ensure security in traditional ways (some pointed out in the PGP documentation). * As seems to be developing, have your public key filerequestable as magicname "PGPKEY" (your own public key only), and your keyring as "KEYRING" (all of your public keys). These should be ASCII-armor files (PGP -kxa) * Origin: World Power Systems / FidoNews / San Francisco CA (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 Tue Oct 13 22:45:57 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Tue, 13 Oct 92 22:45:57 PDT Subject: Mr. Squirrel Message-ID: <2934.2ADBB27E@fidogate.FIDONET.ORG> U> The most pressing thing is not to integrate encryptions in U> mail handlers, but at the level of ether. Ether is an U> enormous security hole. I can walk up to anything running Who uses ethernet?! :-) I think it's safe to say our FidoNet doesn't have three feet of thinwire in it. We're all dialup. Message-reader integrated security is where it's at -- here. You're totally right about it though... but it requires physical access. * Origin: World Power Systems / FidoNews / San Francisco CA (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 Tue Oct 13 22:45:57 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Tue, 13 Oct 92 22:45:57 PDT Subject: Matching Text, Headders and Signatures with Crypto Hashes Message-ID: <2936.2ADBB282@fidogate.FIDONET.ORG> U> From: hugh at domingo.teracons.com (Hugh Daniel) U> For example in NetNews I proposed changing the U> MessageId: headder such that part of the gobldyguk on the U> left side of the atsign was a crypto hash of the body of U> the message and some of the important sending host U> generated headders. With this system of MessageId:'s U> anyone who corrupts a message (intentionaly or otherwise) U> creates a bogus message, as the next machine that gets the U> message can see that the message does not match it U> MessageId: line. There's a FidoNet mailer (Dutchie) that uses MD4 to generate message IDs in exactly this way... They did some cheat, to allow certain filters (CR/LF vs LF, etc) to work. * Origin: World Power Systems / FidoNews / San Francisco CA (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 wixer!pacoid at cs.utexas.edu Wed Oct 14 03:49:44 1992 From: wixer!pacoid at cs.utexas.edu (Paco Xander Nathan) Date: Wed, 14 Oct 92 03:49:44 PDT Subject: Game items Message-ID: <9210140517.AA12767@wixer> Just about any device for refining psychoactives... Alcohol stills, for one. We run one at home in TX, legal now, but which would have been jailbait in my grandmere's time. In certain parts of TX, wirecutters used to be illegal on strangers. They implied cattle rustling, etc. Phone recording equipment is legal now in many areas - formerly forbidden by wiretap laws, but now available through catalogs like Damark, etc. It would be so easy to find counter examples - non-weapon, physical items formerly legal, now illegal or heavily watched/licensed... precision scales, lab glassware, Kevlar, radio transmitters... pacoid. From 74076.1041 at CompuServe.COM Wed Oct 14 08:27:57 1992 From: 74076.1041 at CompuServe.COM (Hal) Date: Wed, 14 Oct 92 08:27:57 PDT Subject: Game items... Message-ID: <921014151922_74076.1041_DHJ62-1@CompuServe.COM> I'm trying to think in terms of things which were illegal but which have good moral connotations today. Crosses and other Christian symbols were supposedly outlawed during the Roman empire (leading to the adoption of the fish as a symbol of Christianity). Posing as early Christians smuggling crosses ought to make the right-wingers happy! Abolitionists had to smuggle runaway slaves out of the South on the so-called "underground railroad". Perhaps cryptography would have helped them coordinate their efforts. Much of the support in the U.S. for freedom and privacy comes from our revolutionary heritage. I'm embarrassed at how little I can recall of what things were restricted in those pre-revolutionary days. I recall the Stamp Act and a few other laws, and I imagine that seditious materials were restricted. Perhaps the game players could be early revolutionaries trading items forbidden under British rule. Hal Finney - 74076.1041 at Compuserve.Com -----BEGIN PGP PUBLIC KEY BLOCK----- mQCNAiqsNkwAAAEEAMKWM52m5EWi0ocK4u1cC2PPyHT6tavk9PC3TB5XBYDegf3d sldRpnjJj1r+aO08FFO+QLEI9wtBqvf1PPP5iLX7sD2uIVlJH14MPtyVtjm9ZKb8 JMtCW74045BgtHBC9yQ3V7vXNV5jM6dE2ocnH4AI/pBFrGLJPKgTA69YIUw3AAUR tCZIYWwgRmlubmV5IDw3NDA3Ni4xMDQxQGNvbXB1c2VydmUuY29tPokAlQIFECqu M1Tidd4O/2f3CwEByrUD/3uoV2y+Fuicrrd2oDawgOw9Ejcx6E+Ty9PVPqKvflLs 0zYyGfeFVSgBbTSDP3X91N3F68nydl9J9VA6QRCGelHM1cZRukCJ0AYbKYfpwUN0 xjEGHsDrd2gT5iWlB3vBZvi+6Ybs4rSq+gyZzVm1/+oRrMen32fz2r0CLgUtHok2 =fF6Z -----END PGP PUBLIC KEY BLOCK----- From stjude at well.sf.ca.us Wed Oct 14 10:28:10 1992 From: stjude at well.sf.ca.us (Judith Milhon) Date: Wed, 14 Oct 92 10:28:10 PDT Subject: game items Message-ID: <199210141727.AA18138@well.sf.ca.us> You needn't timetravel to come up with instances of underground heroism. There is RIGHT NOW an underground dealing with AIDS meds. And there may be, soon, an RU-486 network. These are worlds away from traffic in sleazy recreationals for profit. >jude< From tcmay at netcom.com Wed Oct 14 11:06:29 1992 From: tcmay at netcom.com (Timothy C. May) Date: Wed, 14 Oct 92 11:06:29 PDT Subject: Some (Pseudo)Random Thoughts Message-ID: <9210141805.AA04539@netcom2.netcom.com> Some thoughts on the recent meetings and what we're doing: 1. The importance of trading physical goods in the Crypto Anarchy Game. This, in my view, has been given undue and misleading importance. Physical goods are inherently easy to trace through remailers (via sniffers, radioactive tracers, weight of packages, and many other physical cues), are hard to store physically (imagine getting 100 parcels for later remailing), and, most importantly, have none of the "envelope within envelope within...." protection accorded to the bits of a cryptographic remailing, or DC-Net, system! The elegance of cryptographic protocols is lost with physical goods. Furthermore, physical delivery of any good, whether drugs, stolen missile components, antiquities and art items, whatever, is fundamentally a hard problem to solve...smugglers and thieves have been dealing this since the beginning of time. Stings can be easily arranged, delivery is not anonymous (one merely watches who takes delivery, or who opens a train station locker, etc....this is all SOP for narcs and counterespionage types), and a raid on a remailing entity will result in confiscation of the physical goods and (likely) prosecution of those caught holding the stuff. (Raiding a bit remailing entity produces only random-appearing bits...granted, the authorities may well outlaw bit remailing, or use the RICO and conspiracy/sedition laws to prosecute, but that's another topic.) Our recent emphasis on physical goods, and all the ideas pouring in on what other kinds of "contraband" besides drugs can be used, is misleading. None of the richness of the cryptographic world is faithfully preserved. I urge we get back to our roots and deal only with things that can be expressed purely in bit form. 2. The "colonization of cyberspace" does not mean there is no interaction with the physical world, of course. But that interaction can be mediated with money made by converting information or digital money into physical money. Several methods for this conversion path can be considered: -Alice sells information in the cyberspace domain for the equivalent of, say, $30,000. She converts this to "real" dollars by using an escrow entity which hold both sides of the transaction until it's completed. They then mail the information to the purchaser and send an ordinary check "for services rendered" to Alice for $30K. She reports it on her taxes, probably as a "consulting fee" (for which essentially no government supervision currently exists, nor is likely to....), and the conversion has taken place. (Note: there are still elements of trust involved, notably involving the escrow agent, but trust works pretty well for many things, especially when reputations are at stake. Understanding how real businesses depend on reputations is a missing part of modern cryptology analyses of transactions...the protocol analyzers and number theorists almost never take into account how reputations work in the real world, But I digress.) -Alice and Bob trade information such that Bob gets the information worth about $30K, as above, and Alice gets another piece of information she can use in the "real world" that is worth about $30K. This might be stock tips, or, better, information she can turn around and sell in the "open market" of a service like AMIX! There are lots of wrinkles, inefficiencies, etc., to be worked out. -And then there is digital money. You all know about this, or should. David Chaum, DigiCash, blinded notes, credentials, etc. The handout for the first meeting had a glossary of terms. (IMHO, we should be spending more of our time at our meeting discussing this, and less in playing more interations of the Game.) The fascinating novel "Snow Crash," by Neil Stephenson, makes a mistake in having Hiro Protagonist a very wealthy man in the Metaverse (Stephenson's term for the virtual reality cyberspace) but a very poor man in the Real World. Information _is_ money. Information is liquid, flows across borders, and is generally convertible into real money. (One simple conversion strategy, alluded to above, is for Alice to sell her information for, say, $500K, and then to receive a "consulting contract," perhaps called a "retainer," of $50K a year for the next 20 years. Her retainer is fully legal, is perhaps handled through cut-outs who specialize in this kind of thing, and is a low-risk way to "launder" money from cyberspace into the real world. I have a lot more to say on these schemes, perhaps later.) 3. Are we emphasizing "The Game" too much? If the goal is to produce a paper-based game, similar to "Monopoly" or fantasy role-playing games, then I suppose more practice is needed. But I'm not sure how worthwhile it is to try to design such a game. (Those who wish to should do so, then commercialize it, and become the Avalon Hill of crypto games!) If the goal is educational, for newly interested folks, then I also question how much more effort should be put into it. The ideas of anonymous remailers, of digital money, etc., are, I think, gotten across in the first 60 minutes of the game, especially if some of the formalism is first explained (as it was at the first game, where digital mixes, tamper-resistand modules for implementing mixes, the "Dining Cryptographers Protocol," and digital money had all been freshly covered, so participants were putting the theory to test). I found the first game was instructive, the second much less so (and _not_ because of the focus on drug selling...that was a relatively minor issue). My impression is that many of the newcomers--and they should jump in here with their own reactions (too bad we don't have hypertext links!)--didn't really know how remailing mixes work, how digital psueodnyms can protect privacy in transactions, and how the "Game" was intended to exercise these concepts. 4. We need to talk about the charter or purpose of the "Cypherpunks" or "Cryptology Amateurs for Social Irresponsibility" (CASI--Eric Hughes's term) group. -Is it mostly educational? -Is it a lobbying group, as are EFF, CPSR, and the like? -Is it to produce remailers, digital money, and other programming? -Is it subversive? Now clearly we can't say it's subversive (any bets on who's gatewaying these messages to Other Listeners?). But we also don't want to skew things toward "YALG" (Yet Another Lobbying Group), nor do we want to be a spoon-feeding educational group for people with a casual (and transient) interest in crypto stuff. 5. There have have been several messages so far about worries about the legal implications of these topics, about how some corporate-affiliated subscribers will desubscribe "real fast" if certain discussion trends continue, and so on. Now we can't please everybody, but maybe we ought to talk about this sensitive issue soon, and _in person_. Since it relates to our charter, Point 4 above, I recommend we do this at our next meeting. I'd favor that over another iteration of the Game. In conclusion, we are in at the beginning of Something Big. While I'm somewhat skeptical about the claims for things like nanotech, I see this whole cyberspace/cryptology/digital money/transnationalism ball of wax being _much_ easier to implement. Networks are multiplying beyond any hope of government control, bandwidths are skyrocketing, CPUs are putting awesome power on our desktops, PGP is generating incredible interest, and social trends are making the time right for crypto anarchy. I look forward to hearing your views. -- .......................................................................... 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 2.0 and MailSafe keys by arrangement. From hh at soda.berkeley.edu Wed Oct 14 11:11:49 1992 From: hh at soda.berkeley.edu (Eric Hollander) Date: Wed, 14 Oct 92 11:11:49 PDT Subject: Mr. Squirrel In-Reply-To: <2934.2ADBB27E@fidogate.FIDONET.ORG> Message-ID: <9210141810.AA14191@soda.berkeley.edu> >Who uses ethernet?! :-) Everyone here at UC Berkeley. >I think it's safe to say our FidoNet doesn't have three feet of >thinwire in it. We're all dialup. Message-reader integrated security >is where it's at -- here. In the case of FidoNet, it sounds like that's what's needed, because your mail is being sent from systems that are not multiuser systems. The net really is just for exchanging files and mail; it isn't for remote computer access. >You're totally right about it though... but it requires physical access. Physical access is much easier than people think. I can walk into almost any computer room here at UC Berkeley and plug in. And we have something called building ether in the building I work in: all of the machines in this section of the building are on the same ether net. This means that if we want to see other researchers' data before it's published, we can, because we can see all of their packets. e From Tom.Jennings at f111.n125.z1.FIDONET.ORG Wed Oct 14 17:26:19 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Wed, 14 Oct 92 17:26:19 PDT Subject: illegal objects Message-ID: <2952.2ADC70A6@fidogate.FIDONET.ORG> Hell, there's real-world examples today that some of my friends have been harrassed for: "Obscene materials". OK, sexually explicit photographs are a trivial example. Friends have gotten harrassed (by US customs) for zines containing weird shit, not just sexually explicit. The US/Canada customs people are living in another century and reality plane. * Origin: World Power Systems / FidoNews / San Francisco CA (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 Thu Oct 15 02:10:13 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Thu, 15 Oct 92 02:10:13 PDT Subject: Game items... Message-ID: <2962.2ADD350B@fidogate.FIDONET.ORG> Screw this fake scenario shit, here's some real ones: -- Safe sex in the age of AIDS. Guess what -- oral sex is safe. Cum in your mouth and stomach does not transmit HIV. *No one* is tracking healthy people. There were *two* "documented" cases (none of the above type) that seemed to be oral transmission of AIDS. Saying "oral sex is generally safe" would amount to condoning oral sex. Fat chance in the US. -- HIV is not always involved in AIDS. -- Not all people with AIDS die on schedule like the CDC says. AZT kills people. Many people live years and years. Some few haven't died since the "discovery" of AIDS in 85/86. No one is studying them either. -- Access to genuine information on RU-48 (?) the so-called abortion pill. Turns out it does some cool stuff re: breast cancer and even morning-after abortion. -- Access to sexuality information of all or any kinds. Not all people do the ole missionary position. Erotica of all kinds. If any of these things got a reaction out of you, then maybe they'd make good examples for privacy/encryption scenarios. * Origin: World Power Systems / FidoNews / San Francisco CA (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 Thu Oct 15 02:23:21 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Thu, 15 Oct 92 02:23:21 PDT Subject: one time pads Message-ID: <199210150922.AA09387@well.sf.ca.us> Re. your point about security and burglary. An intruder could copy a one-time pad, but of course an intruder can also copy the private key to an RSA system as well. I'll admit that physical key control is easier with public key systems: one just keeps one's key disc in one's personal possession at all times, and keeps a couple of backup copies in the hands of close trusted friends or family who understand and will take equal precautions. One could also design physical storage media which are intrusion resistant in the sense of self-destructing if tampered with or fed the wrong password; these would work as well for OTP keys as for RSA keys. In some conceivable applications, physical security can be insured as a matter of the vital interests of the participants. Again, I'm by no means trying to suggest that OTPs be considered for particularly wide application. Rather, that OTPs and a range of other systems be designed, implemented, and made available so that potential users can make their own informed choices. -gg From Tom.Jennings at f111.n125.z1.FIDONET.ORG Thu Oct 15 03:12:15 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Thu, 15 Oct 92 03:12:15 PDT Subject: Mr. Squirrel Message-ID: <2963.2ADD42BF@fidogate.FIDONET.ORG> U> > Who uses ethernet?! :-) U> U> Everyone here at UC Berkeley. Well, yes, but my point was really that we don't have one problem with a single solution. What's a gaping hole in one system (physical access) is a big HUH? in another. * Origin: World Power Systems / FidoNews / San Francisco CA (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 hkhenson at cup.portal.com Thu Oct 15 03:39:36 1992 From: hkhenson at cup.portal.com (hkhenson at cup.portal.com) Date: Thu, 15 Oct 92 03:39:36 PDT Subject: Game items... Message-ID: <9210150128.1.14673@cup.portal.com> I have not been paying enough attention to the cyberpunk list, but I did notice that some of you were concerned with the subject, and that Tim May was mentioning "pure information" as a better model to play with, so I thought I would send this in as a sample. Perhaps some ideas of where to take the story will come out of using this model for another game. Anyway, this game theme should not push as many hot buttons as drugs do (though it should!). This fragment of a tale was written shortly after I came back from the first Computers, Freedom and Privacy conference. It is placed in the time period between now and the usual time frame of Gibsonian cyberpunk. It was written to help me think about the social & legal responses we might see when encryption is more widely available-- and used. Sorry the story is incomplete, I just got too busy to finish it, and ran short of ideas as well. And sorry for the obsolete technology involved. I am sure something better than MS DOS will come along eventually. :-) (The usual conditions of posting apply--copyright H. Keith Henson 1991) Green Rage by H. Keith Henson "'Nother hour and I can 'crypt and email this mess." Lenny closed the forth of five files: maps, diagrams, schedules, assignments, and instructions. It was a four person monkey wrench project for destroying a big piece of a paper mill and (he hoped) making it look like an accident. It was due to take place on the east coast in a few weeks. Lenny had never met any of the people who had scouted out the plant, nor the bitter, out-of-work engineer who had figured out how to wreck it, and none of the operators who were involved would meet each other. Made for hard-to-crack operations. Some people on the east coast did the same for the covert side of the GreenRage group that paid Lenny. The tofu sandwich he had for breakfast was a dim memory. "Lunch first." Lenny thought. As he headed out to pick up a vegetarian pizza, he looked through the little glass panels in the front door. "Oh, shit, suits outside," Lenny said it with feeling, but kept his voice down. He turned on his heel in the hall leading to the front door and ran back into the grubby GreenRage office in the dining room of a rented house in San Samon. He managed to hit the power switch on the PC at Stel's desk before the door opened. Stel was in the bathroom. Whether she heard the warning or not, Lenny could get no help from her, and Marge was out on errands. The door was opening--there was no chance to get to the other two computers or to take down the '586 file server in the kitchen--he looked up and in his best bright and cheerful voice (which to Lenny sounded hollow and rehearsed) said, "May I help you?" The first of the four suits, a beefy dude in a grey outfit spoke up. "Yes, you can. We're from the CCA. (The Computer Control Agency): We have a court order to copy all the computer files in this building," (he held up an official looking piece of paper--more trees destroyed, thought Lenny.) "so unless you want to be charged with contempt, you can step back from that computer, and don't touch anything till we are done." Lenny stepped back. He wasn't as terrified as he could have been, though his heart rate must have been close to 120 and his mouth was dry. He had been through raid drills and a few real confrontations with the law at pickets and bleed-ins. "At least it isn't a search warrant, we might keep operating" he thought. Then remembering the drill, spoke up: "Can I see the order?" The beefy one handed it over while his three leaner and younger companions fanned out to the computers. They obviously knew where the computers were, but that did not necessarily mean rot in the organization. How well they coped with the 'puters would say something about that. The paper was about what he expected, an order signed by a judge to copy every storage device in the GreenRage's office to an encrypted WORM drive. The box for paper documents wasn't checked, so they knew they wouldn't find anything useful on paper. Bad sign, it meant they knew more about GreenRage than Lenny liked. "Waste as much time as I can," Lenny thought to himself, and in a very polite voice he asked: "Can I see some ID for you and your men? The closest of the technoids, as Lenny thought of them looked up in disgust after putting his hand on the back of the ancient '386 clone Lenny had just killed. "Its been turned off in the last 2 minutes. Did you do it when we came in?" he said this looking right into Lenny's eyes, while digging out his badge. Lenny didn't lie with his reply, "Its Stel's, she was about to go out, and we try to save power by turning them off when we go out." He said this as loud as he dared, hoping that Stel would hear him in the bathroom, then spoke up even louder, "Stel, we have official visitors, so don't make any sudden moves." At 200+ pounds, and fifty plus years, Stel didn't make many fast moves, unless they were on young guys. In view of the constant water shortage, the chances were only about one in four that she would flush the toilet, and less than even that Stel would wash her hands. Without any running water sounds, she come out. "Pigs, huh." Stel had been politically imprinted as an anarchist at Madison over thirty years ago in the late '60s and early 70's. When it suited her, she could be one of the most obnoxious people Lenny had ever known. At least it diverted the attention from him, chances were low that the cops would grill Stel on who shut off the power on her computer. Beefy, whose' badge claimed to be one Dan Barker, and technoid #1 (Lenny never did get a name for him, flashed their badges. Lenny grabbed a whiteboard marker (almost dry, and the only non computer writing device permitted in the office) and scribbled Barker's name and badge number on the edge of a badly cluttered whiteboard. The other two technoids had fanned out, one to Lenny's desk, and the other to the kitchen. The kitchen one came back shaking his head. "No damn keyboard or display on the server. Have to go in through the other ones to dump the disk." Technoid #2 moved the mouse on Marge's machine, but thank the green mother, thought Lenny, the screensaver program had timed out, and the "I NEED A PASSWORD!" message came up. That meant the password was gone from memory on that machine. Technoid #3 hit paydirt on Lenny's machine: the screen was still alive. He hit the space bar, and pulled out a little alarm timer which he set to go off every 3 minutes. "Damn, damnit" thought Lenny, "I should have set the timeout shorter, has it really been less than 5 minutes since I got up?" And he was mentally kicking himself for not wiping the password when he got up. Technoid #3 noted the directory (ACIDRAIN/TRMINATE) where Lenny had been working and went back up, a level at a time to the main directory on the file server. He seemed prepared to deal with a no printer machine, pulling out a pad of paper from a little portfolio (more trees!) and started making notes on the directory structure. Technoid #2 looked up from Marge's machine and asked Lenny, "I don't suppose you would know the password?" Lenny shook his head and then looked the agent in the eye. "No sir! I certainly wouldn't know Marge's password to get into her personal machine!" And wouldn't admit it if I did know, he thought. Technoid #2 looked over at Stel frowning at the machine on her desk and asked mildly, "I don't suppose you would remember your password?" "Fuck off sharp one," Stel said with a straight face. Even in a near state of panic, Lenny got a flash of amusement as Beefy started to spit out a hot reply. Beefy checked himself as he saw #2 write down fuckoff#1. Stel grinned slightly; she had almost scored one on the agents. Without making a move toward Stel's machine, #2 asked #3, "Shall I try it, Jim?" Jim was engrossed, paging through directories but he mumbled: "No, let's see what I can get before we risk a password given under duress." And, half a minute later, "This is going to be a bitch, I can't find any programs to dump memory, no debug, no basic, no smalltalk, no turbo, nothing." Lenny grinned, and straightened his face with an effort. The crypt program had come with instructions to delete or encrypt under a special key a long list of compilers and interpreters-- not that he understood exactly what they were anyway. "Bob, could you have one of the uniformed officers get the camera out of the car? Looks like we are going to have to photograph some of this." Beefy went to the door and tried to get the attention of one of the uniformed cops that had come with them. No luck, they were both out back, keeping an eye on the building power switch so no one could turn it off. It was less distance to the car, so he just walked out to the car, rummaged around in the back seat and brought back the camera kit. Jim waited for him, typing a space every 3 minutes. "Take it easy on the polaroid, damn film costs two dollars a shot," as he handed the camera kit to technoid #3. Technoid #2 came over to help and started clicking shots of the screen as Jim worked his way around in the directory tree. There were *lots* of interesting directory and file names. Stel, Marge, and the three masked visitors from back east had spent a whole evening making up provocative names like HIT_LIST (Lenny's address book), and $LAUNDRY (data for a spreadsheet program Marge used), and a lot of disaster names like HINDENBG, and TEX_CITY. Since the crypt program left the directories in the clear, they thought they might as well make them amusing. At the moment, with cold sweat dripping down his back, Lenny wished he had made the directories a little *less* provocative. Once in a while, technoid #3 or Jim as Lenny was beginning to use to identify him--gotta scribble that name on the white board--would give the command to type out a file to the screen. He either got a mess of published material from decade-old anarchist newsletters, some of which they carefully photographed on the screen, or computer-generated random bytes (which, of course, they thought was encrypted material). One or the other of the technoids not sitting at the screen kept themselves shielding the power switch and plug. Stel was sitting on the grubby couch waiting for the technoids to either break into the system or screw up. Lenny went over and joined her, feeling miserable about the agents getting in through _his_ system and unwilling to watch any more and give away by body language when they were about to trip. He glanced at his watch. The damn cron program should ask for the password in another 20 minutes. "Jeez," he thought, "I hope they don't get anything." "There are _10_ copies of something which looks like a word processor on the server hard drive--they all have the same byte count and date, and there is _NO_ 'path' set," technoid #3 bitched loudly enough for Lenny to hear. (Happened that this was an accident. Lenny had found that if he copied the word processor into each directory he made, it worked fine.) The server had an old 700 Mbyte drive, and a few copies more or less of a half Meg program made no big difference. However at the moment, the technoids had concluded that this was a clever hack, that the system would wipe the password out of memory if they tried to run the wrong word processor program. They outfoxed themselves: any one of them would have worked fine. ("Type" or "copy" to the screen wouldn't work because the WD*11.0 stored files in compressed binary.) "Well, Bob, it is moment of truth time. We can take a 1 in 10 chance of starting up the word processor and looking at the files, or we can try to load in a program to extract the key from this thing's stinking memory. What say?" "You guys are the experts, don't ask me." After a short conference, technoid #3 fished a diskette out of his pocket, kissed it for luck, and stuck it in the drive on Lenny's machine. "Here goes nothing." and he typed "dir a:". The crypt program was watching for diskette access, and came back with: "I NEED A PASSWORD! "Shit." whispered a dejected technoid under his breath. "Know anybody at NSA?" ---------------- Lenny put the back of his palmtop on the microphone of a payphone and hit the dial button. "That will be one dollar for the first minute." Bong, bong, bong, bong. "Thank you for using ESJI, you have one minute." Buzz-click, "Hello, there is no one here at the moment, but you can record a message." "Here" was a little module of code in an automated PBX/voice mail machine watching for incoming calls after working hours on a line deep in the list of numbers assigned to a small corporation. It was an old machine, and unlikely to get another software upgrade. After taking a call, it would not take another for several hours, and it rotated through several recorded messages. Lenny hit the next button down on the palmtop. #-Beep, 4-Beep, 3-Beep, 6-Beep. "confirm with password. L-beep, E-beep, N-beep. "Record message. End with any key." Beeeeep. "Nancy, its Murray, just called to say hi. Get back to me sometime when you get a chance." #-beep. "Message confirmation number 36, repeat 36," and a click. The PBX made a local call to a paging company and transmitted what looked like a phone number. The phone number digits added up to 36. Lenny punched 36 into his palmtop and hit the enter key. It came up with an address, a description, and a phone number. It was the phone next to the K-mart entrance about a mile away. "K-mart will be closing about the time I get over there," he thought. "Could have taken the bike." He closed the palmtop. It sensed the closing and erased its encryption password. Lenny got back in his tiny 5 year old "B-car," the 60 mpg car some rich dude had been force to take in a package deal when he bought a 20 mpg Lincoln Towncar. He twisted the key. The lights dimmed as the catalytic convertor came back up to heat on the battery. There was a few seconds' wait to let the battery recover, and the car started. Lenny watched for cops as he drove over to the K-mart, but he didn't drive *too* cautiously. That was one sure way to attract attention. There wasn't much of a mob leaving the closing K-mart on a weekday. Lenny parked near the phones and walked over. He was about 20 feet away when the one on the left rang. He picked it up and said, "36." "What's the problem? If you forgot your key, I can't help." The voice on the other end sounded odd. It was probably going through some blind location in Mexico where the automatic number identification had not yet been installed. It also had the quality of digital speech. Original words of the speaker were being converted to phonemes and back to words. Not a hint of the speaker's real voice quality came through, though this dodge did not affect word choice and rhythm patterns. "Agents," Lenny said. The CCAs came in early this afternoon. I don't think they got anything, but I needed someone to talk to." "Dumb idea if they are watching you, but tell me what happened anyway." Lenny related the events of the afternoon up to the point where the agents lost the password on his machine by trying to load a memory dump program from a diskette. And then he went on. "After that, they popped the cover off the server, hooked up their gear and copied the 700 Meg disk, a few dozen 60Mbyte SMs, and a few dozen 3 meg floppies. One of them had your crypt package. They didn't mention my palmtop, and Marge keeps the backup tapes at home. Only took them about 2 hours. They put the covers back on and left me with what they called a PK encrypted 2.4 Gig WORM cartridge. They took one just like it, and even made me choose which one I got. The order said I was required to take one of them. It has all kinds of legal seals and signatures on it. They said take it to our lawyer. One of us took it over about 5 pm. None of us have a way to read it. Are we in trouble?" There was quite a delay. Then, the digital voice spoke up. "Even if they were able to track me down, *I* am not in trouble. I make a point of posting all the programs I ever give out. In source code yet." "I don't think you are in trouble from what they took with them. The copy they left with you is the data off your disk, encrypted with a half-key the judge issued. Until the hearing they can't read it because they lack the other half of the key. The only use for it is to keep them from making a copy of data, changing the data and making another one of those write-once cartridges. So, you are ok till the hearing." There was more delay, then the funny sounding voice on the other end of the line went on. "Presuming the passwords are not compromised, even getting the other half of the key from the judge to look at what they took should not be a big problem. But since they came in at all, I would say you are in big time trouble. That was a piece of dumb luck that they didn't try WD* on your files. Of course they always have the option to give you blanket immunity and force the key out of you, but by the time they get around to doing that, you can forget the key. I sure would. I presume you had the machine convert all the files after they came in to a new password?" "Not yet. I haven't let anyone put a password into any of the machines since they showed up. I'm afraid they will have a camera bug looking over my shoulder. About a month ago, I read in the paper that they did that to a bookie in St Paul." "Not likely for you--but possible. Hmmm, did they leave any judicial orders about not moving the machines?" "Not from what I read on the court order. I can ask our lawyer. Our lawyer may be good at filing objections to logging company projects, but I think he is out of his depth if they go after us criminally. I can't afford a criminal lawyer. I called around and the best deal I could get was $100k retainer, cash or gold, no checks." "They have already gone after you criminally. You don't get a data search order from a judge without a fairly good reason. On the other hand, it was not a search warrant. It is arguable that they shouldn't have gone looking at stuff in your files, but who needs to argue? They either don't have enough on you for that or they are waiting to see what you do and who you talk to after the DSO. I don't know and don't want to know what you are doing, but there must have been something that tipped them off." "I can't think of anything--even if the people we are sending email to on the east coast had all been turned, I can't see how they could have traced it back to us. Mail to them was going through about 10 blind links, sometimes took 3-4 days to get cross country, it was deep 'crypted all the way, and somebody donated the digital stamps." "Never like to use digital stamps I haven't bought myself with cash, and then only from a reputable Swiss bank. But I can't see how that would have done any harm . . . . is there any chance the stamps might have been 'used?' That would certainly compromise your traffic, though not the messages." "Nope, a few of the messages circulate back to us. They wouldn't if the "stamps" were no good." "Not necessarily true. The mom and pop forwarders often accumulate stamps for a week or more before sending them to the bank. You just can't check with a bank on dollar or sub-dollar amounts--connect time eats you up. "The first link was Telesis, and I know they are on line to the bank that issued the stamps . . . . Unless they are . . . . in on it. . . ." Lenny was looking right at the Telesis logo on the phone. "Yeah, '/Paranoia strikes deep/' . . . . Did the court order say anything about why they were going after you?" "No, there was a note on the order that the supporting affidavits were sealed." "You guys rate! There hasn't been a sealed affidavit for a DSO I know about in the last ten years. The stink around the Steve Jackson warrant took years to wear off! Well, they have to unseal them before the hearing. The hearing has to be within the next three weeks if I remember right." "You do, it's on the 9th of next month, 20 days from now." "Well, the first thing you should do is change the password, so you can start forgetting the old one. How much clear stuff was on the disk? "None that I know about . . . . well actually about half the disk was filled with the nastiest old published stuff we could find--rabid libertarian literature and anarchist newsletters, public domain stuff off a CD ROM. The rest was filled with random numbers from a noise card when your guy set it up last year, then we deleted about half of it to give us working space. But far as I know, there was nothing to worry about in the clear. Snooper hasn't been complaining about unencrypted files when I run it on startup every morning." "There is a hole in that program, but it takes some very special circumstances for it to fail. I kind of doubt you are being watched. If they were going to go to that much trouble, a search warrant instead of a digital search order would have been the way to go, but if you are really worried about them looking over your shoulder, take your machine and the server to a random motel you've never been to before. Lets see, if you had to do the whole disk, it would take maybe two hours. You shouldn't lose anything if you have to interrupt the process in the middle--wait, yours is a 3 person office?" "Yes." "Main password, and then one for each of you?" "Yes." "Option 4:7 is what you want to use. It will decrypt only through the old main password, and reencrypt through the new password. Data never comes up to clear. Try that." "Ok. Should I take it off to a motel?" "Suit yourself. You know how good or bad you have been. But do keep me informed. Hasn't been a case this interesting in years. Random route Email by preference, but call if you need to, same method." ------------- Lenny and Marge checked into a motel which had definitely seen better times, but was happy to take cash. A lot of people had quit using credit cards, especially for checking into a motel on the hourly plan. It was just too easy for people to tap into credit card records. The swimming pool was dry in July, but what the heck, they weren't here for swimming. "I can't believe this, Marge, this power outlet has only _two_ holes." "Lenny, this place was built before they invented grounding plugs, what do you expect." "Well, what the heck are we going to do now?" "First we look around. No problem, the socket in the bathroom is a 3 pronger." Lenny plugged in the powerstrip while Marge plugged the pieces of the PCs together and connected a short network cable between them. Lenny joked to keep down his nervousness; "Wonder what they thought of us." Not many couples bring in couple of PCs to do perverted things in the dark." "Lenny!" Marge said sharply. "No, Marge, I meant the _PCs_ will be doing things in the dark, not us." Marge picked up on the joke by looking disappointed. She really wasn't. Lenny was one of those rare guys who just did not care about sex with anybody. Her regular boyfriends knew she was not getting any at work. -------------- The 'crypt program rejected the first three passwords Lenny tried as too simple. Which to him meant easy to remember. He finally got it to accept anhtre spelled a at n7t%h7e$r (the password program would drop the final r). Lenny's first password had been sesame. He had used variations on opendoor, opendore, openwindow, enterhere, portculius, drawbridge, safedoor, gateway at various times. If anybody had a list of his passwords, they would be a long way up on selecting attacks. He felt he was doing the best he could to make them complex, but still rememberable. He left the duress password (bugout) alone. It was one he had kept using for years, and never had needed. Lenny wasn't certain he would use it if he got a chance. Even though Marge backed up the disk every week, he would lose a lot of work if he used the duress password and wiped the disk. ----------- They crammed the computers back into the tiny car five hours later. Marge dropped the key in the slot by the office and they drove back to the GreenRage office where Marge and Lenny set up the machines and Marge started the backup program. The CCA observer made voice and printed notes of their return on his palmtop from the stakeout location inside a furniture company office about a block down the street. --------- The office never got up to full productivity over the next five weeks, but Lenny did finish and email the project--with notes to the effect that the enclosed was chapters from a book he was writing, and a true-to-life description of the data search order being carried out. He left it up to the folks on the other end. If they wanted to carry out a project which was in the hands of the cops, it was on their heads. ---------- The DSO hearing went about as expected. The judge granted a two week extension over the protest of Bruce, the GreenRage's lawyer. When the day came, Lenny, Marge, Stel, and Bruce were all looking more respectable than they usually did. Even Stel was wearing a dress (long out of style, but the only decent one she owned). The hearing at the federal building started in open court with a request from the US Attorney for the judge to review the CCS's material in camera. "Mr. Mulronny, I have already looked over the affidavits you sent over, and I can't do it. I already granted you an extra two weeks, and the law can only be stretched so far. You either have to make a case and let these people defend their data, or you have to drop it." Mulronny looked unhappy, but was prepared with the unsealed affidavits. He gave one to Lenny, one to Bruce, and one to the judge. The judge looked at Bruce, "Your honor, this is only about 11 pages, I think my client and I can review it during a short recess, or you could take up other actions while we review this." Court matters were running a little ahead of schedule that morning, so the judge had the clerk pencil them in after the next two short actions. They went out in the hall, not worrying about snoops except being overheard. The last time a judge found out that someone was bugging the courthouse, the head of the agency that did it spent time in the drunk tank for contempt. Lenny had read the affidavit almost through when they reached the far end of the hall. Bruce waited till he finished, and said, "Well?" Lenny shook his head, "They're after someone else. I've read about some of the events they are citing, but I sure don't know anything about them." That wasn`t entirely true. One of the "events" was one Lenny had put together, but when it didn't come off within a year, he had decided they had chickened out. Since the project he had put together took out much of an oil refinery, he was not surprised. Industrial sabotage on that scale took more than a little guts. When the plant finally blew up, Lenny watched the papers for weeks, but never found out if it was ruled accidental. The feds did not seem to be sure either, they only mentioned it as a possibility. The other accusations were split between cases where Lenny strongly suspected sister organization had done the deed, or industrial accidents where some organization had taken credit for what was probably an accident. Back in court Bruce complained to the judge that there was nothing substantial in the affidavit supporting the DSO, and that while his client did not have anything to hide, the government was asking to break into the confidential business records of a public interest group. And if they would not just forget the whole thing, he wanted more time to respond. The US Attorney would have asked for more time to respond if Bruce had not, so he was agreeable. The clerk set a date for 6 weeks off. -------- Lenny was paralyzed from the neck down. The judge was asking him for the password, and he could not remember it. The bailiff, clerk, Bruce and Mulroony were all talking in a huddle and he could not make sense out of anything they said, no matter how hard he tried. "This will do it!" one of them said, and jammed a furry dead fish under his nose. Lenny found he could move as he pushed it away. He woke up to find the cat had been licking his face and smelling of fish flavored cat food. 5:14 AM. "There isn't much point in trying to get back to sleep," he thought but Lenny flopped back on the bed. The cat started to purr and kneed the covers. Lenny absently rubbed its head, and thought about the next fundraising letter. The DSO had had the effect of galvanizing the GreenRage membership, so donations were way up, and for the first time in several years, there was more than just a little money in the bank account of GreenRage. Of course, it was flowing out almost as fast. Even though Bruce charged about half the going lawyer rate to public interest organiztions, fighting the DSO was going to cost them a bundle. "Just how much of the stuff on the disk is going to cause trouble," Lenny realized he had spoken outloud. If they asked for a special master, the membership list could be declared off limits. Unlike the old days, when the cops could look through outgoing mail at the post office, an electronic mail list was fairly secure. There wasn't much of interest in the finantial records either. Oh, a few thousands spent for sabatage material would be hard to account for if they really dug into it, but the bulk of the money was spent on saleries, office supplies, rent, and telecom charges. They could always claim the money was spent on spray cans and ceramic spikes for trees. And we can say we spent it for dope. Lenny grinned at this one. He had given up smoking dope, made him too paranoid. But, every fall some unknown but appreciated benifactor sent the office a plastic tub of the stickyest buds you could imagine. Perhaps one of their above ground efforts had saved some trees screening the "crop." Marge and Stel had split the tub the last two years. The problem was not the lastest project. Nor was it the one or two a month Lenny had put together over the last 3 years. They were long perged, and the disk space overwritten. And he didn't worry about the contents of the newletters. Presumably *somebody* on the list was a ringer, and the cops had a collection of *The GreenFlag.* What woke Lenny up in the middle of the night (besides his cat) was the stuff which they had on that WORM disk which *had not yet happened*. He could probably get away with claiming that the files on the events which had happened were interactive fiction based on news stories. Or could he? Nope, the damn files are dated prior to the "events," he thought. And, even though fewer than half of the projects he had worked on ever came off, there were at least three or four of them they could nail me on. Lenny turned the light on and pulled his palmtop out of the charging stand next to the bed. He stretched the keyboard out to full size and set there trying to put his thoughts in order. After entering his password, he brought up an organizer program. It prompted: State the problem. "I don't want to go to jail for conspiricy. The only way to stay out of jail is to keep the cops from looking through the GreenRage computer files. Or is it? If they can't convence the judge that they need to look through the files, then no problem. If they can, then they come asking me for the password. Assuming they can't crack the encryption-- which seems likely. If I give it, I go to jail, if I don't, I may get jailed for contempt, unless they give me blanket immunity. In either case, my days of managing monkey wrench projects are over." The organizer program came up with: You have used one or more legal terms. We recommend you submit your completed outline to a lawyer. It then proceeded to break the statements into an if-then-else logic tree which did not help Lenny much either. From hh at soda.berkeley.edu Thu Oct 15 17:08:10 1992 From: hh at soda.berkeley.edu (Eric Hollander) Date: Thu, 15 Oct 92 17:08:10 PDT Subject: one time pads In-Reply-To: <199210150922.AA09387@well.sf.ca.us> Message-ID: <9210160007.AA18430@soda.berkeley.edu> Physical security is not a big issue for RSA (in the pgp implementation) because the secret key ring is itself encrypted. The problem is not so much physical-intrusion-to-get-the-key as it is physical intrusion aimed at modifying software. It would be easy to modify pgp so that the keys are logged, etc, in a way transparent to the user. This is why it is important to keep both the keys and the software that manipulates them off line. It is also important to keep the software from being tampered with. The best way to do this is to put the keys and the software on a hard disk, and put the hard disk in a computer, and carry the computer with you whereever you go. e From hh at soda.berkeley.edu Thu Oct 15 17:23:16 1992 From: hh at soda.berkeley.edu (Eric Hollander) Date: Thu, 15 Oct 92 17:23:16 PDT Subject: Game items... In-Reply-To: <2962.2ADD350B@fidogate.FIDONET.ORG> Message-ID: <9210160013.AA19109@soda.berkeley.edu> >-- Access to genuine information on RU-48 (?) the so-called abortion >pill. Turns out it does some cool stuff re: breast cancer and even >morning-after abortion. RU 486 (no, it's not Intel's pharmaceuticals division). This is actually a really good example of something that could be the subject of the game. Medical researchers need it because it has the potential to save lives. However, synthesis and import of it into the United States is banned, no matter what quantities are needed or what use it is needed for. It is an interesting and powerful substance and we should be doing research on it, but instead we are letting a small minority of people with no medical knowledge dictate the policy of our entire nation. Oh well. I hope to have European citizenship someday (especially if Geroge wins). e From shipley at tfs.COM Thu Oct 15 18:03:41 1992 From: shipley at tfs.COM (Peter Shipley) Date: Thu, 15 Oct 92 18:03:41 PDT Subject: one time pads In-Reply-To: <9210160007.AA18430@soda.berkeley.edu> Message-ID: <9210160103.AA06271@edev0.TFS> > >Physical security is not a big issue for RSA (in the pgp implementation) >because the secret key ring is itself encrypted. The problem is not so much >physical-intrusion-to-get-the-key as it is physical intrusion aimed at >modifying software. To add my two cents, I once had some sensitive files solen from me. the cracker had modified the crypt command to record passwords and current directory (since crypt only works on stdin and stdout). In a matter of a few days they have my crypt password and enough infomation from my file to raise some real hell. Note that they did not bother with breaking the crypt or guessing the password they just rigged the system binaries. -Pete PS: this happend a year ago, and last month a copy of the files appeared on some systems owned by the Bay Area Air Quality Management District in SF (baaqmd). PPS: I *know* that crypt is insecure but I had tared/compressed it and des was not avalible on the systems I was working on. From shipley at tfs.COM Thu Oct 15 18:13:10 1992 From: shipley at tfs.COM (Peter Shipley) Date: Thu, 15 Oct 92 18:13:10 PDT Subject: Who uses ethernet (Mr Squirrel?) In-Reply-To: <9210141810.AA14191@soda.berkeley.edu> Message-ID: <9210160112.AA06320@edev0.TFS> > >Who uses ethernet?! :-) > I do at home, want to tap it? simple. just crawl under my house and pug in to any jack, don't owrry about bringing batteies there are plenty of 120V outlets. -Pete PS: and soon I plan on using ISDN to bridge by home ethernet backbone onto the internet From shipley at tfs.COM Thu Oct 15 18:20:15 1992 From: shipley at tfs.COM (Peter Shipley) Date: Thu, 15 Oct 92 18:20:15 PDT Subject: Game items... In-Reply-To: <2962.2ADD350B@fidogate.FIDONET.ORG> Message-ID: <9210160119.AA06370@edev0.TFS> Tom, you did not sign the document with you pgp key, how am I supposted to know that Eric did not edit this in hopes of me having oral sex with my girlfriend? how can I trust this is the real Tom.Jennings and the NutraSweet version?!? > >Screw this fake scenario shit, here's some real ones: > >-- Safe sex in the age of AIDS. Guess what -- oral sex is safe. Cum in >your mouth and stomach does not transmit HIV. *No one* is tracking >healthy people. There were *two* "documented" cases (none of the above >type) that seemed to be oral transmission of AIDS. Saying "oral sex is >generally safe" would amount to condoning oral sex. Fat chance in the >US. From gg at well.sf.ca.us Fri Oct 16 02:28:15 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Fri, 16 Oct 92 02:28:15 PDT Subject: Who uses ethernet (Mr Squirrel?) Message-ID: <199210160927.AA11421@well.sf.ca.us> Tom, if you're interested in ISDN, my organisation (Integrated Signal) will probably be in a position to hook you up early next year. We're 90% certain to be putting in a network very close to your neighborhood. -gg From pmetzger at shearson.com Fri Oct 16 11:34:23 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Fri, 16 Oct 92 11:34:23 PDT Subject: Who uses ethernet (Mr Squirrel?) In-Reply-To: <9210160112.AA06320@edev0.TFS> Message-ID: <9210161803.AA15862@newsu.shearson.com> >From: Peter Shipley >> >>Who uses ethernet?! :-) >> >I do at home, want to tap it? simple. just crawl under my house and >pug in to any jack, don't owrry about bringing batteies there are plenty >of 120V outlets. > -Pete >PS: and soon I plan on using ISDN to bridge by home ethernet backbone > onto the internet Old hat -- I still remember the days of yore (only about five years ago, but it seems like an eternity) when I worked at bellcore and Phil Karn revealed to me that his home network was on the internet. All I've got from home is a wimpy little UUCP link to this very day. Perry From shipley at tfs.COM Fri Oct 16 11:47:34 1992 From: shipley at tfs.COM (Peter Shipley) Date: Fri, 16 Oct 92 11:47:34 PDT Subject: Who uses ethernet (Mr Squirrel?) In-Reply-To: <9210161803.AA15862@newsu.shearson.com> Message-ID: <9210161846.AA08767@edev0.TFS> > >Old hat -- I still remember the days of yore (only about five years >ago, but it seems like an eternity) when I worked at bellcore and >Phil Karn revealed to me that his home network was on the internet. >All I've got from home is a wimpy little UUCP link to this very day. What I was pointing out was how trivial it would be to compromise such networks (not that I have such a network). From fen at genmagic.com Fri Oct 16 13:38:20 1992 From: fen at genmagic.com (Fen Labalme) Date: Fri, 16 Oct 92 13:38:20 PDT Subject: re- Game items... Message-ID: <9210162038.AA10880@relay1.UU.NET> Subject: RE>re: Game items... >> -- Safe sex in the age of AIDS. Guess what -- oral sex is safe. >> Cum in your mouth and stomach does not transmit HIV. Just don't have eaten chips or have flossed your teeth beforehand. HIV is transmitted semen to blood or blood to blood. >> -- Access to sexuality information of all or any kinds. Not all >> people do the ole missionary position. Erotica of all kinds. I can't resist plugging the San Francisco Sex Information hotline. Call 415/621-7300 with your questions of how to find it, do it better, find someone (animal? thing?) with which to do it with, etc.... They give good phone. Enjoy! Fen From a2 at well.sf.ca.us Fri Oct 16 18:04:53 1992 From: a2 at well.sf.ca.us (Arthur Abraham) Date: Fri, 16 Oct 92 18:04:53 PDT Subject: Game items... Message-ID: <199210170104.AA06520@well.sf.ca.us> re RU-486: has recently been proven to make a nifty "morning-after" pill (is this abortion? only if you believe in the sanctity of blastula) and a study in (I believe) S. CA. is beginning on effectiveness in brain tumors... seems as if this drug has possible wide theropeutic (aw, who can spell?) uses beyond directly sex-lined situations. And RU-P5 is due out 2Q93. -a2. From a2 at well.sf.ca.us Fri Oct 16 18:46:46 1992 From: a2 at well.sf.ca.us (Arthur Abraham) Date: Fri, 16 Oct 92 18:46:46 PDT Subject: Game items... Message-ID: <199210170146.AA14728@well.sf.ca.us> Abortion Pill's Potential Use on Tumors Adds to Debate Over U.S. Market Entree ---- By Ron Winslow Staff Reporter of The Wall Street Journal DD 10/12/92 SO WALL STREET JOURNAL (J), PAGE B8 LP LOS ANGELES -- Medical researchers are studying a potential new * use for the controversial French abortion pill RU-486: treatment of * benign brain tumors. A large-scale clinical trial was launched at the University of * Southern California last week to determine whether the drug effectively slows or halts growth of meningiomas, tumors that occur * on the surface of the brain and spinal cord. TX The answer won't be known for several years, but the study adds another dimension to the debate over whether the drug, known as mifepristone, should be allowed on the market in the U.S. Rousell-Uclaf, its manufacturer, hasn't sought marketing approval in the U.S. because of the heat of the political battle over abortion. The study raises the possibility that a drug that could benefit some patients won't become available because of a political dispute over another application. "There is a good chance there will be legitimate uses for this drug outside of contraception and abortion," said Steven Grunberg, an oncologist at the USC School of Medicine. "Whether U.S. regulatory officials feel this will be sufficient for licensing will be up to them." A study published last week found the drug to be effective as a contraceptive when taken shortly after sexual intercourse. It is already used in France, the United Kingdom and Sweden to induce abortions within the first nine weeks of pregancy. Meningiomas account for 15% to 18% of all tumors in the central nervous system, and while they are benign -- meaning that they don't spread to other parts of the body -- their growth can lead to such problems as seizures, blindness or paralysis. Most can be removed by * surgery, but some grow so close to crucial brain structures that surgery isn't possible. Dr. Grunberg told reporters at a science writers' conference sponsored by the American Medical Association that the large-scale * trial of RU-486 for the tumors comes after a small pilot study of 28 patients turned up encouraging, though not definitive results. In the small study, eight patients experienced improvement in * symptoms or had minor reduction in tumor size, according to brain scans. In a few other patients, growth of the tumor stabilized after treatment began. While not overwhelming evidence of effectiveness, the results were nevertheless sufficient to persuade the Food and Drug Administration to approve a large study that will involve 200 patients at several U.S. medical centers, and will be based at USC, Dr. Grunberg said. Results from the trial aren't expected for at least four years, and based on current medical practice, only a small number of people * would probably benefit from use of RU-486 in meningiomas. The study might have broader impact by drawing attention to other potential benefits of a drug that isn't available in the U.S. because its primary application is to induce abortion. Dr. Grunberg said the drug is also being studied as a treatment for breast cancer, endometriosis and a disorder called Cushing's disease, which is characterized by obesity and hypertension. Several other trials have been approved by the FDA, he added, though none has progressed as far as the meningioma study. * He said his research team came upon RU-486 as a candidate for treating meningiomas because the drug blocks the action of progesterone, a hormone that appears to promote growth of the tumors. "We didn't set out to make a political statement for * RU-486," he said. "It just appeared to fill the bill for what we're trying to do." ******************************************************************** snarf -a2. From wixer!pacoid at cs.utexas.edu Fri Oct 16 22:31:21 1992 From: wixer!pacoid at cs.utexas.edu (Paco Xander Nathan) Date: Fri, 16 Oct 92 22:31:21 PDT Subject: game items Message-ID: <9210170316.AA05655@wixer> For that matter, vibrators are illegal now for sale in Texas. Most all sex toys have to be renamed as "personal enhancement devices" or sumsuch in retail outlets to avoid seizure. Also, drug testing decoy materials - like powdered fake urine - are illegal in TX. From fnordbox!loydb at cs.utexas.edu Sat Oct 17 07:16:32 1992 From: fnordbox!loydb at cs.utexas.edu (Loyd Blankenship) Date: Sat, 17 Oct 92 07:16:32 PDT Subject: Intro & Keystone Message-ID: <9210170556.AA009js@fnordbox.UUCP> First, as a newcomer, and introduction. My name is Loyd Blankenship. I am the Product Development Manager at Steve Jackson Games, and was the employee raided by the Secret Service that set off the formation of the EFF, our lawsuit against them, and much angst within the government. I also use the nome de' plume "The Mentor" when traversing the computer underground. On to stuff relevant to the list: A group of us here in Austin have spent a great deal of time discussing the advantages of RSA-encrypted e-mail. I'm putting a BBS back up later in the year, and would like to offer secure communications to my users. Since the threat of seizure is very real (the feds still have over $10,000 (1989 street price) of computer equipment of mine since I'm "still under investigation"), this needs to be implemented before the message is ever written to hard disk. To implement this, I'm currently trying to get PGP up on my Amiga, then write the necessary C & AREXX functions to link it in with my BBS's (DLG Pro) email function. The outgrowth of this was the Keystone project. We're going to attempt to get everyone in Austin cyberspace public-key capable, and get a master keyring that will be regularly distributed via a trusted system to other nodes in town. Ideally, you would be able to send RSA-encrypted email from any bbs on any of the local nets to any other bbs -- even if all you know is the destination address. We're going to do this by attempting to make the bbs PGP-friendly. All the user has to do is generate a key pair. The two potential weak links in this chain are line security and key validation. The first is almost insurmountable -- unless the user takes the time to d/l a complete copy of PGP and the Austin Keystone Keyring and encrypt the mail on their home system. But if not, then they have to live with the chance that someone is data-tapping. The second will rely on face-to-face identification -- this is why we're making this a local effort. It will probably be Christmas (when I have a 3-week vacation) before serious strides are made in this, but I'm interested in any comments people may have. Loyd p.s. What is this "game" you are talking about? *************************************************************************** * loydb at fnordbox.UUCP Once you pull the pin, * Loyd Blankenship * * GEnie: SJGAMES Mr. Grenade is no longer * PO Box 18957 * * Compu$erve: [73407,515] your friend! * Austin, TX 78760 * * cs.utexas.edu!dogface!fnordbox!loydb * 512/447-7866 * *************************************************************************** From hughes at soda.berkeley.edu Sat Oct 17 13:51:21 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Sat, 17 Oct 92 13:51:21 PDT Subject: one time pads In-Reply-To: <199210150922.AA09387@well.sf.ca.us> Message-ID: <9210172050.AA28275@soda.berkeley.edu> >Again, I'm by no means trying to suggest that OTPs be considered for >particularly wide application. Rather, that OTPs and a range of other >systems be designed, implemented, and made available so that potential users >can make their own informed choices. One time pad systems are expensive enough and in uncommon enough use that I doubt they are going to get written as free software. I personally am not going to work on them, because I don't want to go buy the necessary hardware to generate and hold sufficient key material for a practical application. You also need hardware random number generators for a secure OTP system. Such boxes are not readily available, or come cheap. While not obvious, making random bits is a very deep problem. See Knuth volume 2 for some insights. I suspect that this same argument holds for all the rest of the people in the group as well. I don't know of anybody who wants to implement this system for themselves, given the cost involved. Cryptography is all economics, and the economics here are that one time pad systems are expensive enough that the software that gets written for them will be for in-house use or will be commercial. In either case, someone is paying someone else for developing the software. It might be possible that there are enough people who do want this that there is some money for development. A perfectly possible outcome is the creation of a consortium to hire some implementers who would make some gnu-ware. Such organization does not exist. Until it does, an off-the-shelf OTP system won't exist. Eric From hughes at soda.berkeley.edu Sat Oct 17 14:15:21 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Sat, 17 Oct 92 14:15:21 PDT Subject: physical security In-Reply-To: <9210160007.AA18430@soda.berkeley.edu> Message-ID: <9210172114.AA28842@soda.berkeley.edu> Physical security for pgp is also necessary if you store your pass phrase in memory. As far as modification, detection is good enough, but you'd better make sure your program to detect modifications is not itself compromised! (Does anybody detect an imminent arms race here?) Eric Hollander is correct. Ideally, your keys and your encryption mechanism should be kept secure. At some point in the future, a small card which contains all of this will be standard equipment, as well as a port to plug it into. Eric From hughes at soda.berkeley.edu Sat Oct 17 15:10:14 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Sat, 17 Oct 92 15:10:14 PDT Subject: Keystone In-Reply-To: <9210170556.AA009js@fnordbox.UUCP> Message-ID: <9210172209.AA29900@soda.berkeley.edu> First, let me congratulate Loyd and the others involved with Keystone for working towards the creation of a local distribution mechanism for keys. Every city in the U.S. needs something like this. If it's not happening in your area, start it. Start by getting PGP and making your own key. Then exchange keys with people you know. We have members of the list in many parts of the U.S., Canada, and Europe. There's plenty of work to do. Look around. If no one else is doing this, you should. >Ideally, you would be able to send RSA-encrypted email from any bbs >on any of the local nets to any other bbs -- even if all you know is >the destination address. We're going to do this by attempting to make >the bbs PGP-friendly. All the user has to do is generate a key pair. There are, roughly speaking, two kinds of privacy; one is provided, and one is defended. Provided privacy is unstable, since the person using the privacy does not create it. Defended privacy is stable, because those who want privacy create it themselves to the level at which they want it. Both systems do provide privacy, no mistake. I would be hesitant to implement a system that _only_ required a user to generate a key pair. This, for the users, is too much provided privacy. It will not teach the users how privacy really works, nor will it give them any good idea how their privacy is being maintained. Defended privacy does not need to be difficult. I would spend effort, instead of modifying BBS software, to make it easier for users to handle encrypted email with their own terminal programs. Now, any privacy is better than none. I don't really know if it is easier to modify your BBS or your modem program. But all other things being equal, make it easier for users to maintain their own privacy. >[...] a master keyring that will be regularly distributed via a >trusted system to other nodes in town. Again, trusted systems can turn into provided privacy. If there is a distributed solution you can think up, use it. >The first [weak link, line security] is almost insurmountable -- >unless the user takes the time to d/l a complete copy of PGP and the >Austin Keystone Keyring and encrypt the mail on their home system. This should not be such an onerous task. It might be now, but that can change. Finding ways for users to manage keys, to get keys, and to look up keys are all interesting and useful problems to solve. Every user should encrypt outgoing mail on the home system before it leaves and decrypt incoming mail on the home system after it arrives. If this is not easy, it should be made easy. Not every user need have the complete directory on their own system. They merely need a way to communicate with those that they want to. This probably means a directory service, where people can download keys for the people they want to communicate with. Moving around a complete directory does not scale well. As far as BBS support, if I want to respond to someone and I don't have the corresponding key, I should be able to initiate a zmodem transfer of that key relatively easily, for instance without leaving the discussion area to go to a download area. Eric From gg at well.sf.ca.us Sun Oct 18 01:21:11 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Sun, 18 Oct 92 01:21:11 PDT Subject: one time pads Message-ID: <199210180820.AA24894@well.sf.ca.us> Sigh... well, I guess I can see if the people I know who are interested, would do it as a freebie... Funny thing is, when I first looked into crypto for dissident purposes, back in 1981 or so, I was interested in a PKS implementation, but someone else in my circle persuaded me that OTPs would be preferable in some cases. Now here we are with a PKS and I'm still making noises about OTPs. Guess the debate is closed for the moment... congratulations, y'all, for good arguements in a good tone. Now the well is about to close for the night, so I gotta scoot. Be back soon... -gg From hkhenson at cup.portal.com Mon Oct 19 02:21:17 1992 From: hkhenson at cup.portal.com (hkhenson at cup.portal.com) Date: Mon, 19 Oct 92 02:21:17 PDT Subject: one time pads. Message-ID: <9210190136.1.13588@cup.portal.com> I can suggest a way to "distribute" a one time pad, even though the people never meet. Just agree over the phone on which CD ROM to use, and some forumula for an offset into the CD ROM. You might want to throw away some of the data to make the bit stream less regular, but with 600 meg, who cares? Keith Henson From hughes at soda.berkeley.edu Mon Oct 19 08:48:48 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Mon, 19 Oct 92 08:48:48 PDT Subject: one time pads. In-Reply-To: <9210190136.1.13588@cup.portal.com> Message-ID: <9210191548.AA01490@soda.berkeley.edu> Keith's CD-for-a-pad idea is a variant of a book code. In a book code, parts of the key are in various standard books, often the bible. Advantages: easier key distribution. Disadvantages: key material is public. Should an internal spy learn the few bits of addressing information (which CD, where), the cipher is compromised. Eric From pmetzger at shearson.com Mon Oct 19 17:08:26 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Mon, 19 Oct 92 17:08:26 PDT Subject: one time pads. In-Reply-To: <9210190136.1.13588@cup.portal.com> Message-ID: <9210191948.AA13028@newsu.shearson.com> >From: hkhenson at cup.portal.com >I can suggest a way to "distribute" a one time pad, even though the >people never meet. Just agree over the phone on which CD ROM to use, >and some forumula for an offset into the CD ROM. You might want to >throw away some of the data to make the bit stream less regular, but >with 600 meg, who cares? Keith Henson This seems equivalent to the old "dictionary" or "book" cyphers that people sometimes used. Good cryptanalysts broke them routinely. I'll leave it to your imagination how one might do it, but I'll just note that if you picked a few arbitrary bytes, say bytes 30-40, of all the CDs in the record store, you would find that those few bytes likely distinguish all but prehaps a token number of CDs. Perry From pmetzger at shearson.com Mon Oct 19 17:09:14 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Mon, 19 Oct 92 17:09:14 PDT Subject: one time pads. In-Reply-To: <9210191548.AA01490@soda.berkeley.edu> Message-ID: <9210192003.AA13314@newsu.shearson.com> >From: Eric Hughes >Keith's CD-for-a-pad idea is a variant of a book code. In a book >code, parts of the key are in various standard books, often the bible. >Advantages: easier key distribution. >Disadvantages: key material is public. Should an internal spy learn >the few bits of addressing information (which CD, where), the cipher >is compromised. Actually, in practice internal spies were almost never needed to break book cyphers. They in fact provide only laughable security. Traditional ones didn't even require that the cryptanalyst ever determine what book was being used! Perry From nobody at soda.berkeley.edu Mon Oct 19 23:22:30 1992 From: nobody at soda.berkeley.edu (nobody at soda.berkeley.edu) Date: Mon, 19 Oct 92 23:22:30 PDT Subject: More private PGP...? Message-ID: <9210200622.AA10349@soda.berkeley.edu> One of the things I've noticed about PGP is that it makes it pretty obvious that you're sending an encrypted message. The big -----BEGIN PGP MESSAGE----- at the start pretty much gives that away. In most cases, this is fine, but sometimes it may not be desirable to make it this obvious. Sending encrypted messages may call unwelcome attention to yourself. Also, some people are experimenting with packet radio on the amateur bands, and it's not legal to send encrypted messages there. What I think would be nice would be an "innocent" mode for PGP in which it created files which looked like something else. For example, what if your encrypted output file looked like: begin 666 testpat.gif MI\44:#G4D>QQXR!-M,Z20O1K&5D0, 5-4F.X<%MT M2:V94,K;XE at B?]%IHF+_WGI%(]#=F]/[LV+&! M,NH0(!3B35CW#!-Z7"B_L'=-C 8DLB-(J R"3?EE9<.>QE4Y?T$66IA7B at W? end This will be recognizable, if you've seen many, as a uuencoded file, a common encoding for non-ascii files. The header line suggests that it is a graphics file. Tons of these types of files are sent across email networks every day. Sending your encrypted messages in this form would give you a lower profile. Still, if someone goes to the effort to uudecode your message, and examines the resulting file, it will be obvious that it's not a GIF file because it lacks the proper headers. Instead, with the current PGP implementation it will be obvious that it is in fact a PGP file, because the header format matches the PGP spec. Again, I think it would be better if PGP in this mode were able to produce a file without headers which will give away what it is. Even better would be the ability to mimic headers of some other types of files, such as the .ZIP, .ZOO, or Unix "compress" format which are often used in binary files people mail around. Another thing that I think is kind of bad about PGP in the context of avoiding traffic analysis is that it puts the key ID of the destination person in the header. There was some discussion during development of a mode in which no key ID information would be in the header; the only way you'd have of knowing if the message was for you was to try decrypting it. (There is a checksum which is used internally to tell if the decryption was done with the right key.) This way you could broadcast messages to some group, and no one could know which person in the group you were sending to. These "anonymous destination" messages could be encoded with a key ID of zeros, and the PGP software could easily be modified to let the user try a decryption on such a message, reporting success or failure. How useful do these kinds of features seem to people? Would they really be helpful or is this just paranoia? Hal 74076.1041 at compuserve.com From gg at well.sf.ca.us Tue Oct 20 01:56:22 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Tue, 20 Oct 92 01:56:22 PDT Subject: one time pads. Message-ID: <199210200855.AA27037@well.sf.ca.us> Re use fo CD ROMs for OTPs. That would seem to be a variation on the old theme of the book cipher, which is *not* random and therefore *not* secure. Also, agreeing on key procedures over the *phone* in *clear voice* is kind of like sex without a condom. Not secure. Not safe. Potentially deadly. While we're on the subject of link encryption, the same response pertains to the suggestion made by someone from SJG here (whose name I ought to know but my memory for names has more holes than Bush's economic plan) about key distribution and transmission of cleartext over phone lines. It *doesn't matter* if it's encrypted at the BBS server, if it goes in clear over the phone. Keyword in context recognition is no problem when dealing with ASCII. Various agencies (you know who) have raised this to a fine art. The telephone line is precisely the link in the chain which is weakest and needs most to be protected. If the nasty-wasties break down your door and go for your hard drive, it's already too late. Like worrying about a condom after the fact. Now as a matter of record, it's been demonstrated that a processor emits electromagnetic radiation back over the phone lines as well as electrical power lines, which can be picked up at a distance. So consider for a moment that there is a BBS serving dissidents, who Big Brother wants to monitor. Seeing all the encrypted traffic, they install a device on the phone line and the AC to pick up what the mircoprocessor is doing. And they see it doing crypto, and they see the cleartext which is recovered, and get the keys, and the whole damn thing may as well be transparent. So for BBSs and such, I would argue that it's necessary to have electromechanical relays to isolate the computer from the phone lines when encrypting or decrypting; ideally isolate it from the AC as well (using an uninterruptable power supply, which will run the computer on batteries for some period of time, say 45 minutes). So you have a great big red toggle switch next to the computer, and for some period during the day when doing all the crypto processing, throw the switch to the Safe position to get it off the phones and AC lines. This might make BBS use a little less convenient (in that email becomes available the day after it was posted), but at least it's not literally leaking everyone's secrets into the airwaves. This general area is part of a larger topic called TEMPEST. Anyone else interested in pursuing this angle...? -gg From gg at well.sf.ca.us Tue Oct 20 02:16:09 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Tue, 20 Oct 92 02:16:09 PDT Subject: More private PGP...? Message-ID: <199210200915.AA27714@well.sf.ca.us> Hal, I think those would be vry useful. Now of course, we don't want to advocate that radio users in the United States do anything like sending ciphertext over the airwaves, but we might want to develop something that we can ship to the Gusanos who want to take Cuba back for the Mafia, or maybe in a better vein, something that the Tien-an-men kids can use when overthrowing the Commies in China. Good ideas about message headers. Since the source code for PGP is widely available, it would seem a straightforward matter to alter the program to include the new features. What I'd really like also is a Mac version.... -gg From mark at coombs.anu.edu.au Tue Oct 20 02:19:05 1992 From: mark at coombs.anu.edu.au (Mark) Date: Tue, 20 Oct 92 02:19:05 PDT Subject: Home security... In-Reply-To: <199210200855.AA27037@well.sf.ca.us> Message-ID: <9210200918.AA18129@coombs.anu.edu.au> >This general area is part of a larger topic called TEMPEST. Anyone else >interested in pursuing this angle...? What's the best sources for faraday cages and TEMPEST etc? And does anyone out there implement anything of this type of security at home to protect against monitoring? The cost of such an exercise would be rather prohibitive to say the least. Just curious.. Mark From nobody at soda.berkeley.edu Tue Oct 20 07:52:54 1992 From: nobody at soda.berkeley.edu (nobody at soda.berkeley.edu) Date: Tue, 20 Oct 92 07:52:54 PDT Subject: Tempest. Message-ID: <9210201452.AA01970@soda.berkeley.edu> Re TEMPEST technology: (Note that TEMPEST is the technology for _protection_ against electronic eavesdropping on your computer emissions. There is presumably a code word for performing such snooping, but it must be secret.) I've read that the worst emitter is your CRT screen. In fact, they say that you can sometimes put a TV-type monitor next to your computer monitor and get a faint, ghosty image of your CRT screen on the second monitor. If you get this much without any amplification, it's under- standable that high-quality equipment can pick up an image from a greater distance. The best way to avoid this, IMO, is to use a laptop. The LCD display of a laptop does not use the large electromagnetic fields that a CRT display does. Laptops also use lower power levels in general so they should emit less. I don't really know whether the "raw" CPU activity of your computer could be picked up and interpreted at a distance. With as many different signals as there are on the address and data busses, along with all the other wires you have, I can't really see how anything meaningful could be picked up with remote monitoring. It would seem that they'd be totally jumbled. So, for BBS use, where the system is operating automatically, I'd say that it would be OK as long as you don't display any cleartext or key/password information on the screen. You could just turn the monitor off when it's operating. For home use, a laptop has the advantage that it can have greater physical security (because it's smaller and more portable), you can carry your decryption keys with you, you can download to it at work or school and decrypt without trusting the multi-user systems they have there, and it should be relatively immune to electro- magnetic snooping. Hal 74076.1041 at compuserve.com From hughes at soda.berkeley.edu Tue Oct 20 08:33:46 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 20 Oct 92 08:33:46 PDT Subject: More private PGP...? In-Reply-To: <9210200622.AA10349@soda.berkeley.edu> Message-ID: <9210201533.AA07309@soda.berkeley.edu> >One of the things I've noticed about PGP is that it makes it pretty >obvious that you're sending an encrypted message. [...] Sending >encrypted messages may call unwelcome attention to yourself. First, let me get on record as saying that Hal's "innocent mode" is a good idea that should be implemented. But it's not really a good long-term solution from a social point of view. Encrypted traffic should become the norm, not the exception. Flagging that you're sending encrypted traffic should be encouraged. When questioned about this, people should respond in shocked tones "What do mean? Aren't you encrypting _your_ email?" and then proceed to suppress gentle laughter at them when they say no. When it's cool to encrypt, only the uncool will be plain. So, then, more peer pressure! Consider someone asking you about your encrypted mail to be an opportunity to start a conversation about their position on personal privacy. When your sysadmin asks why your mail can't be read, tell him you are defending your privacy and ask if there is any problem with that. Then, when the sysadmin puts in a filter for PGP traffic, use innocent mode. >Another thing that I think is kind of bad about PGP in the context >of avoiding traffic analysis is that it puts the key ID of the >destination person in the header. Absolutely. Ditto for signatures. Both should be able to be selectively removed. In any case, it should be possible to have nothing appear on the outer envelope. Another feature for PGP would be automatic message padding. To properly do a mix you need to quantize the message lengths. If PGP were to automatically pad with random data, it would save a lot of integration work for the mix. PGP already has a random number generator, after all. Eric From hughes at soda.berkeley.edu Tue Oct 20 09:15:10 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 20 Oct 92 09:15:10 PDT Subject: Tempest. In-Reply-To: <9210201452.AA01970@soda.berkeley.edu> Message-ID: <9210201614.AA13762@soda.berkeley.edu> About Tempest. The ability to monitor is real; it's more powerful than you would first imagine. You can get a lot of insight into what is possible by looking at what is sold as parts for Tempest certification. There is some trade publication devoted entirely to such matters; it's called EMI/RFI News, or Interference Protection News, or something like that. It's free to qualified subscribers. The articles are interesting, but cannot delve into the really interesting stuff. But the ads! Look at what people are selling, and remember that it is protecting against something. Stuff like copper impregnated gasket material, both for computer cases and for doors (in walls). Copper braid and cloth. Conductive glues and caulks. Special connectors. Electrical isolators. Fiber optics. (Aside: If you don't know how to be a qualified subscriber, you're no hacker. Look closely at the subscription card and then figure out where the publisher of a free magazine gets its money.) What is possible? CRT monitoring. A Dutch guy named van Eyck demostrated six years ago or so a CRT monitoring system which he built out of spare parts. It consisted of an TV roof antenna, a non-detent UHF tuner (which you can make yourself by removing the detent plate from an old TV), and a multi-scanning monitor. No amplification beyond what was in the tuner, no sync stabilization, no special directional antennas or any other tricks. He was able to reliably pick up monitor emissions from 100 meters, if I remember correctly. Fancier equipment knows what your screen sync rate is, uses bandpass filters, uses better antennas, knows to look for mostly-persistent frame information, looks for emissions signatures, and is able to read one CRT out of a hundred at half a mile. I suspect this is a low estimate of the ability of modern equipment. Hal mentions using flat panel displays to combat emissions. This works, as evidenced by the continued existence of Grid Computer. Remember Grid, who came out with these way-expensive gas plasma laptops around 1985/6? The reason they sold so many of those and are still around was that a large number of them were Tempest certified. (Even larger revenues!) I understand that the Tempest spec Grids had a thin layer of gold foil in front of the screen, even so. Yes, gold thin enough to see through. Signal wire monitoring. Using twisted pair or coax cable, reduces transmitted energy down to very low levels, improving energy transfer and reducing monitorability. But even with zero radiated energy there is still the near field of the wire which can be inductively tapped. No conductive contact is necessary. If you can put a wire next to my phone line somewhere, you can tap my phone. It's by nature a high impedance tap, requring sensitive ampilifiers but at the same time difficult to find even by a reflectometer. Without a twisted pair, the situation is worse. Keyboards for the PC use a serial protocol at a fixed frequency. The cables are not twisted pair. I haven't heard anything about that specifically, but I presume that keystrokes can be read extremely easily. CPU monitoring. Yes, it's possible. I've heard that it is possible to actually run a CPU in parallel with a monitored one. In order to do this, you need to correlate signals in real time across a fairly wide RF spectrum. Each CPU pin or I/O bus signal occurs in a different physical location inside the case. The case is active in terms of emmission, reflecting signals around like mad. All these different physical locations and reflections give rise to phase differences and interference patterns. Once you figure out what the signatures of the various signals are, you can separate them out from each other by correlation and deconvolution. George's concern about emissions through phone lines falls into this category. Other stuff. I've heard rumors about using microwave pinging to determine stuff about electrical equipment. Or about implanting passive devices that alter the EM field locally in order to make monitoring easier. It's safe to presume that there is some amazing stuff going on. Read The Puzzle Palace for more hints. (Like the valley in WV which is one big antenna.) Emissions monitoring is also all economics. The price to monitor increases with each more sophisticated attack. CRT's are easy, CPU's are hard. I would like to see public research in this area, just like there is public research in cryptography. Until the public has a better idea of what various attacks cost, there can't be rational decisions about emissions security. Eric From G5100035 at NICKEL.LAURENTIAN.CA Tue Oct 20 10:12:23 1992 From: G5100035 at NICKEL.LAURENTIAN.CA (G5100035 at NICKEL.LAURENTIAN.CA) Date: Tue, 20 Oct 92 10:12:23 PDT Subject: Unsubscribe me from mailing list Message-ID: <01GQ68KC14008WWO6L@NICKEL.LAURENTIAN.CA> I can no longer handle the mail volume from your mailing list. Please unsubscribe me from the list. Thanks. From No_Such_Address at atdt.org Tue Oct 20 11:06:12 1992 From: No_Such_Address at atdt.org (No_Such_Address at atdt.org) Date: Tue, 20 Oct 92 11:06:12 PDT Subject: Mac Version PGP Message-ID: <9210201806.AA07990@atdt.org> No one has been able to get me the source-code to PGP, and when I ftp'd it from wherever, it came ZIP'd in a format that my unzipper doesn't recognize. (Maybe I've been ZIP superceded). Anyway, it hasn't been very convenient to get a hold of it for me. But, it should be fairly straight forward to throw it into THINK C. THINK C supports a console with command-line. You would not necessarily have to Mac-ify it (although it would certainly make it more aesthetically pleasing); so porting to the Mac is not a dead-end port. THINK C should be able to compile and execute PGP as-is. As soon as I can get the source, I'll put my words into action. (re: Macifying it: It's simple enough to slap together an interface on top of something like PGP; that's one, maybe two dialog boxes with a bunch of radio buttons and check boxes and a routine to parse it all and hand the info over in a way PGP expects. BFD. So, criticisms I've heard about it being a hassle and a pointless exercise to port PGP to the Mac are without merit, as far as I'm concerned.) From hh at soda.berkeley.edu Tue Oct 20 11:40:12 1992 From: hh at soda.berkeley.edu (Eric Hollander) Date: Tue, 20 Oct 92 11:40:12 PDT Subject: Tempest. In-Reply-To: <9210201452.AA01970@soda.berkeley.edu> Message-ID: <9210201839.AA08315@soda.berkeley.edu> Like I said, just carry everything (keys and software) on your laptop. As soon as the Mac port of the pgp is finished, that's what I'll do. e From fnordbox!loydb at cs.utexas.edu Tue Oct 20 14:43:30 1992 From: fnordbox!loydb at cs.utexas.edu (Loyd Blankenship) Date: Tue, 20 Oct 92 14:43:30 PDT Subject: Keystone Message-ID: <9210201753.AA009kv@fnordbox.UUCP> :I would be hesitant to implement a system that _only_ required a user :to generate a key pair. This, for the users, is too much provided :privacy. It will not teach the users how privacy really works, nor :will it give them any good idea how their privacy is being maintained. I take the opposite view -- I dare *not* supply such a system. Any user that is interested enough in 100% privacy will be encouraged -- both from the email prompt and through the message bases/file areas -- to d/l a copy of PGP. I'll probably write a tutorial on using it as well. But many users do not have the interest/time/ability to set up PGP on their home system. For them, I want to provide the best possible privacy given the ease with which anyone who can find their local LMOS can tap (voice or data) a line... :Defended privacy does not need to be difficult. I would spend effort, :instead of modifying BBS software, to make it easier for users to :handle encrypted email with their own terminal programs. I don't have my user's terminal program -- I *do* have the bbs software. :Again, trusted systems can turn into provided privacy. If there is a :distributed solution you can think up, use it. I don't know any way to maintain an up-to-date, central keyring without someone being in charge of regular updates. I'd make it available via Fido, FTP, BMS and regular d/l. Loyd *************************************************************************** * loydb at fnordbox.UUCP Once you pull the pin, * Loyd Blankenship * * GEnie: SJGAMES Mr. Grenade is no longer * PO Box 18957 * * Compu$erve: [73407,515] your friend! * Austin, TX 78760 * * cs.utexas.edu!dogface!fnordbox!loydb * 512/447-7866 * *************************************************************************** From shawnb at ecst.csuchico.edu Tue Oct 20 15:15:53 1992 From: shawnb at ecst.csuchico.edu (shawnb) Date: Tue, 20 Oct 92 15:15:53 PDT Subject: Fakemail Message-ID: <9210202215.AA29362@toad.com> Cyperpunks.... Man you guys generate lots of stuff... Anyhow I noticed that some of you are using fakemail... Are you using a shell script for this? The only fakemail scripts I've seen have not really worked. Could someone forward a copy to me? Thanks. Shawn From tcmay at netcom.com Tue Oct 20 15:27:38 1992 From: tcmay at netcom.com (Timothy C. May) Date: Tue, 20 Oct 92 15:27:38 PDT Subject: TEMPEST, Eavesdropping, and PDAs Message-ID: <9210202226.AA28803@netcom2.netcom.com> Eric Hughes posted a nice summary of the TEMPEST situation (interception of RF for eavesdropping on computers). I'll just add a few comments. > About Tempest. > > The ability to monitor is real; it's more powerful than you would first > imagine. And the NSA has reportedly restricted several papers on this, though they can't do much about the stuff coming from abroad. Their chief concern doesn't seem to be folks like us, but rather concerns about vans parking outside high tech and defense contractors and slurping up what they can from non-TEMPEST (all caps, for some reason) terminals and computers. And someone asked about building Faraday cages. Don't even try! In 1972-3 I worked inside a Faraday cage in the lab of Dr. Paul Hansma (who's now famous for his atomic force microscope work--small world), and it was real tough to shield against high frequencies (above 500 MHz). Modern computers run at 50MHz and faster and the signal edges are of course much faster. RF emissions are a major hassle, and even 30 dB of shielding will still mean enough emissions for a dedicated listener to pick up. > Hal mentions using flat panel displays to combat emissions. This > works, as evidenced by the continued existence of Grid Computer. > Remember Grid, who came out with these way-expensive gas plasma > laptops around 1985/6? The reason they sold so many of those and are > still around was that a large number of them were Tempest certified. > (Even larger revenues!) I understand that the Tempest spec Grids had > a thin layer of gold foil in front of the screen, even so. Yes, gold > thin enough to see through. BTW, I have one of the original magnesium-cased, bubble-memoried GRiD Compasses. Tres elegant (and even "way cool"....Not! It heats up something fierce, with the magnesium case acting as a heat sink). (I got this at Weird Stuff Warehouse, complete with a magnesium-cased disk drive, cables, etc., for $250. Fully functional, but not a lot of software written for "GRiD-OS." Maybe I'll bring it to the next Cypherpunks meeting.) > monitoring easier. It's safe to presume that there is some amazing > stuff going on. Read The Puzzle Palace for more hints. (Like the > valley in WV which is one big antenna.) Ditto on this book recommendation: all would-be cypherpunks should read James Bamford's "The Puzzle Palace." Though published in 1982, it revealed a lot about such "No Such Agency," so much so that the director of NSA, upon encountering Bamford at a dinner, refused to shake his hand and said "Sir, I consider you an unindicted felon!" > Emissions monitoring is also all economics. The price to monitor > increases with each more sophisticated attack. CRT's are easy, CPU's > are hard. I would like to see public research in this area, just like > there is public research in cryptography. Until the public has a > better idea of what various attacks cost, there can't be rational > decisions about emissions security. I think the longterm solution to this problem is the same as that for the key problem: small, highly portable, self-contained computers for doing the most sensitive work and for providing passwords to remote systems. Smartcards are one approach, though they obviously are highly constrained in what they can do other than act as ATM or VISA cards. (Laptops are one idea. Following Eric's suggestion that we look into TEMPEST issues, perhaps we could "rate" different laptops and PCs for emissions. Just a thought.) Apple's "Newton" PDA ("Personal Digital Assistant"), General Magic's whatever (talk to Fen L., who works there, but who won't say much), Eo's Hobbit-based PDA, and other systems (Sharp, Casio, etc.), offer a better platform, at least for the long term. With 100 MIPS performance, LCD screens, and no dangling keyboards and cables, these gizmos should be favorably positioned for security-conscious applications. RF emissions should be low to begin with (and can be characterized, of course); additional shielding should be easier to achieve than with full-sized units. PDAs also are small enough that people will carry them everywhere, thus both enhancing security against tampering, and also making them workhorses for security applications. With a good interface to desktop machines, the critical security functions can be done inside the PDA (e.g., accessing a terminal or remote system using zero knowledge protocols, where the PDA answers a challenge question without revealing the actual password or whatever secret key). The announced PDAs also have slots for "PCMCIA" cards, small credit-card-sized cards that can add functionality and memory. The lack of a keyboard in the smallest of these units will be a limit (though external keyboards are options...and with some care, these keyboards can even be made TEMPEST class, though leakage will still persist. A battery-operated keyboard with fiber-optic link to the PDA might be one approach.). The issue of hooking these PDAs to desktop machines and networks is an interestesting one. Wirless links would seem to be risky, except that if all critical computations are done _inside_ the PDA then what gets transmitted is not really "fragile" (in the eavesdropping sense). I suspect that someone will offer a small fiber optic link (like the one I have going between my CD player and my DAT machine). And it will be a couple of years before these become common. But it's about 2-3 years from now that our mission gets really interesting, anyway. Digital money, anonymous voting and conferences (imagine using wireless, encrypted links in meetings to negotiate without opponents knowing..just one of several small business product niches), and all kind of other crypto anarchy ideas. PGP 3.0 for PDAs! -- .......................................................................... 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 2.0 and MailSafe keys by arrangement. From tom.jennings at f111.n125.z1.FIDONET.ORG Tue Oct 20 16:26:17 1992 From: tom.jennings at f111.n125.z1.FIDONET.ORG (tom jennings) Date: Tue, 20 Oct 92 16:26:17 PDT Subject: Depository Proposal (revised) Message-ID: <3194.2AE470FA@fidogate.FIDONET.ORG> Just thought I'd forward on something that's cooking in Fidoland. This guy has code running already. I haven't even looked at it yet myself If it's a crock, please be kind and forward suggestions to the author... tomj at fidosw.fidonet.org -------------------- begin forwarded message (Please note that examples still have not been included with this text) Public Keys Depository Proposal By Marcos R. Della (1:125/180 or marcos at zippy.sonoma.edu) Def: De.pos.i.to.ry (di-POZ-i-tohr-ee) n. a storehouse, a place for safekeeping of things -+---------------------------------------------------------------------+- With the latest release of the PGP20 program, public key availability has fallen into the hands of the individual. This provides a relative degree of security over messages that are sent from user to user in various formats (text, binary, etc) over different transportation mechanisms. I will not go into the system that allows public keys to work nor public key history. Instead I'll point you to the rather complete documentation that comes with the PGP program. Unfortunately, there is a major drawback to this system (also pointed out in the PGP documentation). Public key distribution has few security elements involved to insure the validity of a particular key. PGP attempts to address this problem by providing a "signature" system to each public key to give reasonable validity to its origin. Unfortunately, this depends upon trust of the individual who signs the key to begin with. Who polices the policemen? Unfortunatly, the issue of key validity is yet another topic that cannot be easily addressed since authenticity lies in one persons trust of another. Yet there still needs to be a system in which keys can be distributed or held for later use. This system should be multiply redundant and have some degree of immediate access in order to make the information stored useful. One such system would be a depository, a place to store public keys for later retrieval. This proposal will attempt to describe a system whereby you can get around the validation of public keys problem without requiring someone to police the Depository itself! -------- Problems Involved: - How do you know the key depositor isn't faking his/her keys? - How do you verify (at the depository) that a key being deposited is from the key originator or is even valid? - What is to prevent the depository from faking keys that is "signs"? - How can this system be resonably redundant and easy to access? First off, the depository is NOT a validation center. The system never will verify the users as existing or if they are even honest users. The depository key signature only verifies that the key has been deposited and is available for access at any time. Again, the depository DOES NOT verify users, only the fact that a deposit has been made. (A better form of deposit slip) If a user wants to deposit his/her key, what is to prevent the sysop from intercepting this public key, making a substitution replacement, and then forwarding the new public key? Unfortunately, there are sysops out there that have already done this in some respects. Thereby the system has to place the responsibility upon the user for key deposit verification. To prevent the sysop from changing the deposit, the user should use the Depository Public Key (hereafter referred to as DepoKey) to send his/her key for deposit. Again, what prevents the "bad" sysop from just throwing this message away (obviously he can't read it) and sending a fake message (also encrypted with the DepoKey)? Although this eventually thwarts the entire system (the sysop cannot fake the users public key unless the user uploads it in plain text to the sysop), it still causes problems. To prevent this, the user should include some sort of text in the deposit that the depository will mail back to the user, ENCRYPTED along with the user's public key. When the user receives a valid message back that contains his original text, things are fine. If the user does not receive a response in a few days or gets an incorrect return message, then the user should send a cancel message to the depository and re-deposit his or her key. The complete the handshake, the user should send an authentication back to the depository stating that the key was recieved correctly (instructions on how to do this should be returned with the key). If a return reciept isn't back in a resonable period of time, the depository will remove the key from its deposit keyring. NOTE: This will never invalidate a public key, it will only prevent it from being distributed via the depository system. What is to prevent the depository from faking keys that it "signs"? Well, in order to be effective with fake keys, you need to be in the transport path of the messages that you are planning on "stealing". Since the depository is not a major hub or node (except possibly to a few people) this negates any effect of faking keys. Also, once a user has received verification that the depository has his public key, he can then also post it anywhere. The depository will return his public key with a depository signature on it. This allows the user to upload a verified key to anywhere. When keys are distributed with a depository signature on them, then they are on file with the depository in case someone wants to withdraw them later. As long as the public key for the depository is made worldwide public, this system will work. As for creating a multiply redundant system, there should be several sites that are listed as depositories. These systems will on a weekly basis, exchange acknowledged keys (ie, keys that have undergone the handshaking process) with one another. A user can then request a key from ANY of the depository sites and get the same information. For those that want certified keys (other than from the users) such as a BBS system needing the public key of another, there will be a withdrawal mechanism built into the depository to pull single or multiple keys. Also, the complete public keyring may optionally be pulled (FREQing). ----------- The actual mechanism: Below is the Depository Public Key. Any public key that has been signed with this depository key will be assumed to have undergone the handshake process to verify that the originator of the key pair has in fact issued a valid key. This signature only verifies the deposit (a reciept). *** THIS KEY DOES NOT VERIFY THE IDENTITY OF THE USER!!! ONLY THAT *** *** THE USER WAS IN FACT THE ORIGINATOR OF THE PUBLIC KEY *** *** AND HAS DEPOSITED IT INTO THE PUBLIC KEY DEPOSITORY!!! *** For user identification, there should be a second or third signature from a BBS or known friend. This will give the key a verification level. If the user wishes to deposit a key with another person's signature, there will be no problem since the handshake method still insures the source and destination of the message. (Note: This is preferred since depository keys will then be distributed with dual signatures) The depository allow four functions: Deposit, Withdrawal, Cancel, and Acknowledgement of Deposit. To use these function... DEPOSIT: Address a message to "Depository" at one of the listed depositories at the end of this document. The subject will be "Deposit" and the text body will contain your Public Key (in Ascii format) and some small body of text that will be reflected back to you. NOTE: The small body of text and your public key should be encoded WITH the Depository Key. WITHDRAWAL: Address a message to "Depository". The subject will be "Withdrawal" and the text body will contain what you are looking for on each line just as if you were polling your own PGP program. You will be sent back a list of keys with the depository signature verifying the message. Note that a * for the body text will give a LONG list back to you... For fidonet, this MIGHT require a poll to recieve your return list. See Appendix A CANCEL: Address a message to "Depository". The subject will be "Cancel" and the text body will contain the text "CANCEL PUBLIC KEY" with your signature on the message. The cancel will not take place without your signature! You will receive a cleartext response to this. All this does is to remove your public key from the depository keyring. If this comes with a "kill" signature for the key, then it will be moved from the deposit keyring to the invalid/killed keyring. ACKNOWLEDGE: Address a message to "Depository". The subject will be "Acknowledge" and the text body will contain the text "ACKNOWLEDGE" with your signature on the message. Without the signature, your public key will continue the daily countdown to keyring removal. A cleartext message will be returned upon any receipt of this message. Anything that doesn't fit one of these will be rejected and a return message will be bounced back. ------------------------------------------------------------------------- *** WARNING *** This proposal ONLY provides a method of storing keys for public distribution and withdrawl. This in NOW WAY verifies or even attempts to verify the authenticity of the issuer of the key. *** WARNING *** ----------------------------[ CUT HERE ]--------------------------------- Depository #1 (1:125/180) [KeyID:77854F] "Depository #1 [Public Keys]" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAirV7H4AAAEEAMgk39sU7OvZGr/Ig/g0Kaw2cY3FpQOFvRXp9OXmlAch3FBA Ow2/oD8dbKdiQamuIMFw6qpg0Bw2k8mhKXCfFhLIZjH3FJeqKQrV7UvELBJdCT4q b7wRg8jeLos2rR9a4jt+s0srNS/LznfLvquESEhMuzcxSTC27OyxS4Fbd4VPAAUT tBtEZXBvc2l0b3J5ICMxIFtQdWJsaWMgS2V5c10= =rC+3 -----END PGP PUBLIC KEY BLOCK----- --- GEcho 1.00/beta * Origin: The Babble Underground (Home of the Jabber QWK Reader) (1:125/180) SEEN-BY: 125/111 125 180 185 374/14 ;; -------------------- End forwarded message -- Tom Jennings / World Power Systems email: tomj at fidosw.fidonet.org FidoNet: 1:125/111, BBS +1-415-863-2739 postal: Box 77731, San Francisco CA 94107 USA -- 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 hh at soda.berkeley.edu Tue Oct 20 16:53:46 1992 From: hh at soda.berkeley.edu (Eric Hollander) Date: Tue, 20 Oct 92 16:53:46 PDT Subject: another service Message-ID: <9210202353.AA04723@soda.berkeley.edu> I have thought of another service, like the depository, which might be useful to the user community: a time stamping notary service. This would have less security problems than the depository and would also be neccessary if RSA'ed documents are to replace contracts and other paper documents used in business. It would be easy to implement. A machine is set up with a hardware random number generator. This is used to generate a time-stamp key pair, perhaps every day or every hour. A user sends a document to this computer, which then signs it with the private half of the time-stamp key and then remails it to the user. Note that the document sent by the user is probably already encrypted and/or signed; sending it to the time-stamper does not compromise it in any way. The time stamper also keeps publishing the public half of its keys, to a wide enough audience that it would be impossible for any one person (or Agency) to modify all of them. Users could keep their own archives of them. After the time period has elapsed, the time-stamper should erase the private key corresponding to the time period. This is the only time that trust is involved and that the system might be compromised. If a private key were leaked, a time-stamp could be forged. This would allow users to keep dated, notarized documents in their files, so they could later prove that they had certain information at a certain time. Ideas? Thoughts? e From tcmay at netcom.com Tue Oct 20 17:15:26 1992 From: tcmay at netcom.com (Timothy C. May) Date: Tue, 20 Oct 92 17:15:26 PDT Subject: another service In-Reply-To: <9210202353.AA04723@soda.berkeley.edu> Message-ID: <9210210014.AA05539@netcom2.netcom.com> Eric Hollander writes: > I have thought of another service, like the depository, which might be > useful to the user community: a time stamping notary service. This would > have less security problems than the depository and would also be neccessary > if RSA'ed documents are to replace contracts and other paper documents used > in business. Bellcore is offering some form of this service, or plans to. Stuart Haber, one of the codevelopers, described this at last year's Hackers Conference and presented a paper at the Crypto '90 conference, or possibly the Crypto '91. (I have a Xerox of the paper someplace and may be able to dig it up if you're interested) -- .......................................................................... 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 2.0 and MailSafe keys by arrangement. From fen at genmagic.com Tue Oct 20 17:45:27 1992 From: fen at genmagic.com (Fen Labalme) Date: Tue, 20 Oct 92 17:45:27 PDT Subject: Mac Version PGP Message-ID: <9210210045.AA28410@relay1.UU.NET> Subject: RE>Mac Version PGP > No one has been able to get me the source-code to PGP, and when > I ftp'd it from wherever, it came ZIP'd in a format that my > unzipper doesn't recognize. There are several mac un-zip programs available for anonymous ftp from sumex.stanford.edu (cd info-mac/util; mget unzip-11.hqx mac-zip-10.hqx). > But, it should be fairly straight forward to throw it into > THINK C. A person here has put a short amount of effort into "macifying" PGP. He's gotten it to compile in Think and MPW, but it won't run yet. According to him, the technical reason is that some sort of "goofy bus-error bullshit" is occuring, and so, if you figure it out, please let this list know (as well as possible posting it to alt.crypt.sources, if such exists). We will do the same. Good luck! Fen From gg at well.sf.ca.us Wed Oct 21 01:16:08 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Wed, 21 Oct 92 01:16:08 PDT Subject: Home security... Message-ID: <199210210815.AA06441@well.sf.ca.us> Tempest: there are companies which make cages for Macs and PCs, I don't have addresses but they can probably be found with some searching of ads. The main application it would seem, is not the individual home user (unless s/he's a notorious digital dissident) but rather the encrypted BBS, particularly one which decrypts and re-encrypts or retransmits messages. Consider the labor cost of monitoring a computer, and you can see it would be reserved for the ones that are "significant." Keeping your computer off the phones and AC while doing crypto processing, can be fairly easy. Unplug the darn modem from the phone socket. (Gee that was simple, wasn't it?) Use a laptop and run it entirely on the batteries while doing crypto processing. You can go buy an old laptop pretty cheaply these days... Or get an uninterruptable power supply for your main computer; cost will vary from $600 to $1500 depending on how much time you need to be running on the large batteries which are converted into AC to run the computer. -gg From pmetzger at shearson.com Wed Oct 21 08:23:37 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Wed, 21 Oct 92 08:23:37 PDT Subject: another service In-Reply-To: <9210210014.AA05539@netcom2.netcom.com> Message-ID: <9210211427.AA03115@newsu.shearson.com> >From: tcmay at netcom.com (Timothy C. May) >Eric Hollander writes: >> I have thought of another service, like the depository, which might be >> useful to the user community: a time stamping notary service. This would >> have less security problems than the depository and would also be neccessary >> if RSA'ed documents are to replace contracts and other paper documents used >> in business. >Bellcore is offering some form of this service, or plans to. Stuart >Haber, one of the codevelopers, described this at last year's Hackers >Conference and presented a paper at the Crypto '90 conference, or >possibly the Crypto '91. (I have a Xerox of the paper someplace and >may be able to dig it up if you're interested) Haber isn't offering quite the service described -- he worked out a much nicer notarization and time stamping protocol thats really neat. Every day or two a critical number spat out from the service gets published in the classifieds of the New York Times so people can independantly verify that there is no cheating. By the way, technically, the service doesn't do timestamping, just a verified ordering of notarized documents. Unfortunately, there is no mathematically provable way to know what time it is -- you must trust someone on that. Stu's a really nice guy -- maybe someone should encourage him to join this list. Perry From hughes at soda.berkeley.edu Wed Oct 21 09:43:25 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Wed, 21 Oct 92 09:43:25 PDT Subject: Keystone In-Reply-To: <9210201753.AA009kv@fnordbox.UUCP> Message-ID: <9210211643.AA11195@soda.berkeley.edu> Eric: >:I would be hesitant to implement a system that _only_ required a user >:to generate a key pair. Loyd: >I take the opposite view -- I dare *not* supply such a system. [...] >But many users do not have the interest/time/ability to set up PGP on their >home system. For them, I want to provide the best possible privacy given the >ease with which anyone who can find their local LMOS can tap (voice or data) >a line... Where is the key pair generated? It must be on the BBS since your user may not have PGP running. The private key isn't private! The work to do public key encryption in the first place is hardly valuable if the owner of the private key doesn't hold it. If you just want inter-BBS privacy, why not set up each BBS with a PGP key pair, and use that for transfering messages? There's not much difference in security. A monitoring sysop would be able to read all the traffic originating on that board in either system. The difference is that such a monitoring sysop would not be able to read replies. Why? Because the private keys are kept on the originating board. But it sounds as though you're trying to prevent against external monitoring and that you trust your sysops. In this case there is no advantage to issuing keys to individuals; it's just not worth the effort. Loyd: >I don't have my user's terminal program -- I *do* have the bbs software. This is the unfortunate fact of the situation, I acknowledge. But do you know what terminal programs are in the most common use? I suspect most of this stuff could be done with script programming in the various terminal packages. Do you know, in aggregate, how many users of each terminal program you have? You can poll your users to find out. You'll need this data to allocate your effort. And you've got lots of people willing to help, even if they can't because they are working on other projects. Everyone on this list, for example. Let me repeat, for those of you who did not previously know you were willing to help. Everyone on this list should be willing to help Loyd write scripts for his users to use PGP. Cypherpunks write code. This will mean someone who knows Procomm, Crosstalk, Qmodem, Telix, etc. for the PC, someone who knows the various Mac, Amiga, Atari, and other machines. This will mean someone to write nice pretty visual interfaces for PGP to put all the PGP options on menus where they are all visible. This will mean people to think about BBS/terminal protocols. This will mean lots of individual contributions, no single of which need be large, but whose sum will be. Eric From hughes at soda.berkeley.edu Wed Oct 21 10:11:42 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Wed, 21 Oct 92 10:11:42 PDT Subject: TEMPEST, Eavesdropping In-Reply-To: <9210202224.AA28714@netcom2.netcom.com> Message-ID: <9210211711.AA11833@soda.berkeley.edu> >Their chief concern doesn't seem to be folks like us, but rather >concerns about vans parking outside high tech and defense contractors >and slurping up what they can [...] When banks start signing with private keys, then we get an even more interesting monitoring problem. >And someone asked about building Faraday cages. Don't even try! Sometimes it is cheaper to build a whole building to be tempest-spec than to buy all tempest-spec electronics. What I have heard about such stuff is solid copper walls and no windows. No exacly your classical Faraday cage; more like your classical Gaussian surface. :-> TEMPEST is an acronym. I don't remember for what. Eric From hughes at soda.berkeley.edu Wed Oct 21 10:13:36 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Wed, 21 Oct 92 10:13:36 PDT Subject: another service In-Reply-To: <9210202353.AA04723@soda.berkeley.edu> Message-ID: <9210211713.AA11854@soda.berkeley.edu> Re: digital timestamping. Eric Hollander says: >Ideas? Thoughts? Yes. Send code. Eric From barrus at tree.egr.uh.edu Wed Oct 21 13:26:56 1992 From: barrus at tree.egr.uh.edu (Karl L. Barrus) Date: Wed, 21 Oct 92 13:26:56 PDT Subject: the acronym TEMPEST Message-ID: <9210212026.AA00628@tree.egr.uh.edu> > TEMPEST is an acronym. I don't remember for what. > Eric TEMPEST = Transient ElectronMagnetic Pulse Emission STandard. Pretty cool sounding acronym :-) /-----------------------------------\ | Karl L. Barrus | | barrus at tree.egr.uh.edu (NeXTMail) | | elee9sf at menudo.uh.edu | \-----------------------------------/ From barrus at tree.egr.uh.edu Wed Oct 21 13:44:45 1992 From: barrus at tree.egr.uh.edu (Karl L. Barrus) Date: Wed, 21 Oct 92 13:44:45 PDT Subject: fast elliptical encryption Message-ID: <9210212044.AA00695@tree.egr.uh.edu> In the winter NeXTWorld magazine, the article ("Tales from the Crypt") on page 94 mentions various topics of interest: public key encryption, export restrictions, the role of the NSA, etc. (It's just a one page article and doesn't go into much depth). Anyway, NeXTStep 3.0 is bundled with fast elliptical encryption for NeXTMail. As a result, 3.0 is export restricted. Does anybody know about the "fast elliptical encryption" public-key system? How different is it from good ol' RSA? Is it related to the elliptic-curve factoring algorithm (am I remembering this correctly - I don't know how elliptic curve factoring works, but I remember seeing a reference to it somewhere)? Just curious... /-----------------------------------\ | Karl L. Barrus | | barrus at tree.egr.uh.edu (NeXTMail) | | elee9sf at menudo.uh.edu | \-----------------------------------/ From pmetzger at shearson.com Wed Oct 21 14:07:37 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Wed, 21 Oct 92 14:07:37 PDT Subject: TEMPEST, Eavesdropping In-Reply-To: <9210211711.AA11833@soda.berkeley.edu> Message-ID: <9210211934.AA09886@newsu.shearson.com> >From: Eric Hughes >>Their chief concern doesn't seem to be folks like us, but rather >>concerns about vans parking outside high tech and defense contractors >>and slurping up what they can [...] >When banks start signing with private keys, then we get an even more >interesting monitoring problem. Consider that the international clearing and settlement systems for interbank transactions process several TRILLION a day in electronic transactions, and then consider what diverting just a tiny little bit of that to yourself would be worth. Security in banks is ALREADY crucial. Perry From UJACAMPBE at memstvx1.memst.edu Wed Oct 21 14:29:41 1992 From: UJACAMPBE at memstvx1.memst.edu (Campbell James A) Date: Wed, 21 Oct 92 14:29:41 PDT Subject: Put me on your mailing list! Message-ID: <9210212129.AA27437@toad.com> Hey, I'd like to be on the mailing list for CYPHERPUNKS. My address is: ujacampbe at memstvx1.memst.edu If you need this too, here's my PGP 2.0 public key: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAirkL4AAAAEEANAomYnlPXopnms9RtU0ln9CiLJljssOeflC9A+QIDujXhPT yApbL6VPqSUSoFF/e72xTJixyrwBQhw5lAvfvQPEiGIFQQYxviF+Qg/+6/JVvLCj vnGVFl9kKTEYVeONxBNGiaXuSE0VMQLx47iP9AU+wYw62aXmTNtW1BUtX5BHAAUR tDBKYW1lcyBBLiBDYW1wYmVsbCA8dWphY2FtcGJlQG1lbXN0dngxLm1lbXN0LmVk dT4= =0rCj -----END PGP PUBLIC KEY BLOCK----- Thanks! James A. Campbell Memphis State University Memphis, Tennessee From hughes at soda.berkeley.edu Wed Oct 21 22:35:21 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Wed, 21 Oct 92 22:35:21 PDT Subject: Keystone In-Reply-To: <9210220333.AA009m7@fnordbox.UUCP> Message-ID: <9210220541.AA13526@soda.berkeley.edu> Ah. A small PGP subset. You hadn't mentioned this. When you said you weren't requiring the user to run PGP, I assumed key generation must occur on the board. As for your fatal flaw I hadn't spotted, I had spotted it, and the location of the private key was the critical point. If the key is on the BBS, the message goes out in the clear. Look, it boils down to this. If the message traffic to the BBS is to be encrypted, then the user has to generate a key on his own machine and decrypt it on his own machine. There's no way around that. But the user interface problem can be solved. Just make a bunch of .com files which do nothing but spawn pgp by invoking the correct arguments. Very simple; a few lines of C is all. Even the PGPPATH can be set before the spawn. It's an easy encapsulation. It will run a bit slower for load time, but not appreciably. And you won't have to recompile PGP from the distributed executables. Eric From gnu at cygnus.com Wed Oct 21 23:35:44 1992 From: gnu at cygnus.com (gnu at cygnus.com) Date: Wed, 21 Oct 92 23:35:44 PDT Subject: Keystone In-Reply-To: <9210220541.AA13526@soda.berkeley.edu> Message-ID: <9210220637.AA20200@cygnus.com> We have a small project cooking, to use Diffie-Hellman key exchange to choose a random key to encrypt Internet connections (telnet, rlogin, ftp, smtp). This same protocol can also be used over an ordinary modem connection between a user's PC and a BBS, preventing eavesdropping or wiretapping of that phone call. It would also be able to protect phone calls between a PC and a Unix timesharing system, regardless of what networks lie in between, if we wrote a simple login program that handled the modem protocol. (It doesn't protect against active re-routing of the call, e.g. by substituting another machine for the BBS, but we could work on that as Phase II.) (I suggest that the initial Diffie-Hellman handshake all be done in ASCII encoding, no matter what the medium, so that the same protocol can be used on all media, binary-transparent or not.) This scheme would require support in the BBS and in the user's PC terminal program. Given a working Unix implementation, it would be relatively easy to add to the terminal program, if source code for any decent terminal programs was available. This is where Unix shows a real advantage, since you can get free source for just about program, while "free" PC programs means free binaries. If anyone knows of a reasonably popular PC terminal emulator for which source code is freely available and distributable, let us know. (Or, if anyone knows the author of a popular commercial PC terminal emulator program, tell the author that they could consider licensing Diffie-Hellman from RSA for commercial use and adding it to their proprietary terminal program. They're unlikely to do so, since it costs money, unless some very popular BBS's can also be upgraded to do it -- standard commercial chicken/egg problem which free source code solves.) On the BBS side, I've heard the idea of freeing the Fido source code as copylefted code. That would make it easy to add things like login session encryption for the modem users. John Gilmore From whitaker at eternity.demon.co.uk Thu Oct 22 00:00:52 1992 From: whitaker at eternity.demon.co.uk (Russell E. Whitaker) Date: Thu, 22 Oct 92 00:00:52 PDT Subject: "Cypherpunks write code" Message-ID: <2580@eternity.demon.co.uk> Eric Hughes writes: > > Cypherpunks write code. > > This will mean someone who knows Procomm, Crosstalk, Qmodem, Telix, > etc. for the PC, someone who knows the various Mac, Amiga, Atari, and > other machines. This will mean someone to write nice pretty visual > interfaces for PGP to put all the PGP options on menus where they are > all visible. This will mean people to think about BBS/terminal > protocols. This will mean lots of individual contributions, no single > of which need be large, but whose sum will be. > > Eric > Count me in on the Procomm scripting. I *may* do something for Telix, too. Who knows? I may sell the scripts/interfaces on AMiX. ;-) 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 avalon at coombs.anu.edu.au Thu Oct 22 06:55:03 1992 From: avalon at coombs.anu.edu.au (Darren Reed) Date: Thu, 22 Oct 92 06:55:03 PDT Subject: terminal progs to do pgp... Message-ID: <9210221354.AA06975@coombs.anu.edu.au> Rather than rewrite the terminal progs, why not rewrite the BIOS level drivers and such ? (if its possible). At least this way, it would be one hack which would work on all terminal programs...you'd just need a way to turn it on/off which I'm sure wouldn't be that hard :-) cheers, darren From fnordbox!loydb at cs.utexas.edu Thu Oct 22 08:33:10 1992 From: fnordbox!loydb at cs.utexas.edu (Loyd Blankenship) Date: Thu, 22 Oct 92 08:33:10 PDT Subject: Keystone Message-ID: <9210221550.AA009mh@fnordbox.UUCP> :But the user interface problem can be solved. Just make a bunch of :.com files which do nothing but spawn pgp by invoking the correct :arguments. Very simple; a few lines of C is all. Even the PGPPATH :can be set before the spawn. It's an easy encapsulation. It will run :a bit slower for load time, but not appreciably. And you won't have :to recompile PGP from the distributed executables. That's a real good idea. I shoulda thunk of it myself. :-) Loyd *************************************************************************** * loydb at fnordbox.UUCP Once you pull the pin, * Loyd Blankenship * * GEnie: SJGAMES Mr. Grenade is no longer * PO Box 18957 * * Compu$erve: [73407,515] your friend! * Austin, TX 78760 * * cs.utexas.edu!dogface!fnordbox!loydb * 512/447-7866 * *************************************************************************** From hughes at soda.berkeley.edu Thu Oct 22 08:51:19 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Thu, 22 Oct 92 08:51:19 PDT Subject: Keystone Message-ID: <9210221550.AA23915@soda.berkeley.edu> Re: adding D-H key exchange to PC software gnu at cygnus.com writes: >Given a working Unix implementation, it would be relatively easy to >add to the terminal program, if source code for any decent terminal >programs was available. But source code is not available. The trouble is that all the decent terminal programs for PC's are shareware or commercial (or were originally shareware and have become commercial). I too would like to know of any source-available PC terminal programs, but I suspect there are none because of the prevailing shareware culture. Re: getting an author to license D-H key exchange The reason this will not happen is not the bootstrapping problem (chicken/egg), but that there is no perceived value to an encrypted link. The sysop is already has access to everything on the dedicated machine and may even have a policy of scanning all messages. External hackers can't really get in because shell access isn't really done remotely. The only ones you are protecting against are people with a hard tap on the phone line itself. For most people, this is not a concern. Since there's no perceived value and since all the software would require license from RSADSI, it won't happen that way. Re: using a protocol layer avalon at coombs.anu.edu.au writes: >Rather than rewrite the terminal progs, why not rewrite the BIOS level >drivers and such ? (if its possible). That's not possible either. Most terminal programs write directly to the hardware. This is single-tasking, standardized hardware, remember, and the original BIOS interface for the serial port was totally unusable. Some communications programs use FOSSIL drivers, but many (if not most) terminal programs don't support it. (FOSSIL is a BIOS-level serial port interface description which could hooked into or rewritten to support a protocol.) Look, I wish all this stuff were in use. Everyone should encrypt all their communications links as a matter of policy. (That includes voice, and if you thought the PC terminal program bootstrapping was difficult ...) Let's move incrementally, though. If we can get people to at least encrypt all of their e-mail, that will be an excellent start. One incentive would be for the BBS operators to phase in a policy that they will accept no e-mail which is _not_ encrypted. Comments? Eric From omega at spica.bu.edu Thu Oct 22 09:25:56 1992 From: omega at spica.bu.edu (The Omega) Date: Thu, 22 Oct 92 09:25:56 PDT Subject: BBS E-mail policy Message-ID: <9210221623.AA00440@spica.bu.edu> >> One incentive would be for the BBS operators to phase in a policy that they will accept no e-mail which is _not_ encrypted. Comments? << And how does your BBS software tell whether or not you've just sent encrypted mail, plaintext mail or line-noise? (in an encryption/decryption-at-user's-end scenario) -- Omega at spica.bu.edu From sdw at meaddata.com Thu Oct 22 10:09:30 1992 From: sdw at meaddata.com (Stephen Williams) Date: Thu, 22 Oct 92 10:09:30 PDT Subject: Keystone In-Reply-To: <9210220637.AA20200@cygnus.com> Message-ID: <9210221600.AA21898@bugatti.meaddata.com> .. > real advantage, since you can get free source for just about program, > while "free" PC programs means free binaries. If anyone knows of a > reasonably popular PC terminal emulator for which source code is > freely available and distributable, let us know. PC Kermit, of course. The best vt100 emulator around, last I used them heavily. > sdw -- Stephen D. Williams Local Internet Gateway Co.; SDW Systems 513 496-5223APager LIG dev./sales Internet: sdw at world.std.com CIS 76244.210 at compuserve.com OO R&D Source Dist. By Horse: 10028 Village Tree Ct., Miamisburg, OH 45342 GNU Support ICBM: 39 34N 85 15W I love it when a plan comes together From Tom.Jennings at f111.n125.z1.FIDONET.ORG Thu Oct 22 10:52:24 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Thu, 22 Oct 92 10:52:24 PDT Subject: Keystone Message-ID: <3225.2AE6E91B@fidogate.FIDONET.ORG> re: PGP interface to email. I've completed my "RM" program. The PGP interface is single-keystroke, and includes optional pass-phrase management. I've released it with source under the copyleft agreement. It can be downloaded or filerequested from me if anyone's interested. (MSDOS and .MSG format only) --- ReadMail * Origin: World Power Systems / FidoNews / San Francisco CA (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 Thu Oct 22 11:19:49 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Thu, 22 Oct 92 11:19:49 PDT Subject: Keystone Message-ID: <3230.2AE6EFBC@fidogate.FIDONET.ORG> Hughes: U> But source code is not available. The trouble is that all U> the decent terminal programs for PC's are shareware or U> commercial (or were originally shareware and have become U> commercial). I too would like to know of any U> source-available PC terminal programs, but I suspect there U> are none because of the prevailing shareware culture. U> I'll give you all of my Fido/FidoNet and FidoTerm sources. You can already have ReadMail. U> communications programs use FOSSIL drivers, but many (if U> not most) terminal programs don't support it. Commercial people still sneer at amateur systems like FidoNet. Their loss. FOSSIL is widely supported otherwise. FidoTerm and Fido/FidoNet both support FOSSIL, as do "all" FidoNet programs. U> One incentive would be for the BBS operators to phase in a U> policy that they will accept no e-mail which is _not_ U> encrypted. Comments? SHEESH!@+#)(#$ You oughta see what most sysops think. It's embarrassing. In their defense, NO ONE WILL TELL US what is reasonable. I know, I know how much is presently undefined and without precedent, but the broadest general parameters and guidelines are not that obscure. I'm also part of the BBSLAW mailing list (out of EFF) and it's finally contained some applicable stuff. What you wanna bet the lawscum won't let me repeat in any manner the recent thread on email? (Yes I'm asking.) (Most sysops are terrified that an in-transit, third-party message will contain some illegality and they will all be BUSTED. Hence, it is routine for them to review personally every in-transit message, and kill or bounce them! I am not kidding. (I know this must have been dealt with in the Internet (is kumr/cygnus/etc liable when I tell you that RICHARD NIXONS VISA CARD NUMBER is 4131 34534 456456 456546?) but somehow, no one's ever passed this info on to us.) --- ReadMail * Origin: World Power Systems / FidoNews / San Francisco CA (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 rom fidogate!f111.n125.z1.FIDONET.ORG!tom.jennings at kumr.lns.com Thu Oct 22 11:19:49 1992 Return-Path: Received: from kumr.lns.com by toad.com id AA22497; Thu, 22 Oct 92 11:19:49 PDT Received: by kumr.lns.com (/\==/\ Smail3.1.25.1 #25.3) id ; Thu, 22 Oct 92 11:19 PDT Received: by fidogate.FIDONET.ORG (mailout1.26); Thu, 22 Oct 92 11:15:22 PDT Date: Thu, 22 Oct 92 11:03:26 PDT Message-Id: <3229.2AE6EFB9 at fidogate.FIDONET.ORG> From: tom.jennings at f111.n125.z1.FIDONET.ORG (tom jennings) Subject: thread (was Re: A To: cypherpunks at toad.com X-Mailer: mailout v1.26 released Just a slightly amusing message forwarded from PUBLIC_KEYS... From: Wes Cowley at 1:125/180 To: Wes Perkhiser at 1:125/111 Subject: Loss of thread (was Re: A ;Status: (read 2 times) ;^AINTL 1:125/111 1:125/180 ;^APID ReadMail ;^AMSGID RM1:125/111=2AE68513 >----------------------- Do not change this line -----------------------------< WP>>"Hi, how are you, and what's your key?" WP>>P.S. Will that be a new pick-up line? It beats "What's your sign?" "Do you want to swap keys, or just come up to my pad, one time?" * OLX 2.1 TD * The computing field is always in need of new cliches. --- DCI/Chauncy 0.7 * Origin: Bird Lake - (813)265-3256 (1:377/14.0) SEEN-BY: 100/520 102/890 105/36 125/111 125 180 185 135/71 340 163/438 170/109 SEEN-BY: 216/21 234/1 253/513 261/1136 285/27 312/2 374/14 26 48 98 377/3 14 15 SEEN-BY: 377/33 37 396/1 2200/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 Thu Oct 22 13:35:59 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Thu, 22 Oct 92 13:35:59 PDT Subject: Keystone In-Reply-To: <9210220637.AA20200@cygnus.com> Message-ID: <9210221929.AA16268@newsu.shearson.com> >From: gnu at cygnus.com >We have a small project cooking, to use Diffie-Hellman key exchange >to choose a random key to encrypt Internet connections (telnet, >rlogin, ftp, smtp). This same protocol can also be used over an >ordinary modem connection between a user's PC and a BBS, preventing >eavesdropping or wiretapping of that phone call. It would also be >able to protect phone calls between a PC and a Unix timesharing system, >regardless of what networks lie in between, if we wrote a simple login >program that handled the modem protocol. (It doesn't protect against >active re-routing of the call, e.g. by substituting another machine >for the BBS, but we could work on that as Phase II.) I would suggest that it be done during phase one. Spoofing attacks are very important things to guard against, and thanks to PGP there is a handy dandy set of code out there to steal from to provide for public key based authentication of the link. Indeed, I would go further and suggest that the protocol be designed so that it does not reveal the entities forming the link to outsiders (unless one end should intentionally advertise who it is, the assumption should be that both ends know who the other end is a priori). There is also a very good implementation of the IDEA cypher in PGP, which should run well as the conventional cypher for the link (although I would suggest having the protocol negotiate the cypher just in case IDEA gets replaced later on). I am very interested in seeing such a protocol standardized because I have another use for it -- secure telephones. Given modern DSPs to do and cheap V.32bis modems, excellent secure voice communications are feasable. The presense of code in the public domain to handle secure encrypted links could be easily dropped right in to this application. >(I suggest that the initial Diffie-Hellman handshake all be done in >ASCII encoding, no matter what the medium, so that the same protocol >can be used on all media, binary-transparent or not.) I agree that this should be a negotiated option in the protocol (prehaps with some sort of test done at the beginning of the link for line transparency), but I'm not sure it should be mandatory as that eighth bit get significant at times. >If anyone knows of a reasonably popular PC terminal emulator for >which source code is freely available and distributable, let us know. Kermit is the obvious choice. Perry From bill at anubis.network.com Thu Oct 22 14:13:15 1992 From: bill at anubis.network.com (Bill O'Hanlon) Date: Thu, 22 Oct 92 14:13:15 PDT Subject: Keystone In-Reply-To: <9210221929.AA16268@newsu.shearson.com> Message-ID: <9210222112.AA06121@anubis.network.com> > >I am very interested in seeing such a protocol standardized because I >have another use for it -- secure telephones. Given modern DSPs to do >and cheap V.32bis modems, excellent secure voice communications are >feasable. The presense of code in the public domain to handle secure >encrypted links could be easily dropped right in to this application. > I've had much the same idea. There are a lot of people out there with PCs equipped with Soundblasters and V.32 modems. I can't think of a better way to fight back against that ridiculous FBI Telephone legislation. -- Bill O'Hanlon Network Systems Corporation bill at network.com From DELTORTO at AppleLink.Apple.COM Thu Oct 22 16:28:44 1992 From: DELTORTO at AppleLink.Apple.COM (Imaja, David Del Torto,PAS) Date: Thu, 22 Oct 92 16:28:44 PDT Subject: temporary request Message-ID: <719795393.8323950@AppleLink.Apple.COM> Greetings CypherFolk, I, one of your newest members, am on vacation in Europe (right now I'm in Holland enjoying the "coffee" shops) and am temporarily restricted to using AppleLink as my gateway to Internet. Because it costs $0.50 to $0.80 per piece of email, I asked Eric to _temporarily_ remove me from the general alias until I return to the US in December, saving me major bucks. When I get back, I'll announce that you can send me mail at "ddt at well.sf.ca.us". I enjoyed the repartee I sampled and look forward to joining in as I learn more. Offer of the Week: If anyone needs me to physically pick up a PGP key from someone here in Europe, I have a train pass good for another month (maybe longer if I can alter it again) and will consider any request that will take me to interesting locations and connect me with interesting folks. Further Request: If any of you send any interesting stuff to the group alias (e.g. Russ Whitaker's article on "computer cryptography" from the Economist) and think it might be of general interest to someone learning about the whole encryption process (i.e. me), please cc me at "deltorto at applelink.apple.com" anytime. This would be appreciated. I also encourage anyone who has helpful learning material to forward it to me so I can get up to speed. I am working on an interesting project I would like to share with the right people, but I am not prepared to discuss it in public. Does anyone have a copy of PGP 2.0 that runs on a Macintosh? If you email it to me, I will cover any costs you incur. Coolness. Until we all meet in person, dave From hughes at soda.berkeley.edu Thu Oct 22 23:02:09 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Thu, 22 Oct 92 23:02:09 PDT Subject: BBS E-mail policy In-Reply-To: <9210221623.AA00440@spica.bu.edu> Message-ID: <9210230601.AA26160@soda.berkeley.edu> Re: distinguishing between encrypted mail, plaintext mail, and line-noise. I'm really glad this question came up. I passed over it before because I was more interested in the social issue, but the technical one is important. The basic technique is the foundation of cryptography: information theory. For this application, you can just measure the entropy; it alone should be able to distinguish between the three sources. The entropy measures how well one can statistically predict the output of a source. A random source has eight bits of entropy per byte. As randomness decreases, so does the entropy measure. (Mail me if you want references in order to learn this stuff yourself.) Now line noise, let's say, will appear random. So its entropy should be right near the maximum, 8 bits. Text encrypted with PGP using the ASCII armor uses only 64 characters out of 256 possible, or one fourth of the total available. Its entropy would be 2 bits per character. English text is usually around four and five bits per character, if I remember right. To calculate the entropy, you first make a table (of size 256) of character frequencies normalized to the range [0,1]. Call these p_i. The entropy is then (TeX here) $ \Sum_{i=0}^{256}n - p_i \log_2 p_i $. (The log base 2 give bits instead of natural units). Now see if this number is in one of the following ranges: [1.5 .. 2.5] encrypted text [3 .. 6] regular text [7 .. 8] line noise This is a very simple measure. There are other measures to look for the deviation from an expected distribution, which give much more accurate distinctions. One can very easily separate languages from each other just by looking at such measures. Note that none of these techniques ever look at the content. Nor do they look at digraph (two-letter combinations) or trigraph statistics. In fact, the content is completely destroyed by the scanning process! Lots of this stuff is known; this is how the big boys crack codes. I'm glad there arose a natural context to explain some of this stuff. Eric From nobody at soda.berkeley.edu Thu Oct 22 23:10:13 1992 From: nobody at soda.berkeley.edu (nobody at soda.berkeley.edu) Date: Thu, 22 Oct 92 23:10:13 PDT Subject: Eavesdropping on a printer's signature Message-ID: <9210230609.AA26646@soda.berkeley.edu> While doing a summer (1980?) co-op with Raytheon Submarine Signal division in Newport RI, a milk-truck-sized van pulled up out front and opened a sliding side door. Inside was a line printer that was busy printing out the same text that an internal (in the middle of the building, perhaps 150 feet away) line-printer was printing. There were mistakes, but it was readable. My guess is that with all the electromechanical pulses the printer was emanating this was pretty easy. Probably harder to do with a laser printer... From hughes at soda.berkeley.edu Thu Oct 22 23:22:28 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Thu, 22 Oct 92 23:22:28 PDT Subject: Keystone In-Reply-To: <3230.2AE6EFBC@fidogate.FIDONET.ORG> Message-ID: <9210230622.AA26831@soda.berkeley.edu> Re: about a policy to require encrypted email. Here is a statement I would like to see become policy and law: "A provider of communications services cannot be held liable for the consequences of encrypted communications that pass though its system." Here is the argument to support it. If I am a common carrier, I am already off the liability hook by the nature of common carrier. Suppose I am not a common carrier, for example because I provide a value-added service such as electronic mail. Also suppose that I can't observe the contents of traffic that flows through my system because it is encrypted. Then I have no means to take any action whatsoever with regard whatever consequences might occur from that traffic. I cannot be held responsible for actions I cannot take, much less know of the existence of. Such a policy would give BBS operators a complete defense against claims of liability arising from email traffic. It doesn't solve the problem for public discussion areas, but it's a good start. It would also drive the deployment of encryption technology. Eric From scott_collins at genmagic.com Fri Oct 23 00:06:14 1992 From: scott_collins at genmagic.com (Scott Collins) Date: Fri, 23 Oct 92 00:06:14 PDT Subject: Diffie-Hellman Message-ID: <9210230706.AA04122@relay2.UU.NET> Subject: Diffie-Hellman >Since there's no perceived value and since all the software would >require license from RSADSI, it won't happen that way. It was not my understanding that RSA held any patents, copyrights or other controls over Diffie-Hellman key exchange. The 'big-number' math required is not difficult and is fully documented in Knuth's "The Art of Computer Programming", vol2: Seminumerical Algorithms; section 4.3: Multiple Precision Arithmetic. Also note that this multiple precision code is available in the PGP source in the file mpilib.c. The exchanged key could easily be a DES (or other fast symmetric cypher) key -- and usually is. Unless you want to perform an authenticated key exchange with Diffie-Hellman as described in "Authentication and Authenticated Key Exchanges" [Diffie, Van Oorschot and Wiener in "Designs, Codes and Cryptography", 2, 107-125 (1992)] using certificates signed with the RSA algorithm, then RSA doesn't have to enter the picture at all. Is my understanding of RSAs controls incorrect? From gnu at cygnus.com Fri Oct 23 00:28:19 1992 From: gnu at cygnus.com (gnu at cygnus.com) Date: Fri, 23 Oct 92 00:28:19 PDT Subject: Keystone In-Reply-To: <9210230622.AA26831@soda.berkeley.edu> Message-ID: <9210230728.AA25822@cygnus.com> > "A provider of communications services cannot be held liable for the > consequences of encrypted communications that pass though its system." Far too simple. Suppose the provider is a BBS operator who *knows* what their users are passing through the system? Suppose the provider has keys to the encrypted communications? Suppose those keys are only to be used under duress (e.g. under a court order)? Suppose the provider is a parent and the user is their teenage daughter? Suppose the encryption is easily breakable? The principle you are looking for is that if the service provider has no *control* over the content, then they should have no *liability* for it either. The courts are gradually making that happen. But control relates directly to the specific facts of the particular case -- not whether encryption is in use. The case law on liability for content is gradually being made. So far, no particularly horrible precedents have been set (I don't think there are precedents yet in the arrest-the-record-store-owner-for-rap- records-the-cops-don't-like issue). In a good decision, Compuserve was let off the hook for a message sent by someone who Compuserve even paid to moderate a corner of their service -- because Compuserve didn't control the content of that corner. I realize that this group has a tendency toward extremism, but let's temper that with a bit of wisdom, too. John From gg at well.sf.ca.us Fri Oct 23 02:31:20 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Fri, 23 Oct 92 02:31:20 PDT Subject: BBS E-mail policy Message-ID: <199210230930.AA18783@well.sf.ca.us> Eric, count this as another vote for default encryption of all communications links. Omega: the way to tell is to run a frequency count on the text. If it follows the usual distribution for the language it's in, then it's probably plaintext. In which case the BBS rejects it. Voice: yeah, it's a pain in the tail. One thing I thought might be interesting is to use two digitisers: one for the voice input, another for a keystream which is derived from a radio or TV program signal which can be picked up simultaneously by both correspondents. XOR the two streams together and then do whatever you have to do to make the encrypted results transmissable. I actually tried building an analog version of this about ten years ago (might even bring it to one of our meetings, just for fun). Analog voice "encryption" is actually pretty worthless (I didn't know how worthless until I experimented with it) from a security standpoint. Voiceprint modification may have some uses. About five or six years ago I built one of those: based on a pitch shifter with a graphic EQ on the input side and another on the output side. Worked, sort of. Now there is a phone you can buy with something similar built in. -gg From gg at well.sf.ca.us Fri Oct 23 02:39:14 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Fri, 23 Oct 92 02:39:14 PDT Subject: Keystone Message-ID: <199210230938.AA18939@well.sf.ca.us> Re BBSs and encrypted email. Of course it would eliminate liability; well I would expect the Powers That Be to simply outlaw the use of encryption on BBSs or find some legal convolution which has a similar result. The only way we can win on this is to do what we're doing: get this stuff out there far & wide before anyone has a chance to stop it. -gg From wcs at anchor.ho.att.com Fri Oct 23 07:55:30 1992 From: wcs at anchor.ho.att.com (Bill Stewart) Date: Fri, 23 Oct 92 07:55:30 PDT Subject: Diffie-Hellman Message-ID: <9210231456.AA20396@anchor.ho.att.com> Unfortunately, Diffie-Hellman *is* patented, and I'm pretty sure Public Key Partners (closely related to RSA) holds the patent, just as they hold RSA's. To quote Steve Bellovin: U.S. Patent Number: 4200770 Title: Cryptographic Apparatus and Method Inventors: Hellman, Diffie, Merkle Assignee: Stanford University Filed: September 6, 1977 Granted: April 29, 1980 [Expires: April 28, 1997] So we're stuck with it being patented until 1997. Too bad - I was starting to think along the same lines about doing a D-H-based mailer. It's non-trivial, if you have to worry about active eavesdroppers swapping mail messages on you, and it's easier to do if there's a trusted Key Distribution Center, and if you think about all the cases carefully you tend to re-create either Needham-Schroeder or the Everhart-Osborn Bell Labs patent (~1980++), but you can certainly do it for the common case that says the Bad Guys are only listening to your mail and not tampering with it. Bill Stewart, wcs at anchor.ho.att.com From hughes at soda.berkeley.edu Fri Oct 23 09:30:05 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Fri, 23 Oct 92 09:30:05 PDT Subject: Diffie-Hellman In-Reply-To: <9210231456.AA20396@anchor.ho.att.com> Message-ID: <9210231629.AA10278@soda.berkeley.edu> >I'm pretty sure Public Key Partners (closely related to RSA) holds >the patent, just as they hold RSA's. This is what I remember about PKP. Public Key Partners is a consortium of four, two industry and two academic members. RSA Data Security and Cylink are the industry partners. I believe that Stanford and MIT are the academic ones. Eric From jjaloszyns at bluejay.mich.fred.org Fri Oct 23 10:04:47 1992 From: jjaloszyns at bluejay.mich.fred.org (jjaloszyns at bluejay.mich.fred.org) Date: Fri, 23 Oct 92 10:04:47 PDT Subject: TEMPEST Message-ID: <9210231704.AA25073@home.merit.edu> There has been quite a bit of concern about certain people (agencies) using a TEMPEST machine and invading privacy. Most of the things to defeat this that have been taked about have revolved around shielding. What would be the problem with having another device to emit random signals on the same frequency that your monitor operates on? Has this already been implimented? Legal? jon ------------- 43.31.28N, 84.41.41W Jon Jaloszynski Student 9-12 at Shepherd HS, Shepherd Shepherd, MI From hughes at soda.berkeley.edu Fri Oct 23 10:27:18 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Fri, 23 Oct 92 10:27:18 PDT Subject: Keystone In-Reply-To: <9210230728.AA25822@cygnus.com> Message-ID: <9210231726.AA11213@soda.berkeley.edu> My proposal: > "A provider of communications services cannot be held liable for the > consequences of encrypted communications that pass though its system." First let me point out that this wording is intended to be clear, not to be legally useful. This wording cannot stand for itself without reference to the rest of the body of law. I never intended it to. It is also a mistake to think that I am advocating the converse, namely, that the provider would be responsible for all unencrypted communications. Nor do I think that this should be the only defense a provider has available. gnu: >Far too simple. Suppose the provider is a BBS operator who *knows* what >their users are passing through the system? The defense of encrypted communications is not germane here. Such knowledge did not come from the communications because they were encrypted. If the provider could read them, then they weren't encrypted to the provider. Therefore such knowledge came from some other source. A claim that arises from such knowledge is not met by this criterion. The defense of encrypted communications is not a blanket defense. >Suppose the provider has keys to the encrypted communications? Then the defense does not apply. If the provider has keys to the communications, then they are not encrypted as far as the provider is concerned. The question is not the _form_ of the communications, but their _legibility_. >Suppose those keys are only to be used under duress (e.g. under a >court order)? If the keys are in the possession of the provider and the provider and the user have an agreement that the provider is not to use them in any way other than archiving them, then the law cannot expect the provider to routinely breach that agreement to search for possibly illegal content. The court may then subpoena these keys if necessary. >Suppose the provider is a parent and the user is their teenage >daughter? The defense of encrypted communications is not germane here. There is a parent/child relation which creates a claim which the encrypted communication defense is irrelevant to. >Suppose the encryption is easily breakable? The test of due diligence may be applied. If the state of the art is that the encryption is unbreakable, then the communications should be consider to be encrypted. If the cipher is automatically crackable, such as monoalphabetic substitution, then the communications should be consider _not_ encrypted. Remember, the question is not _form_, but _legibility_. >The principle you are looking for is that if the service provider has >no *control* over the content, then they should have no *liability* >for it either. No, this is not the principle I was getting at. I was referring to a principle which was more restricted in its use but which is also clearer in its interpretation. This defense is a subset of the defense of no control. If you can't read the content, then _a fortiori_ you can't control it either. It's really very clear that if you have no basis for distinguishing communications except for size, time, sender, and recipient, that you can't act on anything that passes through the system. >The courts are gradually making that happen. This is a good sign. I heartily approve. But it is easier to define legibility with regard to encryption than it is to define control. Referring to encrypted communications is much less ambiguous and should be considered a step in the larger direction. Eric From hughes at soda.berkeley.edu Fri Oct 23 10:33:40 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Fri, 23 Oct 92 10:33:40 PDT Subject: TEMPEST In-Reply-To: <9210231704.AA25073@home.merit.edu> Message-ID: <9210231733.AA11337@soda.berkeley.edu> It should be possible to jam your own emissions, but that same noise might cause be picked up by your own equipment as well and cause errors. Also remember that most of these signals are detected by correlation, which detects a signal even with a very high S/N ratio. So it's not obvious just how to jam. My first guess is to phase-lock onto your own emmissions and then broadcast random bits at higher strength. With E/M monitoring, just like cryptography, you don't really know how to make defenses unless you know how to attack. Eric From UJACAMPBE at memstvx1.memst.edu Fri Oct 23 11:23:11 1992 From: UJACAMPBE at memstvx1.memst.edu (Campbell James A) Date: Fri, 23 Oct 92 11:23:11 PDT Subject: Removal from distribution list Message-ID: <9210231823.AA08903@toad.com> Please remove my address: ujacampbe at memstvx1.memst.edu from your mailing list. Thank you. From pmetzger at shearson.com Fri Oct 23 12:41:02 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Fri, 23 Oct 92 12:41:02 PDT Subject: Keystone In-Reply-To: <9210222112.AA06121@anubis.network.com> Message-ID: <9210231827.AA19677@newsu.shearson.com> >From: bill at anubis.network.com (Bill O'Hanlon) >>I am very interested in seeing such a protocol standardized because I >>have another use for it -- secure telephones. Given modern DSPs to do >>and cheap V.32bis modems, excellent secure voice communications are >>feasable. The presense of code in the public domain to handle secure >>encrypted links could be easily dropped right in to this application. >> >I've had much the same idea. There are a lot of people out there with >PCs equipped with Soundblasters and V.32 modems. >I can't think of a better way to fight back against that ridiculous >FBI Telephone legislation. Its not quite that simple. The amount of computing horsepower needed to do a good digitized voice compression algorithm like CELP is way beyond what a PC can do without a DSP. However, having most of the link layer encryption stuff out of the way will make the rest of the work much easier. Perry From pmetzger at shearson.com Fri Oct 23 12:44:33 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Fri, 23 Oct 92 12:44:33 PDT Subject: BBS E-mail policy In-Reply-To: <199210230930.AA18783@well.sf.ca.us> Message-ID: <9210231845.AA19935@newsu.shearson.com> >From: George A. Gleason >Voice: yeah, it's a pain in the tail. One thing I thought might be >interesting is to use two digitisers: one for the voice input, another for a >keystream which is derived from a radio or TV program signal which can be >picked up simultaneously by both correspondents. XOR the two streams >together and then do whatever you have to do to make the encrypted results >transmissable. Its so simple to just built fully digital systems that use real public key encryption, I don't see why anyone would want to use something like you are proposing. Your system would provide virtually no real security. I really suggest that anyone who is serious about doing this stuff read unabridged (hardcover only) version of "The Codebreakers" by Kahn. He gets into lots of historical examples of how stupidly designed cryptosystems have cost people their lives. Ususally, people have very poor ideas of what is and isn't secure. I suggest that some historical perspective may give people more respect for how hard it is to do this stuff right. Perry From pmetzger at shearson.com Fri Oct 23 12:46:25 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Fri, 23 Oct 92 12:46:25 PDT Subject: Diffie-Hellman In-Reply-To: <9210231456.AA20396@anchor.ho.att.com> Message-ID: <9210231904.AA21331@newsu.shearson.com> >From: wcs at anchor.ho.att.com (Bill Stewart) >Unfortunately, Diffie-Hellman *is* patented, and I'm pretty sure >Public Key Partners (closely related to RSA) holds the patent, just >as they hold RSA's. >Too bad - PGP violates PKPs patents. Everyone is using it. I'm not encouraging patent violations -- I'm just noting fact. Perry From tribble at xanadu.com Fri Oct 23 14:41:59 1992 From: tribble at xanadu.com (E. Dean Tribble) Date: Fri, 23 Oct 92 14:41:59 PDT Subject: multiple message destinations Message-ID: <9210231806.AA12129@xanadu.xanadu.com> Mail typically wants to get sent to multiple receivers, all with different private keys. I vaguely recall that the way PGP works is it generates a symetric cypher key and encrypts the message with that, then encrypts the generated key with the public key of the intended receiver. Is that how it works? Given that, it should be straightforward (and maybe it already does) encrypt the generated key with several public keys so you get one package that can be unsealed by any of several different receivers. Are there other ways to handle sending to multiple receivers? dean From tribble at xanadu.com Fri Oct 23 14:42:19 1992 From: tribble at xanadu.com (E. Dean Tribble) Date: Fri, 23 Oct 92 14:42:19 PDT Subject: BBS E-mail policy Now see if this number is in one of the following ranges: In-Reply-To: <9210230601.AA26160@soda.berkeley.edu> Message-ID: <9210231641.AA11868@xanadu.xanadu.com> [1.5 .. 2.5] encrypted text [3 .. 6] regular text [7 .. 8] line noise This is a very simple measure. There are other measures to look for the deviation from an expected distribution, which give much more accurate distinctions. One can very easily separate languages from each other just by looking at such measures. Where does uuencoded [compressed] binary lie? I would suspect it lies right around where encrypted text is. Presumably straight encrypted text is statistically random [7..8], but that when you8 encrypt to just the ascii subset is when you lose the entropy. dean From tribble at xanadu.com Fri Oct 23 14:46:09 1992 From: tribble at xanadu.com (E. Dean Tribble) Date: Fri, 23 Oct 92 14:46:09 PDT Subject: Keystone "A provider of communications services cannot be held liable for the consequences of encrypted communications that pass though its system." In-Reply-To: <9210230622.AA26831@soda.berkeley.edu> Message-ID: <9210231631.AA11756@xanadu.xanadu.com> The Compuserver decision some months ago supported this indirectly: Compuserver was held not liable for mail and postings on their system, because they don't claim to read them. I don't beleive Compuserve is a common carrier, so the precedence supports the result you want. dean From tribble at xanadu.com Fri Oct 23 14:48:24 1992 From: tribble at xanadu.com (E. Dean Tribble) Date: Fri, 23 Oct 92 14:48:24 PDT Subject: Call for papers Message-ID: <9210231638.AA11816@xanadu.xanadu.com> Call for Papers "Technological Strategies for Protecting Intellectual Property in the Networked Multimedia Environment" Cambridge, Massachusetts, February 3-5, 1993 sponsored by: Coalition for Networked Information Information Infrastructure Project Science, Technology and Public Policy Program, Harvard University Interactive Multimedia Association Program on Digital Open High Resolution Systems, Massachusetts Institute of Technology This workshop will map the territory between security issues and the need for practical, user-friendly systems for marketing information resources and services. It will survey the technological landscape, evaluate the potential benefits and risks of different mechanisms, define a research agenda, and frame related implementation and policy issues. The workshop will give special attention to how and where within the overall infrastructure different technologies are best implemented. It will present and analyze models for explaining protection systems and strategies. Papers are invited on the foregoing and on the capabilities and relationship of the following technologies and strategies: -- billing servers -- type of service identifiers, header descriptors, and other forms of labeling and tagging -- fingerprinting -- digital signatures -- contracting mechanisms and EDI licensing of intellectual property -- copy protection and serial copy management -- authentication servers and site licensing -- software envelopes -- encryption -- display-only systems -- concurrent use limitations -- structured charging -- technology assessment and risk analysis The workshop will be held at MIT and Harvard on February 3-5, 1993. Participation at the two-day event would be limited to 35- 40 invitees, but the papers will be revised for publication as part of Information Infrastructure Project's publication program. Abstracts of proposed papers should be sent to: Thomas Lee DOHRS/CTPID MIT E40-218 Cambridge, MA 02139 tlee at farnsworth.mit.edu 617-253-6828 Fax: 617-253-7326 or 617-253-7140 ________________________________________________________________ The global Internet offers the beginning of a networked, multifunctional, multimedia environment for both resource-sharing and marketing information products and services. Although underlying technologies may change, the applications and practices developed now are shaping the universal broadband infrastructure of the future. However, concern for copyright protection remains a major impediment to private investment in information resources and services. Owners of information resources are fearful of releasing proprietary information to an environment which appears lacking in security and has no accepted means of accounting for use and copying. Complex library systems may be designed and developed around nonproprietary information, but until there are mechanisms to accommodate proprietary information, the utility of the systems will remain limited by the nature of the material made available. Information technology enables the vision of a distributed, interoperating multimedia environment in which information from a universe of different sources can be combined and recombined to meet specific user needs. Ironically, the vision is threatened by the absence of systematic controls. Mindful of this problem, Congress directed that the National Research and Education Network (the follow-on to the federally funded portion of the Internet) -- (1) be developed and deployed with the computer, telecommunications, and information industries.... (5) be designed and operated so as to ensure the continued application of laws that provide network and information resources security measures, including those that protect copyright and other intellectual property rights.... (6) have accounting mechanisms which allow users or groups of users to be charged for their usage of copyrighted materials available over the Network.... [15 USC 5512(c)] The Act also requires the Director of the Office of Science and Technology Policy to report to Congress by the anniversary of the Act (i.e., December 9, 1992) on "how to protect the copyrights of material distributed over the Network...." [15 USC 5512(g)(5)] Despite this statutory language, federal agencies have yet to address these issues. Many believe that the protection of intellectual property on the NREN as on any network is a private sector problem which needs to be addressed at an applications level, not within the design of the network. Indeed, these intellectual property problems are not new; to a large extent, they represent traditional copyright problems which have been exacerbated by electronic technology, digitization of information, personal computers, and less advanced forms of networking. But the prospect of pervasive, high-bandwidth, interconnected wide-area networks presents the problems in the most complete context. There is a tension between the goals of protection, on the one hand, and interoperation and usability, on the other, that has defeated technological solutions in the past. ADAPSO's proposed hardware lock failed to gain industry acceptance, and software copy protection has been abandoned except in certain high-value niche markets. The microcomputer software industry has come to rely on the threat of lawsuits in the vulnerable corporate environment as a means of copyright enforcement. Nonetheless, a hardware-secured environment incorporating serial copy management has been mandated (as an amendment to the Copyright Act) for the next generation of digital audio technology. In the emerging environment, the conventional distinction between products and services breaks down. Products are networked, and network-accessible services are linked to products. Rights must be acquired to cover all forms of delivery, because multiple delivery paths are likely and the dominant technologies and markets cannot be predicted with confidence. On the other hand, the control and security offered by different technologies may also determine the choice of distribution paths. For these reasons, the workshop will look at the networked multimedia environment as a whole, from mass-market products to specialized services. From hughes at soda.berkeley.edu Fri Oct 23 23:20:44 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Fri, 23 Oct 92 23:20:44 PDT Subject: entropy measures In-Reply-To: <9210231641.AA11868@xanadu.xanadu.com> Message-ID: <9210240620.AA08036@soda.berkeley.edu> Dean: >Where does uuencoded [compressed] binary lie? I would suspect it lies >right around where encrypted text is. Right. >Presumably straight encrypted >text is statistically random [7..8], but that when you encrypt to >just the ascii subset is when you lose the entropy. Exactly. uuencoding will have a slightly lower single-character entropy than the ASCII armor PGP uses because just about every line begins with the letter 'M'. This will skew the distribution slightly. But a better way of distinguishing uuencoding and ascii armor is to see that in falls in the same entropy class, and then just looking at the alphabetic subsets used. Eric From hughes at soda.berkeley.edu Fri Oct 23 23:27:22 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Fri, 23 Oct 92 23:27:22 PDT Subject: multiple message destinations In-Reply-To: <9210231806.AA12129@xanadu.xanadu.com> Message-ID: <9210240626.AA08212@soda.berkeley.edu> Dean: >Are there other ways to handle sending to multiple receivers? 1) You can send it to a service which copies the message and resends it as many times as you need. Or send it yourself. 2) You can have the multiple recipients each share a key and let them trust each other. (Not recommended for the paranoid). 3) You can use a secret sharing system which is tied to a private key, such that revealing the secret allows for the derivation of the private key. The secret itself is a different private key. (I'm not up on the details of these schemes.) Eric From tribble at xanadu.com Sat Oct 24 02:31:19 1992 From: tribble at xanadu.com (E. Dean Tribble) Date: Sat, 24 Oct 92 02:31:19 PDT Subject: multiple message destinations In-Reply-To: <9210240626.AA08212@soda.berkeley.edu> Message-ID: <9210240854.AA15621@xanadu.xanadu.com> Doies the scheme I suggested (and I'm sure is not original) work? Using all the various private keys to encrypt a single cypher key that the rest of the message is encrypted with? dean From 74076.1041 at CompuServe.COM Sat Oct 24 09:02:41 1992 From: 74076.1041 at CompuServe.COM (Hal) Date: Sat, 24 Oct 92 09:02:41 PDT Subject: Multiple messages + entropy Message-ID: <921024155350_74076.1041_DHJ67-1@CompuServe.COM> The Internet PEM (Privacy Enhanced Mail) standard uses the concept which Dean Tribble mentioned of multiple encryption (using each recipient's public key) of a single session key which encrypts the message. PGP's data structures do not currently provide for this but could be extended pretty easily to allow it. On the entropy measure - I thought entropy was how many bits of information you get per character. Encrypted binary text would be pretty close to 8 bits per character. The RFC1113 Ascii encoding used by PGP reduces this to 6 bits per character (e.g. a character set with 64 printable characters) neglecting line separators and message beginnings and endings. So there should be a little less than 6 bits per character for encrypted, Ascii-encoded messages. Hal 74076.1041 at compuserve.com From hughes at soda.berkeley.edu Sat Oct 24 09:24:30 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Sat, 24 Oct 92 09:24:30 PDT Subject: multiple message destinations In-Reply-To: <9210240854.AA15621@xanadu.xanadu.com> Message-ID: <9210241624.AA12449@soda.berkeley.edu> Re: multiple encryptions of a message key. Yes, it works. Sorry. Eric From jjaloszyns at bluejay.mich.fred.org Sat Oct 24 10:01:06 1992 From: jjaloszyns at bluejay.mich.fred.org (jjaloszyns at bluejay.mich.fred.org) Date: Sat, 24 Oct 92 10:01:06 PDT Subject: Keystone Message-ID: <9210241700.AA13531@home.merit.edu> Speaking of that stupid FBI phone legislation, do you know where I can obtain an exact copy of the bill? If you have it, please mail it to me. thanks... jon ------------- 43.31.28N, 84.41.41W Jon Jaloszynski Student 9-12 at Shepherd HS, Shepherd Shepherd, MI From fen at netcom.com Sat Oct 24 13:09:09 1992 From: fen at netcom.com (Fen Labalme) Date: Sat, 24 Oct 92 13:09:09 PDT Subject: ftp.eff.org:/pub/EFF/legislation/new-fbi-wiretap-bill Message-ID: <9210242007.AA14367@netcom.netcom.com> The following is the latest version of the FBI Digital Telephony Proposal, introduced in May 1992. This version removes the previous language that authorized the FCC to set standards and now places it solely in the hands of the Attorney General. Fines are $10,000/day for non compliance with services within the public switched network having 18 months to comply and services outisde having three years. The proposal now manadates that the capability for remote government wiretapping must be included into the system. This proposal clearly enhances the ability of the FBI to monitor communications. It takes the unprecendented step of placing control over certification of telecommunications equipment in the hands of the Attorney General and requires that the equipment be constucted to allow government have the ability to monitor communications from a "government monitoring facility remote from the target facility." All telecommunications users should be concerned by the privacy and security implications of creating systems that have holes for the government or any other knowledgable user to plug into. 102nd Congress 2nd Session S. _____ [H.R. _____] IN THE SENATE [IN THE HOUSE OF REPRESENTATIVES] M. ________________ introduced the following bill; which was referred to the Committee on__________________ A BILL To ensure the continuing access of law enforcement to the content of wire and electronic communications when authorized by law and for other purposes. Be it enacted by the Senate and the House of Representatives of the United States of America in Congress assembled, SEC. 1. FINDINGS AND PURPOSES. (a) The Congress finds: (1) that telecommunications systems and networks are often used in the furtherance of criminal activities including organized crime, racketeering, extortion, kidnapping, espionage, terrorism, and trafficking in illegal drugs; (2) that recent and continuing advances in telecommunications technology, and the introduction of new technologies and transmission modes by the telecommunications industry, have made it increasingly difficult for government agencies to implement lawful orders or authorizations to intercept wire and electronic communications and thus threaten the ability of such agencies effectively to enforce the laws and protect the national security; and (3) that without the assistance and cooperation of providers of electronic communication services and private branch exchange operators, the introduction of new technologies and transmission modes into telecommunications systems without consideration and accommodation of the need of government agencies lawfully to intercept wire and electronic communications would impede the ability of such agencies effectively to carry out their responsibilities. (b) The purposes of this Act are to clarify the responsibilities of providers of electronic communication services and private branch exchange operators to provide such assistance as necessary to ensure the ability of government agencies to implement lawful court orders or authorizations to intercept wire and electronic communications. SEC. 2. (a) Providers of electronic communication services and private branch exchange operators shall provide within the United States capability and capacity for the government to intercept wire and electronic communications when authorized by law: (1) concurrent with the transmission of the communication to the recipient of the communication; (2) in the signal form representing the content of the communication between the subject of the intercept and any individual with whom the subject is communicating, exclusive of any other signal representing the content of the communication between any other subscribers or users of the electronic communication services provider or private branch exchange operator, and including information on the individual calls (including origin, destination and other call set-up information), and services, systems, and features used by the subject of the interception; (3) notwithstanding the mobility of the subject of the intercept or the use by the subject of the intercept of any features of the telecommunication system, including, but not limited to, speed- dialing or call forwarding features; (4) at a government monitoring facility remote from the target facility and remote from the system of the electronic communication services provider or private branch exchange operator; (5) without detection by the subject of the intercept or any subscriber; and (6) without degradation of any subscriber's telecommunications service. (b) Providers of electronic communication services within the public switched network, including local exchange carriers, cellular service providers, and interexchange carriers, shall comply with subsection (a) of this section within eighteen months from the date of enactment of this subsection. (c) Providers of electronic communication services outside of the public switched network, including private branch exchange operators, shall comply with subsection (a) of this section within three years >from the date of enactment of the subsection. (d) The Attorney General, after consultation with the Department of Commerce, the Small Business Administration and Federal Communications Commission, as appropriate, may except from the application of subsections (a), (b) and (c) of this section classes and types of providers of electronic communication services and private branch exchange operators. The Attorney General may waive the application of subsections (a), (b) and (c) of this section at the request of any provider of electronic communication services or private branch exchange operator. (e) The Attorney General shall have exclusive authority to enforce the provisions of subsections (a), (b) and (c) of this section. The Attorney General may apply to the appropriate United States District Court for an order restraining or enjoining any violation of subsection (a), (b) or (c) of this section. The District Court shall have jurisdiction to restrain and enjoin violations of subsections (a) of this section. (f) Any person who willfully violates any provision of subsection (a) of this section shall be subject to a civil penalty of $10,000 per day for each day in violation. The Attorney General may file a civil action in the appropriate United States District Court to collect, and the United States District Courts shall have jurisdiction to impose, such fines. (g) Definitions--As used in subsections (a) through (f) of this section-- (1) 'provider of electronic communication service' or 'private branch exchange operator' means any service or operator which provides to users thereof the ability to send or receive wire or electronic communication, as those terms are defined in subsections 2510(1) and 2510(12) of Title 18, United States code, respectively, but does not include the government of the United States or any agency thereof; (2) 'communication' means any wire or electronic communication, as defined in subsections 2510(1) and 2510(12), of Title 18, United States Code; (3) 'intercept' shall have the same meaning as set forth in section 2510(4) of Title 18, United States Code; and (4) 'government' means the Government of the United States and any agency or instrumentality thereof, any state or political subdivision thereof, the District of Columbia, and any commonwealth, territory or possession of the United States. DIGITAL TELEPHONY AND INTERCEPTION BY CRIMINAL LAW ENFORCEMENT AGENCIES The telecommunications systems and networks are often used to further criminal activities including white collar and organized crime, racketeering, extortion, kidnapping, espionage, terrorism, and trafficking in illegal drugs. Accordingly, for many years, one of the most important tools in the investigation of crime for Federal and State criminal law enforcement agencies has been the court authorized interception of communications. As illustrated below, the majority of original authorizations to intercept wire or electronic communications are conducted by State criminal law enforcement agencies. Interception Applications Authorized State Federal Total 1984 512 289 801 1985 541 243 784 1986 504 250 754 1987 437 236 673 1988 445 293 738 1989 453 310 763 1990 548 324 872 Total 3440 1945 5385 Approximately, 3/8 of authorized interceptions were conducted by Federal agencies, while 5/8 of the authorized interceptions were conducted by State criminal law enforcement agencies.1 The recent and continuing advances in telecommunications technology, and the introduction of new technologies by the telecommunications industry, have made it increasingly difficult for government agencies to implement lawful orders or authorizations to intercept wire and electronic communications, as well as to implement pen register and trap-and-trace court orders or authorizations. These new technologies inadvertently undermine the ability of criminal law enforcement agencies to enforce effectively the criminal laws and protect the national security. Without the assistance and cooperation of the telecommunications industry, these new technologies will impede the ability of the telecommunications industry, these new technologies will impede the ability of the government to enforce the criminal law. Accordingly, the purpose of this bill is to clarify the existing responsibilities of electronic communication services providers and private branch exchange operators, as established, for example, in 18 U.S.C. ____ 2518(4), 3124(A), (B), to provide such assistance as necessary to ensure the ability of government agencies to implement lawful orders or authorizations to intercept communications. Over the past twenty-five years, the working relationship between the criminal law enforcement community, particularly the Federal Bureau of Investigation as the federal government's primary criminal law enforcement agency, and the telecommunications industry, in response to the appropriate court orders or authorizations, has provided government agencies with timely access to the signals containing the content of communications covered by the court orders or authorizations. As a general proposition, this has involved providing the means to acquire the communication as it occurs between two individual telephone users at a remote location, not dissimilar to a call in which the two originating parties do not know that a third party is listening, and in which the third party (the criminal law enforcement agency) records the authorized and relevant calls. Historically, and with relatively few exceptions, the telecommunications industry has provided the criminal law enforcement community with the ability to monitor and record calls: 1. at the same time asthe call is transmitted to the recipient; 2. in the same form as the content of the call was transmitted through the network, notwithstanding the use by the target of custom features of the network; 3. whether stationary or mobile; 4. at the government monitoring facility; 5. without detection by the target or other subscribers; and without degrading any subscriber's service. However, the introduction of new technology has begun to erode the ability of the government to fully effectuate interceptions, pen registers and trap-and-race court orders or authorizations that are critical to detecting and prosecuting criminals. As technology has developed, the telecommunications industry has not always ensured the continued ability to provide the same services to the criminal law enforcement community. The telecommunications industry's introduction of certain types of new technology poses real problems for effective criminal law enforcement. Legislation is necessary to ensure that the government will be provided with this capability and capacity in the future by all providers and operators and to maintain a level playing field among competitive providers and operators in the telecommunications industry. There have been instances in which court orders authorizing the interception of communications have not been fulfilled because of technical limitations within particular telecommunications networks. For example, as early as 1986, limited capabilities became apparent in at least one network which will only be corrected later in 1992. This technical deficiency in a new technology forced criminal law enforcement agencies to prioritize certain interceptions to the exclusion of other court orders. Accordingly, for approximately six years, there have been court orders that have not been sought by the criminal law enforcement community or executed by the telecommunications industry and, as a consequence, important criminal investigations have not been brought to fruition or have been less than efficiently concluded. This is one classic example of new technology affecting adversely the criminal law enforcement community: a microcosm of what may be expected on a nationwide basis without enactment of this legislation. Section 1 of the bill states Congressional findings and purpose. Section 2 is divided into seven subsections.. Subsection (a) establishes as a matter of law the responsibility of electronic communication services providers and private branch exchange operators to continue to provide, within the United States, the capability and capacity for criminal law enforcement agencies to intercept wire and electronic communications when authorized by law. These subsections delineate the existing attributes of wire or electronic communication interception. 1. Concurrent with Transmission. The application for a court order to intercept telecommunications conversations or data transmissions is rarely a leisurely process. For example, on the Federal side, the development of the required affidavits, submission to the Criminal Division of the Department of Justice for approval, transmission of approval to the Assistant United States Attorney, the appearance of the Assistant before a judge to request the order and the delivery of the judge's order to the appropriate telecommunications company is frequently completed in a very short time. However, crime waits for no one and the system for approval of interceptions must and does conform with the realities of the activity that is sought to be investigated and, if appropriate, prosecuted as criminal offenses. Since time is of the essence, current law requires that service providers and operators provide the government forthwith all information, facilities and technical assistance necessary to accomplish its mission. It is critical that the telecommunications industry respond quickly to execute the court order or authorization. The ultimate problem of timeliness, however, is the real-time monitoring of the intercepted communications. As serious and potentially life- threatening criminal conduct is detected, it may be necessary to move quickly to protect innocent victims from that conduct. Accordingly, "real-time" monitoring is critical. 2. Isolated Signal and Services Used. Nearly all of the communications network is partially "analog" at this time. In conducting an interception, for example, of a telephone conversation, the government is allowed to monitor and record criminal conversation such as a conspiracy, minimizing the acquisition of non-criminal or innocent conversation. When an electronic communication services provider or private branch exchange operator introduces a new technology--such as a digital signal--the communications are converted into a different and more efficient form for transmission, but a more difficult form to monitor during interception. The bill requires only that the provider or operator isolate and provide access to the electronic signal that represents the content of the communications of the target of the intercept2 from the stream of electronic signals representing other communications. This provision seeks to ensure that, in the new electronic environment in which signals are mixed for transmission and separated at another switch for distribution, the government does not receive the communications of any individual other than the individuals using the target's communications point of origin and receipt; the government must remain subject to the minimization standards of 18 U.S.C. __ 2518(5). This provision also makes it clear that an electronic communication services provider or private branch exchange operator is not required to provide for reconversion of the isolated communication to analog or other form. The government expects that this process will be accomplished by the government. 3. Mobility and Features. Increasingly, criminal acts are being conducted or discussed over cellular telephones or by using special telecommunications features. As this mobility is introduced, the electronic communication services providers and private branch exchange operators would be required to assure the capability and capacity for criminal law enforcement agencies to continue lawful interception. Further, this subsection makes it clear that features used by the target do not defeat the court order or authorization. For example, communications which have been addressed to the telephone number of the target, but which may have been programmed through a call-forwarding feature to another, otherwise innocent, telephone number, must be captured and made available to criminal law enforcement authorities pursuant to court order or authorization. This requirement will obviate the need for applications for authority to monitor otherwise innocent telephone numbers that receive, only intermittently, calls forwarded by the target. The effect of this provision is to further minimize monitoring of calls of innocent parties. Similarly, certain speed dialing features that mask the telephone number called by the target must be identified for criminal law enforcement investigation. The ability to consistently determine the destination of calls is critical to minimizing the monitoring of innocent calls. 4. Government Monitoring Facility. Government agencies do not normally request the use of telecommunications industry physical facilities to conduct authorized interceptions nor is it encourage by the industry. Normally, the government leases a line from the electronic communication services provider's or private branch exchange operator's switch to another location owned or operated by the government. This minimizes the cost and intrusiveness of interceptions, which benefits the service provider or operator, as well as the government. Accordingly, the ability to monitor intercepted communications remotely is critical. 5. Without Detection. One of the reasons that governments operate their own facilities is to reduce the risk of detection of the interception, which would render the interception worthless. At the present time, the existence of an interception is unknown to any subscriber and is not detectable by the target, notwithstanding folklore and spy novels. This provision merely ensures that the secrecy of effective interceptions will be maintained. 6. Without Degradation. Maintaining the quality of the telephone network is in the interest of the government, the industry and the public. Presently, the existence of an interception has no effect on the quality of the service provided by any network to the target or any subscriber. This provision ensures that the quality of the network will continue to be uncompromised. Absent the assistance delineated by this legislation, the execution of court orders and authorizations by the government could well disrupt service of the newer technological systems, a result that this legislation seeks to avoid. Subsection (b) provides that electronic communication services providers and private branch exchange operators with the "public switched network" must be in compliance with the minimum intercept attributes within eighteen months after enactment. Thereafter, new technologies must continue to meet these minimum attributes. Subsection (c) provides that electronic communication service providers and private branch exchange operators that are not within the "public switched network" must be in compliance with the minimum intercept attributes within eighteen months after enactment. Thereafter, new technologies must continue to meet these minimum attributes. Subsection (d) provides that the Attorney General may grant exceptions to the affirmative requirements of subsection (a), as well as the implementation deadlines of subsections (b) and (c). In considering any request for exception, the Attorney General will consult with Federal Communications Commission, the Small Business Administration and the Department of Commerce, as appropriate. Accordingly, the Attorney General has the authority to except, for example, whole classes, categories or types of private branch exchange operators where no serious criminal law enforcement problems are likely to arise, such as hospital telephone systems. This subsection also permits the Attorney General to waive the requirements of subsections (a), (b) and (c) on application by an electronic communication services provider or private branch exchange operator. Accordingly, if a particular company can not comply with one or more of the requirements of subsection (a), or needs time additional to that permitted under subsections (b) or (c), the Attorney General may grant an appropriate waiver. Subsection (e) provides that the Attorney General has exclusive authority to enforce the provisions of the bill. While a number of States have authority to seek and execute interception orders, they will be required to seek the assistance of the Attorney General if enforcement of this legislation is required. This section also provides for injunctive relief from violations of the provisions of the bill. Subsection (f) provides for enforcement of the provisions of the bill through imposition of civil fines against any company that is not excepted from the provisions of the bill, does not acquire a waiver of the provisions of the bill, and fails to meet the requirements of subsection (a) after the effective dates set out in subsection (b) or (c), as appropriate. A fine of up to $10,000 per day for each day in violation may be levied; for most companies in the telecommunications industry this amount is sufficient to ensure that compliance will be forthcoming. Although this provision is not expected to be used, it is critical to ensure that compliance with the provisions of the bill will occur after the effective dates of the requirements of subsection (a). Subsection (g) carries forward a number of definitions from the current provisions for the interception of wire or electronic communications under "Title III." The definition of "government" that is currently in use includes all States, territories and possessions of the United States, as well as the United States, is made applicable to the bill. [Footnotes] 1Interceptions for foreign intelligence and counterintelligence purposes are not counted within the figures used here, but would likewise benefit from enactment of the legislation. 2 Whether the content is voice, facsimile, imagery (e.g. video), computer data, signalling information, or other forms of communication, does not matter; all forms of communication are intercepted. From fen at netcom.com Sat Oct 24 13:24:14 1992 From: fen at netcom.com (Fen Labalme) Date: Sat, 24 Oct 92 13:24:14 PDT Subject: fbi-wiretap-bill (& ftp.eff.org) Message-ID: <9210242023.AA15395@netcom.netcom.com> >> Speaking of that stupid FBI phone legislation, do you know where I can >> obtain an exact copy of the bill? If you have it, please mail it to me. Mail sent. Also, a pointer to ftp.eff.org is worthwhile to note. I just grabbed a new copy of the bill from there, under /pub/EFF/. Below are some file listings from their archives. Enjoy! Yours in networking, Fen Labalme fen at genmagic.com fen at netcom.com Just say "Know!" General Magic Broadcatch Technologies We Are Everywhere Member of the League for Programming Freedom , the Electronic Frontier Foundation , and the Computer Professionals for Social Responsibility ftp> cd pub/EFF 250 CWD command successful. ftp> ls 200 PORT command successful. 150 Opening ASCII mode data connection for file list. eff-issues legislation about-eff Index mission-statement legal-issues .message about-eff.ps papers local-chapters historical newsletters newsnotes 226 Transfer complete. 160 bytes received in 0.012 seconds (13 Kbytes/s) ftp> cd legal-issues 250 CWD command successful. ftp> ls 200 PORT command successful. 150 Opening ASCII mode data connection for file list. bbs-defamation privacy-vs-amendments Index copyright-law-software copyright-libraries bill-of-rights-overview ecpa-laymans-view email-privacy-biblio-2 media-and-law email-privacy-research search-seizure-files review-liability tempest-legal-issues bbs-and-the-law against-look-and-feel computer-security-intro cyberspace-legal-matrix electrifying-speech eff-fbi-analysis private-open-society 226 Transfer complete. 411 bytes received in 0.038 seconds (11 Kbytes/s) ftp> cd ../legislation 250 CWD command successful. ftp> ls 200 PORT command successful. 150 Opening ASCII mode data connection for file list. ecpa-1986 Index computer-crime-laws fbi-wiretap-bill telecom-act-hr3515 ecpa-1986-senate-bill tribe-proposed-amendment nren-bill-text gpo-windo-info privacy-act-1992-calif gore-infrastructure-bill new-fbi-wiretap-bill 226 Transfer complete. 230 bytes received in 0.024 seconds (9.3 Kbytes/s) ftp> From deckard at chezrob.pinetree.org Sat Oct 24 14:49:54 1992 From: deckard at chezrob.pinetree.org (Stephen Pandke) Date: Sat, 24 Oct 92 14:49:54 PDT Subject: Removal From Mailing list Message-ID: Unfortunately, I must request that I be removed from your mailing list. ] Stephen Pandke --- Stephen Pandke - deckard at chezrob.pinetree.org C.R.I.M.E. BBS - (Chez Rob's Int'l Mail Exchange) 613/230-5307 (data) From drcc at ultrix.csc.usf.edu. Sat Oct 24 17:43:41 1992 From: drcc at ultrix.csc.usf.edu. (David Cabana (MTH)) Date: Sat, 24 Oct 92 17:43:41 PDT Subject: pgp Message-ID: <9210250037.AA19290@ultrix.csc.usf.edu.> Where in the U.S. can I ftp a copy of PGP? I tried Kauri.vuw.ac.nz, but their README asked that I not transfer files. I would like to respect their wishes... Thanks, drc From pmetzger at shearson.com Sat Oct 24 19:34:56 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Sat, 24 Oct 92 19:34:56 PDT Subject: multiple message destinations In-Reply-To: <9210231806.AA12129@xanadu.xanadu.com> Message-ID: <9210250201.AA07719@newsu.shearson.com> >From: tribble at xanadu.com (E. Dean Tribble) >Mail typically wants to get sent to multiple receivers, all with >different private keys. I vaguely recall that the way PGP works is it >generates a symetric cypher key and encrypts the message with that, >then encrypts the generated key with the public key of the intended >receiver. Is that how it works? >Given that, it should be straightforward (and maybe it already does) >encrypt the generated key with several public keys so you get one >package that can be unsealed by any of several different receivers. Yes, that should work. PGP doesn't do it, but it would be straightforward to change it so it could. Perry From shawnb at ecst.csuchico.edu Sat Oct 24 20:33:12 1992 From: shawnb at ecst.csuchico.edu (shawnb) Date: Sat, 24 Oct 92 20:33:12 PDT Subject: pgp key distribution Message-ID: <9210250333.AA11925@toad.com> I'm pretty new to this mailing list, so something along these lines may have already been proposed, but I was considering the possibility of putting together a list of pgp public keys for distribution through this list. My own collection of keys is pretty small, and I would pernally like to expand this, but I think this would provide a great service to the group as well. Let me know what you all think. Shawn From shipley at tfs.COM Sat Oct 24 20:54:34 1992 From: shipley at tfs.COM (Peter Shipley) Date: Sat, 24 Oct 92 20:54:34 PDT Subject: pgp key distribution In-Reply-To: <9210250333.AA11925@toad.com> Message-ID: <9210250354.AA00857@edev0.TFS> jyanowitz at hamp.hampshire.edu is already creating a list (you can find it posted to alt.security.pgp). As for me I maintain two public rings one is a collection I have collected via direct contact (friends mostly) the other is jyanowitz's list plus random other rings). -Pete Ps: I do not know jyanowitz (etc etc, but while we are on the subject) but I guess I should relay his request for people to email him your keys and public rings my casual key: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQA9AirUzbUAAAEBfjC3p5COEUMJ3xzrq4sJCTaU5MgvzC94tp8yxxBJeKUGo7xx gMShBCnIZp+xlFiyxQAFE7QYUGV0ZXIgTSBTaGlwbGV5IChjYXN1YWwptAZjYXN1 YWy0JlBldGVyIE0gU2hpcGxleSA8c2hpcGxleUBiZXJrZWxleS5lZHU+ =OR9u -----END PGP PUBLIC KEY BLOCK----- From joeb at arden.linet.org Sat Oct 24 21:11:19 1992 From: joeb at arden.linet.org (joeb at arden.linet.org) Date: Sat, 24 Oct 92 21:11:19 PDT Subject: remove from mailing list Message-ID: <9210242237.aa22143@src4src.linet.org> Please unsubscribe me from your list. The mail load is just too much. I noticed that there are alot of people that subscribe then unsubscribe. You may want to consider mentioning in your ads the nature of this forum. I assumed it was a periodical newsletter of some kind. I would speculate from the frequency of subscribers that quickly un-subscribe that many are under the same assumption. This topic is very interesting but the mail is just too much. If you guys come out with a newsletter of some kind I'd be very interested. Thanks and sorry for the extra work. - JoeB From 74076.1041 at CompuServe.COM Sat Oct 24 21:47:19 1992 From: 74076.1041 at CompuServe.COM (Hal) Date: Sat, 24 Oct 92 21:47:19 PDT Subject: remove from mailing list Message-ID: <921025044014_74076.1041_DHJ64-1@CompuServe.COM> What we _ought_ to do is to remind people that they should send their unsubscribe notices to cyherpunks-request at toad.com, _not_ to the list address. That way we wouldn't all have to be bothered by reading these messages, and the list volume would be that much lower! From pmetzger at shearson.com Sat Oct 24 22:03:00 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Sat, 24 Oct 92 22:03:00 PDT Subject: pgp key distribution In-Reply-To: <9210250333.AA11925@toad.com> Message-ID: <9210250427.AA08570@newsu.shearson.com> >From: shawnb >I'm pretty new to this mailing list, so something along these lines may >have already been proposed, but I was considering the possibility of >putting together a list of pgp public keys for distribution through this >list. My own collection of keys is pretty small, and I would pernally >like to expand this, but I think this would provide a great service to the >group as well. Let me know what you all think. I keep seeing people propose things like this, and I can't for the life of me understand why. The only way to know for sure that someone's key is theirs is a signature from a trusted introducer anyway, so people can just ask each other in clear for public keys and it doesn't do a lick of harm -- if they have a trusted signature, you can use their key for communication and if they don't, you have to find another way to verify the key. People making lists of keys and distributing them seems fairly useless to me. Can anyone tell me if I am being really really thick here? Perry From Tom.Jennings at f111.n125.z1.FIDONET.ORG Sun Oct 25 12:08:31 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Sun, 25 Oct 92 12:08:31 PPE Subject: multiple message destinations Message-ID: <3266.2AEAF026@fidogate.FIDONET.ORG> U> 1) [...] Or send it yourself. As a paranoid person myself (I use the two phrases "sufficiently paranoid" (me, and most of us in here are sufficiently paranoid -- to at least consider the issues) and "insufficiently paranoid" -- people who conduct business over cordless or cellular voice, etc -- these paren'd subtexts are getting out of hand -- as a paranoid person myself I would only trust sending them myself. It's really a "code" issue -- given a list of addressees, will the miserable program you're using do the work for you. --- ReadMail * Origin: World Power Systems / FidoNews / San Francisco CA (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 Oct 25 13:08:17 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Sun, 25 Oct 92 13:08:17 PPE Subject: pgp key distribution Message-ID: <3269.2AEAFD72@fidogate.FIDONET.ORG> U> From: shawnb at ecst.csuchico.edu (shawnb) U> I'm pretty new to this mailing list, so something along U> these lines may have already been proposed, but I was U> considering the possibility of putting together a list of U> pgp public keys for distribution through this list. My The FidoNet has an echo ("newsgroup") where each message ("article") is someones public key. Here's my keyring, for what it's worth: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAirSicsAAAEEALQ8l1jjbcASxKkdlHACfaE+em9i996Sos8ox50JjhZNu9N6 mft8V0App0eXTYAEumnz+CVVJXjzMUgloGs1ZnyvqkT3VhaF6CyUSUFwXIym/IUk buvs3qqEU55yGTl1s2gcjgiqyL/1jmOIdaaMQNrQ4/4x28gaOFQYMJXaJ+w1AAUR tC5XZXMgUGVya2hpc2VyIDx3ZXMucGVya2hpc2VyQHdlaXNlLm9tYWh1Zy5vcmc+ iQCVAgUQKtRrakq2SryVeKUXAQGF4AP+JDQawppDmAteShKF6Be24MGpByxYnIYR XyHpKOIcGx45S7FZOoS+mGzU4VXRYF9reHvfYGnz0GGjZ962K5tFJSSupF7ccxBi nLA3EYltX8iIufbyLwoS6Bb2gmX6Z5kfDVcffvlw8RqWFAwxows6QU8VvadLa40B mEjvVqzAIgiZAI0CKuQvgAAAAQQA0CiZieU9eimeaz1G1TSWf0KIsmWOyw55+UL0 D5AgO6NeE9PIClsvpU+pJRKgUX97vbFMmLHKvAFCHDmUC9+9A8SIYgVBBjG+IX5C D/7r8lW8sKO+cZUWX2QpMRhV443EE0aJpe5ITRUxAvHjuI/0BT7BjDrZpeZM21bU FS1fkEcABRG0MEphbWVzIEEuIENhbXBiZWxsIDx1amFjYW1wYmVAbWVtc3R2eDEu bWVtc3QuZWR1PpkAjQIq43aAAAABBACqyZ7OXOK217FIvtParcy1nOgZUcLqrapK Fq0nefdbEHLiaB+i1jeTdSoUqehMi3+ZiDICDxuVF6yBqCDsrl3tOd8mLC3Pe6Bk W4gCi6KI2XrIpb1DCKc4EscjzWSku2E0lYiLAfkh4BTwzxcbTr6Yj9CJjVb1JJ46 YDMOhX+YvQAFE7QrRGFyaW4gQ293YW4gPGNvd2FuQGNlcmlhbnRodXMucGluZXRy ZWUub3JnPpkAjQIq4AX1AAABBADPMVf0NZ/LoWxUJXf+a3dTG0xIHW+FCfKbn5os 9ZLwQTV/tloYGolyVSEqIjS7EgxtoFfiqzJyMkN5o4ctxCXs/xcBKfwiib6ffLPn cz5hNInkylhUu6b9K0ZDV5kfzdoeTR2H8SDT2e3vn/GOlCGosOzJS2crKfwnisK+ iFySIQAFEbQJVGVkIFJvbGxltBMyMDEwOjEwMC8xLjBAU0RBbmV0tBIxOjEwNS8z Ni4wQGZpZG9uZXSZAI0CKtfw+gAAAQQAxHc5YohUHjHM3UGj91c39vsntGzR/8cH +m0RokT7/F/F3zXNdLTumHlD92OK4hdAPWEp+xVAygyKKDp+LBFI4JTPhx2iNELm yum5SusJMf1FW+2m6zIK/0gzMqgd2QDb6GsMsFqxlDctnIrz9uqZCJuD3LfHjucw 9RbQfSEuxUsABRe0Okd1eSBNYXJ0aW4gMToxNDMvMjY5IChndXkubWFydGluQGYy NjkubjE0My56MS5maWRvbmV0Lm9yZymZAI0CKtXkPgAAAQQA2srhlr3MEdQ+rcQv atnLX5mhZavCVuyc44Ezhn1EG/kd0vafg93Y5EJTplPryrPeABmuC72RhJ2kdEnZ nsAxO+SkJzX3/FlnVyatu7VVosR2Wcl5pLQMhaYz0ZhRRoIv1GIqAnMmcD/SbBFD puSkzTD4Mjn7TPHJo6l60efyPZUABRG0J01pa2UgTGFzdGVyIDxsYXN0ZXJtQG9o bS5lZS51dHVsc2EuZWR1PrQfTWlrZSBMYXN0ZXIgPDE6MTcwLzEwOUBmaWRvbmV0 PpkAjQIq3Pf5AAABBADTqwU2BaFR8+VElyuQ7VXkGn2IcVPZYxH1pqTRI7G+HTnB iaZl2dT24CkSD5uO7TPAPxFl0A1hDzt03cv3SMdIkfbAxWzI1dwno0+Wy5z84puf tYPjaXA08Dc1L8pAiZzDYtx95NBCKqirjbTFuOl7BUB2HYpjv+K+Xqpu25EANwAF EbQxQmFycnkgS2Fwa2UgPEJhcnJ5LkthcGtlQGYzMy5uMTI1LnoxLmZpZG9uZXQu b3JnPpkAjQIqwncSAAABBACvXC8GUY83UrGJPzD2CG098ZiWfu9yMTPKz2ji+TK4 e0KI5M13DWa+1bWPm+WWv0dYnJrKSmQ7sYbKK3owd/byvNIYC6QfN2Nl0C8RcNk4 lduLlOlEWXzQuLKPaZhqx9uahtibSnHmf705lDnXN4ijPAd5ooc30tf/+yHKJrNc 0wAFE7QtSmFzb24gWWFub3dpdHogPGp5YW5vd2l0ekBoYW1wLmhhbXBzaGlyZS5l ZHU+iQCVAgUQKtBLM//7Icoms1zTAQFkqQQAndM0KgNy0hBQEI7QUrxMBE1nNzvg 5hpoqBO0nCmlckhzB1JZfUATCU9zkNyZ9VifFuGSnoj1HgPYl4lEDOtASZm8MUup bSb1T1JMdkM6C50t9WjPl6LIj0tldHLGefDqpOTantqCdyz8WuRqUJ7S/JKPTNQ0 t5LidT1o4s3/M42ZAE0CKtrZngAAAQIA9UJPv2NsjfiajySZ3ihHPNNUA3J+pBke dcQ6JVpsB1/BS1NVx8KGKivpPXgFtYvtR4oBEZEVlLCZWKoJnH6ZvQAFEbQiUmlj aCBWZXJhYSA8MToxMzUvOTA3QGZpZG9uZXQub3JnPokAlQIFECrchQltbThSc0ua WQEB4uIEAKN+Cl7wUI/1tFckEfZc7WDbsN8F3wP+mZVanZOeQi8KlViSsatQ7D9E 1LfjNo/03BE7vDODpm3l/RHhQLwfDkMuS49EBDF0qhIn45X4v6ImUrF4Fs1MRPQE 10lnoWQs2CjStPmSWhG2jvL7xMPSy1r8m4n6dxGcyxCFML8ckyU8mQCNAiraG3wA AAEEAJuaF6NRnKvVEU3edX8OUxMdb+k3ZRfd2KM3b7+7mahkMqTfKj/wiNpqbnnV /pKoD3jf35KjO0i+Oa5spGCc3I7VCDDcKhHV6iZcYD0lpF2ySh5sUFsRGqWO4oo/ jyzrNgzV0awrg2IYT5u7ClLXbpuZGcdIKbTNdZuaN9X1csanAAUTtDFKaW0gQ2Fu bmVsbCA8SmltLkNhbm5lbGxAZjIxLm4yMTYuejEuZmlkb25ldC5vcmc+iQCVAgUQ KtpDRG1tOFJzS5pZAQHn0wP+LkupLVZYBbGPfXdkHaCxwRWEc5xBfIRO2SwpJZBB HclFuu0OxxOuilc6bAiswbPHoMSP0MnOChOa+g0BFxhRjfKVXiXhP2Oo1lqAZ41r 7E9h4oYs4YYo7fjM1lZZtezWNKIibuW57lhdyvLMbDx6oxCP55AG7zTWRzL0DQnY sjOZAI0CKtHW8wAAAQQApMSslBzYEUQzIER/SRu3xXTdruTE0EQ4CZfa9ZNhVbTx e6joVfUzLTSno6iwzjEJgSeL/yPIukK3hH2whUXLD87dcR+dhSuuK7ans2owRo+c CfH3zKTyMleHZEAVoTSOaDPVVUfUaDpukr0ujXMBa8DAIuoJrsKPiJ6a6GXD6cEA BRe0JkppbSBHcnVicywgVzhHUlQgPDE6MjM0LzFARklET05FVC5PUkc+tB9KaW0g R3J1YnMgPDE6MjM0LzFAZmlkb25ldC5vcmc+tBNKaW0gR3J1YnMgPDE6MjM0LzE+ iQCVAgUQKtT1Lm1tOFJzS5pZAQEfUAQAjYXS5sbp/8ewlqx/TAa/S7n9DSgppoBE Qrqp4uFDInSWvyVz5VsGgbV7tP1Sxntvt9++xwfn2LdSPPDfBLElAiZ+Fd6yRwVd 7wWVbmFml0xFxHwhR6sfovEZ9Mr0RjdeefZhTuN3jWV7EQBHxyFlUQehf7jG104T n45Sv0x7CIu0FkphbWVzIEMuIEdydWJzIDxXOEdSVD6ZAI0CKtW12AAAAQQArC5O dv3qYspAvcmybjWopLbXQJ2EINYd3xiTEnKqKkdyytTIDVIFdmd7sbaaAz9fuGZ4 Gg66Fp+Y3PeVYizkiGIMqpxqcXaLbAaO2A+ZCpmYjbB6s9ZzqcjHUsPF1gg7v1Ll DPDGVA1eNxNqcjpAW1PAfN+mL1UhH8u5b+eWBQEABRG0JVBhdWwgU2NoZW5ja2Ug PDE6MTM1LzM0MEBmaWRvbmV0Lm9yZz6JAJUCBRAq1k5AbW04UnNLmlkBAS6nA/9B MkQ9xoehzuOVyvBRqU7dIDiGR2TKp9q+XTe5tflTqfAhGDJeiUrxVt+FsflXJTQg Hmu6RLXNLyVdZv7N5EyfrQ+SRyxpmPLjsWWCk9CBQ9N0yvGOOgXJHJ/fNDRlW6Ce 67qS0czMyhVe5clvBnGg0dOWddUWOvNYN/u+9G3wxJkAjQIq0f0bAAABBADgjzog l/b8dE3nct9bIGDrHyLFXMVvcVfK5DUsKvNrah9aGjMF2fPxu5Lujk6btTynY0If AHuzz/7i7UMfDhLD8YBHBJJNJ28C2TogiIS9jZg+AOWtUvUA+yJ3s1r9CAWgXWFi hTYWmu6f9FWBq3WnSKYqre6djqPZrd7oItiG4QAFEbQhVG9tIEFsbXkgPHRvbWFA c2FpbC5sYWJzLnRlay5jb20+mQCNAirQwOsAAAEEAPELC7P7vLHK5hz9urWhk9BJ +2i9U1Yzzm6MKM/SI+UAVcXsYTP5g9kGJLUpLVq7KxalB1Rqbvg9FjjIaoiQ+ze7 JIPC5X+e0uU43iLMHkgz2mCg56p9hpgkDxwM3R+cHQ1cr2qrSJb8sClbYtknbgec NM0JMusvUNwtSKqN9fslAAURtExNYXJpYW5uZSBDb3dsZXkgPDE6Mzc3LzNAZmlk b25ldC5vcmcsIG0ubG92ZUBiaXgsIDcxMzMwLjI3MjFAY29tcHVzZXJ2ZS5jb20+ iQCVAgUQKtEZf21tOFJzS5pZAQHMqAP9EKg/17mW/gi0eWiUT/PpY+R+jBi0VtXA dq3HZo+VAFEyARt/fqiOuotiC7OFtnsuTPVtarOSxRpz/5bWdIr7AGIdbnwD2dmZ wvqWDBjvPDzQK1MwPPDpyqRtlEdU9LpwFkn9rVy77KShivrp4xHTVu4RjQUZ8EE5 8ilDyhDolZSJAJUCBRAq0MaYednIlhgdxdUBAaqkA/4gm475FKoXXM9X0/1KH7HR qAiu+VnrfvljT6GJt8c0BGtVsELLAGODAWCuzmP21IWlRznGvipnFXPoTrfi9bkj BijCKmdhB/atLi9FB+YO2B3PWtwmUnWbIa7CQO9vxe4t8jYbyDiICAv72dLJXTHg MxPJAuFIO0ECqScYfb3ol5kAjQIq0LpgAAABBACUmiHr4bN1FBXm/zO/6Yt1bpyZ rbcxLv/0pFk7/FkaPghdXXyjMZWSnosbw/2dVMMv3R1vJB1mWGl6W+tOkqjeqteO AE5Cf/iZHTGE4doS0pGdF8wa6e+mPFRZa/lV+3D9Rh0qDqoAlc0FShvd3aGUEI7e iIB7cGF52ciWGB3F1QAFEbQ9V2VzIENvd2xleSA8MTozNzcvMTQsIDcxNDQxLjMx NTRAY29tcHVzZXJ2ZS5jb20sIEJpeDp3Y293bGV5PokAlQIFECrQx1HcLUiqjfX7 JQEBEoAD/0YzuJ4LMxKY3CunHyOHmGbAcOEXcG6jqH3GarymZgisy1s1OZB5V5ak 4CzrGCj7Yj8k35KDjp+IcQHDM1JpUDUKB5p1iLblWOWmIa0Zb7SgS4gYDY042knk leCYpP39mrBC91SSFrGIWjM+wB9J1Izs8N5bWe0EEJonplR701/omQBtAirXWtcA AAEDALKH2cKuVzOuSo2NTQVwNtiysY+7piD8FZxzjvDGgOYGVJMagPP3ohPmlKVw mky6ljqtDVaGKDNBmWQlYy4KINpcPI801PtTnqzvLGa3aVs1hMX7mt218hn/G1O2 n+mdCQAFEbQ5RGF2aWQgUG93ZXJzIChkdHApIDxkYXZpZC5wb3dlcnNAZjU0Lm4x MjUuejEuZmlkb25ldC5vcmc+mQBNAirXO6sAAAECANunzqcH3SLKWFweZ3BAUXO3 OuAISoBxocBtjmgsvndahwdXFGkQzSPgf6uWt3HIksD0a6sKPOrQjUXODZuyxIMA BRG0OERhdmlkIFRyb3kgUG93ZXJzIDxkYXZpZC5wb3dlcnNAZjU0Lm4xMjUuejEu Zmlkb25ldC5vcmc+mQBNAirXWbAAAAECAKOREYOarMoniJ492Q11sfFe5jNAwqb7 p5UyUCPJmcWXZ4mlHIWkmhqOXUM4VArnYKVIrddBDbkaEVBAW2UrY20ABRO0I0No dWNrIEhheW5lcyA8MTozMDgvNjBARklET05FVC5PUkc+mQCNAirUKygAAAEEALVQ CansIsa6a+WfQiSOZDko678W7O4A/A7iUmJszodnQD+FVy+L2mcsL9pAjNwhAlHs Bb35FOVyD9XasQoyVFUZUrF7n6M5RruGGMrs5Pv2m1tVzkeZcSTWyPS7ovLQXRlt BuS9QbdZu5j8CzMM6g6GvvbqrK01TG5mb1FL1TGDAAURtAtKaW0gQ2FubmVsbJkA jQIq0KeFAAABBAC72+eRnJzbsIhU9gvXFkTddv48TQY0tQoCo9xa9Y8ocZaaemjQ 4uZqb1Hu0pgcTLdz0fM5FL9ZONnINKLkP+neAHhhY1CVLC/1wi4No4XCUvoW+mrW d0gO5rZCETi1866/oQNtl5WttsMicmp+955B/y5LL56lj0aWu/QAnbJS3wAFEbRH UmlkZGxlLCBNaWNoYWVsIEguICA8bWlrZS5yaWRkbGVAaW5ucy5vbWFodWcub3Jn ICAxOjI4NS8yN0BmaWRvbmV0Lm9yZz6JAJUCBRAq1G3WSrZKvJV4pRcBAQ41BADK KK/0vQqSZRfNZ48miAHrM7gwMxmLQzncqHC4H0dio3cx5r4frtmILtb75S/RZ5dT Ghkcyj90F4Zi5S80GvP7LgSOMArzw8WybQWmbWiR55DU6JzSEF8KvX3Re85WCy8m eV7HxvLJ9aF6vjptfCapqZPHAN2p0AFeIJIRRb0wrZkAjQIqrDZMAAABBADCljOd puRFotKHCuLtXAtjz8h0+rWr5PTwt0weVwWA3oH93bJXUaZ4yY9a/mjtPBRTvkCx CPcLQar39Tzz+Yi1+7A9riFZSR9eDD7clbY5vWSm/CTLQlu+NOOQYLRwQvckN1e7 1zVeYzOnRNqHJx+ACP6QRaxiyTyoEwOvWCFMNwAFEbQmSGFsIEZpbm5leSA8NzQw NzYuMTA0MUBjb21wdXNlcnZlLmNvbT6JAJUCBRAqrjNU4nXeDv9n9wsBAcq1A/97 qFdsvhbonK63dqA2sIDsPRI3MehPk8vT1T6ir35S7NM2Mhn3hVUoAW00gz91/dTd xevJ8nZfSfVQOkEQhnpRzNXGUbpAidAGGymH6cFDdMYxBh7A63doE+YlpQd7wWb4 vumG7OK0qvoMmc1Ztf/qEazHp99n89q9Ai4FLR6JNpkAPQIq1mizAAABAYDJSSC4 n8a1x/H5CcCW3kh1wGNUPfwMz8mxlctA8f6u9Ba93SoTOl6EhIGsNhM859kABRG0 Fk1hcmMgZGUgR3Jvb3QgKGNhc3VhbCm0I01hcmMgZGUgR3Jvb3QgPG1hcmNAa2c2 a2YuYW1wci5vcmc+mQCNAirWUOIAAAEEAMwYAT+znuzvB5vAdm4jB+EJiKdnoA1E vxL+Wa4L4W9Q2np1cgblqEvH8uN7nDvy8HX56LMDu6FzlWRHlNqK9z4XgQ7BYKue vNhcxyHQE5/NxlKtI5oSEg11mLLU5nS0EZ9EUwEhQWMhYI5PitvxTVM9tcKifqW/ BMyG4cAURCo/AAURtCJTdGV2ZSBDbGlmZm9yZCA8MToxMjUvMjA5QGZpZG9uZXQ+ mQBNAirV2r0AAAEB/i78BfdkmEIqKt2EhdlFAJc44rB3ZMzChez5zVcB9jRpUz1o MY2M2GnucGRUcvMSvZeF/aqCVIHuodDfqyGYYTkABRG0L1NlY3JldF9TcXVpcnJl bCA8U2VjcmV0X1NxdWlycmVsQFRyZWVob3VzZS5DT00+mQA9AirUzbUAAAEBfjC3 p5COEUMJ3xzrq4sJCTaU5MgvzC94tp8yxxBJeKUGo7xxgMShBCnIZp+xlFiyxQAF E7QYUGV0ZXIgTSBTaGlwbGV5IChjYXN1YWwptCZQZXRlciBNIFNoaXBsZXkgPHNo aXBsZXlAYmVya2VsZXkuZWR1PpkAjQIq0QwSAAABBADUsUTcG5jiohLNic8LAX59 ykQN8vF9CUnB/BQq5au7ShhVYKfAuGztlAkPk0/KdVeXG7Ae+feMpCAHYvZQnn8V z9I/yHdzQVekNQkOG2JxT3C2pQWes5RiAfUyHcCsXoJapVMVXDwRqb/GGTmCSbjs Zesexg9tCMydbzScJkT/zwAFEbQpTWFyY29zIFIuIERlbGxhIDxtYXJjb3NAemlw cHkuc29ub21hLmVkdT6JAFUCBRAq3gxmzT/tLvUlcRcBAV06Af4v/SjkJqxjmSwQ 71TngTsSJEEchXRbGdgHc22eZulnI1BXq2Y+IGpJR1IkQDO9aia17sx/bWi6aY60 lRKe4NzZmQCNAiqwg10AAAEEAMVNMI766ljeuW01xqXKYYV5lmDPvb+6dCQK3m1i BQdan0nopm35j1DIRp3UJZogAe5eimsQg1TALDhTq310OZs9+L6B/HxeX3+4BadI Dad4g+xIlvaFY1Ut/hMdZNkw0tzNZOdUPiO4jYIyirReAUiMCm6jXzkTRITj7/vx xWtPAAURtDNSdXNzZWxsIEUuIFdoaXRha2VyIDx3aGl0YWtlckBldGVybml0eS5k ZW1vbi5jby51az6ZAE0CKrtlMAAAAQIAwCr9FqO5gRboIusjiAAaXo1gb/erXefm 2czvKvWmzm6ARZgOrxcWCr6oUVd5dFEbIbJPFaz3OJkY/DS+zBmQCQAFE7QqQnJh ZCBDLiBNY0NhcnR5IDxmNjE3Lm4xMjUuejEuZmlkb25ldC5vcmc+mQCNAiq2rm8A AAEEAMuZvHCZd4CGhdDcfVfJjx6H/cB5UFJ0FhkzaluDZ37FK7nn9BXhcECVA2o3 TQWPjIh/787s2r3gFSERaI4HlFaXjWvIJ/3BYgkKCxbSmzN9PIrA/QPvNXyv/rE2 XBEFoR9ixWz8W9JEEkkwjSuR3o1/W80iM/sGslOJmEM5slffAAURtCpTaGF3biBL LiBRdWlubiA8Zjc1NTAubjEwNi56MUBmaWRvbmV0Lm9yZz6JAJUCBRAq0NfZbW04 UnNLmlkBAaxzA/9GvJvWV/Y1URG190TA1epJyUG2RRrtii/bMqgBXKH6kEVhMznJ 0M+/huF4213nctZE08RynCBsgpVxQ+y6oBC/Gxw9Yuci1PAB033+NZAbc7cJaOxg mZX7PS6o96s1/Rhl2RHlhDscJd9KgX111hLFJBayvOFIfy9Aimt76WFulpkAjQIq zS3+AAABBACzMsjb4rG9UyVR8oYL7WvZ6Q8BaCSDqSaq7/HK+TqXgjoZE4cYVg/3 WJkmRM8ZbuOwVA49Ssg0Xpj9KINC6dsbMSS5gIhlineM2JR6ioVwICSbsylivDug Tn2VGxWMAgihqJ2z7Tz3VD6eSgpbkqSwXU9gULJNKJFtbThSc0uaWQAFEbQoQ2hy aXN0b3BoZXIgQmFrZXIgPDE6Mzc0LzE0QGZpZG9uZXQub3JnPokAlQIFECrQxmzc LUiqjfX7JQEB/P4D+we6e8+QVJnyYWSWHTKEkUgGZFT9y776QmRmQ3RsnupcY/lh dl9qwl6IQHdo50CXRghRPukPMz+rU204pKCJLENIWz+cRSHyqdy8nsstOjM4dgoq WB8h0QchlNavm0LAmKLTCKgJ7WlnGFxHY+ngeqVMbHpbxR/UUAFf3DyYLiTpiQCV AgUQKtC8BHnZyJYYHcXVAQFqNwP/cktczkLkRwlce+4c7rwvn7nvuuI5gPVlsOdG LpqtnJ6cEgOPYgzHqW8tQrTecfUTm1TTtVKknwEP5YDxCYDcjlvM31n/S7fr4BeQ S/uatCxDqho/8kFFbOW4c6fetV3lag0pROxXWlCGYIYJ9dzRViSvvlS4UCHmPbNw mUdXG1iJAJUCBRAqzWPKGFfk3bG2uCMBASKOA/41iPyVsZbigbE043TQc2O/XTMd eqyy7P6O7fwE/Q+h5Qthl0pd1SeO3krxqjaXLgjZ07pIsb/+6nhU8UkfCEuFdW9Y E7ucOIYH2TSnASvv0WA57xbNluPVbui8gBRtrqpoFd9qIynPbhCxuwsqON7tinww RAygidEyvG4lVVeEq4kAlQIFECrNNyttbThSc0uaWQEB0AAEAIE9A80ah78d5T73 ZmHvHluXjMYBi96N07ix9/wPGa5moEoArV1UL8OZ/OsVXTALH58Pp48m6A96Dz1r H+uel6Jlu9NyRRNVzw4kXv5dYC8/ou7K7hvgB61ugAxtS7PzzjFrotd9IUDd/bkm P94lZ0XeFkE3wPlMN1Jlkot5k2X0mQCNAirGZZEAAAEEAL6UcTrYPKFcQjTs1vTb xGqN1t3WvF2x9N8ZrPfIKwThfPPppUXkCl6Gz0Y/kfu9WbhDoiBnMKIrvXTtsW+h 0f2Lm8Et9RrtMBR9G+CNpIPs+lJNZ9js8rIujX7uanBt/VK/Z0hwdIrzJ8YBEafV 6KJg3lHmfutndxhX5N2xtrgjAAURtDRHSyBQYWNlICBbMTozNzQvMjYgPGdrcGFj ZUBmMjYubjM3NC56MS5maWRvbmV0Lm9yZz5diQCVAgUQKs3JC21tOFJzS5pZAQHy JAQAlMgaSBlNourM5deAGSrgqbinr/T/0nNKCfPpZ3SwKe27No+NEbFmHCpPPjrN SVJoGDN1p8ePSnZdvuqb94cJCGwkdHBWd2c0xAjU4zUY7G+ddogmXfE/7mGdWtXL 7Xtga0vpDZdQ2AubKKCRntaXGNzrqP/5e6csUAhUHd5VLLOZAI0CKrDAUAAAAQQA tjl87QTiBTb4jkruf5IgK7Ig01Saj/PZQu8ruZTbkJbXqkb9RN7q2bbG8RLYjJxc EzCR6a9atG7NNteSuQf4/yu52MxmqIF0BikLD3vqtxMSLKYQpGdXjjAS3T4NhBj4 Z7QS3cijYnWpiMmhHb0egsVV1S3hOnIIZitHZ+yaIMEABRG0K0FyamVuIEcuIExl bnR6IChMRU5UWiBTT0ZUV0FSRS1ERVZFTE9QTUVOVCmZAI0CKm3yLAAAAQQAsYqA tuURAJ9xkSJD6MEWfDmDQH6jXoYw+yxgEojttaCMZsEOqeRCgwZqA0mlwbm1fZsq kl16CLTVKnbZA4yllt2u/8pdFYen8mOs0sBken0H6eWixtGs8uEZlkD86DJToPYa wacwNxNpw8PjfCjWD5FSkO/5SMyv4nXeDv9n9wsABRG0LFBoaWxpcCBSLiBaaW1t ZXJtYW5uIDxwcnpAc2FnZS5jZ2QudWNhci5lZHU+iQCUAgUQKs04AW1tOFJzS5pZ AQErqQP4zrYEvXhV77y90m2Vew8ZbDD/pxSpVWwgM16uU7CBVlAvMqTs/24qT3qJ 4Pcl2K6P1gCVj0Y+m4PFO07UYEm5UX00BYEZxiFFT4w5CO/4BJfrIu3oIdaadSYx dBz1uJYZouoE+kEvd35tIppVPXuGLRXdeojXuw/VOGUYgV9aU4kAlQIFECpvUjT0 ygCBjeci2QEBOfsEAL90+6LOAaROuDLyKKvcG8yTSg/HbkRUrpYsX8ya2O9NRvr2 sLx1zehE5/nRUKI1Tk2pzp5J94qaS50mjlW+a7Kf5tMz9JVpDPeU8Y3k7+Pnb+DG 4lhXBkyUvV3AiqK3x89ZW/jRozIHM+JdT7gyUQ3Vtf2P/4zTvlHyocusmGIgmQCN AipswZkAAAEEAMrcqvIwyKcvxWjFbUIq7/hhzWTrpeThdIxJl7T6P1sX9U6axBhS a1qE8LxwzTZ7/fhqaUlcZbrho5WODDqge325k7c2DCiIGxG+awndQR7a6X28/U05 aQXQiMnS+IgDOLo6gCtGUFoLDoUob5AuljqHlOrQovmoIPTKAIGN5yLZAAURtCdC cmFua28gTGFua2VzdGVyICA8bGFua2VzdGVAZndpLnV2YS5ubD6JAJUCBRAqbfKQ 4nXeDv9n9wsBAcIXA/9w7xBNQn8sTkmfBy6S6tFk7GFGHvQA/9eryxHlqjDDhBKQ eSJJGvPHmNQQ32CnVuv6M54qxT9iusopMv1RFS4ZXTB9u5KV4ajBGvkGfMsHLYgi AEcdUwndShAm6St/zRoJzQ3ae0mAFk9MYJKYcMuJYL3wCZjrrI5YNrrhSO52w5kA jQIqezKiAAABBADWbUO71XAVqN9dlef3kGRtlsSA9gnOkoRCzVlo4hFvO792Ie/Y 1p/c5pz2YAyU+9C0beZHVWHwofAdUmdpF3iz2q+4viODLN2UbD2E7hoPjm3HLLjg iRCKy7lBjtEofLm0TU2mSuAZOR4zKaNcCRcRcSCYtAiJZA/6EarpnZl9RwAFEbQl UGV0ZXIgR3V0bWFubiA8cGd1dDFAY3MuYXVrdW5pLmFjLm56PokAlQIFECqkeZfi dd4O/2f3CwEBrsYD/AqgSbc7d3qYO5Gww2MxZX4gA04nzHbyx3XnX6xWUOU6w+Rx /X/00hP42og+P3Rf+pBg0y4KiIe7hY2TOb6neh3qpcpxkHQKtUkRQd6zYFNRuYoR NTgeusTiiAv0cL6RYaZFWt44RzbOr3tJZrz3uPHLz2nvDvec4zPHvMoWyeVFmQBN AiqKPnYAAAECAM4DUPnxdjb43Il+yDkRUO8TgzOW/hjTs1/blllrVe8HDlABqHZM ib0aNFhKRFYjvsNS3xk34N65vtlI/HoTNvUABRG0IUhhcnJ5IEJ1c2ggPEhhcnJ5 QGNhc3RsZS5yaWdhLmx2PokAlQIFECqmFtb0ygCBjeci2QEBqVwD/A/8vnke2KFN yFLTOdYhiAZlbpPuo621TIYWVxPJ+D+TVkELdn7HWmDpDGQ8l/7XmuDEBrGjFiQj 1Mv67+rnEqhA4ufKyKS57GuSZ90G99iLLimCiA9ytQyRz8Wi8GUzh2lpv7/478Nv xEgya3nVM6LwkXodv4OYPVxUnLoSNFGFmQBNAiqc8q0AAAEB/i6Q/XxMaNqWP1tY 4D8vHr5KiwFz1XvE9F5ltPVPeW2I0EORg6u7xSlreXo9OvRd0BbF+UdOAjH7Pwvh v9xiBCMABRG0IkplYW4tbG91cCBHYWlsbHkgPGpsb3VwQGNob3J1cy5mcj6JAJUC BRAqp3Bp9MoAgY3nItkBAegyA/sEwCWN7IU1T0NVNkcOcqe+lCn8P42UfX1RUKqC fErqT51BAPnSIz0naWFQII8ZE41FQQ6iuKnbfKpmIi4VelzcjzsEwdw15cdnyV8O 9FXQ25ysMe1C6LkodMU20XMjH7744n0NG15PWbNcmwNOQ2119tw+u9rRuuC6PFWF vX0wVZkATQIqxyFfAAABAgDhOocrwWVLJVToItdrune/+sjCF1+GiiEXH1d8Gv8r B5frpXeGoAtWFvmIpmHgPv21zgcR/2Pykc0/7S71JXEXAAURtDFUb20gSmVubmlu Z3MgPHRvbWpAZmlkb3N3LmZpZG9uZXQub3JnLCAxOjEyNS8xMTE+iQCVAgUQKtDh Nm1tOFJzS5pZAQGRrAP+PVrIqMEPeiAmt/K9gjW2xWOVQar5X7v++C/8BqIYj8mm mGddvQa098te5C1OyunMTK0XtFz7kIvcDJhfKzmp+rdI6TfGURvasmirRFAPxPd9 +lJcIQyInHiRDARFub1xGOQ+Q1ndXsaX1f0O93vz/kjXY0SoC8IURY0OFhPF1paJ AJUCBRAqy4RiGFfk3bG2uCMBAaH+A/9S3C84z9CK/NLl1Tczz2hxG6R4C41pwPPR 49LX1wNDafec1RyhDUPVP37kc+Rtu6xxZsvsAk19s7KwwYE5Sp+IRsDk8+Qg3545 wfDVUNfV7fShf7ZW3tZY2ybZp3GP3TzH8JFpQjxRy1z1sNyIhZSaNYUb8awDN+uM mt8zU1SbDw== =TN0Q -----END PGP PUBLIC KEY BLOCK----- --- ReadMail * Origin: World Power Systems / FidoNews / San Francisco CA (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 Oct 25 13:08:18 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Sun, 25 Oct 92 13:08:18 PPE Subject: pgp key distribution Message-ID: <3270.2AEAFD74@fidogate.FIDONET.ORG> U> From: shipley at tfs.COM (Peter Shipley) U> I maintain two public rings one is a collection I have U> collected via direct contact (friends mostly) the other is U> jyanowitz's list plus random other rings). I'm surprised by the number of people who, when they receive a key in the mail, certify it themselves. I leave mine also uncertified unless I got it directly. I don't sign nuttin. --- ReadMail * Origin: World Power Systems / FidoNews / San Francisco CA (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 Oct 25 13:08:19 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Sun, 25 Oct 92 13:08:19 PPE Subject: pgp key distribution Message-ID: <3271.2AEAFD74@fidogate.FIDONET.ORG> U> From: pmetzger at shearson.com (Perry E. Metzger) U> for the life of me understand why. The only way to know U> for sure that someone's key is theirs is a signature from U> a trusted introducer anyway, so people can just ask each U> other in clear for public keys and it doesn't do a lick of I think it is valuable for a number of reasons, none of which are traditional encryption reasons. One: Mostly, in my world, I don't need SECURITY, I need PRIVACY. A paper envelope sealed with water-soluble glue is just fine. It stops casual snoops, like the lock on your car door does. None of which will stop a determined thief, but like Eric says, it's economics -- this level of security is inexpensive as hell. Two: it gets people introduced to the very basic concept that there *is* privacy (security) available, and possible. In the FidoNet, and the BBS world, this is important. Three: In FidoNet, we've got 16,000 sysops, doubling every 18 months, worldwide. Traditional key systems are not only wildly impractical, they're unnecessary for traditional reasons -- who much security to I need to talk to someone 5,000 miles away I've never met? Four: If I need *real* security, I will (or better!) obtain keys in "traditional", secure ways. I can plug these keys into my casual privacy system, which will hopefully encompass the technological mechanisms of en/decryption, signing, plaintext handling, and all the assorted baggage we'll have to drag around anyways. Five: it will entrench some disasters; bum, or faked keys, humongous duplicates, inexperienced people forgetting their secret pass phrases so they can't even issue key-removal certificates (this has happened already; its a MAJOR pain in the ass), one "person" with a zillion IDs, inconsistent IDing, etc etc etc etc etc. Oh well. In fact, no system gets implemented right. Period. To pretend it will is folly. Because of the nature of the beast (patents, feds looking for backdoors, stupidity, centralist, authoritarian types trying to exert control, etc, I'm pushing, hard and fast, to get systems set up LIKE CRAZY of all sorts, with all of them being completely distributed and decentralized. Sufficiently Paranoid. --- ReadMail * Origin: World Power Systems / FidoNews / San Francisco CA (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 nathanf at cup.portal.com Sun Oct 25 16:21:58 1992 From: nathanf at cup.portal.com (nathanf at cup.portal.com) Date: Sun, 25 Oct 92 16:21:58 PPE Subject: Removal from list Message-ID: <9210251610.1.16692@cup.portal.com> Please remove me from the list. My address is nathanf at cup.portal.com Thank you. From tcmay at netcom.com Sun Oct 25 20:10:41 1992 From: tcmay at netcom.com (Timothy C. May) Date: Sun, 25 Oct 92 20:10:41 PPE Subject: Registering Keys with Big Brother Message-ID: <9210260209.AA18958@netcom2.netcom.com> Arise, cypherpunks, evil plans are brewing in the bowels of the Beast! I just read a summary of influential crypto guru Dorothy Denning's talk at the recent 15th National Computer Security Conference (held in Baltimore, don't you know, so con-vee-nient to Fort Meade). See the recent RISKS articles in comp.risks (esp. 13.86). Since RISKS is copyrighted, and we wouldn't to do anything to make the lawscums unhappy, I'll summarize: * Denning proposes that anyone using public key encryption over public networks be required to register their private keys with, for example, the Justice Department. * To avoid the risks of someone else getting the key, she suggests the private keys could be encrypted with the _public key_ of Justice, and then held by an independent agency. (Ostensibly, the encryption and registration could be done by the user himself, though some means of verifying compliance would have to be devised.) * To make use of the private key (for example, to read e-mail encrypted with the key), the government would have to get a court order, present it to the independent agency, take the key back to Justice, decrypt it with the private key of Justice, and then proceed with their surveillance and whatnot. This is ostensibly like the procedure for wiretapping. However, it would screw up the use of encryption in many ways. Registering a key would precluded frequent key changes, would probably cost some fee (on the order of $50, like a driver's license, I'd guess), and would of course greatly complicate the use of digital pseudonyms and all the other neat stuff we've talked about (but which caution tells me not to discuss here on an open and unsecured list...you can check my .sig to see where I stand, of course). My hunch is that Denning and the other "quaint" (cf. Sterling's "The Hacker Crackdown" for a description of how the crypto bigwigs interact with hackers at CFP and elsewhere) cryptheads have alerted the government to the _real_ threat of cryto tools. Position papers are being released as trial balloons, to prepare the way for a "Crypto Crackdown." I hope I'm wrong. We need more information. Let's talk to someone who went to this conference and get the Proceedings as quickly as possible. Cryptically Yours, --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 2.0 and MailSafe keys by arrangement. From hh at soda.berkeley.edu Sun Oct 25 21:29:49 1992 From: hh at soda.berkeley.edu (Eric Hollander) Date: Sun, 25 Oct 92 21:29:49 PPE Subject: BBS E-mail policy In-Reply-To: <9210230601.AA26160@soda.berkeley.edu> Message-ID: <9210260429.AA29646@soda.berkeley.edu> Re: entropy I seem to remember that English text is about 1.5 bits per character. I can find a reference if you're interested. e From hh at soda.berkeley.edu Sun Oct 25 21:41:19 1992 From: hh at soda.berkeley.edu (Eric Hollander) Date: Sun, 25 Oct 92 21:41:19 PPE Subject: entropy measures In-Reply-To: <9210240620.AA08036@soda.berkeley.edu> Message-ID: <9210260440.AA00199@soda.berkeley.edu> >uuencoding will have a slightly lower single-character entropy than >the ASCII armor PGP uses because just about every line begins with the >letter 'M'. This will skew the distribution slightly. But a better >way of distinguishing uuencoding and ascii armor is to see that in >falls in the same entropy class, and then just looking at the >alphabetic subsets used. It's not that simple. The entropy of a byte is the number of bits needed to represent it. If what is uuencoded is extremely repetitive, the entropy will be low, maybe even less than one. On the other hand, if it were random data, it would just be slightly lower than ascii armor. Binaries are somewhat repetitive, so they have somewhat less entropy than random data. English has a lot of redundancy, so it has a low entropy. e From tcmay at netcom.com Sun Oct 25 23:32:00 1992 From: tcmay at netcom.com (Timothy C. May) Date: Sun, 25 Oct 92 23:32:00 PPE Subject: Alpha Particles and One Time Pads Message-ID: <9210260530.AA00679@netcom2.netcom.com> Fellow Cypherpunks, Here's a posting I just sent to sci.crypt, dealing with using alpha particle sources as noise sources for generating one-time pads. Ordinarily I wouldn't bother you folks with this, especially since you're all reading sci.crypt (aren't you? Only the FidoNetters have a good excuse not to.). But this thread ties together two aspects of my life, cryptography and alpha particle errors in chips. --Tim Newsgroups: sci.crypt Path: netcom.com!tcmay From: tcmay at netcom.com (Timothy C. May) Subject: Re: Hardware random number generators compatible with PCs? Message-ID: <1992Oct26.051612.29869 at netcom.com> Organization: Netcom - Online Communication Services (408 241-9760 guest) X-Newsreader: Tin 1.1 PL5 References: <1992Oct25.224554.1853 at fasttech.com> Date: Mon, 26 Oct 1992 05:16:12 GMT Bohdan Tashchuk (zeke at fasttech.com) wrote: : The recent post on building a random number generator using a zener diode got : me to thinking once again about commercial alternatives. : : I haven't seen any commercial alternatives discussed here recently. And since : the market is so specialized, they may well exist but I'm simply not aware of : them. : : The ideal product would have the following features: : : * cost less than $100 : * use a radioactive Alpha ray emitter as the source It's a small world! In my earlier incarnation as a physicist for Intel, I discovered the alpha particle "soft error" effect in memory chips. By 1976 chips, especially dynamic RAMs, were storing less than half a million electrons as the difference between a "1" and a "0". A several MeV alpha could generate more than a million electron-hole pairs, thus flipping some bits. (Obviously the effect of alphas on particle detectors was known, and smoke detectors were in wide use, but nobody prior to 1977 knew that memory bits could be flipped by alphas, coming from uranium and thorium in the package materials. It's a long story, so I won't say any more about it here.) : * connect to an IBM PC serial or parallel port : * be "dongle" sized, ie be able to plug directly onto the port, and : not have a cable from an external box to the port : * be powered directly from the port : * generate at least 1000 "highly random" bits per second This should be feasible by placing a small (sub-microcurie) amount of Americium-241 on a small DRAM chip that is known to be alpha-sensitive (and not all of them are, due to processing tricks). Errors would occur at random intervals, depending on which bits got hit. Getting 1000 errors a second would be tough, though, as such high intensities would also tend to eventually destroy the chip (through longterm damage to the silicon, threshold voltage shifts, etc.). If you really want to pursue this seriously, I can help with the calculations, etc. : Details: : : Certainly in high volume these things can be made cheaply. Smoke detectors : often sell for under $10, and have a radioactive source, an IC, a case, etc. Yes, but smoke detectors use ionization in a chamber (the smoke from a fire makes ionization easier). That is, no real ICs. But ICs, and even RAM chips, are cheap, so your $10 figure is almost certainly in the ballpark. A bigger concern is safety, or the _perceived_ safety. Smoke detectors have, I understand, moved away from alpha particle-based detectors to photoelectric detectors (smoke obscures beam of light). Don't underestimate the public's fear of radioactivity, even at low levels. : Using a well-designed circuit based on Alpha decay should mean that the : randomness is pretty darn good. But not necessarily any better than noise from a Zener. With the higher bit rate from diode noise, more statistical tricks can be done. The relatively low bit rate from alpha decay gives less flexibility. On the other hand, alpha hits are undeniably quite random, with essentially no way to skew the odds (unlike with diode noise). : Everyone these days has either a serial or parallel port available, either : directly or thru a switch box. : : The tiny "dongle" size is a convenience. If it is small and powered directly : from the port, there are no cables to get in the way. There is enough power : available from the signal lines on these ports to power simple devices. E.g. : most mice don't require an external power supply. : : For most applications 1000 bits per second should be adequate. For example, : it would be quite adequate for session keys. For generating pseudo : one-time-pads, an overnight run should generate plenty of values. Continuously : generating values for a month would produce about 300 MB, which should be : enough to exchange new CD-ROM key disks once a month. One time pads are complicated to use. Only very high security applications that can also afford them use them. For example, some diplomatic traffic. I can't conceive of a case where 300 MB a month could be used. And _theft_ (or copying) of the CD-ROM one time pads has got to be a much bigger issue that whether alpha particle noise sources are better than diode noise sources! By about 10 orders of magnitude I would say. Black bag jobs on the sites holding the keys will be the likeliest attack, not trying to analyze how random the noise is (even a fairly crummy noise source will not yield enough information to a cryptanalyst trying to break a one-time pad). Having said all this, I'm glad you gave some thought to alphas. For a time in the late 1970s this was the chip industry's number one headache...it was definitely the most exciting time of my life. --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 2.0 and MailSafe keys by arrangement. From gg at well.sf.ca.us Mon Oct 26 01:54:38 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Mon, 26 Oct 92 01:54:38 PPE Subject: Registering Keys with Big Brother Message-ID: <199210260853.AA20086@well.sf.ca.us> Tim's summary of Denning raises some interesting points, and no doubt this will end up in the courts in due time. Some angles of attack which might be pursued include 2nd amendment (original grounds: protection against tyrrany) and 1st amendment. Re the latter, a lawyer I spoke with some years ago, proposed the idea that freedom of speech in some cases depends on the ability for the speaker to determine who will and who will not receive what is said. Then of course there is always good oldfashioned civil disobedience. If enough people conscientiously violate the regulation, it will become unenforceable and all the more likely to be overturned. -gg From marc at kg6kf.ampr.org Mon Oct 26 03:44:55 1992 From: marc at kg6kf.ampr.org (Marc de Groot - KG6KF) Date: Mon, 26 Oct 92 03:44:55 PPE Subject: Alpha Particles and One Time Pads Message-ID: <9210261024.AA11069@kg6kf.ampr.org> Tim May sez: Here's a posting I just sent to sci.crypt, dealing with using alpha particle sources as noise sources for generating one-time pads. Tim, Why not use a back-biased germanium diode, or other noisy semiconductor junction? Seriously, the NRC has allowed the smoke detector people to spread those little radioactive chunks of Americium for too long. John Walker of AutoDesk actually built an IBM-PC card that generated random numbers from a radioactive source. All the best, ^M From efrem at spitha.informix.com Mon Oct 26 03:52:20 1992 From: efrem at spitha.informix.com (Efrem Lipkin) Date: Mon, 26 Oct 92 03:52:20 PPE Subject: Registering Keys with Big Brother Message-ID: <9210261016.AA15135@spitha.informix.com> It seems that registration would defeat the advantage of a public key system, but it would not prevent private encrypted messages from being hidden from casual traffic analysis or even notice by public key wrapping. This would make registration rather useless against a conspiracy and thus hard to justify in the face of commercial and constitutional opposition. --efrem From hughes at soda.berkeley.edu Mon Oct 26 08:55:04 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Mon, 26 Oct 92 08:55:04 PPE Subject: entropy In-Reply-To: <9210260429.AA29646@soda.berkeley.edu> Message-ID: <9210261554.AA11701@soda.berkeley.edu> Re: entropy Eric Hollander writes: >I seem to remember that English text is about 1.5 bits per character. I can >find a reference if you're interested. There are lots of entropies available to measure. There is "true" entropy, the lower bound for all other entropy measures. This is the compressibility limit. The entropy I was referring to was simply the single character entropy. That is, the probabilities p_i in the entropy expression are the probabilities that a given single character appear in the text. This will be higher than the true entropy. Shannon's estimate for H_1 was 4.03 bits/character. This assumes a 27 character alphabet. The entropy for ASCII-represented English will be higher because of punctuation and capitals. The true entropy of English is much lower than this, of course. But for an simple measure to automatically distinguish between plaintext and ciphertext, it should suffice. Re: uuencoding. In my analysis before I assume that the uuencoding would be of random data. If it is not from random data, then the entropy will be lower. Thanks for the clarification. Eric From 74076.1041 at CompuServe.COM Mon Oct 26 09:23:21 1992 From: 74076.1041 at CompuServe.COM (Hal) Date: Mon, 26 Oct 92 09:23:21 PPE Subject: Registering Keys... Message-ID: <921026155917_74076.1041_DHJ88-1@CompuServe.COM> This proposal to register keys was also mentioned in the July, 1992 Communications of the ACM, in an article by Ron Rivest, one of the creators of the RSA algorithm. He was mostly criticizing the proposed government Digital Signature Standard, stating that he thought that the NSA was purposely trying to get "weak" cryptography installed as the standard. Then he goes on to say, "Are there technical alternatives that would satisfy all parties? Perhaps. It is certainly the case that the formulation of the problem to be solved has never been made explicit for the cryptographic community to work on. I suspect that a solution based on 'escrowed secret keys' might be workable, wherein each user is legally required to depost his or her secret key with a trusted third party, such as the user's bank. Cryptographic hardware and software would only operate with public keys that were certified to having their corres- ponding secret keys appropriately escrowed. A federal agency could then obtain the secret key, or its use, with an appropriate warrant. Once their secret keys were escrowed, multinational corporations could even operate across borders with a high degree of authentication and privacy (except perhaps from court-ordered wiretaps). Cryptographic hardware and software manufactured in the U.S. would not operate abroad without public keys suitably certified as having their secret counterparts escrowed in the U.S. In an extension of this approach, users can escrow their secret keys with several trusted third parties in a 'secret-sharing' manner, so that no single third party can com- promise the user's key. While this approach may have its own difficulties, it does illustrate that weak cryptography is not the only technical approach available. There may be much better techniques for achieving a compromise between a number of conflicting national concerns." At the time that I read this, I thought it was largely a rhetorical device, making the point that if the government wants to infringe on people's privacy, it should come out in the open and do so, rather than skulking about. (Like saying, "if the government _really_ wants to stop sexual immorality it would have to put a TV camera in every bedroom".) And of course (I thought) this kind of proposal would never be taken seriously. I'm shocked that Denning is now advocating it openly. This proposal makes it illegal for people to communicate so secretly that the government can't find out what they are saying. It could apply to postal mail as well as email - it would be illegal to send a message via post which the government couldn't interpret. If this is really the government's purpose, then it should also require that all private conversations be recorded, and the resulting tapes be "escrowed" similarly in case the government needed to find out what was said, for which it would have to get a court order. As Tim suggested, this is probably a "trial balloon" being floated to see what the reaction is. Let's see that it gets shot down. Hal 74076.1041 at compuserve.com From hughes at soda.berkeley.edu Mon Oct 26 09:38:01 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Mon, 26 Oct 92 09:38:01 PPE Subject: Registering Keys with Big Brother In-Reply-To: <199210260853.AA20086@well.sf.ca.us> Message-ID: <9210261637.AA12485@soda.berkeley.edu> Re: Some angles of attack George: >2nd amendment (original grounds: protection against tyrrany) I've thought for a year or so now that if the State Department was going to class cryptography as munitions, then they have _de jure_ acknowledged that civilian use of cryptography is protected under the Second Amendment. Cryptography is not a weapon and should not be restricted for public safety reasons. >1st amendment. Re the latter, a lawyer I spoke with some years ago, >proposed the idea that freedom of speech in some cases depends on the >ability for the speaker to determine who will and who will not >receive what is said. This criterion may be valid, but I don't think it's needed. As I understand it, the restrictions on speech that do exist restrict 1) certain contents, not speech as such, and 2) speech which is public, not private. Encrypted text, by the fact that it is encrypted, is intended to be removed from the public domain. And restricting the transmission of encrypted text based on some assumed content is prior restraint. I'm not sure that any of these arguments really touch a key registration proposal, unfortunately. Guns may be sold, but also registered. It is not the speech that is restricted, but the privacy from the Justice Dept. which is restricted. What I suspect may be more effective is to argue, based on the Tenth (or Ninth? I get them confused) Amendment, that the Federal Government has not been granted specific power to require the registration of key material under any of its other powers. >Then of course there is always good oldfashioned civil disobedience. But the percentage of users of cryptography for communications is a small percentage of the total population as of yet. Eric From hughes at soda.berkeley.edu Mon Oct 26 09:40:33 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Mon, 26 Oct 92 09:40:33 PPE Subject: Registering Keys with Big Brother In-Reply-To: <9210261016.AA15135@spitha.informix.com> Message-ID: <9210261640.AA12615@soda.berkeley.edu> >It seems that registration would defeat the advantage >of a public key system, but it would not prevent private >encrypted messages from being hidden from casual traffic >analysis or even notice by public key wrapping. Sounds like a recipe for selective enforcement, doesn't it? Eric From hughes at soda.berkeley.edu Mon Oct 26 09:53:38 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Mon, 26 Oct 92 09:53:38 PPE Subject: entropy In-Reply-To: <921024155350_74076.1041_DHJ67-1@CompuServe.COM> Message-ID: <9210261653.AA13072@soda.berkeley.edu> Hal: >Ascii encoding used by PGP reduces this to 6 bits per character >(e.g. a character set with 64 printable characters) neglecting >line separators and message beginnings and endings. So there >should be a little less than 6 bits per character for encrypted, >Ascii-encoded messages. Hal is, of course, right. I was getting myself confused between entropy lost in the encoding and the entropy of the encoding. The channel uses up two bits of entropy per character in the encoding. What's left is six bits. As punishment for getting this so egregiously wrong, I'm going to post some C code for measuring entropy so that you all can play with it. Eric From pmetzger at shearson.com Mon Oct 26 10:08:45 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Mon, 26 Oct 92 10:08:45 PPE Subject: Registering Keys... In-Reply-To: <921026155917_74076.1041_DHJ88-1@CompuServe.COM> Message-ID: <9210261643.AA16936@newsu.shearson.com> >From: Hal <74076.1041 at compuserve.com> >This proposal makes it illegal for people to communicate so secretly >that the government can't find out what they are saying. It could >apply to postal mail as well as email - it would be illegal to send >a message via post which the government couldn't interpret. If this >is really the government's purpose, then it should also require that all >private conversations be recorded, and the resulting tapes be "escrowed" >similarly in case the government needed to find out what was said, >for which it would have to get a court order. >As Tim suggested, this is probably a "trial balloon" being floated to >see what the reaction is. Let's see that it gets shot down. I find it repugnant that we've gone all the way over to the notion that people must actively cooperate with their own enslavement. We'd better start getting organized flames against this idea mobilized. Denning is on the net -- anyone care to start flaming on sci.crypt? Its likely the place that will get the most response in the general community. Perry From tcmay at netcom.com Mon Oct 26 11:22:35 1992 From: tcmay at netcom.com (Timothy C. May) Date: Mon, 26 Oct 92 11:22:35 PPE Subject: (fwd) A Trial Balloon to Ban Encryption? Message-ID: <9210261819.AA07688@netcom2.netcom.com> Fellow Cypherpunks, I have rewritten my posting on Denning's proposal and posted it to sci.crypt, for wider discussion. I'm surprised the sci.crypt folks had not already the significance. You might want to consider debating the issue there, rather than on this list, as your words will then be heard by more folks and could mobilize an effort against proposal like this one of Denning's. Cryptically your, --Tim Newsgroups: sci.crypt Path: netcom.com!tcmay From: tcmay at netcom.com (Timothy C. May) Subject: A Trial Balloon to Ban Encryption? Message-ID: <1992Oct26.180813.7002 at netcom.com> Organization: Netcom - Online Communication Services (408 241-9760 guest) X-Newsreader: Tin 1.1 PL5 Date: Mon, 26 Oct 1992 18:08:13 GMT Is there a trial balloon being floated to effectively ban encryption? Noted and influential influential crypto advisor Dorothy Denning has apparently floated the idea of _public key registration_ in a paper or talk at the 15th Computer Security Conference in Baltimore, held recently. Discussion of this is in comp.risks ("RISKS"), so far, but certainly belongs in this group. I posted a summary of this position to a private mailing list devoted to crypto issues and got a huge response of concerned folks. I don't understand why this is not a hot topic on sci.crypt, so I'll post something right now. Here's my understanding of her proposal: * Anyone using public key cryptography would be required to register the private key with the appropriate authorities, for example, the Justice Department. * To head off the obvious concerns about the government routinely reading e-mail, financial dealings, etc., this registered key would be stored at an independent agency after first being encrypted with the _public key_ of Justice. (That is, the independent key storage agency would have an unusable key, so _they_ couldn't use it themselves.) * To obtain a usable form of the private key, Justice would have to get a valid court order, go to the independent storage agency, present the order, pick up the key, open it with their own _private key_, and proceed to open mail, read communications, etc. This is ostensibly the procedure now used for wiretaps. But the effect on encryption would be chilling: -would greatly complicate the rapid changing of keys -would probably be a way to get "unlicensed" crypto programs off the market (e.g., don't think about using PGP 2.0, as the key registration authorities would either insist on another algorithm, or would send the "registration application" to, for example, RSA Data Security for legal action) -would undoubtedly require a "fee" (like a driver's license) -would interfere with the use of digital pseudonyms, anonymous nets (a la Chaum's "DC Net" proposal, which some of us are exploring now), and digital money -would establish the precedent that private communications are not legal, that copies of all private communications must be placed in escrow with the government Registering keys is no different than, for example, requiring a permit for every public utterance or for registering typewriters, modems, computers, fax machines, and copiers. Or banning the use of sealed envelopes for mail. In Phil Zimmerman's great words, it would be like requiring all mail to be sent on postcards. My suspicion, which Prof. Denning will presumably comment on if she's reading this, is that the government folks have come to understand the profound implications of modern crypto and are looking for approaches to head off the coming sea changes. Granted, there are serious national security threats in using modern crypto methods, but there are in any of the new technologies, such as those listed above. Besides, does anyone think all keys will be registered? Hiding bits is a relatively easy thing to do. This key registration proposal is more odious than the "backdoors in telecom equipment" proposal discussed here recently. Can we remain silent as our liberties are taken away? I think it was John Gilmore who said: "If encryption is outlawed, only outlaws will have encryption." -- .......................................................................... 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 2.0 and MailSafe keys by arrangement. From shipley at tfs.COM Mon Oct 26 12:13:42 1992 From: shipley at tfs.COM (Peter Shipley) Date: Mon, 26 Oct 92 12:13:42 PPE Subject: Alpha Particles and One Time Pads In-Reply-To: <9210261024.AA11069@kg6kf.ampr.org> Message-ID: <9210261911.AA12805@edev0.TFS> >Tim May sez: > Here's a posting I just sent to sci.crypt, dealing with using alpha > particle sources as noise sources for generating one-time pads. > >Tim, >Why not use a back-biased germanium diode, or other noisy semiconductor >junction? Seriously, the NRC has allowed the smoke detector people to >spread those little radioactive chunks of Americium for too long. > >John Walker of AutoDesk actually built an IBM-PC card that generated >random numbers from a radioactive source. Q: how hard/cheap will it to build a shielded rs232 plud with a noisy diode in it to provide a random number source? I have written on a possible random number source for Sun SparcStations (I and II). I have a program programs the audio chip to take input from mic port 2 (which is not used in a SparcStation) then I turn up the gain in the pre-amps and read the data of the from the DtoA. I do not know how random it is yet (if anyone wants to run some tests for me I will be happy to email them the program) -Pete From shipley at tfs.COM Mon Oct 26 12:47:45 1992 From: shipley at tfs.COM (Peter Shipley) Date: Mon, 26 Oct 92 12:47:45 PPE Subject: Alpha Particles and One Time Pads In-Reply-To: <9210260530.AA00679@netcom2.netcom.com> Message-ID: <9210261947.AA13100@edev0.TFS> why doesn't someone set up a random number source on a internet host avalible on a tcp/udp socket? thus if I want some numbers all I have to do is: telnet random_host rand_port > ./random_data_file the use a pseudo-random generater to select from my random number stream for a unique random number set. -Pete From hughes at soda.berkeley.edu Mon Oct 26 12:58:58 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Mon, 26 Oct 92 12:58:58 PPE Subject: entropy, with code Message-ID: <9210261958.AA28999@soda.berkeley.edu> The entropy-calculating code is at the end of this message. I took the opportunity to calculate some sample entropies: entropy.c 5.283772 the source code entropy.asc 6.052222 entropy.c, encrypted and armored entropy.as2 6.012493 entropy.asc, with the wrappers removed entropy.pgp 7.830532 entropy.c, encrypted alone entropy.obj 6.112890 entropy.exe 6.947111 randseed.bin 4.584963 from pgp, 24 bytes long pubring.pgp 7.754017 my public key ring The entropy of the source code is in the high end of the range for English, which is not surprising given the amount of symbols in ordinary C code. The entropy increases with the object and the executable, each of which has less overt structure to it. The entropy of the encrypted and ascii armored source code is within 1% of 6 bits, just as predicted. And with the wrappers removed, it's even closer! The binary version of the encrypted message has the highest entropy of all these tests. In randseed.bin, the entropy is much less than 8. But the length of the file is 24 bytes and log_2 24 = 4.584963, indicating that there are no duplicate bytes in the file. Hence the warning: entropy calculations with small samples _will_ be misleading. Note that the entropy subroutine can be used to calculate the frequencies of any distribution. This will allow all you code-writing cypherpunks to measure bit entropies, digram entropies, etc. Eric ---------------------------------------------------------------- /* entropy.c -- Calculate monogram entropies of standard input. */ #include #include /* This next define is to counteract the foolish C 7.00 runtime mapping * of \x1A to EOF */ #define STUPID_NEWLINE_TRANSLATE 1 #ifdef STUPID_NEWLINE_TRANSLATE #include #include #endif /*--------------------------------------*/ #define NUMBER_OF_BYTES 256 long byte_freq[ NUMBER_OF_BYTES ] ; void main() { int c, verbose = 0 ; unsigned int j ; double entropy( long *, int ) ; #if STUPID_NEWLINE_TRANSLATE _setmode( _fileno( stdin ), _O_BINARY ) ; #endif for ( j = 0 ; j < NUMBER_OF_BYTES ; ++j ) { byte_freq[ j ] = 0 ; } while ( EOF != ( c = getchar() ) ) { ++ byte_freq[ (unsigned int) c ] ; } if ( verbose ) { for ( j = 0 ; j < NUMBER_OF_BYTES ; ++j ) { printf( "%3d=%-3d ", j, byte_freq[ j ] ) ; if ( j % 8 == 7 ) printf( "\n" ) ; } } printf( "%lf\n", entropy( byte_freq, NUMBER_OF_BYTES ) ) ; } /*--------------------------------------*/ /* Calculates the entropy of the distribution given in list v of n elements. * The list v gives counts. v is summed, and frequencies are assigned * as v[i]/sum(v). * * Uses the following definitions and identities: * A = \Sum_{i=0}^{n-1} v_i * p_i = v_i / A * H = \Sum_{i} - p_i \log p_i * = log A - 1/A \Sum_{i} v_i \log v_i * lim_{x \rightarrow 0} x \log x = 0 */ double entropy( long *v, int n ) { double h ; long sum ; int j ; /* first sum the array */ sum = 0 ; for ( j = 0 ; j < n ; ++j ) { sum += v[ j ] ; } /* next calculate the entropy function */ h = 0 ; for ( j = 0 ; j < n ; ++ j ) { /* If the frequency is zero, the entropy contribution is zero */ if ( v[ j ] == 0 ) continue ; h -= v[ j ] * log( v[ j ] ) ; } h /= sum ; h += log( sum ) ; /* Now adjust the base of the logarithm to base 2 */ h /= log( 2 ) ; return h ; } From pmetzger at shearson.com Mon Oct 26 14:09:43 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Mon, 26 Oct 92 14:09:43 PPE Subject: Alpha Particles and One Time Pads In-Reply-To: <9210261947.AA13100@edev0.TFS> Message-ID: <9210262036.AA18923@newsu.shearson.com> >From: Peter Shipley >why doesn't someone set up a random number source on a internet host >avalible on a tcp/udp socket? thus if I want some numbers all I have to >do is: > telnet random_host rand_port > ./random_data_file >the use a pseudo-random generater to select from my random number stream >for a unique random number set. Consider that most people who want to use their random numbers for cryptographic purposes don't want everyone in the free world able to read them as they pass through the internet... In anycase, there is a CALmos device out there that is fairly easy to use and produces about 20kbits of good random data per second -- not fast enough for many purposes, but far better than nothing. I suspect there are other devices on the market, but I haven't researched it carefully. I can get information on this particular device out to anyone who is willing to design it into a simple to build RS232 interfaceable box to generate random bits. Perry From a2 at well.sf.ca.us Mon Oct 26 22:54:33 1992 From: a2 at well.sf.ca.us (Arthur Abraham) Date: Mon, 26 Oct 92 22:54:33 PPE Subject: Registering Keys with Big Brother Message-ID: <199210270553.AA26809@well.sf.ca.us> Seems to me that there would be a certain amount of trouble with people registering one private key but communicating with another they had forgotten to register. Bad situation for my large sibling 'cause he wouldn't realize this until after the court order etc. A good solution would be BIG fines for mis-encryption and sampling of messages to make sure they were properly formed -- for our own protection, of course. And if they happened to radomly sample something they didn't like... for instance finding my obviously excessive paranoia.... -a2. From gnu at cygnus.com Tue Oct 27 00:24:43 1992 From: gnu at cygnus.com (gnu at cygnus.com) Date: Tue, 27 Oct 92 00:24:43 PPE Subject: Registering Keys with Big Brother In-Reply-To: <199210270553.AA26809@well.sf.ca.us> Message-ID: <9210270724.AA29964@cygnus.com> Arthur Abrahams incisively notes: > Seems to me that there would be a certain amount of trouble with people > registering one private key but communicating with another they had > forgotten to register. Bad situation for my large sibling 'cause he > wouldn't realize this until after the court order etc. A good solution > would be BIG fines for mis-encryption and sampling of messages... There is no need for sampling of messages. You don't understand the theory of power. Simply make the penalty for encryption without registry, larger than the penalty for any other crime. Then no crime can be hidden behind it. It's like getting Al Capone for income tax evasion; if you investigate someone and they are enforcing privacy on their communications, you can put them in jail for life for that, and can stop worrying about the original suspected offense. John From gnu Tue Oct 27 01:31:25 1992 From: gnu (gnu) Date: Tue, 27 Oct 92 01:31:25 PPE Subject: D-H telnet protocol * Cheap secure phones In-Reply-To: <9210221929.AA16268@newsu.shearson.com> Message-ID: <9210270831.AA29372@toad.com> > > (It doesn't protect against > >active re-routing of the call, e.g. by substituting another machine > >for the BBS, but we could work on that as Phase II.) > I would suggest that it be done during phase one. Spoofing attacks are > very important things to guard against, ... Fine, Perry. You do it. I want to get some "easy" protection out there now. Easy often turns out to be six months of work all by itself. > suggest that the protocol be designed so that it does not reveal the > entities forming the link to outsiders (unless one end should > intentionally advertise who it is... This is the intent. The D-H protocol will not reveal any identifying information, and the rest of what is transacted will be protected under the secret key produced by the D-H protocol. > I am very interested in seeing such a protocol standardized because I > have another use for it -- secure telephones. Given modern DSPs to do > and cheap V.32bis modems, excellent secure voice communications are > feasable. There's a "CELP" standard for voice encoding which you can get from the Feds. They used it as an upgrade in STU-III secure phones. It's Federal Standard 1016. It encodes voice at 4800 bits per second with better quality than any known algorithm under 16,000 bits per second (so says the paper on it). If you give it 16 kbits/sec, it is "toll quality". You can get a free copy of the standard, a "technical information bulletin 92-1" entitled "Details to Assist in Implementation of Fed Standard 1016 CELP", and four floppies full of C and Fortran software that implements it, plus test cases, by requesting it from: Office of the Manager National Communications System Attn: NT 701 S. Court House Road Arlington, VA 22204 +1 703 692 2124 Note that this C and Fortran code doesn't run in realtime on workstations; it requires a DSP. But as the "Implementation Details" paper says: "A high-quality, low power, small-sized voice processor can be constructed for under $200 parts cost in small quantities by adding to one of these [TMS320C31, DSP56001] DSP chips: ROM, 16k words of SRAM, and a Texas Instruments TLC32044 A/D and D/A with filters chip." From gnu Tue Oct 27 02:08:56 1992 From: gnu (gnu) Date: Tue, 27 Oct 92 02:08:56 PPE Subject: A Trial Balloon to Ban Encryption? In-Reply-To: <9210261819.AA07688@netcom2.netcom.com> Message-ID: <9210270908.AA00325@toad.com> > I think it was John Gilmore who said: "If encryption is outlawed, only > outlaws will have encryption." Maybe. But I like John Perry Barlow's formulation better: "You can have my encryption algorithm when you pry my cold dead fingers from its private key." John From gg at well.sf.ca.us Tue Oct 27 02:39:00 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Tue, 27 Oct 92 02:39:00 PPE Subject: Alpha Particles and One Time Pads Message-ID: <199210270938.AA27715@well.sf.ca.us> Re Pete's proposal for an on-net random source which could be accessible to users who would then use a psuedo-random process to select which bits to use in compiling cypher keys: What you'll get will be superencipherment, which is no more secure than the links in the chain. The random stream would be non-secure; and so we're left with the security of the psuedo-random selection process. To analogise somewhat, white noise put through a filter has the characteristics of the filter. Try it with FM static and a graphic equaliser. Now to play devil's advocate here, I wonder if a less-than-perfect physical random source would be acceptable, since the potential domain of decryptions would be large enough that unicity in cryptanalysis would in practice be unattainable. What do you think...? From Tom.Jennings at f111.n125.z1.FIDONET.ORG Tue Oct 27 06:25:26 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Tue, 27 Oct 92 06:25:26 PPE Subject: Registering Keys... Message-ID: <3336.2AED0EE9@fidogate.FIDONET.ORG> U> From: 74076.1041 at CompuServe.COM (Hal) U> This proposal to register keys was also mentioned in the U> July, 1992 Communications of the ACM, in an article by Ron U> Rivest, one of the creators of the RSA algorithm. He was U> solution based on 'escrowed secret keys' might be U> workable, wherein each user is legally required to depost U> his or her secret key with a trusted third party, such as U> the user's bank. Actually this sounds signifigantly different from what Denning is allegedly proposing. This method is analogous to the way FFL (Federal Firearm License) holders record transactions of gun sales (I have an FFL). FFL holders are required to record, in detail, each transaction based upon gun serial number/description, and to/from addresses (buy/sell). The FFL holder maintains the records; the feds dont' get a copy. If a gun is used in a crime, the feds go to the manufacturer, and follow the audit trail of FFL records to follow that guns travels. This is *completely* different than a centralized gun database, where a hypothetical they can compile cross indices based upon oh say name or address or whatever. The third party escrow method puts the same sort of restraint upon searches. I'm not saying I particulary like the method, it's just that it's qualitatively different. The BATF cannot rummage through the audit trail of FFL records, they can only follow the forward/backward pointers per gun. Rivest seems to imply there could be many, independent key-escrow locations. A hypothetical we could form our own key escrow, and while we'd be subject to whatever the hypothetical they would require for access, we could probably do things ilke inform members of all key accesses/inquiries, etc. In short, it bothers me a lot less than Dennings. --- ReadMail * Origin: World Power Systems / FidoNews / San Francisco CA (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 Tue Oct 27 07:10:21 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Tue, 27 Oct 92 07:10:21 PPE Subject: Registering Keys with Big Brother Message-ID: <3329.2AECDB78@fidogate.FIDONET.ORG> U> From: efrem at spitha.informix.com (Efrem Lipkin) U> It seems that registration would defeat the advantage U> of a public key system, but it would not prevent private U> encrypted messages from being hidden from casual traffic U> analysis or even notice by public key wrapping. (Hi Efrem!) Yes but. The ole "chilling effect". Everyone talks about ENCRYPTION and SECURITY, what I want is PRIVACY. You can have privacy today, but if you have to sneak around, if privacy is not the background assumption, it gravely limits your ability to live and act freely. Yes, you will always be able to find co-conspirators, but it would be a weak version of the world in which we could presume privacy to begin with. --- ReadMail * Origin: World Power Systems / FidoNews / San Francisco CA (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 pmetzger at shearson.com Tue Oct 27 09:08:54 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Tue, 27 Oct 92 09:08:54 PPE Subject: D-H telnet protocol * Cheap secure phones In-Reply-To: <9210270831.AA29372@toad.com> Message-ID: <9210271539.AA05477@newsu.shearson.com> >From: gnu at toad.com >> > (It doesn't protect against >> >active re-routing of the call, e.g. by substituting another machine >> >for the BBS, but we could work on that as Phase II.) >> I would suggest that it be done during phase one. Spoofing attacks are >> very important things to guard against, ... >Fine, Perry. You do it. I want to get some "easy" protection out >there now. Easy often turns out to be six months of work all by itself. Why should "hard" be that much more difficult? Looks like an extra few days worth of work if you pull all the public key code from PGP. Admittedly, this would be a big project if one couldn't steal existinc dode, but remember, PGP is copyleft. This whole project is a humungous patent violation anyway, so there is no good reason for not stealing code from PGP. Phil's code is bloody good. Anyway, the "easy" protection is probably the "hardest" part. Getting the encrypted link and drivers running properly is the big deal -- thats the code that will take all the time. Its likely marginal cost to design the protocol "right" from the beginning to make it easy to plug in verification later, and being able to use existing public key code to implement it likely removes most of the sting. All you have to do in order to "fix" things is have both sides public key encrypt their D-H exchanges, and suddenly, you have verification of identity. >> suggest that the protocol be designed so that it does not reveal the >> entities forming the link to outsiders (unless one end should >> intentionally advertise who it is... >This is the intent. The D-H protocol will not reveal any identifying >information, and the rest of what is transacted will be protected under >the secret key produced by the D-H protocol. Ah, but if you want to add in a verification layer, you have to be careful to make sure that you don't reveal too much information in doing the verification. >> I am very interested in seeing such a protocol standardized because I >> have another use for it -- secure telephones. Given modern DSPs to do >> and cheap V.32bis modems, excellent secure voice communications are >> feasable. >There's a "CELP" standard for voice encoding which you can get from >the Feds. Well aware of it; I've got sample source code for CELP and all the rest. However, having a standardized bunch of software for encrypting the link will mean that I have that much less to worry about. Perry From hkhenson at cup.portal.com Tue Oct 27 09:21:45 1992 From: hkhenson at cup.portal.com (hkhenson at cup.portal.com) Date: Tue, 27 Oct 92 09:21:45 PPE Subject: Registering Keys with Big Brother Message-ID: <9210270726.1.5339@cup.portal.com> One consequence of this proposal would be the capturing of *all* email traffic for (possible) subsequent decryption under a court order. After all, how could you complain? They couldn't read your messages of the last ten years unless they happened to get a court order. Knowing how easy it is to get a pliant judge to issue an order, this would be really chilling. Keith Henson (on the other hand, the media makers would love it.) From hkhenson at cup.portal.com Tue Oct 27 09:22:00 1992 From: hkhenson at cup.portal.com (hkhenson at cup.portal.com) Date: Tue, 27 Oct 92 09:22:00 PPE Subject: Registering Keys with Big Brother Message-ID: <9210270747.1.5339@cup.portal.com> Eric mentioned that this topic sounds like a recipe for selective enforcement. If all traffic were captured for possible subsequent analysis, they could get you for a noise burst on a communication line. Couldn't decrypt that even with your key. Keith From hughes at soda.berkeley.edu Tue Oct 27 11:57:12 1992 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 27 Oct 92 11:57:12 PPE Subject: list status Message-ID: <9210271856.AA03357@soda.berkeley.edu> As of today, the list stands at 121 members, at least one of which is a mail gateway. Breakdown of the list by top-level domain: U.S. domains: 42 com 42 edu 1 gov 1 mil 10 org 6 us All other domains: 1 at 3 au 1 ca 1 de 2 il 1 nl 2 no 1 nz 1 pt 1 se 4 uk 1 za Eric From clarka at netcom.com Tue Oct 27 12:37:03 1992 From: clarka at netcom.com (Andrew Clark) Date: Tue, 27 Oct 92 12:37:03 PPE Subject: Please remove me from the mailing list / thanks Message-ID: <9210271930.AA19861@netcom.netcom.com> clarka at netcom.com Andrew Clark My ignorance is my own fault. "We have virtual reality today: George Bush lives in it." | Bad cop! "Macs are to computing what television is to journalism." | No donut! Secondary account at aclark at UCSD.EDU -- prefer mail at netcom site. From pmetzger at shearson.com Tue Oct 27 13:24:00 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Tue, 27 Oct 92 13:24:00 PPE Subject: list status In-Reply-To: <9210271856.AA03357@soda.berkeley.edu> Message-ID: <9210271954.AA07709@newsu.shearson.com> >From: Eric Hughes >Breakdown of the list by top-level domain: >U.S. domains: > 42 com > 42 edu > 1 gov > 1 mil > 10 org > 6 us Hmm... Wonder who Mr. .gov and Mr. .mil are... (1/2 :-) Perry From tcmay at netcom.com Tue Oct 27 13:26:24 1992 From: tcmay at netcom.com (Timothy C. May) Date: Tue, 27 Oct 92 13:26:24 PPE Subject: Hackers Conference--Crypto Session Message-ID: <9210272023.AA26749@netcom2.netcom.com> Glenn Tenney, chairman of the Hackers Conference, has asked me to help put together the crypto session at the Conference next week (6-8 November, Lake Tahoe). I of course agreed....our correspondence is attached below. Sorry if I left off your name in my comments to Glenn ...it seems sometimes that nearly everyone I know has some interest in crypology, privacy, cyberspace, AND is going to Hackers! For those not going to Hackers this year, I'd still like your inputs, and I'll write up some kind of update after it's over, so you'll get some feedback on your ideas. This growing interest in cryptology and the protection of privacy--fanned by the availability of PGP 2.0, the books and articles on hackers and crackdowns by the Feds, the activities of the EFF and CPSR, and by our very own "Cypherpunks" crypto group--should make for an extremely interesting time at Hackers this year. Just about every year at Hackers there's a de facto theme. One year it was hypertext (and Xanadu got started when John Walker of Autodesk met Ted Nelson, Mark Miller, Roger Gregory, and others at Hackers in 1987), another year it was multimedia. Last year it was effectively the EFF, and so on. My hunch is that this year the de facto theme _could_ turn out to be crypto tools and digital protection of privacy. In addition to our session, there will be discussions of wireless communication, the work of the EFF, and a Sunday discussion of these critical issues. These will all fit nicely with our own session. Our session is in "prime time," mid-Saturday afternoon, tentatively (you all know how schedules change!), and is one of the "no competitors" tracks, so attendance should be very high. Accordingly, some premium should be placed on organization, to maximize the information flow. Too many people for the "circle discussion" that worked so well at last year's nanotechnology session (run by Ted Kaehler), so we need to figure out a good format. So give me your inputs! (Also, I think we should get togther informally Friday to bounce ideas around, the better to make the session on Saturday richer and more exciting. I'll let you know in the next several days what we decide, and where we'll meet.) * What topics need to be discussed the most? * What format? Panel discussion? A series of mini-lectures on the various topics? Free-for-all discussion? (Remember that we'll probably be in a big room, with perhaps as many as 100-150 attendees.) * Some ideas for topics (which I'll add to as people make suggestions): - A very brief review of modern cryptology (very brief because we need to move on quickly to the juicy stuff), including snapshot summaries of encryption, RSA (but no number theory!), anonymous mail, digital cash, etc. (Too many crypto panels spend the entire time bringing people up to speed on what prime numbers are, on how one-time pads are used, and so on. I favor giving people a good glimpse of the "exciting" stuff--anonymous mail, digital pseudonyms, information markets, dining cryptographers protocols, etc.--and then letting them go back and fill in the background. Give 'em a glimpse of the Promised Land.) - The uses of digital remailers to protect privacy, and progress on building them (a brief summary) - Possible summary of the "Crypto Anarchy Game" we've been experimenting with here in our Cypherpunks group (Note: we could describe it briefly and then invite folks to play it later that evening, perhaps around midnight) - PGP 2.0...what it is, how to get it, and how to use it - Proposed legislation for trapdoors in telephone equipment, and the possibility that crypto keys may be placed under strict controls (a la my recent post on Dorothy Denning's latest trial balloon) - What we can do about these trends, what we as hackers can do to protect our privacy. Things like: deploying encrypted e-mail as quickly as possible, using digital pseuodonyms, deploying "mixes," arguing for basic constitutional protections, etc. Ideally, people will get so worked up and excited that the rest of the Conference will be buzzing about these issues! Here's Glenn's message to me and my acceptance: > > Considering your keen interest in cryptography, I was > > wondering if you could have your arm twisted to help > > pull together the crypto session for the conference? > > > > It should be fairly easy... Let's see, Eric Hughes will > > be there, as will a couple of guys from BellCore (Sternetta > > and ... ??? ). > > > > If so, plesae let me know and I'll pass on some more names. > > > > Thanks much. > > Glenn Tenney > > Of course I'll help. Anything needed, including what you suggest. > > I'm in regular contact with Eric Hughes, John Gilmore, Fen LaBalme, > Hugh Daniel, Keith Henson, and others. I also know Stu Haber, from > Bellcore...if he could speak briefly about digital timestamping of > documents (and Internet mail applicaitions) that would be timely. > > So I'll so whatever I can. > > BTW, I'll forward my latest posting from sci.crypt about proposals to > require all crypto keys to be registered with the government! That, > alone, is worth of a "hacker politics" discussion at Hackers. > > --Tim (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 2.0 and MailSafe keys by arrangement. From pmetzger at shearson.com Tue Oct 27 17:23:08 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Tue, 27 Oct 92 17:23:08 PPE Subject: Threat to our privacy Message-ID: <9210272346.AA11735@newsu.shearson.com> For Cypherpunks: A copy of mail I just sent to... libernet at dartmouth.edu, extropians at gnu.ai.mit.edu, prz at sage.cgd.ucar.edu, mike at eff.org, mkapor at eff.org [This is being sent out to a wide audiance. If you receive this, its because My friends, its rare of me to try to encourage panic. Occassionally, however, by panicing early we can avert a disaster later on. Risks, an internet mailing list, reported about a week ago on a proposal by Dr. Dorothy Denning, one of the most prominent people in the field of cryptography, that copies of all private encryption keys associated with public key cryptographic systems be held, effectively by the government, to permit them to read people's encrypted messages to each other. Naturally, such invasions of privacy will only be permitted "when a warrant is produced". It has been suggested that this idea might be taken up by several government agencies for "review". Many have noted that the dawning of cheap and effective cryptographic systems could spell the end of the ability of governments to invade people's privacy. Unfortunately, it appears that the government and its cronies have also realized this, and intend to take preemptive action. Our notion of civil rights has decayed so far that it is now considered a citizen's duty to not merely be quiet while he is enslaved but to actively cooperate with his own enslavement. Not merely must we put up with the indignity of the government being granted the right to read our papers and communications to each other, not merely has the FBI attempted to get legislation passed to make phone companies give them easier access to tap phone lines under color of "maintaining the current capability in the presense of new technology", but now it is suggested that we ordinary citizens must personally cooperate to make it easier for them to read our communications. We will be branded criminals if we fail to cooperate, presuming that ideas like this are enacted. It is crucial that the fiends proposing this be convinced that resistance will be too high to implement their plan. It is crucial that before they can even propose legislation that the threat here be brought to the attention of the news media. If the currently proposed FBI legislation were passed, a dictatorial government would have all the tools it would need to tap all the phones in the country -- the only thing restraining that behavior would be a system of warrants that could disappear with a mere change in attitude. If Denning's more serious and sinister idea were proposed for future enactment as legislation (this has not yet been proposed), it would become impossible for individuals to take any action to protect their own communications privacy from a dictatorial regime, even ignoring the question of abuses that could occur right now. I'm convinced that the only thing that prevented the FBI bill from passing this year was the fact that media attention was brought to bear. Its important that this new proposal be exposed to similar sunshine. Far be it for me to suggest restraint of free speech, but I would like to see people think of making such suggestions as having the social acceptability of calling a black person "nigger". Here, for reference, is a copy of an article Dr. Denning just posted to sci.crypt on usenet. I encourage people, rather than discussing this matter on libernet or extropians, to discuss this on sci.crypt where the topic is just breaking. Perry Metzger ---------------------------------------------------------------------- Article 6275 of sci.crypt: Path: shearson.com!uunet!uunet!think.com!sdd.hp.com!zaphod.mps.ohio-state.edu!darwin.sura.net!guvax.acc.georgetown.edu!denning From: denning at guvax.acc.georgetown.edu Newsgroups: sci.crypt Subject: Re: A Trial Balloon on Registered Keys Message-ID: <1992Oct27.143737.1574 at guvax.acc.georgetown.edu> Date: 27 Oct 92 14:37:37 -0500 Distribution: world Organization: Georgetown University Lines: 94 The posting about the proposal I made at the NCSC for key registration is essentially correct. Let me add to it the following: 1. The government is not taking any action to curb crypto and is unlikely to take any such action in the near future. No proposal has been made and no government agency that I am aware of has plans to make such a proposal. The closest we've had to a proposal was a "Sense of Congress" resolution in Senate Bill 266 over a year ago. This would not have mandated anything, but said it was the sense of Congress that service providers should provide accesss to the plaintext of encrypted communications under a court order. It got a lot of opposition and was withdrawn. Thus, don't panic folks -- this was just me making a suggestion. I didn't realize I had that much clout to cause such a stir and call to arms! I expect that the next step will be government sponsored discussions about crypto policy, probably sponsored by NIST, at the recommendation of the Computer System Security Advisory Board headed by Willis Ware. That will provide a forum to work through these issues. 2. The reason I made the proposal is because I am concerned that we may be facing a major crisis in law enforcement. I expect many of you will say "that's wonderful" but I don't see it that way. Electronic surveillance has been an essential tool in preventing serious crimes such as terrorist attacks and destabilizing organized crime. The economic benefits alone are estimated to be in the billions. This issue is not about snooping on innocent citizens but about doing what we can do prevent major crimes that could seriously disrupt other liberties. The problem is likely to get even worse if criminals know they use the telecommunications systems without any chance of getting caught. 3. My proposal was to register your private key with a trustee, different from the government. The key would be encrypted under some other public key so the trustee couldn't decrypt it. I have suggested it be the key of the DOJ, but it could be another independent trustee. I believe this would provide acceptably good protection since someone would need to get a court order and then the cooperation of 3 agencies to get at your communications: the telecommunications provider (to get the bit stream), the first trustee (to get the encrypted key), and the second to decrypt it. Experience with the telecom providers has been that they are very fussy about court orders -- you have to get the semicolons right! You can get even more security by using Silvio Micali's "fair public-key cryptosystem" approach. Called "fair" because it is designed to strike a balance between the needs of the Government and those of the citizens. With his approach, you would break your key up into 5 parts and give it to different trustees. All 5 parts are needed to reassemble it, but it is possible to veryify the parts individually and as a whole without putting them together -- ingenious! He presented this at CRYPTO '92. 4. Someone suggested that law enforcement routinely taps without court order. This is an ungrounded claim for which I have never seen any evidence. Regardless, their ability to do this is disappearing with the new digital based technologies. They need the help of the service providers, who in turn ask for court orders. Court orders are not all that easy to get as law enforcers have to document why other approaches have failed etc. 5. Many people have noted that you could not enforce key registration. They may be right, but I am not throwing in the towel yet. Let's take phones, which is what law enforcers are most interested in. Products are emerging that you can attach to your phone and that will do DES encryption. Criminals and everyone else are most likely to use commercial products -- easiest to get and cheapest. The products could be designed so key registration would essentially be part of the sales process. There can be social benefit to government regulation even when regulation is not 100% successful. None of our laws prevent the acts they outlaw. But this does not mean we should get rid of all laws. 6. Some people have said we should not give up our privacy to the government. But the constitution does not give us absolute privacy. We are protected from unreasonable searches and seizures, but not reasonable ones in response to "probable cause" of crime. In all areas of our lives, the government can invade our privacy if they have good reason to believe we are engaged in major criminal activity. They can break into our homes, our safes, and so on. Do we really want a society where electronic communications cannot ever be broken when there is good reason to believe some major threat against society is being planned? Thank you for your comments and for encouraging those on the other news groups to move over to sci.crypt. I'll try to keep up with this newsgroup and respond to other comments if appropriate, but I honestly can't track them all. Dorothy Denning denning at cs.georgetown.edu (posting from guvax) ---------------------------------------------------------------------- From gnu at cygnus.com Tue Oct 27 19:17:46 1992 From: gnu at cygnus.com (gnu at cygnus.com) Date: Tue, 27 Oct 92 19:17:46 PPE Subject: D-H telnet protocol In-Reply-To: <9210271539.AA05477@newsu.shearson.com> Message-ID: <9210280200.AA24003@cygnus.com> > Why should "hard" be that much more difficult? Looks like an extra few > days worth of work if you pull all the public key code from PGP. The project as I plan it, would require no administration on the part of users. Install and forget. If you add authentication, then end-users have keys to deal with, on an ongoing basis. As I said before, you're free to take what I come up with and add authentication. But stop berating me in public for doing something to further the use of cryptography. > This whole project is a humungous > patent violation anyway, so there is no good reason for not stealing > code from PGP. You have made two bad assumptions here. I do not intend to violate any patents, nor do I intend to steal code from PGP. I'll be glad to talk in private about what is happening, but it is not ready for public discussion yet. > All you have to do in order to "fix" things is have both sides public > key encrypt their D-H exchanges, and suddenly, you have verification > of identity. This is not true. I have a preprint of a paper by Whit Diffie that explains how to weave D-H and RSA together so that you can't accept the authentication but be spoofed on the key exchange, or vice verse. It starts with a simple protocol as described above. Known attacks are explained and the protocol is modified to deal with them. The result is now in use in commercial products (secure phones). It's not as simple as it looks. John Gilmore From nobody at soda.berkeley.edu Tue Oct 27 19:18:01 1992 From: nobody at soda.berkeley.edu (nobody at soda.berkeley.edu) Date: Tue, 27 Oct 92 19:18:01 PPE Subject: One-time pads and DC Nets Message-ID: <9210280211.AA19676@soda.berkeley.edu> Regarding the previous discussion about one-time pads, there is another use for disks full of random numbers. They can be used to implement Chaum's DC-nets. For the degenerate case of just two people communicating, the DC-net is similar to using a one-time pad. However, what you are hiding is not _what_ you are sending, but _who_ is sending it. DC-nets ("DC" stands for "Dining Cryptographers", the example Chaum used to introduce the idea) are designed to hide message sources among some group of people. The people have to be fairly well connected, with near-real-time communications capability. It won't really work for people exchanging email. For the simple two-person case, suppose as in the case of the one-time pad that each person has an identical CD-ROM filled with random bits. What they do is, at some predetermined rate, each person just transmits the bits off his pad. Both people are sending the same bits. When one wants to send a message, he starts toggling certain of his bits. To send a "1" he sends the opposite of the next bit from the one-time pad; to send a zero he sends the correct version of the next bit from the one-time pad. Assuming they don't start transmitting at the same time, what an outside observer will see is that, where before they were both producing exactly the same bits, now they are producing a certain number of opposite bits. Interpreting each opposite bit as a 1, and each case of same bits as a 0, produces a recognizable message. But, the outside observer can't tell which person is sending that message. All he sees is two totally random streams of bits, which disagree at certain spots. Without access to the one-time pads, there is no way for him to tell who is sending. (Of course, the two people involved know who is sending, since one of them is and one of them isn't.) Generalizing to larger numbers of people, you need to have a separate one-time pad shared with each other person in the group. In other words, for a group of N people there has to be a total of N(N-1)/2 one-time pads; each person has N-1 of them. That is, for each pair of people in the group, there is a unique and secret one-time pad which they share. (This is for maximal security - you can get by with fewer pads if you trust each other some.) Now, they all send all the time. What they send is the "XOR" of the next bits of all their N-1 one-time pads. It turns out that if you then "XOR" everybody's output bits, you'll get nothing but zeros as a result. When someone wants to send, he sends the opposite of what he normally would for a "1", and he sends just what he normally would for a "0". Collisions can be handled like ethernet - back off and retransmit. (Chaum had another way involving reserving future blocks of transmit time.) With N people sharing N-1 one-time pads per person, nobody can tell who is transmitting. All anyone knows is whether he himself is transmitting or not; all an outside observer knows is that someone in the group is transmitting. DC-Nets eat up one-time pads even worse than using them for message secrecy does. But, with CD's, you can put a lot of data on a pad. And the system is fairly robust against pads being stolen. If one person's one-time pads are all secretly copied by a spy, then he can tell if that person is sending. But he learns absolutely nothing about which other people are sending. I wonder if it would be possible to experiment with a DC-Net system in the Internet environment. I recently acquired an account on a system with Internet connectivity (I know because I can telnet and ftp from it). I've done considerable programming with Unix socket communication in systems connected by ethernet, and I think the Internet provides a very similar programming interface. It shouldn't be that hard to create a very simple "chat" program in which message sources are strictly anonymous (assuming the existance of the required one-time pad random-number files - for testing, they could be created by random number generators at each end, started with identical seeds). I'll try some experiments along these lines over the next few days. Hal 74076.1041 at compuserve.com From Tom.Jennings at f111.n125.z1.FIDONET.ORG Tue Oct 27 19:45:14 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Tue, 27 Oct 92 19:45:14 PPE Subject: Hackers Conference--Crypto Session Message-ID: <3344.2AEDFD5B@fidogate.FIDONET.ORG> U> From: tcmay at netcom.com (Timothy C. May) U> asked me to help put together the crypto session at the U> Conference next week (6-8 November, Lake Tahoe). I of I consider it my job in the email world yto point out that the real problems are not technical, but social, and a discussion of privacy/crypto without underlying social stuff (how we interact, legal issues like liability, etc) will devolve into technophilia. Yes I'm volunteering. I'll write something up before Hackers. --- ReadMail * Origin: World Power Systems / FidoNews / San Francisco CA (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 tcmay at netcom.com Tue Oct 27 20:06:05 1992 From: tcmay at netcom.com (Timothy C. May) Date: Tue, 27 Oct 92 20:06:05 PPE Subject: Messages in the Least Significant Bits Message-ID: <9210280303.AA21744@netcom2.netcom.com> Cypherpunks, Here's a message I just posted to another mailing list. It has rather strict policies against cross-posting, so I've edited out the headers and the initial chunk of text I quoted. That should make me kosher. (This topic also came up in some e-mail with George Gleason.) Forwarded message: From pmetzger at shearson.com Tue Oct 27 22:34:58 1992 From: pmetzger at shearson.com (Perry E. Metzger) Date: Tue, 27 Oct 92 22:34:58 PPE Subject: D-H telnet protocol In-Reply-To: <9210280200.AA24003@cygnus.com> Message-ID: <9210280519.AA17075@newsu.shearson.com> >From: gnu at cygnus.com >As I said before, you're free to take what I come up with and add >authentication. But stop berating me in public for doing something >to further the use of cryptography. I'm not berating. I'm just suggesting. I understand your reasoning about not wanting users to need to do any administration, and I also understand your desire to do something good for the crypto community. I will not argue that its a bad thing. The only provisio I make is that it is SO easy to spoof exponential key exchange that I'd argue that providing authentication is crucial if people aren't going to be lulled into a false sense of security. Perry From tcmay at netcom.com Tue Oct 27 23:23:28 1992 From: tcmay at netcom.com (Timothy C. May) Date: Tue, 27 Oct 92 23:23:28 PPE Subject: One-time pads and DC Nets Message-ID: <9210280620.AA04910@netcom2.netcom.com> "Nobody" writes about the dining cryptographers protocol. We talked about it at length at our first face-to-face meeting, but the subject has barely come up on this list. People should read the Chaum articles in the handout, and the excellent tutorial by Jurgen Bos, also in the handout. It is truly exciting stuff, much more so than the usual "classical cryptography" that we mostly talk about here on this list. Part of my great concern about the public key registration proposal is that it will, if enforced, kill off many of these approaches that rely on dynamically changing keys and digital pseudonyms. If there's interest out there in the DC Net approach that "Nobody" so nicely summarized, I'll forward some articles I wrote a while back for another list. --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 2.0 and MailSafe keys by arrangement. -- .......................................................................... 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 2.0 and MailSafe keys by arrangement. From mark at coombs.anu.edu.au Wed Oct 28 18:09:15 1992 From: mark at coombs.anu.edu.au (Mark) Date: Wed, 28 Oct 92 18:09:15 PPE Subject: How far would this extend... Message-ID: <9210290109.AA29045@coombs.anu.edu.au> With regard to the FBI bill, the definition of electronic communication provider is rather vague IMHO. It seems to cover a BBS, any unix site (or equiv) etc. (I deleted the article so I cant quote it) Anyway if the above is true will this mean all machines that electronic communication traverses have to have a 'backdoor' so the gov can sit in their offices and run through the mail spool as root? :) Or log into any BBS and do the same? There hasnt been any talk of it as such, probably because they can do it fairly easily anyhow, but it just seems like another loophole in their (the FBI's) favour. _Sometimes_ I'm glad Im an aussie. Mark From tcmay at netcom.com Wed Oct 28 18:24:57 1992 From: tcmay at netcom.com (Timothy C. May) Date: Wed, 28 Oct 92 18:24:57 PPE Subject: (fwd) Registering "Assault Keys" Message-ID: <9210290008.AA29345@netcom2.netcom.com> Cypherpunks, Things have gotten truly exciting. The posting I made alerting sci.crypt readers to the plans of the Crypto Establishment has generated something close to a hundred responses! And lots of private mail for me (moral support, questions, etc.). Dorothy Denning, in what writer correctly called a "spirited defense" of her proposal, acknowledged the truth of my posting and then went on to embellish her plan. I urge you all to read her well-written comments, if only to see how the Establishment views crypto technology. Several members of this list have also written cogent comments. My latest article is included below, for those of you who may not have Net access. Newsgroups: sci.crypt,comp.org.eff.talk,alt.privacy,talk.politics.guns Path: netcom.com!tcmay From: tcmay at netcom.com (Timothy C. May) Subject: Registering "Assault Keys" Message-ID: <1992Oct28.235027.28039 at netcom.com> Organization: Netcom - Online Communication Services (408 241-9760 guest) X-Newsreader: Tin 1.1 PL5 Date: Wed, 28 Oct 1992 23:50:27 GMT Registering "Assault Keys" -- How the Proposal to Register Encryption Keys Has Ominous Parallels to Gun Control The recent proposal that encryption keys be registered with the government has some natural and terrifying implications. (For those to whom this proposal is new, strange, or disturbing, please see the debate raging mainly in the newsgroup "sci.crypt".) Once the principle is established that private communications, letters, faxes, modem transmissions, etc. must be in a form readable--under court order, as Dorothy Denning's proposal goes--by the government, and that "public key encryption" keys must be registered with the authorities, then we can expect the following: * _Classes_ of encryption keys, with some especially strong (in a cryptograhic sense) keys being declared "assault keys," just as certain classes of semiautomatic rifles have been branded "assault weapons" and subjected to media villification and even confiscation by the authorities. In analogy with firearms, there may be "Class 1" dealers in "dangerous" keys. * There may even be _bans_ on the registration (and hence use) of certain classes of algorithms and key lengths. For example, "civilians" may be allowed to use DES, but not RSA. Or the key length may be restricted in various ways. * Strict controls over the types of algorithms allowed. After all, what use will a key be if the government can't run the algorithm? This, by the way, will be another way to control the spread of encryption technology: if only licensed, inspected, and approved algorithms are acceptable to the key registration authorities, innovation and experimentation will suffer. This may make RSA Data Security, Inc., very happy, as it may get the "franchise," while users of bootleg/contraband/experimental algorithms like PGP 2.0 ("Pretty Good Privacy") face severe sanctions. * Spot checks will have to be done to ensure compliance. This may be done in various ways, such as by randomly checking bitstreams and demanding the sender open the message. (Note: Many have posted that this would not be possible. Untrue. The Rehnquist Supreme Court ruled a couple of years ago that the police could enter a bus and ask the passengers to "voluntarily" accept a search of their baggage. Failure to volunteer, so reasoned the court, constituted probable cause for a search! "Catch-22" meets "1984.") * The penalties for noncompliance, or for hiding encrypted messages inside other messages, will likely be severe, else widespread civil disobedience and claims of "ignorance" will result. (Personally, I _expect_ widespread noncompliance. Many people will even flaunt their noncompliance, encrypting truly innocuous messages that few courts, they will hope, will convict them for. Here in California, the noncompliance rate for registration of those evil "assault weapons" is estimated to be as high as 80%.) (My best guess is that the "RICO" (Racketeer-Influenced and Corrupt Organizations Act) and civil forfeiture approaches will be used to simply seize the equipment of anyonone caught sending messages without the suitable seals of approval. Such seizures, used with suspected gun sellers, suspected X-rated video sellers, suspected drug dealers. and so on, have had a profoundly chilling effect.) * A registration system, even if well-intentioned and secured against casual government snooping (and some of the multi-party escrow systems may help do this), will still _greatly complicate_ the use of encryption and will forestall certain very exciting applications of cryptology. Many of the new proposals, for things like anonymous credentials to protect privacy, for digital cash, and for cryptographic voting systems, essentially require the _dynamic_ generation of keys! That is, keys are generated frequently as part of the protocols...there is not single static "public key" that one generates once and then takes down to the crypto equivalent of the DMV for registration. * As with guns, true criminals will of course ignore these laws. Computer networks are already being used for messages that evade wiretaps (as one example, a Mafia guy in New Jersey, on the run, used a well-known computer service to communicate untraceably with his wife), that are used for laundering information and money, and so on. Taking encryption away from citizens will do nothing. I urge readers to get involved in this debate. "If encryption is outlawed, only outlaws--and the NSA--will have encryption." -- .......................................................................... 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 2.0 and MailSafe keys by arrangement. From tcmay at netcom.com Wed Oct 28 19:42:40 1992 From: tcmay at netcom.com (Timothy C. May) Date: Wed, 28 Oct 92 19:42:40 PPE Subject: National Security Agency Message-ID: <9210290239.AA08764@netcom2.netcom.com> Cypherpunks of the world, encrypt! Enclosed below is a posting I made to debunk Denning's claim that the proposed key registration is needed to thwart criminals. P.S. I still need more comments on how the Hackers session on crypto should go. I've gotten some good private e-mail, but little debate here on the list itself. --Tim Newsgroups: sci.crypt,comp.org.eff.talk,alt.conspiracy Path: netcom.com!tcmay From: tcmay at netcom.com (Timothy C. May) Subject: Re: A Trial Balloon on Registered Keys Message-ID: <1992Oct29.022842.8177 at netcom.com> Organization: Netcom - Online Communication Services (408 241-9760 guest) X-Newsreader: Tin 1.1 PL5 References: <1992Oct28.214920.15601 at tessi.com> Date: Thu, 29 Oct 1992 02:28:42 GMT Some comments about the National Security Agency (NSA) and why it wants to restrict wide use of encryption. George Mitchell (george at tessi.com) wrote: : Now it's my turn to go out on a limb. I believe that all the parti- : cipants in this discussion would agree that: When the Government : can show, through legitimately obtained evidence, that a particular : encrypted communication relates to a crime, then they can, after : the fact, subpoena the plaintext of that communication. What : most of us object to is having to yield the keys before the fact. Agreed. The current procedure for subpoenaing documents works fairly well. But Prof. Denning's comments clearly indicate the concern is with catching terrorists, kidnappers, subversives, and other such types _in the planning stage_. That is, wiretapping and surveillance. And I'll got out on a limb, too. My suspicion, and that of many others, is that the case of the FBI catching terrorists before the act in the U.S. (and there's a well-known case of a Japanese Red Army terrorist caught in the Midwest several years ago) reveals the sources the FBI uses. The NSA is the likely source. Only the NSA listening in on millions of telephone conversations (not banned by any law...the laws you hear about on wiretapping and surveillance mostly deal with the FBI, law enforcement, and, supposedly, the CIA. The NSA is almost completely exempt from such laws.). If you haven't yet read James Bamford's "The Puzzle Palace," run out and get a copy and read it. You'll see why former DIRNSA General Odom called Bamford "an unindicted felon." (Why in the eyes of the National Security Establishment, that is.) SIGINT OPERATION MINARET, begun in 1969 when Nixon declared the "War on Drugs," brought the NSA together with the FBI, CIA, BNDD (Bureau of Narcotics and Dangerous Drugs, precursor to DEA) to launch a series of new surveillance programs. In May 1970 the NSA extended routine surveillance to _pay phones_ in suspect areas (sound familiar, with the Digital Telephony Bill?). The release of the Pentagon Papers in 1971 revealed the extent of FBI and NSA elsur (electronic surveillance) on U.S. citizens. OPERATION SHAMROCK goes back even further. Beginning in 1945, the FBI and NSA (its precursors, actually, such as Army Signal Corps, etc.) cooperated to monitor dissidents, radicals, authors, etc. It was not until October 1973 that about-to-be-fired Attorney General Elliot Richardson (now fighting for INSLAW in a very similar case, which Prof. Denning ought to read about) ordered the FBI and the CIA's "Security Service" (aptly named SS) to stop requesting NSA surveillance material. In 1977 the Justice Department recommended against prosecution of the FBI and NSA employees engaged in Shamrock and Minaret. Few Americans understand how pervasive is the NSA's listening system. COINTELPRO, Huston Plan, RCA Global (provided copied of all telegrams for 40 years!), FINCEN, and so many other keywords! Huge antennas in West Virginia, in Idaho, and elsewhere (mostly located near major satellite downlinks). Read Bamford's book. Then be afraid....be _very_ afraid. Understand that there are virtually no laws governing the NSA's surveillance of fax machines, modems, the Internet (including all of these postings, obviously), voice phones, telex and TWX, and on and on. Because of the "national security" role, wide lattitude is given. No doubt some criminal plans are uncovered. The NSA detected, it has been admitted, the planned bombing of the Berlin discotheque that led to the '86 raid on Libya. (However, the bombing still occurred...draw your own conclusions.) But is it worth the price? Now there is talk of using the NSA's formidable listening abilities for economic espionage against our economic opponents! Is it any wonder the NSA is scared sh..less over the spread of secure and untappable communications systems? Be afraid, be _very_ afraid. -- .......................................................................... 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 2.0 and MailSafe keys by arrangement. From shipley at tfs.COM Thu Oct 29 01:33:13 1992 From: shipley at tfs.COM (Peter Shipley) Date: Thu, 29 Oct 92 01:33:13 PPE Subject: speaking of data on music CD's Message-ID: <9210290832.AA21734@edev0.TFS> speaking of messages that can be passwd on musical CD's, I thought this might be of some amusement -Pete ------- Forwarded Message Return-Path: cambler at nike.calpoly.edu Received: by ts2.TFS.COM (5.51/1.00 (TRP - mailsrv)) id AA27917; Tue, 27 Oct 92 03:00:31 PST Received: from zeus.calpoly.edu by tfs.COM (5.61/1.00 (TRP - gateway)) id AA04680; Tue, 27 Oct 92 03:00:21 -0800 Received: by nike.calpoly.edu (5.61-AIX-1.2/1.0) id AA167170; Tue, 27 Oct 92 03:00:19 -0800 Date: Tue, 27 Oct 92 03:00:19 -0800 From: cambler at nike.calpoly.edu (Christopher J. Ambler, Phish) Message-Id: <9210271100.AA167170 at nike.calpoly.edu> To: shipley Subject: Re: laser Here, check this out: Okay, here's the scoop. At the end of the new Information Society CD, there's a 3 minute track (track 12) that's called "300BPS N81" ... Well, I was curious, so I hooked the thing up to a phone line here, tied my modem's carrier detect high, and played with the gain. After 4 or 5 tries, THIS IS WHAT I GOT. - --- begin ath1 OK ato CONNECT 300 SO WE'RE SUPPOSED TO PLAY IN CURITIBA IN 18 HOURS, BUT OUR BUS IS BEING HELD HOSTAGE BY THE LOCAL PROMOTERS. THEY'VE FORMED SOME UNHOLY ALLIANCE WITH THE BRAZILIAN COUNTERPART OF ASCAP; THE PRS. APPARANTLY THE PRS HAS THE LEGAL POWER TO ARREST PEOPLE, AND THEY WANT A PIECE OF THE NATIONAL TOUR PROMOTER'S MONEY. THE LOCAL SECURITY FORCE, "GANG MEXICANA", HAS BEEN BOUGHT OUT FOR 1800 CRUZADOS AND A CARTON OF MARLBOROS EACH. THE ONLY FACTION STILL OPERATING IN OUR DEFENSE IN "BIG JOHN", OUR PERSONAL SECURITY MAN, AND HE'S HIDING IN HIS ROOM BECAUSE A LOCAL GANG IS OUT FOR HIS BLOOD BECAUSE OF A 1982 KNIFING INCIDENT IN WHICH HE WAS INVOLVED. OUR 345-POUND ROAD MANAGER, RICK ONLY HAD THIS TO SAY: "YOU WANTED THE LIFE OF A ROCK STAR!". PAUL, JIM AND I REALIZED THAT THIS WAS ONE SITUATION WE WERE GOING TO HAVE TO GET OUT OF OURSELVES. WE CONVENED A HASTY CONFERENCE IN THE NOVOTEL LOBBY. PAUL SUGGESTED CONTACT- ING OUR NATIONAL TOUR PROMOTER IN SAO PAULO, BUT WE REMEMBERED THAT HE WAS IN RECIFE WITH FAITH NO MORE, WHO HAD JUST ARRIVED FOR THEIR BRAZILIAN TOUR. WE THOUGHT ABOUT CONTACTING OUR BRAZILIAN RECORD COMPANY IN RIO, BUT THEY WEREN'T HOME. OUR EVER-DILIGENT AMERICAN MANAGER WAS ARRANGING HELP OF NUMEROUS FORMS, BUT HE WAS IN NEW YORK, AND JUST TOO FAR AWAY TO GET ANYTHING MOVING IN TIME. AND THERE WERE 6000 KIDS IN CURITIBA WHO JUST WOULDN'T UNDERSTAND. WE KNEW IT WAS TIME FOR ACTION. PAUL WENT UP TO THE PRS GUYS AND INVITED THEM INTO THE BAR TO DISCUSS IT LIKE CIVILIZED MEN OVER A FEW BRAZILIAN DRINKS, OFFERING EACH OF THEM A CIGAR ON HIS WAY. THE AMUSED PRS HEAVIES SEEMED TO LIKE THE IDEA OF A FEW FREE DRINKS, EVEN IF THEY KNEW THEY WOULD NEVER GIVE US OUR BUS BACK. WHEN PAUL WINKED AT JIM AND I ON HIS WAY IN, WE WENT INTO ACTION. I STOLE OFF TO MY ROOM TO PREPARE WHILE JIM WENT INTO ACTION. CREEPING CAREFULLY THROUGH A SERVICE DUCT, HE MANAGED TO GAIN A VANTAGE POINT SOME THREE METERS ABOVE THE BUS, AND DROPPED CAREFULLY ONTO THE ROOF. AFTER USING HIS ALL-PURPOSE SWISS ARMY KNIFE (AFFECTIONATELY KNOWN AS THE "SKIT KNIFE") TO JIMMY OPEN THE ROOF HATCH, HE WENT THROUGH THE DARKENED INSIDE OF THE BUS AND REMOVED THE INSIDE ENGINE SERVICE PANEL. USING SOME SPARE ELECTRONIC PARTS HE FOUND WHILE ON AN ISLAND IN THE AMAZON, HE WIRED THE ENTIRE BUS FOR REMOTE CONTROL, NOT UNLIKE A REMOTE CONTROL TOY CAR. AT THIS POINT, HE ASKED HIMSELF "NOW HOW SHALL I GET OUT OF HERE?!?" PAUL WAS HAVING DIFFICULTIES OF HIS OWN. "COULDN'T YOU SEE YOUR WAY CLEAR TO LETTING US FULFILL OUR CONTRACTUAL OBLIGATIONS IN CURITIBA? THINK OF THE KIDS!" THROUGH OUR TRANSLATOR, FABIO, THE PRS MAN, ALDO, SAID; "NO. YOU AMERICANS THINK YOU OWN THE WORLD. HAH! WE'LL BURN DOWN OUR RAIN FOREST IF WE DAMN WELL PLEASE. WE NEED ROOM FOR COWS!! WE WANT A MACDONALD'S ON EVERY... OH, SORRY, YES ANYWAY, NO. WE NEED 40% OF YOUR CONCERT RECEIPTS TO GIVE TO DAVID BOWIE." HE SAID, WINKING TO THE LOCAL PROMOTER, PHILLIPE. AS PAUL CONTINUED THIS ELABORATE DISTRACTION, JIM EFFECTED AN ESCAPE FROM THE HEAVILY GUARDED BUS BY CRAWLING DOWN INTO THE CARGO BAY, CUTTING A HOLE IN THE FLOOR WITH THE SWISS ARMY KNIFE'S ARC-WELDER, SLIPPING INTO THE MANHOLE COVER SITUATED UNDER THE BUS, AND WALKING UP INTO THE HOTEL'S BASEMENT FROM THERE. JIM CALLED UP TO ME IN MY ROOM AND GAVE THE SIGNAL. WE WERE NOW TO MEET AT THE BACK ENTRANCE, WITH OUR TECH GUYS. BUT FIRST, PAUL WOULD NEED SOME HELP GETTING AWAY FROM HIS UNWELCOME GUESTS, AS THINGS WERE GETTING UGLY. "HE SAYS HE HAS LOST HIS PATIENCE, AND THAT HE CAN THINK OF OTHER WAYS OF EXACTING PAYMENT FROM YOU KURT AND JIM PHYSICALLY." OUR TREMBLING INTERPRETER SAID. THE MOMENT HAD COME. JIM BEGAN OPERATING THE BUS FROM HIS BACK ENTRANCE VANTAGE POINT. AS THE REMOTE-CONTROLLED BUS LURCHED TOWARDS THE PARKING LOT EXIT, THE SUPERSTITIOUS SECURITY YOUTHS FLED IN TERROR. PAUL WAS PULLING ANXIOUSLY ON HIS COLLAR AS THE PRS MAN BEGAN DESCRIBING HIS COLLECTION OF WORLD WAR II NAZI CERIMONIAL KNIVES WHEN A SUDDEN CRASH SPLIT THE TABLEAU. JIM HAD PURCHASED ME THE GIFT OF A COMPLETE BLACK NINJA STEALTH ASSASSIN OUTFIT IN ARACAJU. I HAD BEEN GEARING UP AND CRAWLING THROUGH THE AIR CONDITIONING DUCTS ALL THIS TIME. AS I CRASHED THROUGH THE CHEAP IMITAION- STYROFOAM HUNG CEILING TILES, SKATES FIRST, I FLASHED NINJA STARS ALL ABOUT ME. IN THE ENSUING PANIC, PAUL ESCAPED TO THE PRE-ARRANGED BUS PICK-UP POINT. UNFORTUNATLEY, MY SKATES WERE A POOR CHOICE OF FOOT GEAR FOR ESCAPING OVER THE BROKEN GLASS. OF THE TABLE I HAD LANDED ON. WERE IT NOT FOR THE CONFUSION AND THE NINJA-STAR-INFLICTED WOUNDS DELIVERED TO THE BAD GUYS, I WOULD HAVE BEEN SET UPON WHILE FOUNDERING ON THE GLASS-STREWN CARPET. AS IT HAPPENED, HOWEVER, I LEAPT THROUGH THE OPEN DOOR OF THE CAREENING BUS AS IT DEPARTED THE CITY OF MARINGA FOREVER. IF ONLY WE HAD MANAGED TO GET OUR EQUIPMENT IN THE BUS, TOO . . . EVERY WORD OF THIS STORY IS TRUE. - KURT HARLAND} NO CARRIER ------- End of Forwarded Message From tom.jennings at f111.n125.z1.FIDONET.ORG Thu Oct 29 14:26:42 1992 From: tom.jennings at f111.n125.z1.FIDONET.ORG (tom jennings) Date: Thu, 29 Oct 92 14:26:42 PPE Subject: drugs for sale Message-ID: <3373.2AF03157@fidogate.FIDONET.ORG> A cross posting from FidoNet PUBLIC_KEYS. It would be nice if some other cypherpunks could join the PUBLIC_KEYS echo. ;Date 29 Oct 92 11:28:07 From: Jesse David Hollington at 1:125/33 To: Arol Ambler at 1:125/111 Subject: Test >----------------------- Do not change this line -----------------------------< AA> Anyway, anyone who is concerned can always use some method that hides the AA> fact that any secret content is even being communicated. (Variations on AA> read every fifth word to see the real message, or other standard AA> methods). It's funny you should bring that up. One of the major proponents of encryption here in Region 12 posted the following in the Regional Sysop Echo some time ago... ============================================================================= Having said that, I also wonder whether this insistence upon having everything in plain text isn't fostered by some sysops as a means of receiving information that they otherwise wouldn't be privy to. If one is truly paranoid ( *not* that I would fall into that category in anyone's wildest dreams...ahem), one should worry about why some netmail is read so assiduosly by passthrough systems in the first place. Fortunately, even mail that I send direct to nodes is quoted back and often passes through a whole variety of systems for their inspection and review. Since almost all of my netmail is incredibly innocent there might always be the possibility that some of it will come back to hover like a bad dream in some creative complaint. In broader legal terms, every other communication system avoids eavesdropping on mail. P.S. To understand how powerless you are to prevent encrypted text, read the leftmost letter of each sentence in the last three paragraghs downwards...ahem. =========================================================================== He raises a valid point. Sysops who are so paranoid about encrypted mail being sent through their systems should realize that they are really powerless to prevent it if somebody is determined enough to send a coded message to somebody else. I've sought legal opinions in Canadian law (I don't know how it is in the U.S.) and I've discovered that the less I know about mail passing through my system, the safer I am. If I keep every message on my system, and read them all, then I can be held liable if somebody routes something illegal through my system and it slips by me. If I kill all passthrough mail, and read nothing except what is addressed to me, I am operating under common carrier status, and can't be held liable any more than Federal Express or UPS could. As a result, it's actually better to *encourage* people to send encrypted mail through your system. The belief that if people are sending encrypted mail they're doing something wrong is a fallacy... then again, I'm preaching to the converted here. Cheers, Jesse. --- Maximus 2.01wb * Origin: On a Clear Disk You Can Seek Forever (1:225/1) -- 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 tomj at f111.n125.z1.FIDONET.ORG Fri Oct 30 02:00:19 1992 From: tomj at f111.n125.z1.FIDONET.ORG (tomj) Date: Fri, 30 Oct 92 02:00:19 PPE Subject: PUBLIC_KEYS pre-Backbone topology Message-ID: <3383.2AF0F94F@fidogate.FIDONET.ORG> Here's a nerd message from PUBLIC_KEYS echo conference showing activity and growth. This conference has been around about three weeks. GLOSSARY: node host conference newsgroup echo newsgroup message article 1:222/333 FidoNet address (ie. host site address) backbone a somewhat formal high-throughput systems that carry a large proportion of echos. Only very popular echos are carried on the backbone; low traffic ones the member sites deliver their own mail (we don't ahve corp. sugardaddies like most internet/uucp sites, I pay Pac Bell each month...) The hideous unreadable gunk is a sort of 'traceroute' of generated message traffic during some period of time, and tends to show the topology. Echomail is a completely distributed, redundant database. Moderation is not physically possible (there is a thing called groupmail that is, but we're not using it). It shows who connects to whom. There is at least one human reader/poster at each node (the sysop); my guess would be about 1.5 average for this subject. Why did I mail this to cypherpunks list? To show the amount of interest in PGP, and demystify FidoNet somewhat. here's the current report from msgs posted here: PATHS: Maintain and report PATHS a message takes within an echo Copyright (C) 1991, Graham J Stair. All rights reserved. Release 1b for DOS (16th June 1991, 15:59) {-? for help} Message directory : \msg\pkey\ Checked on : Sat Oct 24 18:13:40 1992 Number of nodes : 53 Number of messages : 778 Earliest message : Sat Oct 03 20:04:12 1992 Latest message : Sat Oct 24 17:06:42 1992 Messages per week : 260.9 1:374/14 (180 of 774) |-}1:374/26 (44 of 53) | |-}1:322/603 (5 of 5) | |-}1:374/12 (1 of 1) | |-}322/6 (4 of 4) |-}1:216/21 (32 of 53) | |-}216/80 (0 of 21) | |-}273/219 (0 of 3) | | |-}1:273/219.4 (1 of 1) | | |-}1:273/937 (1 of 1) | | |-}1:273/219.1 (1 of 1) | |-}1:143/269 (18 of 18) |-}1:374/98 (3 of 6) | |-}1:374/46 (3 of 3) |-}1:100/520 (11 of 11) |-}1:285/27 (26 of 44) | |-}30102/20 (18 of 18) |-}1:170/109 (18 of 18) |-}1:105/36 (20 of 39) | |-}1:105/68 (6 of 6) | |-}1:105/290 (13 of 13) |-}135/71 (0 of 19) | |-}1:135/907 (19 of 19) |-}1:396/1 (5 of 8) | |-}203/23 (0 of 2) | | |-}125/125 (0 of 20) | | |-}125/20 (0 of 11) | | | |-}1:125/209 (8 of 8) | | | |-}1:125/54 (3 of 3) | | |-}1:125/33 (1 of 9) | | |-}1:308/60 (8 of 8) | |-}109/25 (0 of 1) | |-}1:2601/100 (1 of 1) |-}1:234/1 (40 of 40) |-}1:377/14 (56 of 78) | |-}1:377/3 (19 of 19) | |-}377/15 (0 of 2) | | |-}1:377/15.1 (2 of 2) | |-}1:377/33 (1 of 1) |-}163/438 (3 of 9) | |-}1:163/518 (3 of 3) | |-}1:243/3 (3 of 3) |-}1:125/180 (54 of 112) | |-}1:125/111 (38 of 38) | |-}1:125/185 (2 of 2) |-}1:2200/101 (2 of 2) |-}1:135/340 (52 of 52) |-}1:312/2 (16 of 16) |-}1:106/7550 (33 of 33) |-}2:253/513 (2 of 2) |-}1:261/1136 (1 of 1) |-}374/92 (0 of 1) |-}374/13 (0 of 1) Notes: If a node does not appear in this report, it could mean... a) It did not have a message entered from it. b) It did not have a message pass through it to get to the top node. c) Its mail processor doesn't update the ^APATH: kludge with its address. If any feeds change, the report will be unreliable. [converted from high ASCII lines to low ASCII characters by CONV004.ZIP] -30- if we show up in FIDONET.NA tomorrow, everyone stand-by to switch over to Backbone feeds. this ALWAYS take a couple weeks to settle down. cut your direct links as soon as you get confirmation of link from your Backbone source. if you don't get confirmation first, you will probably miss traffic as the Backbone doesn't do rescans. we will get a few dupes. this is inevitable with a private to Backbone changeover and no one should get excited about it. just be sure to pull your direct plug as soon as traffic flows from your Backbone source or you get confirmation of feed, whichever comes first. thanks. TTFN. Chris --- DB 1.50/001027 * Origin: Rights On! - Privacy #1 Right! - Titusville_FL_USA (1:374/14) SEEN-BY: 106/1555 109/25 124/1 125/20 28 33 111 125 180 185 1212 170/610 203/1 SEEN-BY: 203/23 205/10 209/209 374/14 396/1 ;;; -- tomj - via FidoNet node 1:125/555 UUCP: ...!uunet!hoptoad!kumr!fidogate!111!tomj INTERNET: tomj at f111.n125.z1.FIDONET.ORG From edgar at spectrx.Saigon.COM Fri Oct 30 12:02:40 1992 From: edgar at spectrx.Saigon.COM (Edgar W. Swank) Date: Fri, 30 Oct 92 12:02:40 PPE Subject: Subscribe Message-ID: I got this address off Extropians. Sorry if there's a separate "request" address I should be using, but I don't know what it is. Please add me to your mailing list. Please use one of these addresses: Internet: edgar at spectrx.saigon.com UUCP: szebra!spectrx!edgar The address in the network header may not work. I'm familiar with how PGP 2.0 works, including some bugs. I'm trying to start a low-cost public key registry, which can verify public keys independent of the network. Here is my signed 512-bit public key: -----Type bits/keyID Date User ID -----pub 512/4F0C47 1992/09/26 Edgar W. Swank -----sig! 67F70B 1992/10/14 Philip R. Zimmermann -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.02 mQBNAirEvxwAAAECAMUkLHrx6JH45BMd4bxZDNQO3HrLmhZSvsHJzLH9+90BTbuX 3Kvo0pSLCh98m2Abu/LtoHDggJOKxRGee+5PDEcABRG0KUVkZ2FyIFcuIFN3YW5r IDxlZGdhckBzcGVjdHJ4LnNhaWdvbi5jb20+iQCVAgUQKtu1h+J13g7/Z/cLAQFg nAQAjRlKmmSvDMZUWKM2BQFmpqHBiaCg7OLKEFng9pZGx2qzYHCZOL+a9A0exN9P RAtV6bEm9+F8VoOEpVyF346XJwwE1e/13IETHFi7Jd9fbjsw8voQFqz69X2p8xoE LxYtqSlwfOQ3S7JOyyx4/p04fG/JZuRJicVaUIRlDKHJPJ0= =tsbS -----END PGP PUBLIC KEY BLOCK----- -- edgar at spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca From tcmay at netcom.com Fri Oct 30 15:23:43 1992 From: tcmay at netcom.com (Timothy C. May) Date: Fri, 30 Oct 92 15:23:43 PPE Subject: Why I Don't Use PGP Message-ID: <9210302106.AA22149@netcom2.netcom.com> Why I Don't Use PGP -- The Top 10 Reasons (from the David Lettercrypt Show) (...drum roll...) 10. Because I use a Mac and the Mac version is not out yet. 9. Because the Mac version may NEVER be out. 8. Because my old IBM PC won't read the 3.5" diskettes my Mac puts out. 7. Because downloading encrypted files with ZMODEM, writing them to DOS format (with Apple File Exchange), hauling out my Toshiba 1000SE laptop and firing it up, loading the 3.5" diskette, and then running PGP takes 5 minutes per message. 6. Because after doing all of the above, I usually get "This is not a PGP file," due to some obscure mistranslation somewhere along the way. 5. Because I barely have the time to read and respond to my ordinary e-mail, let alone decrypt mail, respond (on my DOS machine), and then reverse the above procedure. 4. Because I'm not yet convinced it is needed. It will be someday, but not for right now. (Getting PGP volume up is a great idea...it's the actual decryption that's a pain. Maybe we ought to send dummy messages.) 3. Because ideally our mailers should handle this in a push-button way (I know about the security flaws in having a nonlocal host machine, such as my NETCOM host, do the PGP procedure...I am hoping that someone will write something that transparently "reaches down" into my machine and triggers the computation locally on my machine--and I need a Mac version, of course. Probably an off-line Newsreader for the Mac, like Nuntius, is needed.) 2. Because I don't give out my PGP key (generated on my Toshiba) to all of those who have e-mailed me about it (especially in the wake of my postings about the Denning proposal). The last thing I want is more e-mail from people I've never met, sending me their encrypted secrets of the universe. (...and the Number One reason I don't use PGP?.....) 1. Because computers were supposed to make my life easier, and they haven't. Well, that's enough reasons. I guess I'm just lazy, or have higher priorities than to spend 5 frustrating minutes per mail message. Ironically, I'm not alone. I have heard that even Phil Zimmerman lets his PGP-encrypted messages pile up in his incoming mail, due to the hassles. As Eric Hughes has noted, it is precisely this pain that will cause improvements to be made. -- .......................................................................... 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 2.0 and MailSafe keys by arrangement. From tcmay at netcom.com Fri Oct 30 15:53:14 1992 From: tcmay at netcom.com (Timothy C. May) Date: Fri, 30 Oct 92 15:53:14 PPE Subject: Copies of Crypt Handout and RSA FAQ Message-ID: <9210302035.AA20939@netcom2.netcom.com> Some people on this list picked up on my mention of the 60-page handout distributed at our first meeting (9-19-92) and have asked about getting copies. I've distributed all the copies I made before, but may be willing to make more. The problem is cost and time: each copy costs me about $2.00 and there are more than 100 people on this list. Any ideas? I also have a fresh copy of RSA's 52-page FAQ (which is also available by ftp, but many folks have had problems printing it). The same calculation applies. Whatever the solution, I will only make one "copy run," as I don't want to be a document distribution service on a continuing basis. Until a solution appears, PLEASE DO NOT SEND ME REQUESTS, MONEY, ETC. BTW, this applies to PGP 2.0 diskettes as well. I just mailed a diskette to someone who'd been unable to get the ftp'ed version. (And my diskette came from someone on this list, too...thanks!) I didn't ask for postage or diskette fees, but I clearly can't do this with dozens of folks. And yet it seems we ought to find a way to do this. One idea is to put our ideas into practice by having some kind of "escrow service" which holds deposited money (small amounts, given the items discussed here) and which can be used to buy small items, with payments handled electronically (ultimately settled with actual checks, of course). This could get out of hand, of course, so it's just an idea. Any comments? P.S. And don't forget to make your suggestions on the Crypto session at Hackers. I'll be issuing a status report soon. --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 2.0 and MailSafe keys by arrangement. From andy at autodesk.com Fri Oct 30 17:50:53 1992 From: andy at autodesk.com (Andrew Purshottam) Date: Fri, 30 Oct 92 17:50:53 PPE Subject: remove from mailing list In-Reply-To: <9210242237.aa22143@src4src.linet.org> Message-ID: <9210302349.AA01575@meefun.YP.acad> Are you Jethroes still using berkeley mail? Get a real mail user agent, like MH, and you can write a pattern that collects all the mail sent to a given address into a mail folder, effectively making your own digest. Andy From Tom.Jennings at f111.n125.z1.FIDONET.ORG Fri Oct 30 20:46:23 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Fri, 30 Oct 92 20:46:23 PPE Subject: Why I Don't Use PGP Message-ID: <3394.2AF2012B@fidogate.FIDONET.ORG> U> From: tcmay at netcom.com (Timothy C. May) U> 10. Because I use a Mac and the Mac version is not out yet. I'll ask in the FidoNet PUBLIC_KEYS echo about Smackintoshes. U> 9. Because the Mac version may NEVER be out. ... prolly cuz noone can figger out how to make a lot of money from it! U> 4. Because I'm not yet convinced it is needed. Ayup. My feelings exackly. This is starting to sound just like my gun arguments... I don't need one on the street, but someday I may, no? U> 3. Because ideally our mailers should handle this in a U> push-button way Some do already... --- 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 Sat Oct 31 03:45:42 1992 From: gg at well.sf.ca.us (George A. Gleason) Date: Sat, 31 Oct 92 03:45:42 PPE Subject: Why I Don't Use PGP Message-ID: <199210311044.AA08180@well.sf.ca.us> Re. Ten Reasons Why I Don't Use PGP: This is exactly why we need a decent user interface. The ideal would be a public-domain wordprocessor, which could be fairly simple, with a menu option for encrypt/decrypt, signature, and so on. I've been working on something like this for my OTP, and would be glad to participate in a project to do it for PGP and other systems. -gg From 74076.1041 at CompuServe.COM Sat Oct 31 09:42:14 1992 From: 74076.1041 at CompuServe.COM (Hal) Date: Sat, 31 Oct 92 09:42:14 PPE Subject: Why I Don't Use PGP... Message-ID: <921031163437_74076.1041_DHJ36-1@CompuServe.COM> The best way to integrate PGP into other software is a tough question. There are so many different ways in which people read and send mail. A lot of people receive their mail on some other machine, often a multi-user machine. So, the first question is, should the mail be crypted there, or should it be crypted on your personal machine. The second choice is preferable from the security point of view, but that means that you need to download at least your PGP mail in order to decrypt it, and it means you have to compose your mail on your home machine before encrypting, uploading, and sending. (Phil Zimmermann had an idea for multi-user systems in which the RSA portion of the decryption, which involves your secret key, would be done on your personal machine, then the decrypted session key would be uploaded to the multi-user machine and the IDEA decryption done on the message itself. This way you only have to upload and download a couple hundred bytes regardless of the length of the message. This would require PGP to be integrated into a terminal program.) If you _do_ download your mail before reading it, you could get in the habit of downloading _all_ of your mail into a big file, then running a word processor or some more specialized program to read the messages, one at a time, and compose replies. Then, when you were done, you could upload and send the replies. If you worked in this mode, which probably few people do, you could integrate PGP by running it on the downloaded mail file before running your WP to read it. I have a Perl script which runs PGP on a file, finding the PGP messages in it, decrypting them, and replacing them _in_the_file_ with their decrypted versions. (Normally PGP outputs its decrypted contents to another file, which is a little inconvenient.) This can make PGP pretty transparent for decryption if you actually read your mail in this way. Another possibility is to use a WP or mail reading program which has a "filter" mode, one which lets you pass incoming or outgoing mail through some program, and replace the mail with the results of that program. I don't know which programs can do this. A lot of Unix programs can, like VI and EMACS, but I don't know about PC's or other home machines. PGP has a filter mode which is designed to be used with WP's which can do this. There have been a couple of messages on alt.security.pgp which have advice on using PGP with various Unix mail reading programs. Mark Riordan's soon-to-be-released RIPEM program (an alternative, incompatible, RSA public-key program) has some ideas in its manual on how to use its filter mode with Unix mail, which mostly apply to PGP as well. One other point: regarding a Mac port: There have been at least a couple of messages on alt.security.pgp over the past couple of months from people who have successfully compiled the PGP sources under Think C on the Mac. However, as a Unix/PC program, it ends up using a character window for I/O, which you type into just like you would on a PC. This is unacceptable for Macs, so nobody has released one of these. Still, compared to what Tim has to do, it would be an improvement. I think people should release their executables which work like this as an interim crutch version until the real Mac version is available. Hal 74076.1041 at compuserve.com From Tom.Jennings at f111.n125.z1.FIDONET.ORG Sat Oct 31 13:31:32 1992 From: Tom.Jennings at f111.n125.z1.FIDONET.ORG (Tom Jennings) Date: Sat, 31 Oct 92 13:31:32 PPE Subject: Why I Don't Use PGP... Message-ID: <3400.2AF2EC7B@fidogate.FIDONET.ORG> U> From: 74076.1041 at CompuServe.COM (Hal) U> The best way to integrate PGP into other software is a U> tough U> question. There are so many different ways in which U> people read and send mail. U> don't know which programs can do this. A lot of Unix U> programs can, like VI and EMACS, but I don't know about U> PC's or other home machines. PGP has a filter mode which Not to brag, but my offline-reader (DOS version of a 'read news' program), as well as at least one other I know of, does a pretty good job of this. It handles the decrypted plaintext reasonably securely too. It does the decryption locally. (You have to manage your own keyrings externally, though of course keys embedded in messages are handled OK.) Solutions are out there. --- 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 tcmay at netcom.com Sat Oct 31 13:45:38 1992 From: tcmay at netcom.com (Timothy C. May) Date: Sat, 31 Oct 92 13:45:38 PPE Subject: Why I Don't Use PGP... In-Reply-To: <3400.2AF2EC7B@fidogate.FIDONET.ORG> Message-ID: <9210312042.AA02821@netcom2.netcom.com> Tom Jennings writes: > Not to brag, but my offline-reader (DOS version of a 'read news' > program), as well as at least one other I know of, does a pretty good > job of this. It handles the decrypted plaintext reasonably securely > too. It does the decryption locally. (You have to manage your own > keyrings externally, though of course keys embedded in messages are > handled OK.) > > Solutions are out there. I'm impressed. Maybe in 2-3 months this'll all shake out a bit, with a Mac version (rumored to be in beta), more "push-button" PGP systems, etc. By the way, Tom has generously agreed to talk about PGP, mailers, FidoNet, etc., at our Crypto session at Hackers. (I'll be sending out a more complete status report soon.) --Tim (Also, I have changed the last line of my .sig to reflect my current unwillingness to mail my PGP key to all of those who are asking for it. Hopefully this will soon change.) -- .......................................................................... 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 oren at coma.huji.ac.il Sat Oct 31 13:51:56 1992 From: oren at coma.huji.ac.il (Oren Mitz) Date: Sat, 31 Oct 92 13:51:56 PPE Subject: Please remove me from the mailing list! Message-ID: <9211010151.AA18004@coma.huji.ac.il> Sorry, can't handle the numer of messages every day . Thankx and out. bye bye from O> Message-ID: <9210312101.AA03883@netcom2.netcom.com> Hal Finney, Tom Jennings, Eric Hughes, and others are working on solutions to the "ease of use" problems I cited in my posting. Hal F. writes: > The best way to integrate PGP into other software is a tough > question. There are so many different ways in which people read > and send mail. > If you _do_ download your mail before reading it, you could get in > the habit of downloading _all_ of your mail into a big file, then > running a word processor or some more specialized program to > read the messages, one at a time, and compose replies. Then, when > you were done, you could upload and send the replies. > > If you worked in this mode, which probably few people do, you could > integrate PGP by running it on the downloaded mail file before running This is a major drag, destroying the feedback loop of reading mail and responding to it immediately. And, as Hal alludes to, it requires extra stuff, like PERL scripts, which complicate matters. > on the Mac. However, as a Unix/PC program, it ends up using a character > window for I/O, which you type into just like you would on a PC. > This is unacceptable for Macs, so nobody has released one of these. > Still, compared to what Tim has to do, it would be an improvement. I > think people should release their executables which work like this as > an interim crutch version until the real Mac version is available. Here's hoping. Several people claim to be working on a real Mac port. (I thought the idea someone had of doing it inside a HyperCard stack was a good one..HyperCard supports a CLI and so could run PGP, and HyperCard newsreaders exist, so in perhaps the two could be united.) Zimmerman's PGP has spurred people to think about the many practical issues of P-K crypto...authentication systems, keyrings, user interfaces, and so on. This alone is a major step forward. --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 MCGRATH at elec.canterbury.ac.nz Sat Oct 31 19:24:20 1992 From: MCGRATH at elec.canterbury.ac.nz (Jim McGrath) Date: Sat, 31 Oct 92 19:24:20 PPE Subject: PGP vs RSA Message-ID: 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. 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? Jim McGrath I'd rather have a bottle in front of me than a frontal lobotomy.