On 1/11/12 10:34 AM, Linus Nordberg wrote: > Alex Le Heux <[email protected]> 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 _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
