Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935920AbcLVCkI (ORCPT ); Wed, 21 Dec 2016 21:40:08 -0500 Received: from frisell.zx2c4.com ([192.95.5.64]:53589 "EHLO frisell.zx2c4.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932990AbcLVCkF (ORCPT ); Wed, 21 Dec 2016 21:40:05 -0500 MIME-Version: 1.0 From: "Jason A. Donenfeld" Date: Thu, 22 Dec 2016 03:40:00 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage) To: Andy Lutomirski Cc: George Spelvin , "Ted Ts'o" , Andi Kleen , "David S. Miller" , David Laight , "D. J. Bernstein" , Eric Biggers , Eric Dumazet , Hannes Frederic Sowa , Jean-Philippe Aumasson , "kernel-hardening@lists.openwall.com" , Linux Crypto Mailing List , "linux-kernel@vger.kernel.org" , Network Development , Tom Herbert , Linus Torvalds , Vegard Nossum Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1363 Lines: 26 > On Wed, Dec 21, 2016 at 5:13 PM, George Spelvin >> After some thinking, I still like the "state-preserving" construct >> that's equivalent to the current MD5 code. Yes, we could just do >> siphash(current_cpu || per_cpu_counter, global_key), but it's nice to >> preserve a bit more. >> >> It requires library support from the SipHash code to return the full >> SipHash state, but I hope that's a fair thing to ask for. This is not a good idea. If I understand correctly, the idea here is to just keep around SipHash's internal state variables, and chain them over to the next call, sort of like how md5_transform with the current code works on the same scratch space. There has been no security analysis in the literature on this use of the primitive, and I have no confidence that this is a secure use of the function. Unless somebody can point me toward a paper I missed or a comment from a real cryptographer about the specifics of SipHash, I think I'm right to admonish against this dangerous road. Let's talk about constructions. And let's only decide on a construction that we're actually equipped to analyze. Let's definitely not talk about making our own primitives, or retrofitting nice primitive's internals into our own Frankenstein. Alternatively, if I'm wrong, please send me an eprint/arXiv link to a paper that discusses this use of SipHash.