From: tcmay@netcom.com (Timothy C. May)
To: cypherpunks@toad.com
Message Hash: 0655facc56fc0dc541fbd4483945b06d5b1c07d10b890d0c7d7f37a0fb5c01bb
Message ID: <199408120226.TAA29483@netcom3.netcom.com>
Reply To: <199408120145.SAA23405@kaiwan.kaiwan.com>
UTC Datetime: 1994-08-12 02:26:07 UTC
Raw Date: Thu, 11 Aug 94 19:26:07 PDT
From: tcmay@netcom.com (Timothy C. May)
Date: Thu, 11 Aug 94 19:26:07 PDT
To: cypherpunks@toad.com
Subject: Re: Reailers: To Log or Not to Log?
In-Reply-To: <199408120145.SAA23405@kaiwan.kaiwan.com>
Message-ID: <199408120226.TAA29483@netcom3.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain
Diogenes the Anonymous Barrel Shifter writes:
> Tim May pondered:
>
> > And even that last remailer may be able to claim ignorance (and win in
> > court) if he can show that what he mailed was unreadable to him, i.e.,
> > encrypted to the recipient. (This is another reason I favor a goal of
> > "everyone a remailer.")
>
> The only problem I see with the "everyone a remailer" concept is
> that, in the presence of traffic analysis, a locally generated
> message will show up as an imbalance between incoming and
> outgoing messages, will it not?
Several easy ways to avoid this:
1. No reason that "N messages in, N + M messages out" can't be a
common occurrence, e.g., dummies. (Messages will in fact get absorbed
by sinks, so dummies/padding/MIRVing is expected anyway.)
(And the values of N and M will have scatter anyway.)
2. Or could delay one of "other" messages, inserting the
locally-generated one. (Pushes the "problem" to next transmission, one
could say, but I doubt it matters.)
3. Circulate dummy messages into one's won remailer, replacing the
dummy with the "real" message. N messages in, N messages out.
4. No reason for the "N in, N out" approach anyway, as a probabalistic
method can be used, with the (dreaded) "random delays" used. (Provided
sufficient reordering occurs, as we've discussed so many times.)
I don't think it's likely that all remailers will have some fixed
policy for the value of N.
> > With canonical remailers, and no logging, earlier remailers should be
> > safe.
>
> That brings up an interesting point -- does the very act of
> logging remailing activity, specifically the recording of sources
> and destinations of forwarded messages perhaps open the operator
> up to INCREASED liability? IOW, if the remailer is being used in
> the furtherance of a "crime", the presence of a log which records
This has always been a likely possibility, but not tested in court.
Logging is a VERY BAD THING, though I understand why remailer
operators feel compelled at this point to do it. (I don't run any
remailers, so I won't moralize...the point about it being a very bad
thing is in terms of what a "mix" is supposed to be. People should go
out and find Chaum's 1981 CACM paper, which has been referenced so
many times.)
> Also, I suspect that if increased activity on a remailer is
> useful in thwarting traffic analysis, then foreswearing the
> keeping of logs should serve to INCREASE the throughput as users
> gain confidence that any "footprints" they might leave behind are
> promptly erased.
^^^^^^^^^^^^^^^^
Forward security, a la certain Diffie-Hellman protocols, is needed. A
true Chaumian mix does this with some security hardware
(tamper-responding modules), and the DC-net approach eliminates even
the need for TRMs.
--Tim May
--
..........................................................................
Timothy C. May | Crypto Anarchy: encryption, digital money,
tcmay@netcom.com | anonymous networks, digital pseudonyms, zero
408-688-5409 | knowledge, reputations, information markets,
W.A.S.T.E.: Aptos, CA | black markets, collapse of governments.
Higher Power: 2^859433 | Public Key: PGP and MailSafe available.
"National borders are just speed bumps on the information superhighway."
Return to August 1994
Return to “tcmay@netcom.com (Timothy C. May)”