Re: strengthening remailer protocols

[Lance Cottrell <loki@infonex.com>]

Mixmaster prevents replay, so flooding multiple copies of a single message
will not work. This is the reason Mixmaster has no reply block feature. I
can see two ways in which replies can work safely.

One time reply blocks. Each block is used once and only once. Each routes
separately, and the creator never deploys enought to allow a good trace (no
more than 5 in existence at any one time). They would probably need to be
managed by some kind of nym-server. They have the disadvantage of allowing
denial of service by simply using up all the available reply blocks. The
block also point back to the sender (as all reply blocks must). This allows
an attack to rubber hose each operator in succession at the attacker's
leasure. Normal chains contain no information about where they have been,
so interception and cooperation must happen in real time (much more
difficult).

The other solution is message pools. I think this will turn out to be the
only really secure and reliable system. Some sort of automated use of pools
by remailers (so the user need not do so directly) might be possible. I
designed such a system several months back, with little response.

At 4:50 PM -0700 9/2/96, Timothy C. May wrote:
>This type of attack is why "reply-block" schemes are fundamentally flawed.
>Any such scheme gives an attacker (a traffic analyst) a wedge with which to
>deduce mappings. It is a kind of "chosen plaintext" attack (loosely
>speaking). Or a "forcing attack." Maybe a "flooding attack" is as good a
>name as any. One floods the reply block and simply watches where the water
>goes.
>
>(If there were more academics in the crypto community looking at digital
>mix issues, there would likely be clever names for the various attacks.)
>
>Several folks on this list, including (from memory), Scott Collins, Wei
>Dai, Hal Finney, myself, and others, have noted this weakness over the
>years.
>
>Note that merely fiddling around with probabilities of transmission, such
>as described above, will not be enough. This just adds a layer of noise,
>which will disappear under a correlation analysis.
>
>(For newcomers, there are interesting parallels between statistical
>analysis of ciphers and similar analysis of remailer networks. And lots of
>statistical tools can be used to deduce likely mappings based on
>source/sink correlations, digram analysis, etc. Making a remailer network
>robust against such analyses will take a whole more basic thinking. Merely
>increasing message volume is not enough. Nor is increasing latency enough.
>Generally speaking, of course.)
>
>Instead of reply blocks, I think use of message pools (a la BlackNet) is a
>more robust reply method, as it uses "widely-distributed messages" (a la
>Usenet newsgroups) to get around the source/sink correlation issue.
>
>--Tim May
>
>
>We got computers, we're tapping phone lines, I know that that ain't allowed.
>---------:---------:---------:---------:---------:---------:---------:----
>Timothy C. May              | Crypto Anarchy: encryption, digital money,
>tcmay@got.net  408-728-0152 | anonymous networks, digital pseudonyms, zero
>W.A.S.T.E.: Corralitos, CA  | knowledge, reputations, information markets,
>Licensed Ontologist         | black markets, collapse of governments.
>"National borders aren't even speed bumps on the information superhighway."


----------------------------------------------------------
Lance Cottrell   loki@obscura.com
PGP 2.6 key available by finger or server.
Mixmaster, the next generation remailer, is now available!
http://www.obscura.com/~loki/Welcome.html or FTP to obscura.com

"Love is a snowmobile racing across the tundra.  Suddenly
it flips over, pinning you underneath.  At night the ice
weasels come."
                        --Nietzsche
----------------------------------------------------------