Re: [tor-dev] atlas.torproject.org question

[Karsten Loesing <karsten@xxxxxxxxxxxxxx>]

On 7/5/13 7:28 PM, me@xxxxxxx wrote:
> Mh I guess I need to refactor the search input to make it a bit more
> clear. Using ?search searches for fingerprints, nicknames or beginning
> of ip addresses in relays and nicknames or hashed fingerprints in bridges.
> 
> Atm I only hash all the requests for bridge or relay details.

Let me try to explain the idea behind the fingerprint hash madness:

We want to avoid that original bridge fingerprints go on the wire or
reach the Onionoo server.  Even though we use https, and even though the
Onionoo server is, in theory, trusted.

However, it would be extremely hard to make sure that bridge operators
never paste the content of there data/fingerprint file into their
browser.  It's the natural thing to do.

The solution is that the browser applies SHA1 on *any* 40 hex character
long fingerprint it receives from the user.  Onionoo can then look up
the hashed bridge fingerprint in its list.

To be more precise, Onionoo looks up 40 hex character long fingerprints
in four lists:

- original relay fingerprints: that's how Atlas and your new tool
support searches for relays by fingerprint *right now*.

- hashed bridge fingerprints: that's what your tool would request when
users paste the content of their data/fingerprint file and your tool
hashes it.

- hashed relay fingerprints: if your tool hashes all fingerprints,
including relay fingerprints, Onionoo wouldn't find relays anymore,
unless it also looks them up by hashed relay fingerprint.

- hashed hashed bridge fingerprints: if people see their hashed bridge
fingerprint on a details page and paste it into the search field, your
tool would hash it once more, so Onionoo needs some way to find the
bridge again.

Note that you don't need to hash anything you receive in a response from
Onionoo.  So, requests for bridge or relay details can use the same
identifiers that you receive in summary files.  These are all safe.

Also note that this doesn't work for hex strings with 39 or fewer
characters.  Nothing we can do about that, so leave them unchanged.


tl;dr: Your tool should apply SHA1 on all 40 hex character search inputs.

Best,
Karsten

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev