[tor-dev] Is Taking Checksum of Packet Payloads a Vulnerability?

[Paul Syverson]

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 at 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 at lists.torproject.org
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev