From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762011AbcLPRHM convert rfc822-to-8bit (ORCPT ); Fri, 16 Dec 2016 12:07:12 -0500 Received: from smtp-out6.electric.net ([192.162.217.193]:52187 "EHLO smtp-out6.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752922AbcLPRHG (ORCPT ); Fri, 16 Dec 2016 12:07:06 -0500 From: David Laight To: "'George Spelvin'" , "ak@linux.intel.com" , "davem@davemloft.net" , "ebiggers3@gmail.com" , "hannes@stressinduktion.org" , "Jason@zx2c4.com" , "jeanphilippe.aumasson@gmail.com" , "kernel-hardening@lists.openwall.com" , "linux-crypto@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "luto@amacapital.net" , "netdev@vger.kernel.org" , "tom@herbertland.com" , "torvalds@linux-foundation.org" , "tytso@mit.edu" , "vegard.nossum@gmail.com" CC: "djb@cr.yp.to" Subject: RE: [PATCH v5 1/4] siphash: add cryptographically secure PRF Thread-Topic: [PATCH v5 1/4] siphash: add cryptographically secure PRF Thread-Index: AQHSVyr8rhwSYxAiWE2DHzMI3vCk6aEKzUgg Date: Fri, 16 Dec 2016 17:06:57 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6DB0241238@AcuExch.aculab.com> References: <20161215232840.22459.qmail@ns.sciencehorizons.net> In-Reply-To: <20161215232840.22459.qmail@ns.sciencehorizons.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.99.200] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Outbound-IP: 213.249.233.130 X-Env-From: David.Laight@ACULAB.COM X-Proto: esmtps X-Revdns: X-HELO: AcuExch.aculab.com X-TLS: TLSv1:AES128-SHA:128 X-Authenticated_ID: X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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