Re: Attacks on remailers

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)

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

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

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

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

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

	Joe> Thoughts?

I think this is probably the best solution proposed to date.

Does the RSA-signed DH key exchange mentioned above provide security
against possible spoofing on the remailer machine (someone else using the
agreed-upon port)? How exactly would such a thing be implemented?

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

On the user side, I think a good tool to augment this would be a
mailer program which kept a list of the functioning remailers with
keys, and randomly selected a route through them using a random
(reasonable) number of hops, and performing the necessary nested
encryptions.  Then it could start the remailer hopping process via
special socket connection to the first remailer in the chain.

Perhaps a protocol could be worked out for the mailer program to
request from any one of the remailers a current list of the
functioning remailers? (in an effort to transparentize the process
some more, as manually maintaining a list of current remailers would
be tedious.)


We would need to work out the protocol details beforehand, such as how
to handle busy ports etc.
(Who wants to work on this project with me?)


Can someone supply a reference for DH key exchange? (for me, as I don't
know the details and so can't implement it. (is it patented?))

-Sam