Improvement of remailer security

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

boldt@math.ucsb.edu (Axel Boldt):

> 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).

Nope...  PGP encrypts the message with a random IDEA key, and then
encrypts the IDEA key with RSA.  You'd have to guess which IDEA key was
used, and encrypt that with RSA.  The SS couldn't guess 2^128 possible
IDEA keys in a hundred years, even with 10 cray supercomputers...  (of
course, they might be able to do it a hundred years from now... but by
then nobody would care about some stupid 20th century email message.)

Karl Barrus's latent-num and truncate-line features on his former
tree-remailer handled all of the traffic-analysis problems rather
nicely, however...

> 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.

JPP's remailer does this, except it only posts to alt.test.  Maybe you
could convince him to allow it to also forward to remailers when a
remailer public key is specified... :)

On Fri, 11 Mar 1994 01:00:37 -0500 (EST), Matthew J Ghio
<mg5n+@andrew.cmu.edu> said:

> boldt@math.ucsb.edu (Axel Boldt):

>> 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).

> Nope...  PGP encrypts the message with a random IDEA key, and then
> encrypts the IDEA key with RSA.  You'd have to guess which IDEA key was
> used, and encrypt that with RSA.  The SS couldn't guess 2^128 possible
> IDEA keys [...]

Thanks for pointing this out. I wasn't aware of the fact that pgp
encrypting is not deterministic in the sense that encrypting the same
message with the same public key need not result in the same output.

I guess that makes my whole suggestion pointless.

Axel


P.S. Pardon my ignorance: Doesn't this scheme you describe above make
the random generator the most attackable part of pgp encryption,
thereby sidestepping the whole RSA stuff?

> P.S. Pardon my ignorance: Doesn't this scheme you describe above make
> the random generator the most attackable part of pgp encryption,
> thereby sidestepping the whole RSA stuff?

Yes, the reason for all the work on Good (TM) Random Numbers.. :-)

-derek