Dave is correct. This attack will not work for the reaseons he said. Just a minor quibble: Dave is not quite correct about the origins of 'onion routing'. We called it that because of a data structure that we used in the original system (and shared by our second generation system and also ZKS Freedom and some others, given an abstract enough description). This data structure does not exist in Tor, which instead uses "onion skins". The original design created a layered public-key structure: each layer contained the address of the next hop and material sufficient to create the symmetric keys that would be used to encrypt and decrypt data passing on the established circuit. There was nothing but layers, with no message or data in the middle---just like an onion. Anything that emerged from the exit node headed for Bob would not be encrypted by the onion that built the circuit; it would be encrypted by the symmetric keys that were distributed via the onion. It's true that this is encryption is layered, but there is something at the middle of it, the traffic to be sent to Bob. We did sometimes call this 'data onion' because of the layering, but we called it 'onion routing' because of the circuit-creating data structure being comprised of nothing but layers. Tor uses onion skins, which roughly are one-layer onions, to build circuits. Among other things, this gives Tor's traffic forward secrecty. Onions, per se, were never used in Tor (even though Tor's onion routing ;>) HTH, Paul On Sat, Dec 17, 2011 at 08:40:33AM -0800, Dave Jevans wrote:

This attach will not work. Alice's tor client on her computer creates a Multi layered encrypted connection, hence the term onion routing. If Alice's connection to the exit node goes through 3 tor nodes (eg entry, middle, exit) then the connection is encrypted three times with different keys as it enters the entry node EN. This decrypts the first layer, and this traffic is sent to the middle node. This node decrypts the second layer of the onion, and sends ti to the exit node. The exit node decrypts the third level of onion encryption and forwards to Bob.

Thus a packet sniffer doing checksums anywhere in between wil Not see the same traffic, and will not be able to correlate between Alice's packets and those that traverse to Bob, or between any of the intermediate nodes.

On Dec 17, 2011, at 8:25 AM, "Daniel Cohen" <danielc192@gmail.com> wrote:

...

Hi,

I am new to Tor, but after reading about its design, and reading a few research papers on its vulnerabilities (specifically timing attacks), I had the following thought:

Suppose Alice is connecting to Bob via Tor, using HTTPS encryption. She sends a packet to the Tor entry node (call it En). The packet travels through the network, emerges from an exit node (call it Ex), and arrives at Bob.

Alice => En => Tor Network => Ex => Bob

Now suppose that Alice's connection is being monitored, as well as a group of the exit nodes (which are either hostile or having their packets sniffed). When the encrypted packet leaves Alice on its way to En, it is sniffed, and a checksum is made of its encrypted payload. The packet then continues through the network as usual, and emerges from an exit node.

It appears to me that the attacker need only check packets coming out of exit nodes to see if their payload checksums match that of the packet observed leaving Alice. Unlike timing attacks, which require a reasonable number of packets to confirm Alice's identity, this attack would require only one, since checksums have an almost 0% chance of collision. If a packet with the same payload checksum as Alice's is discovered, it almost certainly originated from her.

Is this a problem with Tor's architecture? If so, has this issue already been addressed?

Thanks,

Daniel Cohen _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

---

tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev