LWN: Comments on "Unmixing the pool"

Reversible mixing

kleptog — Mon, 24 Mar 2014 22:48:38 +0000

To me it seems more like people aren't aware of the security proofs that exist. The reversibility means it's impossible to make an RDRAND that will steer the pool to a particular state without knowing what the state is.

And if your threat model includes the possibility that the RDRAND can actually peek into the state of the pool it is being mixed into, well, then you're screwed anyway.

Unmixing the pool

nix — Mon, 24 Mar 2014 16:54:51 +0000

The entropy estimate is also used to block /dev/random *writers* (i.e. things adding entropy) if the pool is believed to contain lots (i.e. there is a high watermark as well as a low). This is beneficial to keep things that acquire entropy from expensive-to-read sources like USB devices from trying to acquire it on idle systems that don't need any more entropy.

Reversible mixing

mentor — Thu, 20 Mar 2014 18:29:43 +0000

These sorts of debates over security properties in lieu of a security proof, especially when the possibility of not being able to trust the actors involved is present, makes me deeply dubious.

I'm no expert in the field, but it seems to me that even if a reversible process has a useful security property, it may not be necessary to use that reversible process to get the property.

Unmixing the pool

jimparis — Thu, 13 Mar 2014 21:00:21 +0000

> if someone can snoop on the pool state, it's game over, they don't need to play games with adding entropy to the pool.

Assuming they have some way of getting that information out of the compromised system, sure. From the link I mentioned: "Of course, the malicious device will also be able to see other sensitive information, not just x and y. But this doesn't mean that it's cheap for the attacker to exfiltrate this information! The attacker needs to find a communication channel out of the spying device. Randomness generation influenced by the device is a particularly attractive choice of channel, as I'll explain below".

Unmixing the pool

dlang — Thu, 13 Mar 2014 20:46:01 +0000

if someone can snoop on the pool state, it's game over, they don't need to play games with adding entropy to the pool.

And if they only know about some inputs, but not others, they can't predict the output.

Unmixing the pool

jimparis — Thu, 13 Mar 2014 20:04:06 +0000

> That means, if I have an initial secret pool state X, and hostile attacker controlled data Y, then we can do:
> X' = mix(X, Y)
> and
> X = unmix(X', Y)
> We can see from this that the combination of (X' and Y) still contain the information that was originally in X. Since it's clearly not in Y.. it must all remain in X'.

That's assuming the pool state X is secret. If the HWRNG can snoop on things, like the CPU's RDRAND instruction can, then it can easily choose Y based on X, in which case the "it's clearly not in Y" assertion doesn't apply. See e.g. http://blog.cr.yp.to/20140205-entropy.html.

Unmixing the pool

hkario — Thu, 13 Mar 2014 18:28:26 +0000

I think this would only influence output from the pool (the amount of whitening applied to output bytes) and has no impact on input

Unmixing the pool

smoogen — Thu, 13 Mar 2014 16:52:45 +0000

I wonder if people assuming that the random mixing was not reversible might cause security problems. I can't think of any off-hand, but many security problems come from faulty assumptions on someone's part of how something else is done.