The recent penet troubles are a reminder that secure anonymous return addresses are a lot harder than secure anonymous mail with no return capability. Maybe it's time to go over the options available to us for anonymous return? 1. Remailer memorizes a pseudonym. I don't like this, mainly because it leaves the remailer operator vulnerable to pressure to reveal the correspondence between real and anonymous id's. It also opens up about a million possible security holes, as we've noticed. 2. The anonymous message includes a cryptographic "stamped self-addressed envelope" which contains a layered list of remailer addresses encrypted at each layer. This requires modified behavior of remailers; they must be willing to "unwrap" an address-list separately from the message body, and then "wrap" the entire message with the destination's public key, in order to disguise the correspondence between input and output. I think this has been discussed here before. Has anyone implemented it? I strongly suggest that this method be implemented in the cypherpunks remailers. Let's call it the SASE feature. What do you think? 3. The reply to an anonymous message can be posted in a public place encrypted for a key known only to the sender. Have I missed any important methods? -- Marc Ringuette (mnr@cs.cmu.edu)
Re: options for anonymous return Marc writes:
1. Remailer memorizes a pseudonym.
2. The anonymous message includes a cryptographic "stamped self-addressed envelope" which contains a layered list of remailer addresses encrypted at each layer.
3. The reply to an anonymous message can be posted in a public place encrypted for a key known only to the sender.
Have I missed any important methods?
A variant of (1) greatly increases the security. Have the remailer memorize an anonymous return address of type (2). The information that is contained in a remailer then, per pseudonym, is a. the pseudonym b. the address of the next remailer to use c. a block of stuff to be prepended to the outgoing mail. Presumably this is forwarding instructions for the next remailer. It would also be encrypted with the public key of the next remailer. Thus, even if the whole pseudonym mapping list were compromised, it would only reveal a list of sites to try and compromise next. And at some point the private remailer keys have to be compromised as well, since all the remailing instruction are encrypted with them. This system can also be chained, creating "routing pseudonyms" on various remailers and encrypted instructions pointing one pseudonym to another. Eric
A variant of (1) greatly increases the security. Have the remailer memorize an anonymous return address of type (2). The information that is contained in a remailer then, per pseudonym, is
a. the pseudonym b. the address of the next remailer to use c. a block of stuff to be prepended to the outgoing mail. Presumably this is forwarding instructions for the next remailer. It would also be encrypted with the public key of the next remailer.
This is an excellent idea! It would provide decent security without forcing J. Random User to figure out how to use the SASE block. You'd want to have a list of address/SASE pairs to use, choosing randomly from those that have not yet died. Oh, a complication. It would probably be necessary to be able to add new address/SASEs as they become available, to avoid death of your pseudonym through cumulative remailer attrition. But nobody but the owner can be allowed to add destinations, for obvious reasons. The only apparent way to handle this is to require a password at the time of pseudonym creation. One-way-hash it, and require it to add and remove destinations. It should be PK-encrypted on its way to the remailer, if possible. This approach does not require an identity to be irrevocably tied to a destination address, interestingly -- you can remove chains to your old address, and add ones to your new. Suggestions? Holes? Implementations?
Eric
PGP 2 key by finger or e-mail Eli ebrandt@jarthur.claremont.edu
participants (3)
-
Eli Brandt -
Eric Hughes -
Marc.Ringuette＠GS80.SP.CS.CMU.EDU