[tor-dev] Sanitizing IPv6 addresses in bridge descriptors
karsten.loesing at gmx.net
Mon Jan 16 07:46:47 UTC 2012
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:
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. ;)
More information about the tor-dev