> On 14 Jul 2017, at 06:30, Christian Weisgerber <[email protected]> wrote:
> 
> On 2017-07-13, Florian Obser <[email protected]> wrote:
> 
>> It switches the hash function to SipHash24 from sha512 as suggested by dlg
> 
> It's for from clear to me whether SipHash is suitable for crypto
> operations, and which ones, other than the hash tables it was
> designed for.

the abstract on the siphash paper says:

"SipHash is a family of pseudorandom functions optimized for short inputs. 
Target applications include network traffic authentication and hash-table 
lookups protected against hash-flooding denial-of-service attacks."

i somehow have the impression that it's use for hash tables was a convenient 
bonus rather than a specific design target of the algorithm. it was handy that 
it is good at spreading bits from a small input into its output.

> 
> We went with SHA-512 for RFC 1948 TCP initial sequence number
> generation, which is arguably performance-sensitive, while RFC 7217
> addresses are certainly not.  I think we should use a SHA-2-family
> function such as SHA-512 here.

i dont mind which way we go, but i would like to make two (possibly invalid) 
arguments. 

firstly, we're generating public information. if anyone wants to "collide" with 
us, the can just copy and use the same ip, regardless of how we got there. as 
long as the key is strong enough we should be able to prevent prediction of 
other soii based addresses. if we're trying to protect against recovery of 
information, specifically the mac address, we could just not feed that into the 
hash. use the name of the interface instead, which is what netstart uses to 
assign addresses too.

secondly, im always wary of truncating hash output in case it throws away some 
of the guarantees it's supposed to provide. if you cut sha512 output down to an 
8th of its size, is it 8 times easier to calculate a collision, or more than 8 
times easier? sha384 being a truncation of sha512 kind of argues against this 
though.

with regard to the code, siphash implied a length for soiikey which makes the 
sysctl handling a lot easier. if (when?) we go back to sha512 id like to see a 
fixed key length remain. we can make it bigger, but just keep it one size.

> 
>> +# Apply soiikey.conf settings.
>> +soiikey_conf() {
>> +    stripcom /etc/soiikey.conf |
>> +    while read _line; do
>> +            sysctl -q "net.inet6.ip6.soiikey=$_line"
>> +    done
>> +}
> 
> I think .conf is a strange choice of name for what is not a
> configuration file but effectively a private key, cf.
> 
> /etc/{iked,isakmpd}/private/local.key
> /etc/ssh/ssh_host_<algorithm>_key

id also like to see key in the name, not conf.

> 
>> +SOOIs use the whole 64 bit of the host part while SLAAC addresses are
>> +formed from MAC addresses and have 48 bits of entropy at most.
> 
> 46 bits.
> (The first bit of a MAC address is 0 for unicast addresses, the
> second is 0 for "universally administered" addresses, i.e., those
> that are uniquely assigned to a device by its manufacturer.)
> 
> -- 
> Christian "naddy" Weisgerber                          [email protected]
> 

Reply via email to