We don’t need the full output width of a good hash function, but for _this_ purpose (as far as I understand) we don’t need the strength of a good hash function either – and we surely don’t need the unnecessary performance hit of a good hash where we don’t need a good hash.
Or am I missing something? — Regards, Uri On 1/10/17, 2:19 PM, "openssl-dev on behalf of Benjamin Kaduk" <openssl-dev-boun...@openssl.org on behalf of bka...@akamai.com> wrote: On 01/10/2017 12:31 PM, Richard Levitte wrote: Benjamin Kaduk <bka...@akamai.com> skrev: (10 januari 2017 18:48:32 CET) On 01/09/2017 10:05 PM, Salz, Rich wrote: Should we move to using SIPHash for the default string hashing function in OpenSSL? It’s now in the kernel https://lkml.org/lkml/2017/1/9/619 Heck, yes! -Ben I fail to see what that would give us. OPENSSL_LH_strhash() is used to get a reasonable index for LHASH entries. Also SIPhash gives at least 64 bits results, do we really expect to see large enough hash tables to warrant that? We don't need to use the full output width of a good hash function. My main point is, "why would we want to ignore the last 20 years of advancement in hash function research?" Section 7 of the siphash paper (https://131002.net/siphash/siphash.pdf) explicitly talks about using it for hash tables, including using hash table indices H(m) mod l. -Ben
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
