[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Attacks on remailers
Samuel Pigg <[email protected]> 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.
(they're trying to pry me away from my NeXT, so don't reply directly to the
From: line; use [email protected])