[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