[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 21 Dec 2016 15:24:32 +0100
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: George Spelvin <linux@...encehorizons.net>
Cc: Eric Dumazet <eric.dumazet@...il.com>, Andi Kleen <ak@...ux.intel.com>,
David Miller <davem@...emloft.net>, David Laight <David.Laight@...lab.com>,
"Daniel J . Bernstein" <djb@...yp.to>, Eric Biggers <ebiggers3@...il.com>,
Hannes Frederic Sowa <hannes@...essinduktion.org>,
Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>, kernel-hardening@...ts.openwall.com,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
Andy Lutomirski <luto@...capital.net>, Netdev <netdev@...r.kernel.org>,
Tom Herbert <tom@...bertland.com>, Linus Torvalds <torvalds@...ux-foundation.org>,
"Theodore Ts'o" <tytso@....edu>, Vegard Nossum <vegard.nossum@...il.com>
Subject: Re: HalfSipHash Acceptable Usage
Hi George,
On Wed, Dec 21, 2016 at 7:34 AM, George Spelvin
<linux@...encehorizons.net> 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
