I've done some security testing against this hash function. Does anyone want to follow up and see if they can extend the attacks I describe[1]?
"GxHash is a fast and robust non-cryptographic hashing algorithm"
Exactly that I should use it when I want a fast hash, but not when I want a robust cryptographic hash? In which case I can ignore your attack? (Not to discount your work, I'm just trying to understand the scope here)
So I can use it in my hash-map, or whatever O(1) lookup, but I shouldn't use it in my rewrite of SSL?
BTW in the past (20 years ago?) there have been attacks on non-cryptographic hashes used for hash maps: denial of service by creating crafted requests to HTTP servers... The parameteres would be picked maliciously and would be all ending in the same "buckets". That attack worked on both Java and PHP servers. IIRC it's been solved by adding random seeding (and I noticed that GxHash mentions it's seedable: not saying it'd counter every attack but it's already something).
There have been places where a dev chose to use a non-cryptographic hash when they should not have, because they hadn't thought of the threat model (out of ignorance, or just didnt occur to them).
But in most cases, nothing happens. They gained performance, or ease of development, etc. So it's a worthy trade off most of the time (whether they did it knowingly or not).
If a small change to the seed mixing (literally moving a line from the end to the beginning of the function) increases the security with no penalty to performance, then we might as well make the change.