Attacks on remailers

[hfinney@shell.portal.com]

>>>>> On Wed, 25 Aug 93 11:39:11 EDT, J_G_Thomas%CAASD1@mwmgate1.mitre.org said:

	Joe> A new protocol is probably the cleanest way to solve the
	Joe> problem of traffic analysis of messages addressed with
	Joe> encrypted address blocks.  The best way to get security
	Joe> in a remailer chain is to nest your encryption, so only
	Joe> one layer gets peeled off in each remailer hop.  That
	Joe> isn't possible with encrypted address blocks, since the
	Joe> sender will only know the address (and public key) of the
	Joe> first remailer in the chain.  All hops after the first
	Joe> one must send the same message out as they got in, with
	Joe> just a layer off the encrypted address block.

As I indicated in my long posting, it is not necessary to send out the
same message that was received.  Chaum proposed encrypting the message
(the non-address-block portion) with a secret key at each stage, a key
which would be revealed to the remailer (along with the address of the
next address in the chain) when it peeled off its own layer of encryption.

		But if
	Joe> remailers talked to each other by first doing RSA-signed
	Joe> Diffie- Hellman key exchange, then encrypting the
	Joe> traffic, a packet snooper wouldn't be able to correlate
	Joe> incoming and outgoing messages.

If no encryption is done on the message body, there is another attack for
this case that I didn't mention.  It is:

Run a remailer.  For every anonymous address floating around on the net,
try sending a message to it.  Look at the messages which pass through
your own remailer and look for matches to the message you sent.  Any
anonymous address which includes your remailer as one of the elements
will pass through you.  You have then defeated all of the stages of the
chain before yourself.  In particular, if you happen to be the last remailer
of the chain, you have broken the anonymity of the anonymous address.

This attack, while not the most powerful on the list, defeats many of the
principles of remailer chains, such as that the chain is as strong as
its strongest link.  It requires you to strongly trust at least one
remailer in the chain (the last one), whereas without this attack you
would not have to especially trust any single remailer.  So it is sig-
nificant.

Diffie-Hellman encrypting messages between remailers would not help against
this attack.

Also, rather than DH it would be just as effective to use the public key
of the next remailer in the chain, and more convenient: some remailers are
not able to participate in TCP exchanges, being connected to the net
by occasional uucp connections.

This lack-of-TCP problem also impacts the proposal to use a public telnet
port for message communication.  Another problem with that proposal is
that it would need the remailers to run as background processes.  With the
current software they can run as mail filters, which makes them much
less conspicuous to system managers.

The suggestion for remailers to send messages by telnet connection to
port 25 of some other machine (rather than by piping to sendmail as they
currently do) is perhaps reasonable (for those systems with TCP access),
although it makes the remailer somewhat harder to set up since you have to
find some other machine which will let you connect to their port.  Also,
I think some machines may log incoming or outgoing telnet connections to
this port, since it is a common technique for mail forgeries.  I have heard
that most systems will actually not allow public telnet connections to
this port.

I don't know that much about how widely available telnet and other TCP/IP
services are on the net, so if these techniques are more usable than I
am suggesting I'd like to hear about it.

Hal Finney
hfinney@shell.portal.com