[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Attacks on remailers
>>>>> On Wed, 25 Aug 93 11:39:11 EDT, J_G_Thomas%[email protected] 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.
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-
Diffie-Hellman encrypting messages between remailers would not help against
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
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.