[openssl-dev] use SIPhash for OPENSSL_LH_strhash?

[Short, Todd]

I’d be doing it in a manner similar to Poly1305, since that’s a fresh memory… it shouldn’t take long.
--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// "One if by land, two if by sea, three if by the Internet."

On Jan 11, 2017, at 9:44 AM, Richard Levitte <levitte at openssl.org<mailto:levitte at openssl.org>> wrote:

Can we look forward to a github PR?

In message <97D0BE2D-11C6-4D01-9A5D-FACCC5B27127 at akamai.com<mailto:97D0BE2D-11C6-4D01-9A5D-FACCC5B27127 at akamai.com>> on Tue, 10 Jan 2017 22:42:17 +0000, "Short, Todd" <tshort at akamai.com<mailto:tshort at 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> // tshort at akamai.com<mailto:tshort at 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 <levitte at openssl.org<mailto:levitte at openssl.org>>
tshort>     wrote:
tshort>
tshort>
tshort>
tshort>
tshort>     Benjamin Kaduk <bkaduk at akamai.com<mailto:bkaduk at 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 <bkaduk at akamai.com<mailto:bkaduk at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20170111/f8745999/attachment-0001.html>