message depots

[jim@bilbo.suite.com (Jim Miller)]

The mailing list has been pretty quite today.  How about a new(?) idea to kick  
around...


One of the main unsolved problems with anonymous remailer networks is that,  
somewhere, there has to be a remailer that knows the mapping from your  
anonymous identity to your real identity (or at least your real e-mail  
address).  This means that you will have to trust the person running the  
remailer.

It seems to me that as long as remailers use a message *delivery* paradigm,  
this problem is unsolvable.  However, there is another paradigm that can be  
used which can solve this problem.  I call it the "message depot" paradigm.

It wastes a lot of bandwidth and cpu cycles.  However, I believe that in the  
not too distant future we'll have more bandwidth than we know what to do with  
(Telecosm).  Perhaps someday we'll also have more cpu cycles than we'll know  
what to do with (cray on a chip).  When that day arrives, this idea will become  
practical.  Until then, it will probably just be a toy.  Still...


Here how I see it working...


Simplest case:  One message depot

Not too different from a message-only BBS where all messages are encrypted.

If Bob wants to send a secure message to Alice and defeat traffic analysis, he  
will encrypt the message with Alice's public key and send it to the message  
depot.  Alice (and everyone else) periodically grabs *all* new messages from  
the message depot and attempts to decrypt them.  Alice finds that she can  
decrypt one of them; the one from Bob.  If Bob signed the message before  
encrypting it, and Alice has Bob's public key, she can verify the signature.   
Of course, this doesn't means she knows who "Bob" is, just that "Bob" sent the  
message.  Replace "Bob" with you favorite 'nym.

Since everybody is periodically downloading all new messages, the message depot    
doesn't know which message goes to which person.  Also, since the only clue to  
the sender's identity is the message signature, the message recipient may not  
know the identity of the sender.  (It would depend on how the recipient got the  
sender's public key.)


Scaling Up a Step:  Multiple message depots

Place a dozen message depots in the picture.  They each publish a unique public  
key, which means that people can send encrypted messages to the depots as end  
points.  The depots would poll each other for new messages to see if there is a  
message encrypted with their public keys.

Example: Depot A polls depot B for new messages.  Depot A attempts to decrypt  
the new messages.  It finds one that it can decrypt.  Upon decrypting the  
message, the depot sees a depot command and more message.  The one and only  
depot command will be: "PUT THE REMAINDER OF THE MESSAGE IN YOUR MESSAGE POOL  
AS A NEW MESSAGE".  Any message the depot cannot decrypt will be discarded.

How is this useful?  Well, by nesting a message in layers of digital envelopes,  
a sender can effectively move the message around the set of message depots  
until it reaches a depot that the final recipient polls.

Lets say that Bob knows that Alice polls Depot E, yet, for some reason, Bob  
doesn't want to send the message directly to Depot E.  What does he do?  He  
first signs the message with his private key (if he wants to), then encrypts it  
with Alice's public key, appends the depot command and encrypts everything with  
Depot E's public key, appends another depot command and encrypts everything  
with Depot B's public key.  He then sends the result to Depot B.

Depot B decrypts the message, sees the depot command, strips it off and places  
the remainder in its message pool as a new message.  Some time later, Depot E  
polls Depot B for new messages.  Depot B obliges.  Depot E attempts to decrypt  
the messages, finds that it can decrypt one of them.  It sees the depot  
command, strips and posts the remainder of the message to its message pool.   
Eventually, Alice polls Depot E for new messages.  And you can guess the rest.

If Bob doesn't know which message depot Alice polls, he can send copies to a  
number of different depots and hope that Alice will find it.  If he sent it to  
*all* depots, Alice will eventually get the message (unless she stops polling  
altogether).

Messages depots will delete messages after a configurable amount of time.   
Also, the depots will not keep track of who has sucked down which set of "new"  
messages.  This implies that the people polling the depots will have to tell  
the depot they want all messages since a given time.  The client-side polling  
software can easily keep track of this for the user.



Interfacing to the rest of the world:

To support sending messages to specific e-mail addresses or news groups,  
somebody will have to run a remailer that polls the message depots.  A sender  
will encrypt a remailer command and a message using the remailer's public key  
and direct it to the depot that the remailer polls.  The remailer will find the  
message and interpret the remailer command.  The command could be "SEND THIS TO  
<an Internet address>", or "POST THIS TO <a newsgroup>", or whatever.

Replies would have to travel back through the depot net.  The body of the  
message can indicate a message depot to "reply" to.


I believe most of this message depot idea can be automated.


As you can see, this mechanism consumes lots of bandwidth and lots of cpu.  But  
it does not require that you trust any part of the system except the part that  
sits in front of you.  I also believe that it successfully defeats traffic  
analysis.


"All the smarts will be at the fringes of the network." 


	- the guy who is writing Telecosm (and whose name escapes me).


Jim_Miller@suite.com