On Fri, Jul 14, 2017 at 11:06:49AM +1000, David Gwynne wrote: > > > 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.
My understanding of siphash is, too, that we are probably fine with using it, but then what do I know about hash functions... And since we are arguing about it and this is not performance critical at all we shouldn't half-arse it and just go with sha512. > > 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. Yes, there is no point for a user to set a key of a specific length. It's a randomly generated opaque blob. I'll send an updated diff shortly addressing all the input so far, thanks! -- I'm not entirely sure you are real.
