Ask HN: Why don't PCs have better entropy sources?

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

They have plenty of peripherals that can act as sensors, where you can draw entropy seeds from.

You can even leave an empty pin with a PCB trace to act as a crude antenna and pick up garbage RF.

You can use the built in RC oscillator as a crude temperature sensor.

My point is, if you're creative, embedded systems offer you so many options without any added cost.

I don't follow where the confusion is coming from?

[1] https://www.st.com/resource/en/application_note/dm00073853-s...

[2] https://csrc.nist.gov/Projects/Random-Bit-Generation/Documen...

Even presuming you modify the hardware/firmware, the additional cycles to handle and process the sensor data mean additional power draw compared to normal operation (embedded devices may frequently power down to wake from some interrupt to save power, additionally not all instructions turn on the same number of transistors - floating point ops require more power than simple branch instructions) - something again that prohibits doing this easily.

So "without any added cost" is simply untrue.

The reality is that randomness is relatively expensive, whether via hardware or software. Phones have more sensors - they also have massively complex SoCs and large batteries, which still are drained often over the course of a single day. They also tend to cost 1k+ USD, at least for flagship models (prices go as low as 50$ these days, but this is more from economies of scale and resale value economics than because phone hardware/software is suddenly cheap to manufacture)

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.

Stuff that depends on the existing bugs in order to function can keep functioning. Everything else can move to something sane.

Obviously I'm missing something here.

Also, just, it seems unlikely that the kernel project is going to agree to run two entire unrelated CSPRNG subsystems at the same time! The current LRNG is kind of an incoherent mess root and branch; it's not just a matter of slapping a better character device and system call on top of it.

For a start, there's a long tail of migrating all useful software to /dev/sane_random. Moreover, there's a risk new software accidentally uses the old broken /dev/random.

Besides, /dev/sane_random essentially exists; it's just a sysctl called getrandom().

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

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

There are some ways, although that doesn't mean they're always used.

I read this week QEMU has provides a virtio RNG device to the guest, that reads from the host. That's good. What I'm less clear about is other hypervisors, or whether x86 hypervisors tend to provide RDRAND support.

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 such a connector would have been standardized, very small analog noise generator boards that could be plugged in it would cost only a few dollars at most, and they would not contain any device more complex than an operational amplifier.

This solution cannot be back-doored, because it is trivial to test the ADC without a noise-generator attached, to verify that it really is an ADC and the small PCB with the analog noise generator can also be easily inspected to verify that it contains only the specified (analog) devices.

All this could have been very simple and cheap if it would have been standardized, and not more difficult to use than the unverifiable CPU instructions.

As it is, the paranoid must have electronics experience, to design and make their own analog-noise generator, to be used either with the microphone input of the PC audio connectors (which includes a weak power supply), or better with the ADC of a small microcontroller board, to be connected via USB (preferably on an internal USB connnector of the PC motherboard).

