Re: One Time Reply Blocks (was Re: strengthening remailerprotocols)

[Lance Cottrell <loki@infonex.com>]

At 10:33 AM -0700 9/10/96, Bill Frantz wrote:
>At 10:06 PM 9/9/96 -0700, Lance Cottrell wrote:
>>At 4:19 PM -0700 9/9/96, Bill Frantz wrote:
>>>To paraphrase John Von Neumann, any system which uses reply blocks is in a
>>>state of sin.  By this I mean that if there is a chain pointing at you, a
>>>sufficiently powerful attacker can walk down that chain and find you.
>>>
>>>Given that, I will join the state of sin by proposing a mechanism which
>>>will allow Alice to receive a reply from Bob, but change her mind at any
>>>time.  The basic idea is to have a one-time reply block which either Bob or
>>>Alice can send to.  If Alice thinks that too much time has elapsed, and
>>>powerful enemies are walking down her reply block chain, she can send
>>>herself a reply and break the chain.  (She might send a reply thru each
>>>link in the chain to break all the links.)
>>
>>The reason the message is not resendable is that the remailers keeps track
>>of the serial number of that header. If forced, the log of serial numbers
>>could be deleted, and the operator would process the message.
>>
>>Unless you are assuming some key archived by each remailer for the reply
>>block, then I think it will be possible to repair the chain.
>
>I was thinking of storing a reply-key in each remailer.  The protocol might
>go something like this (straw man proposal):
>
>(1) Alice picks n random ids (say 160 bits or so) and n random keys.
>(2) Alice sends the combination <id[i], key[i]> to remailer[i], i=0,n-1.
>(3) Alice builds a reply block which consists of the remailer return path,
>each element encyphered with the appropriate key and sends it to Bob.
>(4) When a remailer processes a reply block element, it removes it from the
>reply block, looks up the id in its database, decrypts the address of the
>next hop, removes the database element and forwards the message.
>
>If Alice becomes nervous, she sends n "replys" thru each remailer to cause
>the return path to be destroyed.
>

It is a good idea, but it does involve another whole level of
infrastructure. I am not at all sure that message pools are not a better
system. Your suggestion requires The client to do a lot of work, and for
the remailers to store many keys for indefinite periods.

	-Lance

----------------------------------------------------------
Lance Cottrell   loki@obscura.com
PGP 2.6 key available by finger or server.
Mixmaster, the next generation remailer, is now available!
http://www.obscura.com/~loki/Welcome.html or FTP to obscura.com

"Love is a snowmobile racing across the tundra.  Suddenly
it flips over, pinning you underneath.  At night the ice
weasels come."
                        --Nietzsche
----------------------------------------------------------