[openssl-dev] use SIPhash for OPENSSL_LH_strhash?
Peter Waltenberg
pwalten at au1.ibm.com
Wed Jan 11 01:28:36 UTC 2017
Reality check
Others have pointed this out but I don't think it's making it through.
LHash doesn't need a cryptographic hash and it doesn't have security
implications. It certainly doesn't need a keyed hash.
LHash does need to be something that's good at distinguishing short text
strings, that's not necessarilly the same thing as a good cryptographic
hash, and possibly it's exactly the opposite thing due to the limitted
incoming symbol space (ascii text).
About the only thing LHash needs is high performance in it's use area. I'd
suspect that switching MD5 to SHA-1 in the existing algorithm would get
you that simply because SHA-1 is asm optimized on most platforms now and
MD5 typically isn't.
I'd suggest that anyone wishing to change this should at least have to
demonstrate improved performance in the OpenSSL use case before it's
accepted.
Peter
From: "Short, Todd" <tshort at akamai.com>
To: "openssl-dev at openssl.org" <openssl-dev at openssl.org>
Date: 11/01/2017 08:42
Subject: Re: [openssl-dev] use SIPhash for OPENSSL_LH_strhash?
Sent by: "openssl-dev" <openssl-dev-bounces at openssl.org>
I think I might have an init/update/final version of siphash24 lying
around somewhere that would be compatible with OpenSSL’s EVP_PKEY
mechanism (similar to Poly1305, in that it needs a key).
--
-Todd Short
// tshort at akamai.com
// "One if by land, two if by sea, three if by the Internet."
On Jan 10, 2017, at 4:55 PM, Richard Levitte <levitte at openssl.org> wrote:
Benjamin Kaduk <bkaduk at akamai.com> skrev: (10 januari 2017 20:19:21 CET)
On 01/10/2017 12:31 PM, Richard Levitte wrote:
Benjamin Kaduk <bkaduk at 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.
I agree with the advice when one can expect huge tables. The tables we
handle are pretty small (I think, please correct me if I'm wrong) and
would in all likelihood not benefit very much if at all from SIPhash's
relative safety.
Of course, one can ask the question if someone uses LHASH as a general
purpose hash table implementation rather than just for the stuff OpenSSL.
Frankly, I would probably look at a dedicated hash table library first...
Cheers
Richard
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
--
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/4ffa7200/attachment-0001.html>
More information about the openssl-dev
mailing list