On Mon, Jan 31, 2011 at 05:50:02PM -0500, Nick Mathewson wrote: > On Mon, Jan 31, 2011 at 3:52 PM, Karsten Loesing > <karsten.loes...@gmx.net> wrote: > > On Mon, Jan 31, 2011 at 03:03:57PM -0500, Ian Goldberg wrote: > >> Is there enough entropy in the things you're hashing to prevent > >> reversing the hash? > > > > Well, I guess so. We're hashing the bridge identity fingerprints. From > > dir-spec.txt: > > > > "fingerprint" fingerprint NL > > > > [At most once] > > > > A fingerprint (a HASH_LEN-byte of asn1 encoded public key, encoded in > > hex, with a single space after every 4 characters) for this router's > > identity key. > > > > Does this mean we're safe here? > > I think we're okay. A censor could in theory correlate this with > certificates, if it had them, but I think most automated certificate > crawlers will wind up with link certs only, so the censor will need to > do their own crawling to find bridges. > > If we care a lot, we could instead have the sanitization process use > some secret X and report H(X|H(ID key)) in place of H(ID key).
Your call. If you think adding a secret X is important here, we can change the process. Note that this change affects all published sanitized bridge descriptors, because they contain these hashed fingerprints, too. We should be consistent with the fingerprints we put into bridge pool assignments and bridge descriptors. That doesn't exactly make this a cheap change, because I'll have to sanitize two years of descriptors again. But if it's important, I can do it. Speaking of sanitizing bridge descriptors, there's a related change to the current sanitizing process discussed in Trac ticket #2435. I'd really like to hear your opinions to that ticket (either here or as comments to the ticket), because that change is about preserving hashed IP addresses in sanitized bridge descriptors: https://trac.torproject.org/projects/tor/ticket/2435 Thanks, Karsten
