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
