Re: Publishing sanitized bridge pool assignments

[Ian Goldberg <iang@xxxxxxxxxxxxxxx>]

On Wed, Feb 02, 2011 at 03:50:25PM +0100, Karsten Loesing wrote:
> 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@xxxxxxx> 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

"Never rely on a secret that's expensive to change".

For sure the secret should be long.  20 bytes is probably OK, but why
not 256 bits?  As long as the whole thing you're hashing fits in one
hash block, it's not more expensive.  (And why SHA1?)

What happens if someone _does_ brute the secret?  How important is it to
keep a consistent secret?

   - Ian