Repository navigation
Change Siphash to use one of the faster variants of the algorithm (Siphash13, Highwayhash) #29754
Description
Jean-Philippe Aumasson answered on "can Siphash13 used instead of Siphash24 for hash function of hash tables":
we proposed SipHash-2-4 as a (strong) PRF/MAC, and so far no attack whatsoever has been found,
although many competent people tried to break it. However, fewer rounds may be sufficient and I would
be very surprised if SipHash-1-3 introduced weaknesses for hash tables.
So that, there is no reason to burn more cpu power on redundant rounds.
Activity
[-]Use lightweighter Siphash variant: Siphash13 instead of Siphash24[/-][+]Use light Siphash variant: Siphash13 instead of Siphash24[/+]bstrie commentedon Nov 10, 2015
Sounds like it would only take a two-line change to test the perf impact of this change. @gankro, did you have some hashtable benchmark scripts lying around?
arthurprs commentedon Nov 10, 2015
That'd be interesting. Sub.
Gankra commentedon Nov 10, 2015
You can fork http://cglab.ca/~abeinges/blah/hash-rs/ if you want to do some ok-ish comparisons.
@bluss is my goto expert on siphash.
Gankra commentedon Nov 10, 2015
Note that direct consumers of SipHash may break if they decided to manually seed it and store the results. So this isn't a totally free change.
bluss commentedon Nov 11, 2015
Aumasson is the cryptographer, maybe we can ask him what he thinks about Rust going for SipHash-1-3 specifically? I'm curious what people have learned about SipHash in general now that it's been out for several years.
If we weaken it so much that it doesn't prevent hash flooding anymore, then we lose the reason to use SipHash and could use a faster hash function.
I know I tried long ago and noted that SipHash-1-2 didn't even pass the Smhasher testsuite (which is probably bad). (SipHash-N-M is for N hash rounds per 8 bytes of input and M fixed rounds as finalization).
funny-falcon commentedon Nov 11, 2015
Siphash-1-3 passes Smhasher. It is smallest configuration, which has good avalanche.
Siphash is protected from "seed independent collisions" with any configuration with good avalanche.
Siphash24 is recomended for MAC cause when you do MAC you put result in public, so there are other vectors of attack: plain text, chosen plain text, differential, etc. As cryptographers, Siphash authors simply recommend more rounds than minimal required to protect against future investigations.
Within hash-table result of hash-function is not published, so there is no way to recover seed. Then protection from "seed independent collisions" is just enough.
Agree. There should be separate SipHash13 for internal/hash-table usage, and SipHash (24) remains for direct/external usage.
funny-falcon commentedon Nov 11, 2015
I asked him year ago about using SipHash13 for hash tables. Answer is in issue text.
I think, we can ask him again.
tarcieri commentedon Nov 12, 2015
If @veorq feels its fine then it should be fine. The worst case is there's a hashDoS against Siphash13, in which case you can upgrade to a stronger hash function.
bstrie commentedon Nov 12, 2015
@gankro, how likely do you think this is to break code in the wild? I was under the impression that we considered the precise underlying default hash function to be an implementation detail (with the caveat that you can count on it to be cryptographically secure).
tarcieri commentedon Nov 12, 2015
@bstrie from a security perspective, I'd say you definitely should not couple to the hash function in any way. Java made that mistake (the hashing algorithm was included in the Java Language Specification) and that made it so they were not able to adequately respond to hashDoS.
bstrie commentedon Nov 12, 2015
@tarcieri That's actually tied in with what I'm implying here. Supposing that we did switch to 1-3, and that an attack on 1-3 was later discovered, we'd want to reserve the right to bump it back up to 2-4 (or, you know, whatever the state of the art is by then) without risking massive breakage in the ecosystem. If changing the default hash function should prove to be disruptive at the current point in time then that's a separate problem that we need to consider, hence why I'm curious as to the true magnitude of such a change.
Furthermore, I get the impression that the breakage that Gankro's envisioning wouldn't be detectable by Crater.
bluss commentedon Nov 12, 2015
Using 1-3 doesn't fix the fundamental slowness of our hashing, but it will instead speed up the long data case. The short data case remains a problem, due to (I think):
Of course we should still go for it, if possible, but I don't think it's a substitute for allowing faster alternatives to be used (application may choose to sacrifice hash flooding defence, deciding it's not useful for them).
72 remaining items
random.c: use sip_hash13 as faster but still safe alternative to sip_…
random.c: use sip_hash13 as faster but still safe alternative to sip_…
random.c: use sip_hash13 as faster but still safe alternative to sip_…
random.c: use sip_hash13 as faster but still safe alternative to sip_…
random.c: use sip_hash13 as faster but still safe alternative to sip_…
random.c: use sip_hash13 as faster but still safe alternative to sip_…
random.c: use sip_hash13 as faster but still safe alternative to sip_…
random.c: use sip_hash13 as faster but still safe alternative to sip_…
random.c: use sip_hash13 as faster but still safe alternative to sip_…
random.c: use sip_hash13 as faster but still safe alternative to sip_…
random.c: use sip_hash13 as faster but still safe alternative to sip_…
random.c: use sip_hash13 as faster but still safe alternative to sip_…
random.c: use sip_hash13 as faster but still safe alternative to sip_…
switch SipHash from SipHash24 to SipHash13 variant
switch SipHash from SipHash24 to SipHash13 variant