Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759807AbcLUOYk (ORCPT ); Wed, 21 Dec 2016 09:24:40 -0500 Received: from frisell.zx2c4.com ([192.95.5.64]:38330 "EHLO frisell.zx2c4.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754214AbcLUOYi (ORCPT ); Wed, 21 Dec 2016 09:24:38 -0500 MIME-Version: 1.0 In-Reply-To: <20161221063412.6425.qmail@ns.sciencehorizons.net> References: <1482298164.8944.8.camel@edumazet-glaptop3.roam.corp.google.com> <20161221063412.6425.qmail@ns.sciencehorizons.net> From: "Jason A. Donenfeld" Date: Wed, 21 Dec 2016 15:24:32 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: HalfSipHash Acceptable Usage To: George Spelvin Cc: Eric Dumazet , Andi Kleen , David Miller , David Laight , "Daniel J . Bernstein" , Eric Biggers , Hannes Frederic Sowa , Jean-Philippe Aumasson , kernel-hardening@lists.openwall.com, Linux Crypto Mailing List , LKML , Andy Lutomirski , Netdev , Tom Herbert , Linus Torvalds , "Theodore Ts'o" , 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: 1626 Lines: 40 Hi George, On Wed, Dec 21, 2016 at 7:34 AM, George Spelvin wrote: > In fact, I have an idea. Allow me to make the following concrete > suggestion for using HalfSipHash with 128 bits of key material: > > - 64 bits are used as the key. > - The other 64 bits are used as an IV which is prepended to > the message to be hashed. > > As a matter of practical implementation, we precompute the effect > of hashing the IV and store the 128-bit HalfSipHash state, which > is used just like a 128-bit key. > > Because of the way it is constructed, it is obviously no weaker than > standard HalfSipHash's 64-bit security claim. > > I don't know the security of this, and it's almost certainly weaker than > 128 bits, but I *hope* it's at least a few bits stronger than 64 bits. > 80 would be enough to dissuade any attacker without a six-figure budget > (that's per attack, not a one-time capital investment). 96 would be > ample for our purposes. > > What I do know is that it makes a brute-force attack without > significant cryptanalytic effort impossible. Depends who's doing the cryptanalytic effort I guess. Please don't roll your own crypto. It's a dangerous road. Putting homebrew crypto into the kernel would be an error. Let's stick with the constructions and security margins that the cryptographers give us. JP made that fairly clear, I thought. There are already people working on this problem who undergo peer review and a career devoted to solving these problems. One result for small systems that need 128-bit security is Chaskey, which you can go read about if you're curious. Jason