New /dev/random Implementation Hits 35th Revision

[abott]

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

That's not how the Linux kernel works. It'll be merged when it's ready. FIPS better learn how to roll their own kernel.

[F.Ultra]

Aren't the random seeds only generated on the server side?

if that where the case then TLS would have been completely broken security wise. Random nonces are needed from both sides during the handshake for anything remotely secure.

[tchiwam]

anyone did a distribution of that rng ?

[schmidtbag]

In fact it can be pretty simple and straight forward: https://xkcd.com/221/

Hahaha what a perfect reference.

[George99]

How hard could it be to just get a simple random number?

In fact it can be pretty simple and straight forward: https://xkcd.com/221/

[schmidtbag]

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

Aren't the random seeds only generated on the server side?

[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.

[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.

[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.

[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...