Hi George, On Wed, Dec 21, 2016 at 7:34 AM, George Spelvin <linux@xxxxxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
