Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756748AbcLRAGV (ORCPT ); Sat, 17 Dec 2016 19:06:21 -0500 Received: from trent.utfs.org ([94.185.90.103]:53304 "EHLO trent.utfs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752553AbcLRAGU (ORCPT ); Sat, 17 Dec 2016 19:06:20 -0500 Date: Sat, 17 Dec 2016 16:06:15 -0800 (PST) From: Christian Kujau To: "Jason A. Donenfeld" cc: Tom Herbert , Netdev , kernel-hardening@lists.openwall.com, LKML , Linux Crypto Mailing List , Jean-Philippe Aumasson , "Daniel J . Bernstein" , Linus Torvalds , Eric Biggers , David Laight Subject: Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function In-Reply-To: Message-ID: References: <20161214035927.30004-1-Jason@zx2c4.com> <20161214184605.24006-1-Jason@zx2c4.com> User-Agent: Alpine 2.20.99 (DEB 191 2016-12-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 540 Lines: 16 On Thu, 15 Dec 2016, Jason A. Donenfeld wrote: > > I'd still drop the "24" unless you really think we're going to have > > multiple variants coming into the kernel. > > Okay. I don't have a problem with this, unless anybody has some reason > to the contrary. What if the 2/4-round version falls and we need more rounds to withstand future cryptoanalysis? We'd then have siphash_ and siphash48_ functions, no? My amateurish bike-shedding argument would be "let's keep the 24 then" :-) C. -- BOFH excuse #354: Chewing gum on /dev/sd3c