On 16/10/2024 18:07, Stephen Hemminger wrote:
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.

I understand that SipHash has good cryptographic quality and can be used for MAC, but here we are talking about NCHF that are used for hash tables, and in this case a good uniform distribution of hash values is very important. Siphash has this property, as does lookup3.

P.S. Regarding above mentioned collisions in CityHash128 - it seem the problem was solved in 2015


    
-- 
Regards,
Vladimir