Publishing sanitized bridge pool assignments

[Karsten Loesing]

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.loesing at 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