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.
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.