In message <199408110444.VAA20478@jobe.shell.portal.com>, hfinney@shell.portal.com (Hal Finney) wrote:
Other ideas have been proposed for this problem. Chaum suggested having a public area where messages for a group of people would arrive;
This is an excellent way of getting around this problem, but it uses lots of bandwidth. Another idea I have been interested in is picking a message up from the middle of a chain. In other words, your return address block lists 10 remailers (for example), and you just happen to run the 7th. After the message hits your remailer, it continues through a few more hops and then gets eaten by /dev/null. Your remailer, meanwhile, has snarfed a copy of ALL of the traffic running through it to another machine. There you manually enter parameters to use to scan for messages to you. If the feds come to you and demand that you perform this process while they monitor it, you enter a different set of parameters that uncover innocent messages that you arrange to be occasionally passing through. If they've traced a message all the way to the end, they'll know it was to one of the 10 remailer operators in the chain, but several of them are in inconvenient jurisdictions... and maybe one of these tap-points was arranged to start another chain.....
One problem with anonymous return addresses is that the address changes deterministicly as each layer is stripped off. This allows the message to be tracked by introducing copies with different bodies but the same ARA (which is why Chaum specified use-once). Eric Messick proposed a system in which the message bodies would be changed at each step by the remailers involved. I don't recall the details, but I think that in order to read the message the user had to send it back through those same re- mailers after receiving it, to undo the transformations which had been done on it.
Not quite that bad. Another message would have to be sent only if there was insufficient postage for one of the remailers, and that remailer decided to deliver it rather than just dropping it. Otherwise, all of the info necessary to decode the message is known to the recipient.
It was a complicated scheme and we really didn't spend enough time on it.
That is certainly true. I've been trying to figure out how to subdivide the project so that early implementations can be done without sacrificing the ability to do the more complex stuff later.
I view easy-to-use, secure ARA's as an unsolved (and perhaps unsolvable) problem.
I don't think they can be unconditionally secure without wasting lots of bandwidth. Having one of the links be a wide area broadcast is very secure, but expensive in bandwidth. It's all economics...
Hal Finney
-eric messick