Linux Kernel Diverts Question To Distros: Trust CPU Hardware Random Number Generators?

[phoronix]

Phoronix: Linux Kernel Diverts Question To Distros: Trust CPU Hardware Random Number Generators?

In a controversial move, the Linux kernel will be pushing the question off to distribution vendors on whether to put trust in CPU hardware random number generators...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Q-HW-RNGs

[some_canuck]

Tso doesn't seem to know that China already makes their own CPUs.

[Adarion]

As far as I know it's been relatively few, I only recall Loongson. Now there are a few more coming in the x86 area, the AMD dervied one(s) and via VIA's x86 license.

there are also some "external" HWRNGs.
https://en.wikipedia.org/wiki/Compar...ber_generators
There are 4 open designs. Not that much. Those should be more trustable (after reviews). Otoh, there is still a lot of closed hardware (and SW/FW) in most systems anyway, so it's just lowering the risk amount, not eliminating them entirely.

[mb_q]

This is so terribly stupid; there are tons of uses for even a non-trusted but fast HWRNG, like rendering, machine learning, scientific/business simulations; register-access latency class RNG with infinite cycle and no dumb artefacts would be groundbreaking.

But no, RDRAND must be for 'security', so it is wrapped in some kind of a hardware PRNG and thus slower than many software PRNGS. On the other hand, while it most likely has no backdoor (it is literally the worse possible place in a CPU to put such), it cannot be ever trusted by anyone sane because it is perfectly closed.

Such a waste.

[kpedersen]

It is a very sad state of affairs when we don't trust the people we *have* to rely on. Doesn't that more make them our captors than our vendors?

We *really* need a truly open-source hardware stack!

[schmidtbag]

Here's what I don't get: why do people continue to make such a big fuss out of random number generators? It seems at least once per year I hear about someone saying the existing method isn't good enough. And yet, is there actually any realistic proof of that? Yes, I understand they can be predicted, but how often has this been exploited in the real world, or, how easily could it be exploited? The way I see it, if someone is really that anal over having the most secure and random number possible, there are plenty of hardware number generators out there. Spending $100 or so for peace of mind is not that big of an expense, especially in the server market (where this is the most relevant). I'd much rather the kernel level random number generator be fast and useful for non-security related programs.
That being said - I'm a little bit surprised modern server motherboards aren't more commonly equipped with integrated random number generators.

I don't necessarily disagree with Ts'o's comments, but I question how much it's actually worth concerning over.

[RavFX]

It is a very sad state of affairs when we don't trust the people we *have* to rely on. Doesn't that more make them our captors than our vendors?

We *really* need a truly open-source hardware stack!

That will change nothing to the current situation, except if you actually own the fabs required to manufacture all the parts and supervise or control everything in the production process.

With an open source hardware stack, it allow NSA, CSIS & friend to study the actual hardware implementation so they can provide a nice hardware patch for the CPU to add some backdoor. Then they send these patch to TSMC and friends with a couple thousand bitcoins and voila! Better backdoor in your "open" CPU, better and more performing backdoor than what you can get in closed hardware where they need to spy in the internal and try to reverse engineer said hardware and then hide the hardware modification without being caught.

[chithanh]

As far as I know it's been relatively few, I only recall Loongson. Now there are a few more coming in the x86 area, the AMD dervied one(s) and via VIA's x86 license.

FeiTeng (Sparc, ARM)
Loongson (MIPS)
Shenwei/Sunway (Alpha, custom ISA)

The Sunway SW26010 powered the leading Top500 system between June 2016 - June 2018.

[oleid]

It's not like the RN of those HW-RNGs are used directly. They're used to fill the pool of entropy used by entropy based RNGs. And the funny thing is: Adding non-random data to entropy pools doesn't lower the entropy. It merely doesn't increase it.

[Weasel]

This is so terribly stupid; there are tons of uses for even a non-trusted but fast HWRNG, like rendering, machine learning, scientific/business simulations; register-access latency class RNG with infinite cycle and no dumb artefacts would be groundbreaking.

You do realize RDRAND is an instruction available for user-space right? So what stops you from using it no matter the distro's decision? ffs just use inline asm or an intrinsic and you have it.

But no, RDRAND must be for 'security', so it is wrapped in some kind of a hardware PRNG and thus slower than many software PRNGS. On the other hand, while it most likely has no backdoor (it is literally the worse possible place in a CPU to put such), it cannot be ever trusted by anyone sane because it is perfectly closed.

Software PRNGs are terrible because they are seeded only once or so in most applications, compared to RDRAND, at least according to its specs, obviously we don't know if it truly lives up to its specs, but there's no proof to the contrary either. RDRAND can be thought of as true randomness in a way; impossible to predict. Software PRNGs will *never* achieve this.

Of course you can claim backdoors and all that but that doesn't make it weaker than software PRNGs, just not as good as the specs suggest. There's no proof, either, so...