On Sat, 13 May 2000, Steve Schear wrote:
> >yeah - this kind of "self-coercing" adversary doesn't seem to have been
> >considered by remailers much, either theoretical or practical. Do you know
> >if he fingered the middleman remailers on the chain, too, or just the
> >endpoints?
>
> How would he know the middle men? This is why Goldberg's example of using
> a HotMail, or similar, exit remailer needs to be widely deployed.
I was under the impression that in this case the adversary constructed the
remailer chain himself, so necessarily knew the middle men. The real
question then is whether the adversary can prove that the bad data went
through the middle men.
If the client does all the encryption itself, then it knows the exact
string which will be passed between each remailer in the chain. It can
log messages coming into and out of each remailer and build up a picture
of the chain as the message passes through. Then later it can turn over
the original packet, all of its layers, and show that they are consistent
with what was logged as going through the specified middle men.
(the original packet can be "found miraculously" or "via a court
order" or just posted someplace. I think this is the trickiest part of
the attack, since it won't work if the entrapment is obvious.)
(the logs have to be credible, as well. Some public-spirited soul might
take to keeping and publishing such logs -- pseuodnymously, of course --
until they came to be accepted as a tool for keeping up reliability or
somesuch)
Now we have convincing evidence that a particular message passed through
all these middleman remailers. Even if the last hop is someone untouchable
like HotMail, it doesn't matter.
It seems one way to defeat the attack is to make sure that a passive
adversary can't recognize its own message passing between remailers.
Then the adversary cannot create the logs which afterwards are used to
prove a message passed through the remailer. One way to do this is to
have the remailers re-encrypt packets passing between them. I'm not sure
whether Mixmaster 2.9b does this ; it's listed on Cottrell's page as a
"for future version" fix (along with remailers that connect over IP). I
know 2.9b doesn't do the remail-over-IP thing, but I haven't found
anything about re-encrypting when directly sending a packet.
What might help is remixing -- instead of sending each message directly to
its next hop, mix it to the next hop. Do this between every hop. Then the
outgoing message from a node will not be known to the adversary. When the
message makes it to the next hop, though, if it is not re-encrypted with
that next hop's public key, then the adversary will know what the message
looks like and so can notice it on the logs. Again, I need to read the
source to see if Mixmaster 2.9b does this.
Thanks,
-David
