New /dev/random Implementation Hits 35th Revision

[phoronix]

Phoronix: New /dev/random Implementation Hits 35th Revision

Going on for more than four years now has been creating a new /dev/random implementation and this Friday marks the 35th revision to this big set of patches that aim for better performance and security...

http://www.phoronix.com/scan.php?page=news_item&px=LRNG-dev-random-35

[Jakobson]

It will be eventually merged because without it LRNG does not meet new FIPS requirements in next year summer.

[topolinik]

The 35th release and still not merged?
Well, I warmly wish this a better fate than GNU HURD

[Jakobson]

The 35th release and still not merged?
Well, I warmly wish this a better fate than GNU HURD

Security is not easy. And not easy at all when changing almost the whole LRNG in a way that's not break anything existing. Needs also to take care of all low-entropy IoT devices in addition to misbehaving user space applications reading directly from /dev/random which may block.

[elatllat]

I look forward to it as I currently have to install
rng-tools, haveged, and change defaults to use urandom.

[schmidtbag]

How hard could it be to just get a simple random number? Stop over-complicating it. When it comes to security, any generator that is purely based on software is a bad idea, so for anyone who actually cares about something "truly" random ought to resort to other solutions anyway.

It's really not hard or expensive to get a totally unpredictable number. Leave /dev/random alone.

[OneTimeShot]

It's really not hard or expensive to get a totally unpredictable number. Leave /dev/random alone.

Actually, it's probably one of the harder problems in computer security. Modern CPUs include hardware randomness, but it's good to pull from a number of sources.

I completely agree with your "it ain't broke, don't fix it" approach, though. At least the fact that it is taking them this long is a good indication that if they didn't know what they were doing at when they started, they've figured it out now...

[schmidtbag]

Actually, it's probably one of the harder problems in computer security. Modern CPUs include hardware randomness, but it's good to pull from a number of sources.

Yes, getting a truly random number through software is indeed one of the harder problems. That's why I was implying to use an external/hardware solution. There are dozens of ways to get completely unpredictable numbers for very cheap, like tuning a radio where all you get is noise or a probe measuring radioactive decay. Anyone who is anal enough about security should never depend on a purely software solution, because as long as the algorithm can be reversed, it isn't secure. Using the cosmic microwave background or subatomic activity is a very easy and reliable way to prevent prediction, without even needing an algorithm.

So as far as I'm concerned, /dev/random should only be used for anything where security isn't important, like video games.

[Jakobson]

So as far as I'm concerned, /dev/random should only be used for anything where security isn't important, like video games.

Entropy sources for /dev/random will be chosen by user during compile time. However none of random sources will be not allowed crediting entropy to multiple similar noise sources and that is problem in existing LRNG implementation and needs rework anyway. Every random source must be able separately to be tested which has not been possible.

[Ironmask]

So as far as I'm concerned, /dev/random should only be used for anything where security isn't important, like video games.

That's not how the world works, though. We have SSL encryption to worry about now.