Is this assumption correct, that adding a magnetometer, accelerometer, simple GPS, etc to a motherboard would improve its entropy gathering? Or is there a mathematical/cryptographical rule that makes the addition of such sensors useless?
Do smartphones have better entropy gathering abilities? It seems like phones would be able to seed a RNG based on input from a variety of sensors that would all be very different between even phones in the same room. Looking at a GPS Android app like Satstat (2) it feels like there's a huge amount of variability to draw from.
If such sensors would add better entropy, would it really cost that much to add them to PC motherboards?
----
(1) https://www.hackerneue.com/item?id=30848973
(2) https://mvglasow.gitlab.io/satstat/ & https://f-droid.org/en/packages/com.vonglasow.michael.satsta...
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...
A real randomness source would be really great to have in pretty much every computing device these days, considering the widespread use of encryption.
If your security threat profile has to account for actors with the resources to perform reverse engineering of your hardware, side channel analysis and RF injection, then we're already way out of the realm of low cost devices.
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)
Reading from RF trace does not take any more power than any other analog pin voltage measurement.
Running a few more instructions to "process" (not as if there's much processing needed) the sensor readings is also hardly measurable.
https://wiki.qemu.org/Features/VirtIORNG
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.
How is there any overlap in the devices that can't have something clever figured out and devices that could possibly see an update to their kernel code?
Note: Extremely good reason for breaking userspace is along the lines of "/dev/random has been found to be insecure causing mass security mayhem" not "man I'd really like to ignore the 0.01% of users this would cause an issue for so I can get my patch in faster".
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().
but that risk is at 100% NOW, how is it not worth reducing it?
[1] https://en.wikipedia.org/wiki/RDRAND
[2] https://www.electronicdesign.com/resources/article/21796238/...
In both cases, RDSEED is "true random", according to Intel and AMD (though the specific argument for why it qualifies as true random differs on their designs)
RDSEED is like /dev/random while RDRAND is like /dev/urandom.
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.
One issue that I've been wondering about is how safe this is. Presumably you can't let a VM use the RDRAND directly because it could starve the entropy of other VMs. Assuming that presumption is true, a hypervisor would need to manage that shared resource fairly amongst the VMs.
I'm pretty sure rdrand is fine, and would not bat an eye if Linux trusted it, but I'm not sure I would bet some nuclear launch codes on it. Linux is trying to be as safe as practically possible, not just "Probably safe".
If it's even remotely an issue there are dedicated hardware sources in various form-factors like PCIE or USB. They're pricey but at least you can vet what your getting if that matters so much.
Are there any real-world accounts of people getting pwned because of a bad pseudo rng?
How much do we trust what we're told about the circuit? Does its interface talk to that noise-source all the time? Or is there a cutaway inside that maybe jumps to a seeded PRNG in response to a special memory-write? Would you know if it did?
I'm not saying that RDRAND is backdoored. I've got no reason to assume that it is. But it would also be very hard to prove that it -isn't-. If I was doing something where I actually cared about the quality of my entropy, I might not want to just take Intel at their word.
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/
A backdoored RNG is unlikely to ever repeat patterns, that would be obvious, so it should be trustworthy enough to create a unique number.
It also probably, but not definitely can't phone home without someone noticing(Unless it can target specific people who aren't looking), and if it can, it can also send anything else it wants anyway.
An insecure but unique seed hashed with a secret machine specific value should be safe, it's not like they can manipulate the final value without having a way to break the hash, right?
You could even reuse the secret between machines as long as the attacker doesn't know it and everything else in the hash is unique.
Whatever network boot thingy or ansible job could provision random seeds when it updates the OS.
"One ring to rule them all" is the quote my inner security sense immediately reaches for
https://www.cloudflare.com/de-de/learning/ssl/lava-lamp-encr...
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
Like cloudflare's beacon thing.
However lotteries are mostly just entertainment like any other gambling, and the balls are part of the show, so they would need some other spectacle.
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 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.
(See https://www.hackerneue.com/item?id=2947936 from 2011 but the original article link seems to have gone)
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).
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...
> 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.
Is this true? If you crank the gain on the cheap mic amplifier that comes with basically any laptop or motherboard, you'll get a ton of noise. Yes, the high bits will be correlated between samples, but if you XOR all the bits in a sample - or multiple samples - together, that ought to be a pretty solid random bit, no? You just need to make your XOR-ing "window" span at least 1 bit's worth of entropy in the stream. It's not megabytes per second, but it's a lot better than having the user wiggle the mouse, surely?
Analog TV tuners were very cheap. Now it no longer makes sense to use an expensive analog capture board for a RNG.
There are much cheaper solutions.
For no more than $10, you can make a RNG using the ADC of either a microcontroller board with USB interface or of an audio USB dongle or of the microphone connector of the motherboard audio.
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).
if you run the same program twice, you get the same result. this is the wonderful result of all that work... but now there's no noise so there's no randomness.
random number generators are actually just mathematical functions that produce a stream of output with a flat distribution given a fixed input. the simplest ones give the exact same output given the same input. (sometimes this is exploited in debugging of algorithms that make use of randomness, like monte carlo methods).
newer hardware has hardware support for generating random numbers using analog phenomena, but older hardware doesn't always have this. there are some clever hacks in the kernel that make use of noise found in the clocks that drive the digital system, as well as sampling from a variety of external sources (interrupts from things like network activity, or keyboard/mouse, or other hardware).
the problem here is that they want good randomness early in the boot process when a lot of those interrupts aren't being generated (because the hardware hasn't started), there's no hardware support for randomness, and the clock noise trick doesn't work.
my guess is that they'll probably add a few more random (hah) hacks to try and generate noise when there's no peripherals although the article states that they're going out and trying to fix userland by adding a program that saves/restores some randomness for each boot.
there's so much random noise in the environment that it is extremely hard to answer.
moreover, we know that early development of sensorimotor systems is driven by random noise. we learn to control our bodies by being stimulated by environmental noise, attempting to use our effectors (muscles), observing how that works out, correcting errors and then improving on it.
what gives rise to consciousness? i'd argue the randomness from the noise in our environments.
And you need to be assured that a sequence meets those needs without being able to test it to exhaustion, which means it has to be provable from inspection of the algorithm and original sources of entropy. At least, provable enough for the application. ;-)
That said I do also understand why it is relatively easy to make PRNGs. But that is just dissimulation, its just making instructions eat their own tail.
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.
you take all of them and run it through an appropriate extractor. it is very easy for ADC error to have structure and bias.
Extra sensors cost extra money, and people not are willing to pay for no visible benefit to them.
https://ieeexplore.ieee.org/document/7132901
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".