From: Andy Lutomirski Subject: Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF Date: Fri, 16 Dec 2016 14:15:57 -0800 Message-ID: References: <20161216204358.nlwifgcqnu6pitxs@thunk.org> <20161216221352.26899.qmail@ns.sciencehorizons.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: "Ted Ts'o" , Andi Kleen , "David S. Miller" , David Laight , "D. J. Bernstein" , Eric Biggers , Hannes Frederic Sowa , "Jason A. Donenfeld" , 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 To: George Spelvin Return-path: Received: from mail-ua0-f180.google.com ([209.85.217.180]:33991 "EHLO mail-ua0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1762032AbcLPWQS (ORCPT ); Fri, 16 Dec 2016 17:16:18 -0500 Received: by mail-ua0-f180.google.com with SMTP id y13so4323587uay.1 for ; Fri, 16 Dec 2016 14:16:18 -0800 (PST) In-Reply-To: <20161216221352.26899.qmail@ns.sciencehorizons.net> Sender: linux-crypto-owner@vger.kernel.org List-ID: On Fri, Dec 16, 2016 at 2:13 PM, George Spelvin wrote: >> What should we do with get_random_int() and get_random_long()? In >> some cases it's being used in performance sensitive areas, and where >> anti-DoS protection might be enough. In others, maybe not so much. > > This is tricky. The entire get_random_int() structure is an abuse of > the hash function and will need to be thoroughly rethought to convert > it to SipHash. Remember, SipHash's security goals are very different > from MD5, so there's no obvious way to do the conversion. > > (It's *documented* as "not cryptographically secure", but we know > where that goes.) > >> If we rekeyed the secret used by get_random_int() and >> get_random_long() frequently (say, every minute or every 5 minutes), >> would that be sufficient for current and future users of these >> interfaces? > > Remembering that on "real" machines it's full SipHash, then I'd say that > 64-bit security + rekeying seems reasonable. > > The question is, the idea has recently been floated to make hsiphash = > SipHash-1-3 on 64-bit machines. Is *that* okay? > > > The annoying thing about the currently proposed patch is that the *only* > chaining is the returned value. What I'd *like* to do is the same > pattern as we do with md5, and remember v[0..3] between invocations. > But there's no partial SipHash primitive; we only get one word back. > > Even > *chaining += ret = siphash_3u64(...) > > would be an improvement. This is almost exactly what I suggested in my email on the other thread from a few seconds ago :) --Andy