- cypherpunks-legacy - lists.cpunks.org

Meeting Sat. Oct. 10, noon, Mt. View
by Eric Hughes 05 Oct '92

05 Oct '92

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(a)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

1 0

A statement of purpose
by Eric Hughes 05 Oct '92

05 Oct '92

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.

1 0

Nuts & Acorns
by Secret_Squirrel＠Treehouse.ORG 05 Oct '92

05 Oct '92

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)

2 1

Re: Secure IRC
by Tom.Jennings＠f111.n125.z1.FIDONET.ORG 05 Oct '92

05 Oct '92

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(a)f111.n125.z1.FIDONET.ORG

2 2

Secure IRC
by postmastuh＠dawkmastuh.guv 05 Oct '92

05 Oct '92

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$

2 1

PGP echo conference...
by Tom.Jennings＠f111.n125.z1.FIDONET.ORG 04 Oct '92

04 Oct '92

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(a)f111.n125.z1.FIDONET.ORG

1 0

public vs. private
by Judith Milhon 04 Oct '92

04 Oct '92

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.

1 0

No Subject
by omega＠spica.bu.edu 02 Oct '92

02 Oct '92

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(a)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. ======================================================================

1 0

Re: Secure IRC
by George A. Gleason 02 Oct '92

02 Oct '92

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

1 0

No Subject
by omega＠spica.bu.edu 01 Oct '92

01 Oct '92

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(a)csli.stanford.edu.

1 0