From: tcmay@netcom.com (Timothy C. May)
To: cypherpunks@toad.com
Message Hash: b8f104390fb8edf8bb79916ffa4d23126f8d239e7fdbbf802e475fdf28050a8b
Message ID: <9301170742.AA11487@netcom3.netcom.com>
Reply To: <9301151822.AA13343@xanadu.xanadu.com>
UTC Datetime: 1993-01-17 07:45:44 UTC
Raw Date: Sat, 16 Jan 93 23:45:44 PST
From: tcmay@netcom.com (Timothy C. May)
Date: Sat, 16 Jan 93 23:45:44 PST
To: cypherpunks@toad.com
Subject: Ideal Remailers
In-Reply-To: <9301151822.AA13343@xanadu.xanadu.com>
Message-ID: <9301170742.AA11487@netcom3.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain
SOME PROPERTIES OF IDEAL REMAILERS
Cypherpunks,
It's been exciting seeing the work being done by so many of you on
remailers! Not being either a PERL user or a UNIX box owner, I haven't
had much to add to the debate these past several weeks.
But on the issue of basic, primitive features of remailing networks, I
want to make some points. I'll use Dean's message as a starting point.
Dean Tribble writes:
> Has anyone thought about the consequence of randomly picking a
> remailing path instead of using the same one? It occurred to me
> yesterday that randomly picked paths could reveal more information to
> the remailer sites so that they could figure out the connection
> between a pseudonym and the eventual destination pretty well. It's
> just an intuition at this point, though.
I assume Dean means that by analyzing some kind of characteristic of
the message and enough of the routings, some "common factor" analysis
might reveal the sender.
This may be true in cases where the routing path is _visible_
(unencrypted at some or all nodes) to some or all of the remailer
nodes. However, I think we all expect remailers to (eventually) have
most or all of these properties:
* All packets are encrypted to the public key of the remailer node:
only the previous (n - 1) and next (n + 1) nodes in a remailer path
are known to node n, except by collusion between remailers.
* Some number of incoming messages are collected together before
remailing in an order that gives no clues about the order received,
e.g., lexicographic order. (I realize that at this stage of
experimentation, such "accumulation" may not be practical.)
* The remailer node n should "forget" the connection between incoming
and outgoing paths. The Chaum "digital mix" idea, when implemented
with tamper-resistant hardware, means a remailer can explicitly keep
no record of the incoming and outgoing paths, making collusion at a
later time (perhaps demanded by authorities) unproductive.
* The tamper-resistant, fully-automated nature is very important.
Running remailers on insecure boxes, or large Unix machines at
corporate and university sites, is not a long-term situation!
* Each originator of a piece of mail should, ideally, also operate a
remailing service (at least at some low level). This will allow any
message "traced back" (somehow) to a person to be "deniable"..."But I
didn't write that message, I just remailed it! And, no, my remailer
box doesn't keep any records."
* Payment for remailing services can be done in several ways.
Eventually, digital money can be used. A more immediately doable
scheme may to use the equivalent of "stamps." Since "digital stamps"
is confusing, call it "digtial postage." It may work as follows:
-Tim's Remailing Service sells "rolls" (lists) of 50-digit numbers
(large enough to make guessing unproductive) for perhaps $0.29 per
number. Each number is a "promise to remail" for some typical-sized
message, with more stamps needed for longer messages.
- No crypto protocols are really needed. Forgery by copying is handled
by simply saying that the first use of number is the only use...the
buyer of numbers must keep his numbers secure (at his site, and in
the remailing chain). The seller of numbers (e.g., Tim's Remailing
Service) is not likely to try to cheat purchasers of stamps by denying
he issued them (by standard reputation-based systems, independent
auditing services, etc.).
* Return envelopes can be handled by enclosing prepaid envelopes as
part of the message. (No record need be kept of the path, obviously,
as the return path through a web of remailers is independent of the
initial path.)
* It is very likely--almost certain, in fact--that various remailing
services will have have various policies, prices, reputations, etc.
Some will be cheap-but-not-secure, others will be secure-but-slow, and
so on. As our "Crypto Game" revealed so clearly last September at our
first Cypherpunks meeting, some remailer sites will be "narcs," some
will sell their knowledge to others, and so on. This is to be
expected, especially given that we will be operating in a nearly pure
anarchocapitalist situation, with no "enforcement" by
authorities...fortunately, free markets are quite efficient in
correcting such problems (the topic of another essay, perhaps).
But such a market will allow a user to select a remailing path, known
only to him (if collusion is avoided, and if the remailers have the
robust properties mentioned already).
I mention these robust properties--what we can call the "ideal
remailer"--because some of the existing or planned remailers do
various "non-ideal" things, like keep logs of all mail, run on
nonsecure machines, don't have strong encryption, and so on.
These imperfect remailers are still useful, especially at this early,
experimental stage. And they may exist even after more ideal remailers
come into use. Of course, there "market value" is likely to be fairly
low...
The robust, ideal remailers are what we should be shooting for.
And I think we're making amazingly fast progress.
-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^756839 | PGP Public Key: by arrangement.
Return to January 1993
Return to “tribble@xanadu.com (E. Dean Tribble)”