KINNEY WILLIAM H <kinney@spot.colorado.edu> writes:

Recent traffic on anonymous remailers/servers:

...

From: Eli <ebrandt@jarthur.claremont.edu>

...

From: Hal <74076.1041@CompuServe.COM> This method of posting does not allow you to receive replies. I have set "nicknames" for these two accounts as "Untraceable account" which will appear in the "From" line on the postings. Hopefully that will offer a clue that the normal reply mechanism doesn't work. Maybe the nickname should say so more explicitly?

The security provided by this technique could be provided without the IMHO serious disadvantage of having no return address. Eric's hybrid approach, where a pseudonym server hands mail to an remailer chain, is secure (barring sophisticated traffic analysis) if you trust the last remailer in the chain. Julf, have you thought about whether you want to do something like this?

...

Hal

Here's an idea I haven't seen suggested before, which would remove

the need

for a pseudonym server:

[Description of chain-encrypted header info, separated from message text]

This seems to me to be a very robust pseudonymous mail system which

could be implemented by relatively minor changes to the existing Cypherpunk

remailer structure. It has the additional advantage of being decentralized

and maintenance-free. It could be used for pseudonyms on net news, e-mail,

wherever, and could presumably be integrated in some way into Julf's

anon server.

Yes, this would seem to be the way to do this, and this type of nested-encrypted routing information is what I was referring to as an "SASE" in my front-end/back-end anonymous posting design. There are some drawbacks, however. Traffic analysis by watching a remailer's feed, and seeing messages come in and go back out is much easier, since the message _text_ is unchanged from one remailer to the next. In fact, however, such traffic analysis is not difficult with the present system, since message lengths can be used to correlate messages going in and out, and the remailers aren't getting enough traffic to do much internal "mixing" to avoid obvious FIFO behavior. The obvious solutions are a remailing protocol that supports padding out messages to a few "standard" lengths, and increasing the remailer traffic, perhaps with dummy messages. But this doesn't help in the above case, when routing information is separate from message text, and not known to the sender (except for the first hop). One possible solution relies on the fact that each remailer must know the next hop a message will take. When the remailer is forwarding mail with separately encrypted header information, it will append some random bits to the message, then encrypt it with the next remailer's public key. (Note that if the appending of random bits is skipped, the system provides no security against traffic analysis, since the adversary can simply try encrypting incoming messages with various remailers' public keys, then watch to see if that message comes back out). I've got some more ambitious ideas for this (encrypted return addresses as a MIME content-type?), but I think the version outlined above could be implemented pretty easily, although I admit I haven't really read through the remailer scripts. I'll take a crack at it as soon as I get my Linux box (a couple weeks) if people think it's a good idea. Joe