1994-02-11 - message pools revisited

Header Data

From: jim@bilbo.suite.com (Jim Miller)
To: cypherpunks@toad.com
Message Hash: 1cdba26734790ce437da8f2baad52587cee0b80128750353e0c39f1cadc78736
Message ID: <9402110507.AA13369@bilbo.suite.com>
Reply To: N/A
UTC Datetime: 1994-02-11 05:20:24 UTC
Raw Date: Thu, 10 Feb 94 21:20:24 PST

Raw message

From: jim@bilbo.suite.com (Jim Miller)
Date: Thu, 10 Feb 94 21:20:24 PST
To: cypherpunks@toad.com
Subject: message pools revisited
Message-ID: <9402110507.AA13369@bilbo.suite.com>
MIME-Version: 1.0
Content-Type: text/plain



Someone once said that a system of remailers is as strong as its  
STRONGEST link.

"As long as even ONE remailer in the chain is trustworthy, hiding the  
connection between incoming and outgoing messages, your anonymity is  
preserved."

While I agree with this in principal, I'm still not satisfied.  I  
want a remailer system that is secure from eavesdropping and traffic  
analysis even if ALL remailers are untrustworthy.

You might ask why I am not satisfied with current remailer designs.   
My unease stems mostly from irrational fears and distrust of the  
people running the remailers.  I don't personally know any of the  
people who are running remailers.  How can I be sure they are not  
colluding?  How can I be sure their machines haven't been penetrated  
by the Bad Guys?  It may be true that the remailer system is as  
strong as its STRONGEST link, but how do I know where that strongest  
link is?  As long as there is any doubt, I'm not satisfied.  Others  
may feel the same, and refrain from using remailers.

With sufficient traffic, messages exchanged via a message pool are  
secure from eavesdropping and traffic analysis, even if the message  
pool is untrustworthy.  The problem is, the message pool schemes I'm  
familiar with (admittedly, not that many) don't scale up well.

One kind of message pool works like a mailing list.  People subscribe  
to the message pool by sending the message pool server their e-mail  
address (and perhaps also a public-key).  A member of the message  
pool sends an anonymous message by encrypting it with the recipient's  
public key and sending it to the message pool server.  The message  
pool server sends a copy of the encrypted message to every member of  
the message pool service.  Only the person who has the corresponding  
private key will be able to decrypt the message.  All other members  
of the pool will get garbage.  One benefit of this type of message  
pool is that the messages come to you.  You don't have to go and get  
them.  Also, if an encrypting remailer is a member of the message  
pool service, then members can "route" messages through it to  
non-members.

Another kind of message pool works like a BBS system.   A person  
sends a message by encrypting it with the recipient's public key and  
sending it to the message pool server.  The message pool server adds  
the message to a pool of messages it maintains.  Messages stay in the  
pool for a finite time, and then are deleted.  People periodically  
downlaod the current set of unexpired messages from the pool and see  
if they can decrypt any of them.  If they find a message they can  
decrypt, then the message was meant for them.  The advantage to this  
scheme is that there is no concept of a "member".

Some time last year, before I joined the cypherpunks mailing list, I  
posted a message to sci.crypt suggesting that people create a news  
group called "alt.crypt.messages" so people could exchange messages  
anonymously.  Some people said this was a good idea.  Others said  
that it was suggested before by others (it had).  Still others said  
it wouldn't work because people wouldn't carry the news group because  
they wouldn't be able to know what kind of stuff was being sent  
through it.

I think it is time to ask again.  Do people think it would be a good  
idea to create a news group for exchanging anonymous messages?   
Alternatively, perhaps some cypherpunks with free time would like to  
code up a simplified distributed message pool service modeled after  
USENET.  You would need servers to distribute the messages and  
front-end "reader" apps to simplify searching for messages destined  
for you.  Any takers?

Jim_Miller@suite.com





Thread