The following design[1] uses _two_ pluggable analog noise generator boards (since you don't trust one). The writeup will be of interest to the paranoid in this thread.

[1] http://nosuchlabs.com/

This is a good example of how you can make a RNG using a microcontroller board connected to an internal USB connector of the motherboard.

However what they have is not perfect, because the RNG boards include the ADC and some simple digital post-processing, providing a RS-232 serial output. For better auditability, the RNG boards should have been simpler, with only the analog part of the RNG, and they should have used an ADC input of the microcontroller instead of using a RS-232 input. If you compile from source and you write the flash of the microcontroller yourself, then it is secure enough.

Because only seldom such boards are available for buying, many people have done something like this only for themselves.

However the problem is that this is a non-standard solution. A connector like the 3-pin header shown at this link should have existed on every motherboard (but with analog input, not with RS-232 input). All software should have expected to have a standard RNG input on the motherboard, like it expects to have HD Audio input/output or temperature/RPM sensors. If the ADC would have been provided by the motherboard chipset, which already provides many other ADCs, there would have been no need for a microcontroller and no need of firmware for the microcontroller.

Had they wanted, Intel could have easily standardized a RNG input for the chipset, like they have standardized HDAudio, SMBus and countless other chipset features. Anyone else would have followed.

It is very likely that standardizing such a solution would have been actually much cheaper for Intel and AMD than implementing RNG instructions inside the CPU, which will always remain non-recommendable for any serious applications, so they waste die area and testing time during manufacturing, and they may also reduce a little the yields of good dies.

Any well-designed back-door in a black-box RNG cannot be discovered by testing.

Except for the RNG, the only other thing that cannot be trusted at all is because your computer/smartphone might allow remote connections to a management component of its hardware, regardless how you configure it.

Wired connections are not very dangerous, because you can pass them trough an external firewall and you can block anything suspicious.

The problem is with the WiFi connections, e.g. of the WiFi Intel chipsets in laptops, and obviously the least under your control are the mobile phones.

However even a smartphone can be put in a metal box to ensure that nobody can connect to it (even if that also defeats the main use of a mobile phone, it can make sense if you are worried about remote control only sometimes, not permanently).

On the other hand, a RNG that cannot be verified to be what it claims to be, is completely useless.

That there are some chances to test them does not provide any measure of trust... you actually have to perform the audit to achieve that.

>... On the other hand, a RNG that cannot be verified to be what it claims to be, is completely useless.

If we are going to take such an absolute line over RNGs, then, to be consistent, we should take the same attitude to the rest of the hardware and software we use - but, per my previous point, that means actually evaluating it, not just having the possibility of doing so.

One might, instead, argue that we should use only verifiable RNGs because that is actually feasible (at least for non-mobile equipment), but that does nothing to bring the rest of the system up to the standard of your last paragraph.

Any other malicious behavior is implausible, as either easy to detect or requiring too much information about the future (to be able to determine what to do and when to do without a remote control connection). Self-destruct is something that could happen e.g. after a certain number of active hours, but this would make sense only if you are a target for someone able to load special firmware into your own computer. If that would be a general feature of a computer, it would be easily detected after it would happen randomly.

So if you do not trust the HW, you must prevent remote connections. This is easy for desktop/server computers, if you do not have WiFi/Bluetooth/LTE and you do not use Intel Ethernet interfaces (or other chipset Ethernet interfaces, with remote management features) connected to the Internet or to any other untrusted network. Towards untrusted networks, you must use Ethernet interfaces without sideband management links, e.g. you may use securely USB Ethernet interfaces.

Unfortunately, currently there is no way to completely trust laptops when WiFi connections are possible, even if they claim that e.g. Intel vPro is disabled. In any case, it is still better if the manufacturer claims that this is true (like in my Dell laptop), even if you cannot verify the claim with certainty.

Even if someone would be able to connect remotely to your computer and spy you, they will have access only to your unencrypted or active documents.

If you use a bad RNG for encryption purposes, then the spies could also access any encrypted and non-active documents, which is a much greater danger.

In conclusion, the RNG is still in the top position of the hardware that cannot be tested and cannot be trusted. Nothing else comes close.

Yes, you are repeating yourself without addressing the issue that the ability to verify does not, by itself, confer any trust. Even if we accept your conclusion, it does not mean the other risks are inconsequential.

I trust my hardware manufacturers to be afraid of putting a backdoor into their chips if a binary captured via network surveillance could be used to show that a backdoor existed. This would be devastating to their business. Therefore, I trust them to not do anything that risks this occurring.

This is why people were so uneasy when internally-accessible unique serial numbers were added to the microcode engines of Intel processors.

You can protect yourself against faulty key generation by generating the key offsite or on a HSM.

However, a flaw in a RNG that allows a third party (hello NSA) to break cryptography - you cannot defend from that, you can't even detect it.

You always put bad randomness through enough calls of one way functions that reversing them is computationally infeasible for your adversary for the lifetime of the secret.

    Purity spiral

Note also most people have never seen a real lava lamp, only digital reproductions, like the one in Day of the Tentacle. Not the same thing.

(Some) People who study this often get lost down the rabbit hole and come out thinking the universe is deterministic.

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

The same can assuredly apply to capturing entropy.

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

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

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?

So if the temperature changes from 65.78614329 degrees to 66.24667182 degrees, you don't take 65 and 66, you take 329 and 182. Those digits are most likely to be random noise and not something an attacker can manipulate at will. Even if the analog part of the sensor is stuck at the same temperature as in your example, the digital reading will probably fluctuate around that value with plenty of random digits.

I get these are probably unlikely, but curious if there's some built-in detection for similar cases.

you take all of them and run it through an appropriate extractor. it is very easy for ADC error to have structure and bias.

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

2. regardless of how much technology/research went into developing the GPS, it's still fairly simple to access from a software point of view. A CPU may have millions/billions of transistors that are intricately placed, but that doesn't mean using your CPU to add two numbers can't be described as "simple".

> 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

There is no need to tune to a dead channel. Instead of connecting a TV cable or antenna, it is enough to connect a coaxial resistive terminator on the TV input connector. Then all the channels are dead.

Unfortunately this is a dead technology, so I have abandoned it after I retired my last motherboard with PCI connectors.

You can do something similar with the audio microphone input, but the TV tuners had a much higher bandwidth and a much higher sensitivity. For good results with the microphone input you need to make an analog noise generator, instead of using just a resistor, as it was enough for a TV tuner.

For this purpose, radio receivers are just very sensitive amplifiers. Any very sensitive amplifier will output noise when its input is terminated on a resistor, both amplified resistor noise and additional noise from sources internal to the amplifier.

When you use much less sensitive amplifiers than radio receivers, e.g. audio amplifiers, a resistor at the input may be not enough and you must put there a source of greater noise, e.g. an avalanche breakdown diode (a.k.a. Zener diode).