From: "Mark M." <markm@voicenet.com>
Date: Sun, 28 Apr 1996 10:55:42 +0800
To: Alan Bostick <abostick@netcom.com>
Subject: Re: An idea for refining penet-style anonymous servers
In-Reply-To: <Uc5fx8m9LojB085yn@netcom.com>
Message-ID: <Pine.LNX.3.92.960425181712.779A-100000@gak>
MIME-Version: 1.0
Content-Type: text/plain


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

On Thu, 25 Apr 1996, Alan Bostick wrote:

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

Funny.  I had the *exact* same idea a couple of months ago.  However, I
did find several flaws in it.

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

Perhaps the address could be hashed several times for the table look-up and
then the address could be hashed a less number of times for decryption with
the IDEA key.  This reduces the amount of code needed and also eliminates
any problems with only using 128 bits of SHA output.

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

In the scheme I thought of, a password would be sent with the message, which
would be hashed, appended to the hash of the address, and then hashed again
to get the decryption key.

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

Searching for the real address behind a pseudonym is not hard at all.  Just
hash the anonymous address, look it up in the table, then decrypt the
cooresponding encrypted address.  This was the major flaw that I spotted with
this scheme.

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

The only other problem I found is a pretty minor one: the address database
would be twice as large as it would be if it was stored in plaintext.  I
don't think that much security is gained by using this scheme.

- -- Mark

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
markm@voicenet.com              | finger -l for PGP key 0xf9b22ba5
http://www.voicenet.com/~markm/ | bd24d08e3cbb53472054fa56002258d5
"The concept of normalcy is just a conspiracy of the majority" -me

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv

iQCVAwUBMX/727Zc+sv5siulAQGbwgP/XfQ2qw4HrzRX/DtFq542EnwnDuE+ACYk
OG3/dlCzqn4mmXNBB1QAh3K7tzNS0Gah46fODI/5lTHRqwyFehFIC96X3L45mEPO
QJWcvu2mqf6KhR5QnanB6jNw+okp1NAvTRJA2QhIZtPBBS3Xm3NfhrtHF8BKdxdu
WqjXM4HMjxs=
=gpZ8
-----END PGP SIGNATURE-----