Why don't PCs have better entropy sources?

PCs can and do include hardware support for entropy gathering, see RDSEED [1]

Linux is aware of RDSEED and uses it to provide additional randomness when available. You do need to trust the implementation to be free from backdoors and bugs - some CPUs are known to be buggy. [2]

Randomness seeding issues largely does not concern desktop PCs or smartphones (although you can easily catch early booting programs like systemd reading randomness before it has been fully seeded) [3].

It is a much bigger issue on either small embedded devices or VMs, both of which may have very few peripherals to gather entropy from. They can be provided randomness through dedicated hardware support, or from the host, and they probably should be, but that still leaves many real-world systems currently running Linux out in the cold. This is not just a theoretical problem, as has been shown by looking at indicators like RSA keys with colliding primes, which should never happen when generated with good RNG. [4]

[1] https://en.wikipedia.org/wiki/RDRAND

[2] https://github.com/systemd/systemd/issues/18184

[3] https://github.com/systemd/systemd/issues/4167

[4] https://freedom-to-tinker.com/2012/02/15/new-research-theres...

I think it's worth repeating this:

While there are platforms with better and worse hardware sources of unpredictable bits, the problem with Linux /dev/random isn't so much a hardware issue, but rather a software one. The fundamental problem Linux tries to solve isn't that hard, as you can see from the fact that so many other popular platforms running on similar hardware have neatly solved it.

The problem with the LRNG is that it's been architecturally incoherent for a very long time (entropy estimation, urandom vs random, lack of clarity about seeding and initialization status, behavior doing bootup). As a result, an ecosystem of software has grown roots around the design (and bugs) of the current LRNG. Major changes to the behavior of the LRNG breaks "bug compatibility", and, because the LRNG is one of the core cryptographic facilities in the kernel, this is an instance where you really really don't want to break userland.

The basic fact of kernel random number generation is this: once you've properly seeded an RNG, your acute "entropy gathering" problem is over. Continuous access to high volumes of high-entropy bits are nice to have, but the kernel gains its ability to satisfy gigabytes of requests for random numbers from the same source that modern cryptography gains its ability to satisfy gigabytes of requests for ciphertext with a 128 bit key.

People looking to platform hardware (or who fixate on the intricacies of threading the LRNG isn't guest VMs) are mostly looking in the wrong place for problems to solve. The big issue today is that the LRNG is still pretty incoherent, but nobody really knows what would break if it was designed more carefully.

All x86 CPUs sold after 2015 or so have built-in hardware random number generators [1]. They get their entropy by sampling thermal noise on the input of a meta-stable logic gate [2].

[1] https://en.wikipedia.org/wiki/RDRAND

[2] https://www.electronicdesign.com/resources/article/21796238/...

Read the LWN article. The problem isn’t PCs at all - it’s virtual machines, and embedded machines, that hang at startup, waiting for any entropy at all. Of course you could say the bug is in the hypervisor, or the embedded board designer, but the Linux kernel developers can’t afford to break these use cases just for purity’s sake.

There are such sensors, listening to thermal noise, right inside most CPUs https://en.wikipedia.org/wiki/RDRAND It's a question of trust. Do you trust that Intel (or whoever builds the physical RNG) didn't build a backdoor, a secret predictability? Maybe it's safer to build your own.. or combine several sources (like linux kernel does).

> magnetometer, accelerometer, simple GPS,

At boot time, on a server sitting in a rack beside thousands of others ... how are these going to help any? They aint moving and the RF/energy environment around them should be steady state or well within characterize-able bounds of noise.

"Random enough" is a metaphysical question when you get into it. If an RTLSDR stick and a site customized munger script can't provide enough entropy for the entire data center you've fallen into a Purity spiral and will never be happy, anyway.

If you zoom in enough there is noise everywhere. Thermal noise across a resistor is particularly easy to measure [0]. Purists might want a nuclear decay event[1], or even a cosmic ray detection[2] but the more complex the apparatus the more shenanigans can occur.

For hyper important entropy, humans must invest in a macroscopic and very slow spectacle - a publicly prepared experiment broadcast live to a large audience. [3]

0 - https://analog.intgckts.com/noise/thermal-noise-of-a-resisto...

1 - https://en.wikipedia.org/wiki/Schr%C3%B6dinger%27s_cat

2 - https://www.youtube.com/watch?v=gwIGnATzBTg&t=479s

3 - https://www.youtube.com/watch?v=Bup0TcbQeVs

For those that want an (additional) source of entropy, the FSF offers[1] a USB HWRNG[2] that uses ADC quantization noise. It seems to be simple and clever enough to get the job done. True to FSF form the source is available if you want to adapt it to your own MCU. The data provided by mine passed all the randomness quality tests I could throw at it.

I don't know if it's still maintained or not, but the developer proposed a public entropy pool[3] which looks interesting. Full disclosure: I haven't looked at it closely enough to understand how the trust model works.

[1]: https://shop.fsf.org/storage-devices/neug-usb-true-random-nu... [2]: https://www.gniibe.org/memo/development/gnuk/rng/neug.html [3]: https://www.gniibe.org/memo/development/kun9be4/idea.html

The problems you mentioned are not related to PCs or systems with motherboards like you are thinking. Every not-too-ancient PC CPU has been able to gather sufficient entropy just from cycle timing jitter. The problem is with old, simple embedded systems (and actually just emulations of said systems).

As many of these comments show, it's easy to come up with creative and probably effective sources of entropy.

The problem is knowing when you've collected enough to (re)seed your random bit generator.

Entropy sources usually have failure modes that result in predictable data in the output. The entropy source has to work even when someone is using an arc welder nearby or puts popcorn in the microwave.

Assuming kernel memory stays secret, collecting entropy should only be a problem during boot.

But distro maintainers aggressively optimize boot times, so there's a little time to spend collecting entropy at boot. Systems usually save a bit of entropy on the hard drive across boots, but that has its own issues. Unfortunately, first boot is when the SSH keys are generated, so that's kind of the worst-case scenario.

They already do have; see Intel's implementation on Ivy Bridge : https://www.electronicdesign.com/resources/article/21796238/...

(See https://news.ycombinator.com/item?id=2947936 from 2011 but the original article link seems to have gone)

Here is a test of Linux' random number generator by Germany's national ITSEC body, BSI: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publicat...

Generally speaking, a lot of proposed sources of "randomness" may not be as random as people think. And off-the-shelf hardware may be compromised/influenced by governemnts (see the NSA-NIST scandal).

For safe communication (one-time pad), you need plenty of truly random numbers, not pseudo-random ones.

It would therefore be good to have an open source source of entropy as a USB device, e.g. based on radioactive decay of some harmless but unstable isotope. There are companies offering such devices, but again I would not trust any of them but prefer people build their own from open hardware specs (it is likely that these vendors are infiltrated by intelligence agencies the same way as Swiss-based Crypto AG was - https://en.wikipedia.org/wiki/Crypto_AG).

PCs are not where problems with entropy generally are a large issue. For starters, many CPUs have inbuild hardware entropy sources (although not everybody trusts them)

There are good entropy sources (as others have indicated)

But just because there are good entropy sources on physical hardware doesn't mean the overwhelming majority of system instances are inheriting those sources well (and not just virtual machines/cloud processing)

6 years ago I wrote about haveged, truerand, and twuewand[0] (specifically in the context if improving the entropy pool for a heavy Java app)

There are also dedicated USB dongles ... but again: they don't help much (if at all) for hosted instances (containers, VMs, etc)

--------------

[0]https://antipaucity.com/2016/04/01/improve-your-entropy-pool...

I think VIA [1] did this on some of their mini-ITX boards with embedded CPUs. I seem to recall a contemporary review saying that they used electrical noise to implement an RNG, a fact which is corroborated [2] here:

> Nehemiah stepping 3 and higher offers an electrical noise-based random number generator (RNG) that produces good random numbers for different purposes.

[1] https://en.m.wikipedia.org/wiki/VIA_PadLock [2] http://www.logix.cz/michal/doc/article.xp/padlock-en

I had an idea many years ago about using those cheap tv tuner cards that were briefly somewhat popular in PCs as an entropy source. If it could reliably tune to a dead channel I imagine it would be a good source of quality entropy.

Serious question, I don't know much about this - why is it hard to generate a random number? I don't really understand this conversation about needing better entropy.

For entropy sources that measure the environment, are there attacks where the attacker manipulates the environment? For example, when the source is measuring the temperature, an attacker could alter the temperature near the sensor to create more predictable random numbers?

Related: And does software detect if a sensor is broken or a poor source on entropy? Like if it broke and locked itself on to the same constant temperature reading?

I guess this is why "gpg --generate-key" asks you to bang randomly on your keybaord and wiggle your mouse, lol.

Nobody answered the real answer: there's simply no need. Existing solutions work good enough for most people, and it's dirt cheap.

Extra sensors cost extra money, and people not are willing to pay for no visible benefit to them.

You can use a cell phone camera as a TRNG, there are plenty of papers ie

https://ieeexplore.ieee.org/document/7132901

Interesting photonics opportunity here: could you produce a single photon slit-lamp on a chip for entropy production? Not sure you can do better than that.

We should use the white noise or turbulence generated by our PC fans as entropy sources. Brownian motion is one of the best entropy sources we have.

Given the day this was posted on I was half expecting it to be a proposal to add radiation sources as a standard computer component

> simple GPS

Excuse me, but when did pinging multiple satellites thousands of kilometres away (in orbit) become simple?

Because PC's weren't, from the beginning of its history, desgined for security scenarios.

Isn’t that what a Secure Enclave is for? I believe it has a TRNG, a true random number generator.

Will quantum computing solve this issue?

They do have lots of sensors that can be used... We have bad defaults and a not-very-skillful usage of said hardware. On workstations there are lots of options. In datacenters, there could be some dedicated hardware for it somewhere - and an skillful usage of said entropy being imported into each rack unit.