Re: Message Havens

Thus spake SINCLAIR  DOUGLAS N <sinclai@ecf.toronto.edu>:
>  klbarrus@owlnet.rice.edu (Karl Lui Barrus) writes:

>> Maybe I wasn't clear in what the "message haven" offered... I'm trying
>> to get away from the penet style mapping tables, persistent
>> information tying you and your pseudonym, and solve the "unsolicited
>> anonymous mail" problem.  The message haven requires no trust, no
>> tables, no information since it just accepts message and files them,
>> and if you retrieve all the message, the haven can't figure out which
>> ones you are interested in!
>This flavour of message haven would not require persistent tables.
>A crooked operator /could/ maintain them, but unlike penet they are
>not required.  Every time you log into a message haven, you tell it
>what tags you are interested in.  Here the level of trust is similar
>to that of a regular remailer.  The remailer /could/ keep logs to
>destroy your anonymity, but we hope it doesn't.
>
>I realize this solution is far from ideal.  But as I posted before,
>I don't believe the numbers favour a message haven where everything
>is downloaded.  I have this nagging feeling that there is some
>very elegant cryptographical way of doing this employing secret
>sharing, but I can't actually think of how to do it.

Couldn't each message have a short header, which is encrypted with the 
final recipent's public key?  When you go to retrieve mail from the haven, 
you request the complete list of headers (or at least those that are new). 
If you can decrypt the header, then the message is for you.  You then 
request that those messages, and also some random messages, be sent to you. 
If the sender uses one or more current-style remailers to send his/her 
message to the haven, it would much more difficult to work out a map of 
who is talking to whom.  

david
--------------------------------------------------------------------------------
David Scheidt                      PGP 2.3 key by email
scheida@yang.earlham.edu           or finger scheida@earlham.edu

"If we don't remember what we do, how will we know who we are?"
					-Ronald Reagan

As regards message havens...

	Seems to me that you should also have all of the messages to you 
collated into one block, have some random length padding added, and then 
encrypt the whole thing and send it back to you. If you have this all 
done automatically by the server at the haven, then you may not even need 
to call all of those random other messages down. That is, assuming you 
trust the sysadmin of that haven, which is probably not the best of ideas.

	Anyhow, you can do somwthing similar with anonymous remailers. 
Maybe someone should (or already has) written a client which will take 
your message, pad it with some extra gibberish, then construct all of the 
headers necessary (and encrypt several times along the way) to post it 
along a path of remailers which either the user inputs, or it randomly 
determines. Seems to me that if you leave the actual routing in the hands 
of the user, and not at the discretion of the first remailer you send it 
to, you gain a far more secure transmission. Of course i could be wrong...

	It would be nice if remailers supported padding from this end as 
well. ie, insert something like 

::
Padding: ***

	and this tells the remailer that, after decrypting the message 
(presumably it was sent to a remailer that supports encryption) it should 
discard whatever comes after the ***, or however it happens to be 
implemented. This gives yet another layer of obfuscation between me and 
whoever doesn't like me...

*       *       Mikolaj J. Habryn
                dichro@tartarus.uwa.edu.au
    *           "Information wants to be free!"
                PGP Public key available by finger
    *           #include <standard-disclaimer.h>

> 	Seems to me that you should also have all of the messages to you 
> collated into one block, have some random length padding added, and then 
> encrypt the whole thing and send it back to you. If you have this all 
> done automatically by the server at the haven, then you may not even need 
> to call all of those random other messages down. That is, assuming you 
> trust the sysadmin of that haven, which is probably not the best of ideas.
The only problem I see here is that it requires the message haven
know your public key.  All sorts of man-in-the-middle attacks become
possible here.  I don't know that I'd trust a machine to do an intellegent
web-of-trust; it can't actually meet people at a conference and swap cards.