Publishing sanitized bridge pool assignments

[Ian Goldberg]

On Wed, Feb 02, 2011 at 04:29:05PM +0100, Karsten Loesing wrote:
> 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.

Actually, to keep it to one SHA block (447 bits, not including padding),
you can have at most 255 bits (31 bytes, if we're byte-aligned) for the
secret.  I wouldn't suggest spanning the secret across SHA blocks.

> 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?

SHA-512 seems like overkill if we're only using 3 bytes of the output.
SHA-256 should be fine.  Indeed, there's no _actual_ reason to believe
SHA-1 isn't fine here, except for the general "don't be mandating SHA-1
for anything new at this point" rule.

> > 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).

A 31-byte secret is far more likely to leak than be brute-forced, of
course.  If it's leaked one month, is it likely to leak again another
month?

   - Ian