[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #10969 [Tor]: Set of guard nodes can act as a linkability fingerprint



#10969: Set of guard nodes can act as a linkability fingerprint
------------------------+-----------------------------------
     Reporter:  asn     |      Owner:
         Type:  task    |     Status:  new
     Priority:  normal  |  Milestone:  Tor: 0.2.5.x-final
    Component:  Tor     |    Version:
   Resolution:          |   Keywords:  tor-client tor-guards
Actual Points:          |  Parent ID:
       Points:          |
------------------------+-----------------------------------

Comment (by NickHopper):

 Leif and I talked about this a bit at the Dev meeting -- it's a pretty
 tough problem to solve. From an anonymity standpoint, probably the most
 attractive solution is something like:

 1. At startup the user (or OS) provides a pass phrase, PP.

 2. For each SSID the user connects to, the tor client has a separate state
 file.

 3. The state file is encrypted using Hash(PP|SSID) as the key.

 4. tor can determine which state file to use by trial decryption - if none
 decrypt correctly, the client uses a new state file, picking fresh
 guard(s) for this SSID.

 What's unpleasant about this approach is that trial passphrases can be
 tested offline, and the SSID doesn't add a lot of entropy to the task
 (none if the adversary knows at least one SSID the client connected
 through), so a user's state file essentially becomes a record of all the
 SSIDs she has connected to. One option would be to convert this into an
 online brute force attack, by incorporating some unpredictable element
 that is retrieved through tor into the key calculation. The process would
 become something like:

 1. At startup the user (or OS) provides a pass phrase, PP.

 2. For each SSID the user connects to, the tor client has a separate state
 file.

 3'. To compute the key, the client connects through tor to a "blind
 signing hidden service," which signs exactly one value per connection;
 the client gets a signature Sig on Hash(PP|SSID) and then computes
 Hash2(Sig|PP|SSID) to compute the state file encryption key.

 4. as above.

 The idea here is that each pass phrase test requires an online connection
 attempt, so we can naturally rate limit the brute forcing speed.

 The connection to the hidden service need not use a guard node, because
 the fact that a new session connects to the blind signing service isn't
 private; and since the signatures are blinded the service can't accumulate
 information about a user.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/10969#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs