Theoretical vs. practical cryptography in the kernel

Posted Aug 14, 2020 1:02 UTC (Fri) by robert.cohen@anu.edu.au (subscriber, #6281)
Parent article: Theoretical vs. practical cryptography in the kernel

One part of the complaint was "the 32 bits applied to the PRNG come from the "fast pool", which can be thought of as a sort of queue of random bits waiting to be fed into /dev/random. These bits are not removed from the fast pool; they are still, eventually, used to add entropy to the primary random-number generator."

How hard would it be to remove the bits from the "fast pool" when they are added to prandom_u32. That way they wouldnt be added to both RNG's.

Theoretical vs. practical cryptography in the kernel

Posted Aug 14, 2020 7:21 UTC (Fri) by kleptog (subscriber, #1183) [Link] (2 responses)

You can't really. The "fast pool" is 128 bits and any new information is "mixed" in, you can't really "unmix" it.

I also think the issue is way overblown. So 32-bits of this fast pool are used elsewhere. Even if they were completely exposed, it doesn't help you with the other 96-bits and they are eventually mixed even more before being fed to the actual pool.

If you require that all inputs to your random number generator be verifiably random then you have set your goals impossibly high as the article states. Entropy is a theoretical measure, there is no actual way to determine how random something actually is. You'd need to examine the entire multiverse and count the number of universes which are (apparently) identical except for those bits. A better approach seems to me to collect as much unpredictable data as you can and keep on mixing. Estimating the actual randomness is (IMHO) a fool's game.

Theoretical vs. practical cryptography in the kernel

Posted Aug 16, 2020 4:36 UTC (Sun) by rahvin (guest, #16953) [Link]

As pointed out in the article, even if you can access and read the whole pool of 128 bits you have to be know exactly when it's inserted in the RNG and time it all perfectly at each step. There's been plenty of news about how the RNG's input data can be determined using various methods (like the RNG data pulled from the network port) but you still have the base problem of knowing exactly when that data is put in the RNG and to what program which RNG bit's go and that just sounds like something that would be nearly impossible.

Theoretical vs. practical cryptography in the kernel

Posted Aug 31, 2020 11:52 UTC (Mon) by cpitrat (subscriber, #116459) [Link]

"You'd need to examine the entire multiverse and count the number of universes which are (apparently) identical except for those bits. "

Hold my beer ...