- cypherpunks-legacy@lists.ogf.org

A novel (?) return address idea
by jthomas＠mango.mitre.org 01 Mar '93

01 Mar '93

It seems clear now that the default behavior of the anon.penet.fi remailer (generating only one anonymous ID per user, and anonymizing all messages to other anon users with that ID) is inadequate. At the same time, Julf argues persuasively that users have come to expect that their replies to anonymous Usenet articles will be anonymized. The current na/an address workaround is okay, but I think we could do better. Here's my scheme: When a user first mails to or through a penet-style remailer, the remailer software will automatically allocate an ID for the sender's return address, as usual. _But_, it will keep this number secret, in an internal database. Let's consider this ID to be a binary number. The remailer appends to this ID number some "salt" bits (random bits, perhaps with some time-stamp info to guarantee that the same salt bits are never applied twice, if the RNG is weak). This collection of bits is then encrypted with a secret key only the remailer knows (note: this should _not_ be the secret half of a public/private key pair, for reasons that should become clear). The encrypted bit string is converted by a uuencode/armourtext process that produces characters that will be legal for an e-mail address. This is then used for a return address. When someone wants to reply to an anonymous message or post, the remailer decrypts the address, ignores the "salt" bits, looks up the anonymous ID in its database, and sends it on to the desired recipient. The advantage of this scheme is that no two messages will have the same return address, and no information about the sender can be gleaned from the return address; yet the remailer can allow replies to every message without keeping any more records than it does under the current version. A couple disadvantages could be running out of bits for the return address, and adding more encryption work for the remailer. You'd definitely have to own the machine, and implement some, er, different mailing software, since you'd have to accept mail for users with any random name whatsoever. And, of course, this method is only useful for penet-style remailers, not cypherpunk/mixnet remailers which should not remember anything about messages that pass through. What do you all think about this for a "Mark II" anon.penet.fi? Joe

2 1

anon.penet.fi confusion
by nowhere＠bsu-cs.bsu.edu 01 Mar '93

01 Mar '93

I thought that someone would bring it up, but since no one has, I guess I will. Isn't is very easy to accidentally type na1234 or an1234 when intending the other? It's just a matter of transposing two characters. This could result in a user signing a message that is sent with the anonymous ID or accidentally sending the actual address when thinking it was anonymous. Since a password can be assigned, the prior could be eliminated, but the latter is still possible. I commend Johan for his work and appreciate the new service, regardless of how it may sound. Chael Hall -- Chael Hall nowhere(a)bsu-cs.bsu.edu, 00CCHALL(a)BSUVC.BSU.EDU, CHALL(a)CLSV.Charon.BSU.Edu (317) 285-3648 after 5 pm EST

1 0

RE: CFP Costs Too Much!
by Pat Farrell 01 Mar '93

01 Mar '93

In Message Sun, 28 Feb 93 15:44:21 -0800, tcmay(a)netcom.com (Timothy C. May) writes: >.... I would also dearly like to attend CFP, but I also would dearly love to attend CFP again. I went to last year's session on a student subsidy and loved it. It changed the direction of my academic study. I don't understand where CFP's organizers are coming from. I applied for a student tuition subsidy for this year, and heard nothing. I submitted a request for a "birds-of-a-feather" session to talk about key registration, and got Dorothy Denning, TC May, and Mike Godwin to tentatively agree to participate. I've heard nothing. It is much too late to get cheap airfare to SF, so I'm not going. I'm a student. I can't afford the $2000 that attending CFP will cost, including airfare, hotel, meals, conference fee, etc. I admit to having a part time job, which supports my wife, daughter, mortgage, and pays tuition and buys books. It sure doesn't pay well enough to afford CFP93. Pat Pat Farrell Grad Student pfarrell(a)cs.gmu.edu Department of Computer Science George Mason University, Fairfax, VA PGP Public key availble via finger #include <standard.disclaimer>

1 0

Mail server for PGP sources
by dclunie＠pax.tpa.com.au 01 Mar '93

01 Mar '93

