[109432] in Cypherpunks
Re: Mixmaster Versions & "Traffic Analysis"
daemon@ATHENA.MIT.EDU (Anonymous)
Wed Mar 24 02:36:46 1999
Date: Wed, 24 Mar 1999 08:18:03 +0100 (CET)
From: Anonymous <nobody@replay.com>
To: mail2news@basement.replay.com, mail2news@nym.alias.net,
cypherpunks@toad.com
Reply-To: Anonymous <nobody@replay.com>
-----BEGIN PGP SIGNED MESSAGE-----
Anonymous <nobody@drule.org> wrote:
> Since there are several different iterations of Mixmaster 2.0.4 floating
> around (b01 through b43, I believe) and every mixmaster encoded message
> contains a first line like this:
>
> ---Remailer-Type: Mixmaster 2.0.4b35---
>
> Does this help an attacker using traffic analysis to track a mixmaster message
> all the way through a remailer chain? Does this help to distinguish between
> my message, using "build 35" and other mix messages using different "build #'s"?
> If so, what if anything, can be done about it?
>
> Thanx--
That's an excellent question. That would depend on whether that
same build number stays with the message through all its hops, or
whether it's replaced with the build number that the first remailer
is using before it's sent to the second remailer, etc. My answer
will be based on those two possibilities:
If the build number in the header CHANGES with each remailer's
version of the software, then there should be no problem. While
your build number would be known to the first remailer, it knows
where the message originated, anyway. Beyond that, your message
should blend in nicely with the rest of the traffic stream in the
remailer net.
If the build number STAYS with your message, then you're more
vulnerable, especially if you are one of a very few users using a
particular build. You'd be vulnerable if only two of the remailers
in your chain, the first and the last, happened to keep logs showing
the sender and the version number, or the recipient and the version
number. IOW, a message arrives, someone demands that it be traced,
the operator of the last remailer says it came from another
remailer, and was encrypted with build 25 software. Then the rest
of the remailers are requested to check their logs for build 25
messages, and one of them has a build 25 message that came from you.
If build 25 is so infrequently used that yours is the only such
message that's been logged in awhile, then the finger points at you.
Withour logging (shich remailer should NOT be doing, IMO), you'd be
a little safer. They could use traffic analysis to trace it to the
final remailer, but with the reordering pool at that remailer, your
message would only be one of the possible messages in the pool that
could have resulted in the message in question. Still, would you
like to be singled out as one of only 5-10 suspects?
The solution (if one is needed)? I'd recommend using the "almost"
latest and greatest build of Mixmaster. When a new one comes out,
give it some time for a bunch of other people to learn about,
download, install, and start using it, then use it yourself. Or you
could get the latest Type2.list file, see which build most of the
remailers are running, and use that one. (Assuming that number in
the files gets changed each time a remailer upgrades versions, and
not just when the key is first generated.) You'll at least have the
advantage of "hiding" among a larger "crowd". Another tactic would
be to create your Mixmaster message, then send it to your first
Mixmaster remailer inside of a Type I (Cypherpunks) style message
using PGP encoding. This would hide your Mixmaster header from
prying eyes entirely.
I hope this weakness does not exist. It would certainly not be in
keeping with Lance Cottrell's idea of having indistinguishable
packets in the Mixmaster net. A stopgap measure might be for
<someone> so send out cover traffic to random chains of remailers
using different build numbers of Mixmaster.
- --
Charlie Comsec
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQEVAwUBNvhgrAbp0h8ZvosNAQEElgf7ByA4EI4PAjeCAfr2SMCk+iH/ZKpjepdt
+TK90de6Dyf696iQ939H/3XupoMyQ9e7s7VQc+pjEep5hMWhFkmgLmk1LRK3Gs4x
Co5paIx6P+t/agT7SsEmm/YXrVfVsCoRnZZUfXcvgJfPHA6wdnenqG5KJMsGZUhy
UUyVv2sZAgh8DSlHw4qCxnVkw4Ut2uc121gog8kvSr7mxLbM+jGp7UNsIWmqX6ZL
EHMxY2r3Pz1YK/AE+NaznGwYx+jh1iCR+9d3OZIO9MVV/ek7PJCmWBXRqN+z/fxy
jEkiZYOe9hdgC52bVVV1QCswaZXsmDEIyAAxpiWcmsY9iq4GAepb2w==
=HVvf
-----END PGP SIGNATURE-----
