On Mon, Nov 06, 2000 at 05:21:34PM -0500, Adam Back wrote:
Adam Shostack made the comment about insufficiency of padding in PipeNet you're referring to.
Sorry about that.
The other thing we could do is move content inside the network -- much of the traffic analysis material comes from the fact the exit traffic is in the clear. For example if many web servers supported connections from the freedom cloud using freedom protocol, and nodes in the network did per hop padding using a modified PipeNet scheduling algorithm where you would try to use PipeNet scheduling, but instead of delaying, if a packet didn't arrive in time, you would send some cover instead on a hop by hop basis. Then you package this thing as an accompanying apache server and encourage lots of people to run it.
I don't think that works very well. When you send some hop by hop padding, every node downstream would be able to tell that some delay occured somewhere upstream in the connection. So if either the receiver (the last node) or the next to last node is compromised, the attacker would be able to trace the caller by correlating between delays in the network and where hop by hop padding occurs.