I gather some people have had trouble obtaining sources for PGP. I have accumulated those I can and they are available from my mail server. If you can get these somewhere closer then great, but if desperate feel free to get them from here (as long as the load doesn't get out of hand I will keep it going). The address is "mail-server(a)pax.tpa.com.au". Help is available by sending in the message body: send help end An index of PGP files is available by sending in the message body: index pgp end And results in something like the following ... Date Size Index: pgp ---------- ------ ---------------------------- 1992/12/25 216K security/pgp/macpgp2.0.sit.hqx 1992/12/25 160K security/pgp/msiguide.zip 1992/12/25 33K security/pgp/ngclon11.zip 1992/12/25 168K security/pgp/pgp-ng.zip 1992/09/13 184K security/pgp/pgp20.zip 1992/09/13 376K security/pgp/pgp20src.zip 1992/12/25 536K security/pgp/pgp21.tar.Z 1992/12/25 192K security/pgp/pgp21.zip 1992/12/25 656K security/pgp/pgp21ami.lha 1992/12/25 240K security/pgp/pgp21os2.zip 1992/12/25 440K security/pgp/pgp21src.zip 1992/12/25 224K security/pgp/pgp21_next.tar.Z 1992/12/25 256K security/pgp/pgp21_sparc.tar.Z 1992/09/13 464K security/pgp/unix_pgp20.tar.Z Probably pgp21.tar.Z or pgp21.zip are what you want for unix or pcdos respectively. If anyone has a more recent mac version I will put that up too. david

1 0

Anon address attack...
by Hal 01 Mar '93

01 Mar '93

-----BEGIN PGP SIGNED MESSAGE----- It seems like there are several problems that arise from this "automatic" anonymization of messages sent through the Penet remailer. You have these security threats which involve people being tricked into sending messages through the remailer in such a way that the recipient knows the true email address from where the messages are coming. (I think that is what happened here with "deadbeat", because otherwise why would he have asked people to send their email addresses? He wouldn't need email addresses since he could reply to people without knowing them, by just using a "reply" command in his mailer.) (It's interesting that he also sent his message via one of the Cypherpunks remailers. Maybe he thought they worked like the Penet remailer and he could break anonymity on those as well.) Another problem that people have complained about is when they respond to an anonymous posting, they get a message from Penet saying that they now have an anonymous ID assigned. This confuses and bothers some people. We had some debate about this issue here several months ago (before Penet was operating, I think). One question is, if I send mail to anonymous person A, does that mean or imply that I should be made anonymous to A? This is to some extent a matter of expectations. Some people argued that should be no expectation of anonymity in this case; A is the one who wants to be anonymous, not the people who are sending to him/her. Others replied that since some anonymous remailers already worked this way, there would be an expectation of anonymity, and so the safest assumption was to anonymize all messages since people can always override the anonymity by revealing their true addresses. I think these attacks on Penet re-open these questions. Evidentally there is positive harm that can occur by automatically anonymizing all messages which pass through a remailer. (BTW, I certainly don't mean here to be presuming to tell Julf what he should or should not do with Penet. I'm just taking that as an example. We have discussed adding similar functionality to our Cypher- punks remailers. The main problem occurs when sending a message to an anonymous Penet address. For the other uses of the Penet remailer, for anonymous posting and for mail to a non-anonymous address, it's more reasonable to assume that anonymization is desired. (Otherwise, why would they be using the service?) But when sending a message to an anonymous address, it's not known whether the sender wants to be anonymized or not. One possibility (which might not be that easy technically) would be to assign a new anonymous ID for each such message through the Penet server. This means that you would get a _different_ anonymous ID for each of these messages, preventing an attacker from pairing up your "usual" posting ID with your email address. (Perhaps this anonymous ID creation could be suppressed with another X- command, as proposed earlier, but this could be the default behavior.) It might be hard to keep track of that many anonymous ID's, but perhaps they could be kept active for only a limited period of time (several weeks or months) and retired after that. It might seem that people should just be careful about what they send through Penet, but there are some problems with this. What do you do if you get a message from an5877(a)anon.penet.fi asking for advice on cryptography mailing lists? If you reply, your questioner can figure out who the reply is coming from, and sees your Penet alias. There is no way to prevent this from happening currently. Also, I have seen proposals that anonymous ID's should be made less recognizable, so that instead of an5877(a)anon.penet.fi we would have joe(a)serv.uba.edu. In such a situation it might be tedious to scrutinize every email address we send to (via replies, for example) to make sure it isn't a remailer where you have an anonymous ID. All in all, I think some changes need to be made in how anonymous addresses are used and implemented in order to provide reasonable amounts of security. Hal Finney -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK4lfIagTA69YIUw3AQGzQAQApOduiD7P2C26f7ml5tcOJf6xQff7bdV0 qw+zjOevW6hSBunOY59Qstkk5uQ2CoEALDAyUfKRsy7dionBAtCJYlwfX7uclHKL Sonor8bg0NPHMP8SV/antacq00fK3b5wtiFFMn3WsjCvSEjhGoB9SIE/TB/zL9Et Ow8JEodP488= =cXHd -----END PGP SIGNATURE-----

8 11

Re: dispatches from the front lines of anonymity
by wcs＠anchor.ho.att.com 01 Mar '93

01 Mar '93

X-Real-Subject: Re: not assigning IDs for alt.whistleblower X-Real-From: Richard M. Nixon X-Real-Message-Body-Begin: It's probably a reasonable policy - anybody who wants to can add a signature line or equivalent giving themselves a pseudonym, and if they want private replies they can provide a PGP or RIPEM public key. A clean way to avoid the problem of encrypted replies cluttering up the newsgroup is to also create alt.whistleblower.followup or a.w.crypt, with similar non-assignment of ids, so readers can easily skip over the crypted private replies. If some whistleblower, or some whistlelistener, is more trusting, they can even post their an12345 address. I *would* recommend the following policies - - accept email in PGP, RIPEM, and also unencrypted MIME, X.400, and vanilla formats- not everybody who wants to blow a whistle has the right-shaped whistle handy. - publish an "official" method for defining what part gets posted - e.g. Anonymous-Subject: Use me instead of the main header Subject: Begin-Anonymous-Message-Body: ..... End-Anonymous-Message-Body: as part of the *text* of the message, so that people with different mailers can be sure about what parts get kept and what don't - it would be real annoying to have the signature-stripper delete the good parts of a message because they looked like signatures, or leave on the signatures because they looked like text, but some mailers won't let your do what you want with headers. Also publish a policy for messages that _don't_ contain them. A proper approach might be to use the MIME headers, but accept them from inside the message body as well as from the headers of proper MIME messages, so people can do them by hand. This has the added advantage of supporting Content-Transfer-Encoding: headers so you can tell more easily which encryption was used, and so senders of unencrypted messages can use compression or rot13 :-) to avoid having their message sent in obvious ascii. X-Real-Signature: "Maybe I _was_ a crook" X-Real-Message-Body-End: Bill # Bill Stewart wcs(a)anchor.ho.att.com +1-908-949-0705 Fax-4876 # AT&T Bell Labs, Room 4M-312, Crawfords Corner Rd, Holmdel, NJ 07733-3030

2 1

header field indicating an anonymous address
by Eric Hughes 01 Mar '93

01 Mar '93

Marc R. suggests that we standardize on a header field to indicate that a message was anonymous. I suggest "Anon-Sender:". There's already a "Sender:" field in RFC-822, indicating who sent the message, as separate from who wrote the message. The "Anon-Sender:" field should contain an email address for the maintainer of the remailer. Why? To facilitate complaints. :-) Eric

3 2

Handling Abuses of Remailers
by tcmay＠netcom.com 01 Mar '93

01 Mar '93

I'll keep this one very short. * To handle _abusive volumes_ through remailers, charge for remailing. Short term, this may be a problem, but this is the long term market solution. * To handle _abusive messages_ through remailers, ignore them. "Sticks and stones" and all that. Put positive reputation filters in place. Accept e-mail only through those you know or have reason to trust. As Sandy Sandfort so cogently put it, punish the perps, not the words of the perps. This is the basis of our society, and a good basis, too. -Tim May -- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)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 | Public Key: MailSafe and PGP available.

2 1

Infrastructure
by nobody＠alumni.cco.caltech.edu 01 Mar '93

01 Mar '93

-----BEGIN PGP SIGNED MESSAGE----- Some time back there was some debate here about whether MIME ("Multipurpose Internet Mail Extensions") features could be exploited to make encryption easier to use. I didn't pay much attention at the time, because I didn't know anything about MIME. But then a couple of weeks ago John Gilmore posted about Metamail, a software system designed to make it easy to integrate MIME into commonly-used mailers. I've played with Metamail a bit, and I do think this could be a good approach. Metamail basically performs a mail-sorting function, automatically passing mail which has the MIME "Content-type" header to a filter or display program based on a very flexible "mailcap" file. To add PGP (or PEM, or RIPEM) support would be a matter of defining a Content-type header for this application, then creating the appropriate 1-line entry in the mailcap file. This does sound like a pretty easy way to add this capability. The nice thing is, Metamail has already done the work of figuring out how to patch a whole bunch of different mailers to add this support. By using metamail we would be leveraging off this already-existing work. Here are some excerpts from the "mailers.txt" file that comes with the distribution, written by Nathaniel S. Borenstein: > Abstract > > It is surprisingly easy to use the RFC1049 "Content-type" header to turn > virtually any mail reading interface into a multi-media mail reading > interface. Mail readers are simply modified to use the new "metamail" > program whenever they receive non-text mail. The metamail program is > itself easily customizable by the use of a "mailcap" file that specifies > the media types supported by a given site or user. Given the existence > of the metamail program, this document explains how to add multimedia > support to sixteen very different mail reading programs, including all > of the most popular UNIX mail reading programs and (so far) one DOS mail > reading program. > [...] > The Basic Idea > > Basically, there are only two things you have to do to each mail reading > program: > > 1. Make the mail reader notice the special header ("Content-type") that > marks a message as a non-text message. (In the case of mail readers > that already understand certain content-types, such as Andrew, the mail > reader must be modified only to deal with the content-types it does not > already know how to handle. > > 2. When the special header appears, instead of (or, if it's much > easier, in addition to) showing the user the body of the message, the > mail reader must send that body off to the metamail interpreter. The > metamail interpreter includes features that deal with the diverse > situations of terminal-oriented and window-oriented mail readers. > [...] > A Variety of Mail and Bulletin Board Reading Interfaces > > With this document, you can patch all of your site's mail reading > interfaces to support whatever multimedia formats are deemed useful at > your site. This means that those who regularly use the multimedia tools > can begin to send mail in those formats freely, without worrying about > the ability of any local user to interpret the mail. It is my intent to > make this document exhaustive; as time goes on, I hope it will grow to > include an ever widening set of mail reading interfaces. Currently it > includes all of the mail reading interfaces that I know to be in use > anywhere in Bellcore's research laboratories. > > Currently this document describes how to add support for the following > mail readers: > > Berkeley Mail (/usr/ucb/Mail, /usr/ucb/mail, and Tahoe mail) > SunMail (another version of Berkeley mail, but rather different) > Xmail (an X11 interface to Berkeley mail) > Mailtool (older versions of a SunTools interface to Berkeley mail) > Imail (Bellcore MICE mailer) > PCS readmail/rdmail/sreadmail (another Bellcore mailer) > MH -- Rand Message Handling System > XMH -- X11 Interface to Rand Message Handling System > Rmail -- GNU Emacs mail reading package > VM -- Another GNU Emacs mail reading package > MH-E -- Yet another GNU Emacs mail reading package (GNU interface to MH) > CUI -- Andrew low-end mail reader > VUI -- Andrew termcap-based mail reader > Messages -- Andrew multimedia mail reader > BatMail -- Andrew Emacs mail-reading interface > Elm -- Mail reader from HP. > Mush -- Yet another popular mail reader > Msgs -- simple Berkeley bulletin board reader > UUPC --a mail reading program for MS-DOS > TRN -- a threaded netnews reader. > > > If you have mail readers that are not dicussed here, you will still > probably find some of this code useful as a model. If you develop a > patch for some other mail reader, and you send it back to me, I'll > include it in future versions of this document. I am very impressed with the range of mailers covered here. Unfortunately, access to source is needed for most of the patches. But my guess would be that patched versions would become available even to people who don't have source. I'm not really sure what is happening with PGP specifically in terms of MIME. I think there has been some work done with PEM integration. There doesn't seem to be any reason why these programs can't integrate nicely with MIME, and this Metamail package looks like it might be the most cost-effective way of getting widespread encryption into use. Hal -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK5EwE6gTA69YIUw3AQHa3gP/d9rJg8FTE4glB3CbUy5skG8j0AS4qvGn ugFhor0RZYpZIrsZn+XXJaiaO6+7je8fdEuwO2SkFBS90p6D7vtR40hqPUPnc4io q4z4UYRwV3aIVMjWZqyDncYQUouUltXh9utwH7nsbZX4Md9vDWwuq9ck7DHZhT+m O7Zx1+44kRY= =4Kad -----END PGP SIGNATURE-----

