Re: One Time Reply Blocks (was Re: strengthening remailer protocols)

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. ------------------------------------------------------------------------- Bill Frantz | "Lone Star" - My personal | Periwinkle -- Consulting (408)356-8506 | choice for best movie of | 16345 Englewood Ave. frantz@netcom.com | 1996 | Los Gatos, CA 95032, USA

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 ----------------------------------------------------------
participants (2)
-
frantz@netcom.com
-
Lance Cottrell