Can we look forward to a github PR?

In message <97d0be2d-11c6-4d01-9a5d-faccc5b27...@akamai.com> on Tue, 10 Jan 
2017 22:42:17 +0000, "Short, Todd" <tsh...@akamai.com> said:

tshort> I think I might have an init/update/final version of siphash24 lying
tshort> around somewhere that would be compatible with OpenSSL’s EVP_PKEY
tshort> mechanism (similar to Poly1305, in that it needs a key).
tshort> --
tshort> -Todd Short
tshort> // tsh...@akamai.com
tshort> // "One if by land, two if by sea, three if by the Internet."
tshort> 
tshort>     On Jan 10, 2017, at 4:55 PM, Richard Levitte <levi...@openssl.org>
tshort>     wrote:
tshort> 
tshort> 
tshort> 
tshort> 
tshort>     Benjamin Kaduk <bka...@akamai.com> skrev: (10 januari 2017
tshort>     20:19:21 CET)
tshort> 
tshort>     On 01/10/2017 12:31 PM, Richard Levitte wrote:
tshort> 
tshort> 
tshort>             Benjamin Kaduk <bka...@akamai.com> skrev: (10 januari 2017
tshort>             18:48:32
tshort> 
tshort> 
tshort>         CET)
tshort> 
tshort>                     On 01/09/2017 10:05 PM, Salz, Rich wrote:
tshort> 
tshort>                 Should we move to using SIPHash for the default string
tshort>                     hashing
tshort>                     function in OpenSSL? It’s now in the kernel
tshort>                     https://lkml.org/lkml/2017/1/9/619
tshort> 
tshort> 
tshort> 
tshort>                 Heck, yes!
tshort>                 -Ben
tshort> 
tshort> 
tshort>             I fail to see what that would give us. OPENSSL_LH_strhash
tshort>             () is used
tshort> 
tshort> 
tshort>         to get a reasonable index for LHASH entries. Also SIPhash
tshort>         gives at
tshort>         least 64 bits results, do we really expect to see large enough
tshort>         hash
tshort>         tables to warrant that?
tshort> 
tshort> 
tshort> 
tshort> 
tshort>         We don't need to use the full output width of a good hash
tshort>         function.
tshort> 
tshort>         My main point is, "why would we want to ignore the last 20
tshort>         years of
tshort>         advancement in hash function research?" Section 7 of the
tshort>         siphash paper
tshort>         (https://131002.net/siphash/siphash.pdf) explicitly talks
tshort>         about using
tshort>         it
tshort>         for hash tables, including using hash table indices H(m) mod
tshort>         l.
tshort> 
tshort> 
tshort>     I agree with the advice when one can expect huge tables. The
tshort>     tables we handle are pretty small (I think, please correct me if
tshort>     I'm wrong) and would in all likelihood not benefit very much if at
tshort>     all from SIPhash's relative safety.
tshort> 
tshort>     Of course, one can ask the question if someone uses LHASH as a
tshort>     general purpose hash table implementation rather than just for the
tshort>     stuff OpenSSL. Frankly, I would probably look at a dedicated hash
tshort>     table library first...
tshort> 
tshort>     Cheers
tshort>     Richard
tshort>     --
tshort>     Sent from my Android device with K-9 Mail. Please excuse my
tshort>     brevity.
tshort>     --
tshort>     openssl-dev mailing list
tshort>     To unsubscribe:
tshort>     https://mta.openssl.org/mailman/listinfo/openssl-dev
tshort> 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Reply via email to