2 1

RISKS for alt.whistleblowers
by wcs＠anchor.ho.att.com 01 Mar '93

01 Mar '93

I would expect two kinds of people to cause trouble for alt.whistleblowers: amateurs and professionals. Amateur troublemakers may cause the most volume of trouble, and the largest signal-to-noise problem, but the more serious concern is what happens if there's enough signal in the noise to be a threat to professionals, whether governments, corporations, or criminals. If I were a professional who wanted to stop a group like this, and options like court orders, violence, or confiscation weren't appropriate, I'd consider a few approaches like the following: - Flooding - it's really not hard, even with automatic protections - if you can emulate, or abuse, all the neighboring anon-remailers, you may even force disconnects from them. - Crying wolf, and other disinformation - if there are enough bogus posts, people will stop reading the newsgroup, and the talk.bizzare crowd wil take over because they're the only ones who can handle the noise .. - Posting libel, slander, child pornography, calls for violence, bomb threats followed by real bombings, blackmail requests, photographs of local politicians in real or fake compromising situations, and enough other legally dangerous material that the moderator and/or people who carry the newsgroup wouldn't be able to take the heat. It's really not all that hard, if somebody's serious about it. Crypto-anarchy is a good thing, but governments and other bad guys can hide behind it just as effectively as anarchists can. .... and the last count I've heard on the radio was that 19 separate groups have called in to claim responsibility for the World Trade Center bombing; some even called 911, though presumably they used pay phones ... Bill Stewart, somewhere out in Cyberspace

2 1