Re: [tor-bugs] #21615 [Metrics/Atlas]: Use hashed fingerprint in all lookups

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#21615: Use hashed fingerprint in all lookups
---------------------------+-----------------------------------
 Reporter:  cypherpunks    |          Owner:  irl
     Type:  enhancement    |         Status:  needs_information
 Priority:  Medium         |      Milestone:
Component:  Metrics/Atlas  |        Version:
 Severity:  Normal         |     Resolution:
 Keywords:                 |  Actual Points:
Parent ID:                 |         Points:
 Reviewer:                 |        Sponsor:
---------------------------+-----------------------------------

Comment (by cypherpunks):

 Replying to [comment:1 irl]:
 > Atlas doesn't claim to hash fingerprints and we instead provide
 instructions on how to look up bridges using the hashed fingerprint. I'm
 not convinced this is a defect, as clearly lookups using fingerprints
 work.
 To give some back story, I noticed the inconsistency while working on
 #15415. Looking at the requests, the hash would change between requests
 because the search page doesn't hash the fingerprint and the details page
 does. For example, looking at the requests to Onionoo when browsing to
 https://atlas.torproject.org/#search/BC630CBBB518BE7E9F4E09712AB0269E9DC7D626,
 the first details request (from the search page) uses the actual
 fingerprint while subsequent calls (from the details page) use the hashed
 fingerprint.

 > Is Onionoo generally happy to respond to hashed fingerprints in place of
 fingerprints for both relays and bridges then?

 Onionoo does seem to be happy. For example, browsing to
 https://atlas.torproject.org/#details/C7A9862525665B3E5E48D27FCBC0D8B6E8A9F3C7
 which is a bridge shows a different hash in the request to Onionoo because
 it is hashed again.

 > What is the gain for this over the loss that a bridge fingerprint could
 be entered into the browser and perhaps leaked?
 I'm not sure. The hashing of fingerprints can be traced back to commit
 [https://gitweb.torproject.org/atlas.git/commit/?id=ba56727fad15316814a7caf4acee4e49c173b86c
 ba56727fad15316814a7caf4acee4e49c173b86c] which doesn't give a motivation
 other than that Onionoo supports it.
 >
 > I'm not saying it's a bad idea, I'm saying I'm not sure I understand the
 motivation yet.
 I just like it to be consistent. Either everything should hash before
 requesting Onionoo or nothing should. Because its obviously hard to
 remember and check that every request should hash before sending it, i
 lean towards not hashing. It would remove the dependency on the JavaScript
 SHA library, remove some code, and speed Atlas up slightly.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21615#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