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