1994-08-12 - Re: Reailers: To Log or Not to Log?

Header Data

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

Raw message

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."




Thread