[tor-dev] Sanitizing IPv6 addresses in bridge descriptors

[Karsten Loesing]

On 1/11/12 10:34 AM, Linus Nordberg wrote:
> Alex Le Heux <alexlh at funk.org> wrote
> Wed, 11 Jan 2012 09:57:00 +0100:
> 
> | > RFC 3849 defines the prefix 2001:DB8::/32 as being reserved for
> | > documentation.  That should be fine for this.
> | 
> | The documentation prefix is for just that, use in documentation :)
> | 
> | ULA (RFC4193) is actually closer to the 10/8 (RFC1918) addresses that you use for IPv4.
> 
> Oh, right.  *blush*

So, just to get that right: how would we apply RFC4193 here?

- We start with FC00::/7 as the prefix for Local IPv6 unicast addresses.

- We set the 8th bit, the L bit, to 1, because we're generating the
subsequent Global ID locally.

- We generate a random 40-bit Global ID for "Tor sanitized bridge IPv6
addresses."  We don't change it, ever.

- We set the 16-bit Subnet ID to all zeros.

- We use the least significant 24 bits of the 64-bit Interface ID for
the actual sanitized bridge address that was formerly encoded in 10.x.x.x.

As an example, a sanitized IPv6 bridge address would be:

  [fc01:0123:4567:89ab::fedc:ba98:7654]

Does that make sense?



As for using a 19-byte or 75-byte long secret key for the SHA-256 input
(see my original mail in this thread), I think I'll go with 19 bytes.

Whoever wants to break the secret needs to brute-force these 19 bytes
using a known input IPv6 address and known sanitized address from us
(which can easily be acquired by running your own bridge).  The
brute-forcing will take them a while, and it'll only tell them the
secret key for one month.  And once they have it they still need to
brute-force a 16-byte input IPv6 address that matches a given 3-byte
sanitized address.  They'll need to repeat the last step for every
bridge address there is.

There are vastly easier ways to learn bridge addresses.  Heck, we run a
service that tells you those.  Something tells me I'm overthinking this. ;)

Best,
Karsten