Re: Publishing sanitized bridge pool assignments

[Karsten Loesing <karsten.loesing@xxxxxxx>]

On Wed, Feb 02, 2011 at 09:56:05AM -0500, Ian Goldberg wrote:
> On Wed, Feb 02, 2011 at 03:50:25PM +0100, Karsten Loesing wrote:
>> 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?)

Pasting the proposed hash function here so that people can follow the
discussion without opening the Trac ticket:

  H(IP address + bridge identity + secret)[:3]

20 bytes was just a suggestion.  We already have 24 bytes as input to the
hash function (IP address = 4 bytes, bridge identity = 20 bytes) plus the
suggested 20 bytes for the secret.  We can as well make the secret 32
bytes long, or 40.

SHA1 was just a suggestion, too.  No reason not to use SHA-256, SHA-384,
or SHA-512 (which are the digests in the Java implementation we use).

How about using SHA-512 and making the secret 40 bytes long?

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

If someone brute forces the secret, they only need the bridge identity to
further brute force the bridge's past IP addresses.  We usually assume
that the adversary doesn't have original bridge identities, unless they
request bridges on their own.  And if they do request bridges, they
already know current IP addresses.  But when they also have the secret,
they can use our archives to learn about the bridge's past IP addresses.
It's unclear whether that's a problem for someone.  Possibly.

With a changing secret, the adversary could only use the found secret for
descriptor archives of that month.  And they'll have a much harder time
brute forcing secrets for past months, for which they cannot set up their
own bridges (as described in comment #1 in #2435).

Best,
Karsten