On Wed, 2019-10-16 at 14:00 +0300, Jarkko Sakkinen wrote: > On Mon, Oct 14, 2019 at 12:29:57PM -0700, James Bottomley wrote: > > The job of the in-kernel rng is simply to produce a mixed entropy > > pool from which we can draw random numbers. The idea is that quite > > a few attackers have identified the rng as being a weak point in > > the security architecture of the kernel, so if we mix entropy from > > all the sources we have, you have to compromise most of them to > > gain some predictive power over the rng sequence. > > The documentation says that krng is suitable for key generation. > Should the documentation changed to state that it is unsuitable? How do you get that from the argument above? The krng is about the best we have in terms of unpredictable key generation, so of course it is suitable ... provided you give the entropy enough time to have sufficient entropy. It's also not foolproof ... Bernstein did a speculation about how you could compromise all our input sources for entropy. However the more sources we have the more difficult the compromise becomes. > > The point is not how certified the TPM RNG is, the point is that > > it's a single source and if we rely on it solely for some > > applications, like trusted keys, then it gives the attackers a > > single known point to go after. This may be impossible for script > > kiddies, but it won't be for nation states ... are you going to > > exclusively trust the random number you got from your chinese > > certified TPM? > > I'd suggest approach where TPM RNG result is xored with krng result. reversible ciphers are generally frowned upon in random number generation, that's why the krng uses chacha20. In general I think we shouldn't try to code our own mixing and instead should get the krng to do it for us using whatever the algorithm du jour that the crypto guys have blessed is. That's why I proposed adding the TPM output to the krng as entropy input and then taking the output of the krng. James > > Remember also that the attack doesn't have to be to the TPM only, > > it could be the pathway by which we get the random number, which > > involves components outside of the TPM certification. > > Yeah, I do get this. > > /Jarkko >
