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?






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
Heck, yes! 
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.


Attachment: smime.p7s
Description: S/MIME cryptographic signature

openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Reply via email to