On 1/11/12 10:34 AM, Linus Nordberg wrote:
Alex Le Heux alexlh@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