Theoretical idea for enhancing Tor

Discussion in 'privacy technology' started by noone_particular, Jul 20, 2013.

Thread Status:
Not open for further replies.
  1. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    A theoretical idea to make Tor more resistant to timing attacks and adversaries who may be able to see both endpoints (NSA).
    Tor idea.PNG
    Tor would split the traffic into 3 branches. These would be recombined at the exit node. I realize this has some major hurdles involved, starting with knowing what pieces to recombine and the routing of each piece, but it would make it much more difficult to compare endpoint traffic and identify the user. The initial connections would also appear more like conventional traffic since it's common for a browser to connect to multiple locations on any given site.

    Any thoughts?
     
  2. EASTER

    EASTER Registered Member

    Joined:
    Jul 28, 2007
    Posts:
    11,126
    Location:
    U.S.A. (South)
    Browser inner workings are well beyond my expertise but your graphical representation definitely seems to carry some merit and interest.

    From the theoretical to useful implimentation is very welcome indeed if possible for Tor.
     
  3. The_PrivaZer_Team

    The_PrivaZer_Team Developer

    Joined:
    Feb 14, 2013
    Posts:
    1,077
    Location:
    France
    Very smart !
     
  4. x942

    x942 Guest

    This is interesting. It would be possible but would probably had more over head to TOR.
     
  5. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    You'd have to figure out a way for the exit node to recombine the encrypted data. I guess each stream would have to be assigned a random key that signifies it belongs with the other streams, after an extra layer of encryption on each stream.

    The overhead would be very significant as well as you're now waiting on significantly more terminals, with the exit node now having to pair and recombine the data after the next layer of encryption.

    It could work, but anyone who controls the exit node would still know that all three streams came from the same place. Nodes in the middle would know the same thing that they always do, the node before, the node after, right?

    You could propose this to the TOR group and see what they think.
     
  6. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    It would be a substantial memory load on the exit nodes, having to cache packets short term until the others in the sequence arrive. I don't think the processor load would be any worse than the load a browser adds. The way I visualize it, the entrance nodes wouldn't change, except that there'd be 3 of them. The hard part would be with the first stream sending data back thru the chain to the source with exit node routing info for the other 2 streams. That routing info containing the exit node IP would be encrypted until the 2nd hop where it would be decrypted and routed to the designated exit node. The final reassembly data would be decrypted by the exit node. It would be slower, but much more difficult for an adversary to follow, even if they could see both ends. It would be very demanding on their equipment to try to recombine all the streams, assuming that they could capture them all. Used on a larger scale, something like this might even make their new data center insufficient to the task.

    Regarding exit nodes seeing all the traffic, I see no way to eliminate that problem. That said, the more clean exit nodes Tor users add, the lower the chances of using a bad exit node becomes.

    What would be the best way to submit this idea to the developers?

    edited to fix typos.
     
    Last edited: Jul 20, 2013
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.