No offense, but you don't come off very nicely in that thread. Perhaps you could rephrase your criticism in a way that would make the maintainers more likely to listen to you?

No, it lead to actual harm on billions of users. And Google did listen and reacted accordingly.

But they still didn't put their hash to external scrutinity, still waiting for the pull request to get it tested with smhasher.

Still, there's no need to be rude.

I'm never rude.

…I personally find that very hard to believe. Maybe you weren't specifically "rude" here, but you were clearly unpleasant–you called their claims "false" and "nonsense" repeatedly, which is rarely if ever necessary.

Calling false claims "false" is necessary and not rude.

And I just added Highwayhash now to smhasher by myself and my initial analysis was confirmed. It's the 2nd slowest of all tested good hashes, only behind Siphash. Every other is simplier and faster. Chi-Square on the lower 32bits was 0.00 so it's really a good one. But I see no usecase for it, really.

The WOOL 2009 paper where it takes days to attack a 14-bit key is irrelevant for attacking a 64-bit key. They even say that 32 bits would make the attack infeasible.

Offline attacks to find collisions are irrelevant because revealing the key breaks the security model.

Saying you can recover the key from side-channel attacks on probe sequences is actually a claim that SipHash/HighwayHash are not secure PRFs.

If you're not making these claims, you're not communicating very well what your security claims are.

Attacking a hash table needs not more than 14bits. This is enough to produce enough collisions to break a typical bad table. If a hash function produces 14 or 32 or 64 bits is irrelevant if only the lowest needed bits are used.

My hash tables are secure against known seeds BTW, every hash table should. Almost all use cases make it trivial to get to the seed in certain ways. Calling a hash table secure relying on a secured random seed is theatre, and securing is actually simplier and faster than relying on a broken model and slow hash functions.

I think you're confusing the key/seed with the output. The paper is about key sizes, not hash output sizes. Again, if you claim it's trivial to recover the seed in "almost all use cases", you should be able to demonstrate that pretty easily, no?

I don't have anything against recommendations to use all bits in the hash output, or good collision handling, just these unfounded security claims about key recovery.