From: tcmay@netcom.com (Timothy C. May)
Date: Tue, 24 Nov 92 21:12:15 PST
To: cypherpunks@toad.com
Subject: An Anonymous Contribution...
Message-ID: <9211250508.AA01456@netcom.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


(The following message arrive in my mailbox, with a request to repost
it anonymously. Sometimes these "manual" methods work pretty well!
--Tim May)


Tim,
	I have been following your arguments in CypherPunks.

The name will turn off a lot of your natural friends, but your arguments are
dead on.  The Crux of the matter is digital cash.  And getting
these anonymous remailers working.  PGP is a basic enabling
thing.  Not that RSA hasn't been around forever, but it
just wasn't useable without a standard.  My deepest gratitude
to you and your friends.

The remailer business needs to get standardized also.  My personal
hack is attached below.  One problem not addressed in the first
crop of remailers is the problem of how do you handle return
paths.  There are lots of trivial ways to get anonymous outgoing
mail. Most telephone systems do not identify the caller, there are
lots of other ways to get this function.  But the problem is getting
an answer back with out unmasking.  The mathematicians may be able to
conjure up a better scheme, but I see the backward security to be
simply a matter of tearing the connection (return path down) faster
than it can be backtraced.  It would be nicer if some kind of
DC-net return path could be devised.  But timeout control will 
definitely work. With a large number of the forwaring nodes, and
multi-hop paths, it would become quickly very impractical to shake
down the originator,  So the return path could be left "up" for 
quite some time before having to replace it.  Certainly long enough
for a reasonable reply.  Better yet of cource would be a completely
uncrackable return path that you could leave up long enough to use
institutional advertising.  Eg: run a business from.

Another way to leave up long lasting connections (return paths)
is to select one really HARD point node.  This is the one they
have to shake down first.  And use continuously shifting paths
behind that node.  (all sounds like a router ? ) 

If you could repost this anonymously
I sure would appreciate it.  I am  (ahem, respectable), and have
some kids left to feed. 

Could you tell me how to find out more about David Chaum's work?

do you have an email address for him, is he on one of the mailers,
or have anything published?

My hunch is that this whole business could heat up fast.  Within just a
few years the government could be forced into "wage/price" controls.
A great application for the NREN?

Thanks,  xxxxxxxx@yyyyyy.zzz

---------Tear off  -----

This is a proposal for a simple anonymous forwarding protocol.

1>  With the exception of cases 4> and 5> below:

    Any message addressed to the forwarding node that does not
    contain a valid PGP encrypted block, encrypted with the 
    node's public key causes the forwarding node to reply to
    the sender with its public key, plus whatever other 
    text the node wishes to add.

2>  If a properly encrypted message is decrypted with the node's
    secret key; The body of the decrypted message is scanned
    for the following sequence:

    "Please forward this message to:"  FORWARD.ADDRESS  "Thank you."

    The trigger strings are what is shown above in the quote marks
    but not including the quote marks.  No actual quote marks are used.

    Everything after the period of the Thank you. string is forwarded
    to the address specified by the FORWARD.ADDRESS string.

    Messages not containing the forwarding request are presumed
    to be addressed to the node itself.

3>  The incoming RETURN.ADDRESS and the FORWARD.ADDRESS are stored
    by the node.

---- Clean up.

4>  Receipt of a message whose RETURN.ADDRESS matches a stored
    FORWARD.ADDRESS will be repeated without modification
    to the stored RETURN.ADDRESS associated with the stored FORWARD.
    ADDRESS.  Bounced mail is returned similarly, 

5>  Receipt of a message whose RETURN.ADDRESS matches a previously
    stored RETURN.ADDRESS will cause a message to be
    forwarded to the previously stored FORWARD.ADDRESS 

    If the incomming message in this case contains a valid encrypted
    block, It will be decrypted and forwarded.  Otherwise, whatever
    contents of the body found will be forwarded.

    Subject lines should be repeated without modification.

    Null bodies or subject lines should work.

6>  In both cases 4> and 5>, the stored RETURN/FORWARD
    addresses are erased.

-xxxxxxx



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