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