On Mon, Oct 14, 2024 at 11:42 AM David Schinazi <dschinazi.ietf@xxxxxxxxx> wrote:
The draft currently mentions this issue in its security recommendationssubsection about collisions [1], but it currently recommends still usingFNV1a with an unknown offset_basis as the solution. I think thissection should instead recommend using a cryptographic hash for suchuse cases.
First, a nit: it currently has the word "unknownable", but I think it's supposed to be "unknowable".
A bigger problem is that the terminology around SipHash is really confusing. Frustrating, because even the IETF writes something clear, there will be all of this other stuff out there.
Compare:
Wikipedia: "SipHash is designed as a non-cryptographic hash function."
The paper: "cryptographically strong"
The author's repo: "cryptographically secure"
The reports from checking all QUIC packets on the Google front-end make sense, since that seems like that's exactly what it's for.
I remember when all these DoS attacks hit. There were some implementations, at least in web things, that weren't affected. They were using various tree structures instead of hashtables. djb recommends a tree in his presentation[0], but says "hashtables are perceived to be simpler".
Here is a good explanation of a case where you can ignore these issues (non-networked uses):
The only reason I know of these references is because I'm a Rust enthusiast, and I thought "huh, what's SipHash?" one day a few years ago.
thanks,
Rob
"Defending against hash flooding
My favorite solution:switch from hash tables
to crit-bit trees"
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
