|
Message-ID: <063D6719AE5E284EB5DD2968C1650D6DB0241238@AcuExch.aculab.com> Date: Fri, 16 Dec 2016 17:06:57 +0000 From: David Laight <David.Laight@...LAB.COM> To: 'George Spelvin' <linux@...encehorizons.net>, "ak@...ux.intel.com" <ak@...ux.intel.com>, "davem@...emloft.net" <davem@...emloft.net>, "ebiggers3@...il.com" <ebiggers3@...il.com>, "hannes@...essinduktion.org" <hannes@...essinduktion.org>, "Jason@...c4.com" <Jason@...c4.com>, "jeanphilippe.aumasson@...il.com" <jeanphilippe.aumasson@...il.com>, "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "luto@...capital.net" <luto@...capital.net>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "tom@...bertland.com" <tom@...bertland.com>, "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>, "tytso@....edu" <tytso@....edu>, "vegard.nossum@...il.com" <vegard.nossum@...il.com> CC: "djb@...yp.to" <djb@...yp.to> Subject: RE: [PATCH v5 1/4] siphash: add cryptographically secure PRF From: George Spelvin > Sent: 15 December 2016 23:29 > > If a halved version of SipHash can bring significant performance boost > > (with 32b words instead of 64b words) with an acceptable security level > > (64-bit enough?) then we may design such a version. > > I was thinking if the key could be pushed to 80 bits, that would be nice, > but honestly 64 bits is fine. This is DoS protection, and while it's > possible to brute-force a 64 bit secret, there are more effective (DDoS) > attacks possible for the same cost. A 32bit hash would also remove all the issues about the alignment of IP addresses (etc) on 64bit systems. > (I'd suggest a name of "HalfSipHash" to convey the reduced security > effectively.) > > > Regarding output size, are 64 bits sufficient? > > As a replacement for jhash, 32 bits are sufficient. It's for > indexing an in-memory hash table on a 32-bit machine. It is also worth remembering that if the intent is to generate a hash table index (not a unique fingerprint) you will always get collisions on the final value. Randomness could still give overlong hash chains - which might still need rehashing with a different key. David
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.