Wei writes:

...

[...] 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. [...]

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.

I think I phrased that badly. The hop that didn't receive enough packets on a link would create padding, but the padding would be end-to-end between that hop and the end hop (the recipient node, be that client or freedom enabled web server). Clearly if you compromise enough exit nodes, you can then selectively DoS links and observe the padding as the exit node must see it. With freedom and to some extent with the freedom on servers variant (my earlier comment quoted above) I think 3 hops is roughly the maximum useful number of hops. This is because it's a real-time protocol and it's not end-to-end padded. In the case of freedom it's simply not end-to-end padded, with the servers variant it could be end-to-end padded, but the attacker could compromise other nodes, induce delay and therefore persuade the node to pad and then correlate the padding with the compromised exit node. Hence in either case two compromised nodes gives you a lot of info. With PipeNet's synchronous mix-net you don't have this problem, but you have the performance and DoS problems.

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.

I agree with this conclusion despite the ambiguous explanation -- the attack is a little more active, and requires more compromises, but still holds I think. So this type of network is not secure against too many node compromises, where-as PipeNet's synchronous mix-net has more mix-net like properties. However it offers reasonable security, it should have reasonable performance, be resistant to widespread DoS and have similar bandwidth overhead to PipeNet. You could use traffic shaping (in any of the networks we discussed) to reduce the bandwidth consumption in quiet periods as Lucky described in the past based on slowly moving average, typical period fluctuations etc. There is another parameter in the previous comparison I missed off: 4. Bandwidth Cost With the server variant of freedom you could also mix different classes of traffic -- some with end-to-end padding and some with no padding. The padding is fairly expensive in bandwidth. Also one could have different route create and destroy rules -- PipeNet create and destroy mixing will make route setup quite slow. In this way you could build a network which supports different performance, cost, DoS resistance and security trade-offs. You could presumably allow PipeNet in the same network also. There is some advantage to having more people using the same protocol, because there will be limits to the cover provided to each other of different traffic classes. Weaker things could be eliminated from the picture for example with higher level threat models, if the threshold of compromised nodes or capability of attacker is above the weaker higher performance routing protocol, but below that required to compromise the high security protocol. Adam