This is a part opf the problem. You've adopted a new code for short strings (lower than 16 bytes, that are supposed to be fully hashed and not subsampled), and it still has evident collisions.
And hashes of consecutive strings of the same length are also consecutive (because you add the byte *after* transforming the current intermediate hash insted of before).
Later when the hash value is used by truncating some high bits (according to the table size), they remain consecutive: the hashed "main" positions in the table is sequential when short keys of equal size are sequential. This makes it extremely easy to rapidly create long collision lists linking all non-null keys together, so the worse case is evident to reproduce (so all table lookups will use slow full table scans.
Now the symptoms are demonstrated. The new hashing is not better than the older one, it is even *worse*.
Anything that sub-sample the string in a predictable way makes it very easy to generate collisions: just use characters that are not hashed
So sub-sampling should not be there or sub-sampling must not be predictable looking at the code
For Max security one should not be able to predict the hash of a new string based on previous strings and their hashes - use a keyed hash such as Siphash which is in fact adopted by many
But you can do this in your Lua installation
Andrea
--
