Wei Dai wrote:
On Thu, Nov 02, 2000 at 10:14:24AM -0500, Adam Shostack wrote:
Actually, I'm unconvinced that even pipenet style padding is sufficient. Looking at the work on traffic analysis thats been done, we're in about 1970. We have one time pads (dc-nets), and some other stuff, but we don't have a DES to analyze. We have an adversary who has spent a long time learning how to do this well.
I'd prefer if people talked about PipeNet style traffic scheduling instead of PipeNet style traffic padding. What's really important to PipeNet security is that the timing of packets don't leak information, and padding is just a part of what's necessary to achieve that kind of timing. So I'd agree with you that padding by itself isn't sufficient, but I'd be interested in hearing more if you think PipeNet as a whole isn't sufficient.
For those that don't know about PipeNet Wei has a description here [1]. PipeNet is a synchronous mix-net where users stay connected and consume bandwidth 24x365 to avoid revealing when they are using it. PipeNet's synchronous behavior would be implemented on top of TCP with it's best-effort service by using the following scheduling algorithm (from [1]): | Each node expects one packet from each link id in each time unit. | Extra packets are queued for processing in later time units. | However, if a node does not receive a packet for a link id in a | particular time unit, it stops normal processing of packets for that | time unit and queues all packets. This ensures that any delay is | propagated through the entire network and cannot be used to trace a | particular connection. This is to defend against active attacks delaying packets to observe the effect on the network and hence trace routes. However I think this scheduling algorithm would have the side effect of making this variant of PipeNet very vulnerable to DoS attacks. Any user can arbitrarily delay packet delivery for the entire network by ceasing to send packets. It would also seem that performance would degrade badly to effectively the performance of the worst ping time link. (PipeNet uses mixing at each node.) Perhaps there are some engineering trade-offs you could make if you were to try to practically implement PipeNet. Adam [1] http://www.eskimo.com/~weidai/pipenet.txt