Improvement of remailer security

[boldt@math.ucsb.edu (Axel Boldt)]

I think the recent death-threat-to-Clinton desaster has made clear
that the remailers we have are not very secure, mainly because
incoming and outgoing mail seems to be monitored at many sites.

Even the current pgp encryption scheme offered by some remailers
doesn't help much, once the incoming and outgoing messages are known:
just take the outgoing message from the remailer, encrypt it with the
remailer's public key, compare this to the incoming messages and you
know who sent this message (repeat if a chain of remailers was used).

Here's a proposal which could close this hole: remailers should allow
for a new header 'Encrypt-with:' which takes as argument a public pgp
key. This is used just like the 'Request-Remailing-To:' header,
i.e. using the '::' construct in the body of the pgp encrypted
mail. ('Encrypt-with:' offers no additional security if no pgp
encryption is used in the first place.) The semantics is that the
remailer, just before passing the message along (and after having
decrypted it, of course) encrypts the message using this public key
and adds an 'Encrypted: pgp' header to it.

To make sure that no remailer on the way knows the contents of the
message, we should add one more mechanism: Whenever a remailer
encounters a message with an 'Encrypted:' header, and the decrypted
message contains another 'Encrypted:' header, the remailer decrypts it 
again. (Perhaps this feature exists already?)

In this way, even if someone knew the contents of every incoming and
outgoing mail of the remailer, they couldn't tell which incoming
message produced which outgoing message. To trace a message back to
its origin through a chain of remailers, one would have to know in
addition all the secret keys on the way (except the first one).

Axel