On Wed, 16 Oct 2024 16:48:12 +0100 "Medvedkin, Vladimir" <vladimir.medvedkin@intel.com> wrote:Hi Stephen, Thanks for introducing this hash function. I have just a few nits: On 01/08/2024 16:31, Stephen Hemminger wrote:The existing hash functions in DPDK are not cryptographically secure and can be subject to carefully crafted packets causing DoS attack.Currently in DPDK we have 3 hash functions, 2 of them can be used with our cuckoo hash table implementation: 1. CRC - Very weak, do not use with hash table if you don't fully control all keys to install into a hash table. 2. Toeplitz - keyed hash function, not used with hash tables, fastest if you have GFNI, level of diffusion fully depends on the hash key, weak against differential crypto analysis. Technically may be used with hash tables in number of usecases. 3. Jenkins hash (lookup3) - and here I can not say that it is not secure and it is subject to collisions. I'm not aware on any successful attacks on it, it has a great diffusion (see https://doi.org/10.1002/spe.2179). It is also keyed with the same size of the key as rte_hsiphash(). So I won't agree with this sentence.I am not a crypto or hash expert. This text is based on the statements by the original author of siphash who does have such expertise. See the wikipedia page: https://en.wikipedia.org/wiki/SipHash and the original paper: https://web.archive.org/web/20170327151630/https://131002.net/siphash/siphash.pdf The problem is that Jenkins and Toeplitz "were designed to have a close-to-uniform distribution, not to meet any particular cryptographic goals"
The original paper link isn't working, for review I used this:
https://www.aumasson.jp/siphash/siphash.pdf
Let me quote a bit more form this WP:
"Recent hash-table proposals such as Google’s CityHash [18] and Jenkins’ SpookyHash [21] provide very fast hashing of short strings, but these functions were designed to have a close-to-uniform distribution, not to meet any particular cryptographic goals. For example, collisions were found in an initial version of CityHash128 [22], and the current version is vulnerable to a practical key-recovery attack when 64-bit keys are used."
I haven't found anything about the lookup3 hash function, which
is different from the SpookyHash hash function implemented by Bob
Jenkins.
P.S. Regarding above mentioned collisions in CityHash128 - it
seem the problem was solved in 2015
-- Regards, Vladimir