1996-04-25 - An idea for refining penet-style anonymous servers

Header Data

From: abostick@netcom.com (Alan Bostick)
To: cypherpunks@toad.com
Message Hash: 64cdc1ce1920f9514492f32cc005d1b58d709715aad14eef26af862a1791e4d8
Message ID: <Uc5fx8m9LojB085yn@netcom.com>
Reply To: N/A
UTC Datetime: 1996-04-25 16:41:35 UTC
Raw Date: Thu, 25 Apr 1996 09:41:35 -0700 (PDT)

Raw message

From: abostick@netcom.com (Alan Bostick)
Date: Thu, 25 Apr 1996 09:41:35 -0700 (PDT)
To: cypherpunks@toad.com
Subject: An idea for refining penet-style anonymous servers
Message-ID: <Uc5fx8m9LojB085yn@netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

Does the world need to have the anon.penet.fi model of anonymous email
and news posting refined, given the existence of Cypherpunks remailers
and Mixmaster digital mixes, not to mention nymservers?

I will listen respectfully to the arguments of the people who say "no",
and they're very likely right.  But penet *is* the most widely used
means of anonymous communication on the Internet - largely because of
its ease of use compared to genuinely secure remailers and mixes.

The other night, while sick and feverish with the flu, a scheme popped
into my head that would seem to make penet-style anonymous servers less
vulnerable to compromise through seizure of the remailer equipment or of
the address database.  In the cold light of day and normal temperature,
it still seems like a sound idea to me, and I wondered what other people
would think of it.

My scheme is the design of the address database.  It consists of two
hash tables, one for sending messages (which maps anonymous IDs onto
sender's addresses), and one for receiving them (mapping recipient's
addresses onto anonymous IDs).  A cryptographically secure hash (say,
MD5) is used for the index of both tables.

The index of the sending message table is the MD5 hash of the sender's
address.  The table entry the index points to is the sender's anonymous
ID, encrypted by a symmetric algorithm (maybe IDEA).  The encryption key
would be a different hash, by another algorithm (let's suppose it's
SHA), of that same address.

In forwarding a message, the server MD5-hashes the sender's address and
looks at the table.  If it doesn't find a corresponding entry, it
creates one.  If it *does* find an entry, it SHA-hashes the sender's
address and uses this key to decrypt the anonymous ID.  In the unlikely
event of collision the decrypted ID will be gibberish and the server
does something sensible (like appending padding to the address and
trying again).  The header information is filtered and the anonymous ID
inserted in the From: line. 

The receiving message hash table is designed similarly, in reverse.  The
index of the hash table is the MD5 hash of the anonymous ID; the entry
in the table is the recipient's email address, encrypted with the SHA
hash of the anonymous ID.  When a message comes in, the anon ID is
hashed and looked up in the table.  If  nothing is found, the message is
bounced. If an entry is found, the anon ID is SHA hashed and the table
entry decrypted.  If it is gibberish, a collision has taken place and
handled appropriately.  The message is then forwarded to its intended
recipient. 

What all this accomplishes is to obscure more information from attackers
and from honest operators.  In the event of abuse it is a simple matter
to find out who the abusers are and block them out.  If the operator is
subject to subpoena, anyone named in the subpoena can be easily
identified . . . *but nobody else can!*  Authorities cannot use a search
for one identity as an excuse for a fishing expedition in the address
database. 

(Obscuring information from honest operators can protect the operator
when questions of liability or even conspiracy come up.)

There is a way that attackers who have seized or copied the database can
search it - by trying it out on anonymous IDs, or user addresses, until
they hit paydirt.  And of course such an anonymous server can be no more
trustworthy than its operator; and the fundamental security limitations of
the penet-style anonymous server are well-understood.

So what do people think of this scheme of mine?  Are there drawbacks or
weaknesses that I'm not seeing?  Is it a good idea?  I'd really like it
if *something* good came out of being laid up with the flu. 

- -- 
Alan Bostick               | They say in online country there is no middle way
mailto:abostick@netcom.com | You'll either be a Usenet man or a thug for the CDA
news:alt.grelb             |    Simon Spero (after Tom Glazer)
http://www.alumni.caltech.edu/~abostick

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQB1AwUBMX+n0OVevBgtmhnpAQFkrwL+N+CklsLNsqHXNPnCOs1mogNydNnCtvGs
cUqK9rG3xpTYFsPMH6lhWq8wfPfKtQ88xs3RC/JE8ypcDZBugifNDf7hTuGeLZ8n
Q8RDvnAq0qNz9rxqHiMuyOQ3kf6YEVys
=g5SU
-----END PGP SIGNATURE-----





Thread