On Sat, Aug 08, 2020 at 11:19:01AM -0700, Linus Torvalds wrote: > If siphash is a good enough hash to make the pseudo-random state hard > to guess, then it's also a good enough hash to hide the small part of > the fast-pool we mix in.
No! No, no, a thousand times no. I *just* finished explaining, using dribs and drabs of entropy allows an *information theoretical attack* which *no* crypto can prevent. The drip-feed design of the current patch is a catastrophic antifeature which must be anethametized. You could replace SipHash with a random function, the platonic ideal to which all other cryptographic functions are compared, and you'd still have a hole. The fact that *nothing* can fix bad seeding is the entire reason /dev/random exists in the first place. *Second*, I have no intention of using full SipHash. I'm spending all of that security margin making it as fast as possible, leaving just enough to discourage the original attack. As you just pointed out, half-MD4 (still used in fs/ext4/hash.c) is quite enough to discourage attack if used appropriately. If you go and *vastly* increase the value of a successful attack, letting an attacker at long-lived high-value keys, I have to put all that margin back. (Not to mention, even full SipHash only offers 128-bit security in the first place! Shall I go and delete AES-256 and SHA2-512, since we've decided the Linux kernel is capped at 128-bit security?) It's not even remotely difficult: use the *output* of random.c. Making that safe is what all that code is for. (It costs some cycles, but SipHash's strength lets you go long enough between reseeds that it amorizes to insignificance.)
