] The complex version: Onion Routing is a connection-oriented
] anonymizing communication service. Users choose a
] source-routed path through a set of nodes, and negotiate a
] "virtual circuit" through the network, in which each node
] knows its predecessor and successor, but no others. Traffic
] flowing down the circuit is unwrapped by a symmetric key at
] each node, which reveals the downstream node.

What about traffic analysis? While I don't know much about this, I had a talk about this very same thing with Decius not too long ago. Don't you need some type of anonymous cloud takes and "holds" your request for some random length of time? That way if enough people are inject requests into the cloud, there is no way to match an incoming transmition cloud with one leaving the cloud.

Acidus wrote:
] ] The complex version: Onion Routing is a connection-oriented
] ] anonymizing communication service. Users choose a
] ] source-routed path through a set of nodes, and negotiate a
] ] "virtual circuit" through the network, in which each node
] ] knows its predecessor and successor, but no others. Traffic
] ] flowing down the circuit is unwrapped by a symmetric key at
] ] each node, which reveals the downstream node.
]
] What about traffic analysis? While I don't know much about
] this, I had a talk about this very same thing with Decius not
] too long ago. Don't you need some type of anonymous cloud
] takes and "holds" your request for some random length of time?
] That way if enough people are inject requests into the cloud,
] there is no way to match an incoming transmition cloud with
] one leaving the cloud.

It's a performance tradeoff, and it is thought that even the typical padding and reordering is not sufficient. The design document has this to say:

No mixing, padding, or traffic shaping (yet): Onion Routing originally called for batching and reordering cells as they arrived, assumed padding between ORs, and in later designs added padding between onion proxies (users) and ORs [27,41]. Tradeoffs between padding protection and cost were discussed, and traffic shaping algorithms were theorized [49] to provide good security without expensive padding, but no concrete padding scheme was suggested. Recent research [1] and deployment experience [4] suggest that this level of resource use is not practical or economical; and even full link padding is still vulnerable [33]. Thus, until we have a proven and convenient design for traffic shaping or low-latency mixing that improves anonymity against a realistic adversary, we leave these strategies out.

They suggest (but dont say outright) that reordering & batching may occur at some point. It would certainly give me more warm fuzzies if it did.

http://freehaven.net/tor/cvs/doc/design-paper/tor-design.html

makes for an interesting read...

Acidus wrote:
] ] The complex version: Onion Routing is a connection-oriented
] ] anonymizing communication service. Users choose a
] ] source-routed path through a set of nodes, and negotiate a
] ] "virtual circuit" through the network, in which each node
] ] knows its predecessor and successor, but no others. Traffic
] ] flowing down the circuit is unwrapped by a symmetric key at
] ] each node, which reveals the downstream node.
]
] What about traffic analysis? While I don't know much about
] this, I had a talk about this very same thing with Decius not
] too long ago. Don't you need some type of anonymous cloud
] takes and "holds" your request for some random length of time?
] That way if enough people are inject requests into the cloud,
] there is no way to match an incoming transmition cloud with
] one leaving the cloud.

It's a performance tradeoff, and it is thought that even the typical padding and reordering is not sufficient. The design document has this to say:

No mixing, padding, or traffic shaping (yet): Onion Routing originally called for batching and reordering cells as they arrived, assumed padding between ORs, and in later designs added padding between onion proxies (users) and ORs [27,41]. Tradeoffs between padding protection and cost were discussed, and traffic shaping algorithms were theorized [49] to provide good security without expensive padding, but no concrete padding scheme was suggested. Recent research [1] and deployment experience [4] suggest that this level of resource use is not practical or economical; and even full link padding is still vulnerable [33]. Thus, until we have a proven and convenient design for traffic shaping or low-latency mixing that improves anonymity against a realistic adversary, we leave these strategies out.

They suggest (but dont say outright) that reordering & batching may occur at some point. It would certainly give me more warm fuzzies if it did.

http://freehaven.net/tor/cvs/doc/design-paper/tor-design.html

makes for an interesting read...