<!DOCTYPE html><html><head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body> <div class="moz-cite-prefix">On 16/10/2024 18:07, Stephen Hemminger wrote: </div> <blockquote type="cite" cite="mid:20241016100710.131fcbf2@hermes.local"> <pre class="moz-quote-pre" wrap="">On Wed, 16 Oct 2024 16:48:12 +0100 "Medvedkin, Vladimir" <a class="moz-txt-link-rfc2396E" href="mailto:vladimir.medvedkin@intel.com"><vladimir.medvedkin@intel.com></a> wrote: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">Hi Stephen, Thanks for introducing this hash function. I have just a few nits: On 01/08/2024 16:31, Stephen Hemminger wrote: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">The existing hash functions in DPDK are not cryptographically secure and can be subject to carefully crafted packets causing DoS attack. </pre> </blockquote> <pre class="moz-quote-pre" wrap="">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 <a class="moz-txt-link-freetext" href="https://doi.org/10.1002/spe.2179">https://doi.org/10.1002/spe.2179</a>). It is also keyed with the same size of the key as rte_hsiphash(). So I won't agree with this sentence. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> 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: <a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/SipHash">https://en.wikipedia.org/wiki/SipHash</a> and the original paper: <a class="moz-txt-link-freetext" href="https://web.archive.org/web/20170327151630/https://131002.net/siphash/siphash.pdf">https://web.archive.org/web/20170327151630/https://131002.net/siphash/siphash.pdf</a> The problem is that Jenkins and Toeplitz "were designed to have a close-to-uniform distribution, not to meet any particular cryptographic goals" </pre> </blockquote> The original paper link isn't working, for review I used this: <a class="moz-txt-link-freetext" href="https://www.aumasson.jp/siphash/siphash.pdf">https://www.aumasson.jp/siphash/siphash.pdf</a> 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 <blockquote type="cite" cite="mid:20241016100710.131fcbf2@hermes.local"> <pre class="moz-quote-pre" wrap=""> </pre> </blockquote> <pre class="moz-signature" cols="72">-- Regards, Vladimir</pre> </body> </html>