From: J_G_Thomas%CAASD1@mwmgate1.mitre.org
Date: Wed, 25 Aug 93 08:45:38 PDT
To: cypherpunks@toad.com
Subject: Re: Attacks on remailers
Message-ID: <199308251542.AA23719@mwunix.mitre.org>
MIME-Version: 1.0
Content-Type: text/plain


Samuel Pigg <b44729@achilles.ctd.anl.gov> wrote:

> Actually what I was proposing was the direct usage of SMTP itself rather
> than going through the host machine's mail system. As anyone can do it,
> it would help with the usage of student accounts as remailers.
> And with direct SMTP (socket connections to port 25 of the receiving machine)
> you have some control over the header information that is generated.

> The protocol is outlined in RFC821 if anyone wants to look at it.

The trouble is, one side (the receiver) is still keeping logs, since only 
sendmail (or some other root process doing the same job) can bind to port 25.  
On most machines, that means logs.  There are plenty of ports over 1000 that 
user processes can bind to, and that cypherpunk remailers can support, if we 
want to go that way.  I think it's worth thinking about.  (This is in addition 
to receiving mail delivered normally to their e-mail adresses, probably either 
by port-25/sendmail or uucp).

We could start by having cypherpunk remailers talk to _each_other_ on an agreed-
upon, unlogged port, using RFC 821 protocol.  Final hops to non-remailer 
addresses will have to be handled on port 25, of course, but within the 
remailer web we can avoid sendmail logs entirely.  After that's implemented, we 
could talk about using a different protocol.  

A new protocol is probably the cleanest way to solve the problem of traffic 
analysis of messages addressed with encrypted address blocks.  The best way to 
get security in a remailer chain is to nest your encryption, so only one layer 
gets peeled off in each remailer hop.  That isn't possible with encrypted 
address blocks, since the sender will only know the address (and public key) of 
the first remailer in the chain.  All hops after the first one must send the 
same message out as they got in, with just a layer off the encrypted address 
block.  But if remailers talked to each other by first doing RSA-signed Diffie-
Hellman key exchange, then encrypting the traffic, a packet snooper wouldn't be 
able to correlate incoming and outgoing messages.

The latter is one of the "expensive" attacks, I think, and should be thought 
about after we make sure the logs aren't being kept.

Thoughts?

Joe
(they're trying to pry me away from my NeXT, so don't reply directly to the 
From: line; use jthomas@mitre.org)