Compromised Remailers

Bryan L. Fordham bfordham at socialistsushi.com
Sun Dec 14 13:56:50 PST 2003


Tim May wrote:

> I haven't carefully looked at the current source code (if it's 
> available) for things like "Type II Mixmaster" remailers, things which 
> offer reply-blocks.

The source is available for mixmaster.  However, Type II does not offer 
reply blocks.

> Certainly for the canonical Cypherpunks remailer, the 
> store-and-forward-after-mixing remailer, the fact that the nested 
> encryption is GENERATED BY THE ORIGINATOR means that interception is 
> useless to a TLA. The most a TLA can do is to a) not forward as 
> planned, resulting in a dropped message, or b) see where a particular 
> collection of random-looking (because of encryption) bits came from 
> and where they are intended to next go.

Not necessarily.  You don't have to be able to read a message to 
determine what it is.  In the case of an amphibian remailer operator 
(who shall remain nameless) revealing the identity of someone using his 
remailer, this remop ran 2 of the three remailers being used.  The chain 
went:

A -> B -> C -> D -> E
where A is the sender, E the recipient, and B and D are the remailers 
controlled by the same person. Also, if the message to E had been 
encrypted it wouldn't have mattered much in identifing who what sending 
something to whom.

The remop could tell that a message from A coming in through B always 
resulted in a message going to C, and that such messages always had a 
corresponding message from D to E.  The fact that the messages were 
encrypted to each remailer's key, and that the middle remailers was not 
compromised, did not protect the user.

There were a some special circumstances to this, the biggest one being 
that A was sending a ton of messages, all of similar size, through the 
exact same chain.  But it does show the problem with Type I reply blocks 
in use by the current system.

> In particular, a TLA or interceptor or corrupted or threatened 
> remailer operator CANNOT insert new text or new delivery instructions 
> into packets received by his node BECAUSE HE CANNOT OPEN ANY PAYLOAD 
> ENCRYPTED TO THE NEXT NODE. Anything he adds to the payload bits 
> (which he can see of course, though not decrypt or make sense of) will 
> of course make the next node see only garbage when he tries to decrypt 
> the payload.

Of course they can't alter the encrypted text, but it may be possible to 
add text after the pgp-encrypted block to make tracking the messages 
easier.  There's also the issue of taking a reply block and replaying it 
with new text in order to watch where it goes.

[snip]

> And if even a fraction of the remailers are compromised, then with 
> collusion they can map inputs to outputs, in many cases. (How many 
> they can and how many they can't are issues of statistics and suchlike.)

Exactly. This is the case I was mentioning above.  It shows that the "if 
one remailer is legit your messages are safe" line of thinking is not 
necessarily true.

[snip]

> Adding reply-block capability significantly raises the risks for 
> traceability, in my opinion. I am not casting doubt on the Anonymizer 
> and on Mixmaster Type N (whatever is current), but I have not seen 
> much detailed discussion here on the Cypherpunks list, and I am 
> unaware of peer-reviewed papers on the cryptographic protocols being 
> used. (If they exist, pointers here would be great to have!)

Type II is the current, though cypherpunk (Type I) are in use.  II does 
not allow for reply blocks.  Type III (mixminion) is in active 
development and allows for SURBs - Single Use Reply Blocks -- that will 
allow for nyms without having to store a set number of reply blocks that 
can be replayed (a la the current type I pseudonym setup)

Anyway, just a few thoughts.  I'm far from an expert on this so take 
everything with a large grain of salt.

--B





More information about the cypherpunks-legacy mailing list