Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755496AbcLSOQK convert rfc822-to-8bit (ORCPT ); Mon, 19 Dec 2016 09:16:10 -0500 Received: from smtp-out4.electric.net ([192.162.216.189]:52525 "EHLO smtp-out4.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753222AbcLSOQI (ORCPT ); Mon, 19 Dec 2016 09:16:08 -0500 From: David Laight To: "'George Spelvin'" , "tom@herbertland.com" CC: "ak@linux.intel.com" , "davem@davemloft.net" , "djb@cr.yp.to" , "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" , "torvalds@linux-foundation.org" , "tytso@mit.edu" , "vegard.nossum@gmail.com" Subject: RE: [PATCH v5 1/4] siphash: add cryptographically secure PRF Thread-Topic: [PATCH v5 1/4] siphash: add cryptographically secure PRF Thread-Index: AQHSV9U/rhwSYxAiWE2DHzMI3vCk6aEMQscAgAMQgFA= Date: Mon, 19 Dec 2016 14:14:59 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6DB0242669@AcuExch.aculab.com> References: <20161217152122.19677.qmail@ns.sciencehorizons.net> In-Reply-To: <20161217152122.19677.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 Content-Length: 613 Lines: 21 From: George Spelvin > Sent: 17 December 2016 15:21 ... > uint32_t > hsiphash24(char const *in, size_t len, uint32_t const key[2]) > { > uint32_t c = key[0]; > uint32_t d = key[1]; > uint32_t a = 0x6c796765 ^ 0x736f6d65; > uint32_t b = d ^ 0x74656462 ^ 0x646f7261; I've not looked closely, but is that (in some sense) duplicating the key length? So you could set a = key[2] and b = key[3] and still have an working hash - albeit not exactly the one specified. I'll add another comment here... Is it worth using the 32bit hash for IP addresses on 64bit systems that can't do misaligned accessed? David