OneRNG – Open Hardware Random Number Generator
onerng.info
onerng.info
The issues with RNGs usually come down to lack of use of a secure RNG, bugs within the RNG or early boot time entropy. Only the third may benefit in theory from a hardware RNG, but the devices that potentially have this problem usually don't come with an USB port, so it doesn't help either.
Also this "lost entropy" thing has long been a bane of VM servers, which could consume vast amounts of it. I think this changed fairly recently.
And lots of things have USB ports these days, including things like commercial wifi access points, routers, switches, etc. Some of those have internal ones.
RDRAND is kinda-sorta like /dev/urandom, while RDSEED is /dev/random with stronger entropy guarantees.
Linux didn't want to "trust" this hardware, for whatever reason. I guess there was that one time an AMD bug in the instruction returned all-zeros (or something similar). But as "long as the instruction is properly working", it is... well... working, lol.
But its not like its really possible to test if its working correctly.
--------
From that perspective, a hardware RNG needs to be "large" and "discrete" enough for humans to easily test and prove that its working, to create trust. Otherwise, hardware and/or firmware bugs could lead to a security problem.
EDIT: if you are at a mass produced but don't verify kinda person, then you might as well use RDSEED instructions to get her entropy. Intel/AMD probably are good enough to prevent firmware / hardware bugs. I know that VMs also have an issue here: whether or not to make RDSEED deterministic/predictable or not. Should the future RDSEED instructions be saved in a VM snapshot?
/dev/urandom and /dev/random is almost the same nowadays, the only difference is that random will block after boot until enough entropy is collected, but it never "runs out" of entropy anymore.
The only hardware RNGs that can be trusted are those that use an analog-digital converter (e.g. one of the ADCs included in any microcontroller, or the audio microphone input of a computer) and a discrete analog noise source, e.g. a diode or a resistor, because their components can be tested separately, to verify that they do what they claim to do.
Nevertheless, the output of the hardware RNGs provided by the Intel or AMD CPUs can be used in a reasonably secure way if the supposedly random values are never used directly, but they are passed through a cryptographic hash, e.g. SHA-256. Even SHA-1 is completely adequate for this special purpose, where collision-resistance does not matter (and it is faster than any other secure hashes in the ARM, AMD or Intel CPUs with SHA-1 instructions).
Even better, the supposedly random value could be hashed together with the timestamp read from the TSC, or just with the value of a counter incremented after generating a random number, for additional unpredictability. One can add to the hash a unique computer identifier, e.g. the MAC address of the first Ethernet interface. In this case, distinct sequences of uniformly-distributed pseudo-random numbers will continue to be produced even in computers where the hardware RNG remains stuck to a constant value, as it happened in some buggy AMD Zen models.
The hashing (with a secure hash algorithm) of the RNG output destroys any hidden structure that might have been exploitable by the designers of the hardware RNG, while preserving the uniform distribution of the random numbers.
Suppose the internal RNG is just AES in counter mode(Assume somehow they can persist state internally) They then know the full list of numbers it will ever make.
They also know the full list of hashed numbers it will ever make, if they know the hashed block size, which they do if they know what software you are using.
Now when you make a private key they just try all trillion possible offsets into the list of numbers it could likely be, hash those 32 bytes or whatever the block size is, and see if that's your key.
But I am not the paranoid type nor do I currently have things to hide from anyone with access to Intel backdoors, so I'm not too worried.
I think Linux has it pretty well figured out mixing in other sources just to be sure.
Moreover, as I have already written, this possibility is easily circumvented by also hashing a time-varying value and a value unique to each computer, not only the RNG output.
Otherwise there is no need to store a table of values.
If a home type PC is used for a year, there will be a finite amount of randomness used from the HW generator in total. Probably under a terabyte I would guess. Maybe under a gigabyte.
If you are doing something like looking for an encryption key, you know it's somewhere in that terabyte, which you can generate too, then put every possible block through your hash, and try it.
You don't even need to store anything, you can just generate them since they're deterministic. And if the backdoor is based on a block cipher in in counter mode or something like that, you can do it all in parallel on FPGAs in seconds if you're a billionaire.
Why would you go to any of this trouble and not just XOR the output of RDRAND into the starting seed (based on hardware entropy) for your PRNG (/dev/urandom)? Even if it turns out that Intel is providing a single static value (like all zeros) to every device ever, that's not going to help them figure out the starting seed if the rest of the entropy is from a sufficiently secure source.
At some point, you gotta just trust the hardware.
All Intel and AMD CPUs are compromised from a security POV by features much more dangerous than the hardware RNG, i.e. by the existence of the System Management Mode and of the extra processors included in the CPU package, which can do absolutely anything in a manner that cannot be detected by the owner of the computer.
As long as Intel and AMD do not publish a complete documentation of how their remote management features work and as long as they do not allow the owners of the computers to control them, it can only be assumed that they can be backdoored.
Whatever documentation exists for those features, it appears to be provided only under NDA, presumably only to the companies which write remote management applications for large corporations.
Nevertheless, like for the hardware RNG, there are workarounds that can make very unlikely the exploitation of any hardware backdoor.
For example, if a computer with an Intel CPU is used in a router/firewall exposed to the Internet, it is prudent to not use any Intel Ethernet interface for the Internet interface. If there are only Intel Ethernet interfaces, an USB to Ethernet adapter can be used. This will prevent the use of the remote management by an attacker.
The same applies for the WiFi, for a secure router/firewall, any Intel WiFi must be disabled (e.g. by disconnecting the antennas) and replaced by a WiFi dongle.
If the opponent has enough control of your CPU to rewrite your assembly instructions to do nefarious things, you have more than just RDSEED to worry about.
It is enough for the supposedly random numbers to be non-random, i.e. deterministic, according to a function known only by the designers of the hardware RNG.
It is impossible to distinguish by testing a true RNG from a good pseudo-RNG.
Designing a hardware pseudo-RNG instead of the claimed true RNG is a trivial task.
Succeeding to exploit it to decrypt something, e.g. some HTTPS traffic, is however not very likely, because it is easy to avoid this by combining the output of RDSEED with other sources of random numbers and by processing it, e.g. by hashing.
So it can be hoped that the designers of a hardware RNG do not attempt to backdoor it, because the chances of that being used successfully are low and the penalty if that would ever be discovered is high.
For very good reasons. The circuit is opaque and vendor specific.
The OneRNG presented in the article is claimed to be verifiable, at the very least.
Intel and other chip vendors don't even bother making the claim.
Replacing an open source chain that can be fed with entropy from several sources and mixed together, with a black box that is hard to inspect and trust.
The solution to fix this is to find a way to generate more entropy. The system doc on random seeds has lots of information about what you can use: https://systemd.io/RANDOM_SEEDS/.
One of the options is RDRAND, which my CPU can do. But after reading a bit about it, it seems that some people are supicious of RDRAND. I have no idea if I should too, and since it was disabled by default on my distribution, I decided to keep it of for now, as I don't really understand this subject.
At this point I wondered if any hardware RNG existed, and found the OneRNG, that seems like a cool project, so I posted it here.
This is not a recommandation to use OneRNG instead of RDRAND, I don't know enough about this domain to suggest one or another.
Back in the old days when cryptography was a weird concept nobody understood, we had the Linear Congruential Generator (LCG)[1] to generate pseudo random numbers. It looked random, so we used it.
Then some egghead said "give me a few outputs of your LCG and I can reverse it back to a seed"[2]. Oh damn! What do we do? The obvious solution: Reseed the RNG before you use it.
Then another egghead said "I've invented Mersenne Twister (MT). It is faster and more secure"[3]. So we switched to that. No need to reseed the RNG anymore!
But then someone said "We have broken MT. Take some numbers. Give it to this app, and it will give you the seed"[4]. And so we started to reseed the RNG again.
Today it is hash-chaining, XOR-shift and improved linear-feedback shift register algorithms.
Do you want to put your money on that we have now reached bug-free well-enough PRNGs that we no longer have fiddle with reseeding? It is a dangerous gamble. More than anything I wish we were clever enough to create robust, correctness proven and high-performance PRNGs so we could stop all this nonsense - but alas, here we are.
[1] https://academic.oup.com/comjnl/article/1/2/83/425243
[2] https://en.wikipedia.org/wiki/Marsaglia%27s_theorem
[3] http://www.math.sci.hiroshima-u.ac.jp/m-mat/MT/ARTICLES/mt.p...
But nobody is going to be directly using USB numbers to make billions a second for simulations, these dongles are mostly meant for cryptographically secure stuff.
Their competition is whatever algorithms Linux urandom snd OpenSSL are using at the moment, and the builtin RNGs most chips have had for a decade.
CSPRNGs are occasional broken, but it seems to happen about as often as other crypto primitives. They are based on hashes and ciphers usually, and these days those can go for decades without much progress on a break.
Unless P==NP or something happens and ruins all the fun, I'm fine with current crypto prngs. I don't think I've ever handled data that was so critical that anything else was needed.
If fairness, more and more MCUs (esp based on ARM Cortex) that contain some sort of TRNG / entropy source. Some of them have fairly good quality too. But there are still tons of 8051-based MCUs that lack any source of randomness. Having a cheap, physically compact, low power source of entropy that can be attached is in these cases quite useful. Esp for securing systems already in use.
The entropy isn't very "clean" (lots of auto-correlation), but it's unpredictable enough to seed a crypto hard RNG which can also be built into the FPGA and operate at very high speed.
It's also an increasing PITA to convince synthesis tools to actually emit ring oscillators, which they consider to be a design bug (which they almost always are, except in this specific case), but it's still possible.
[EDIT]: a quick search on github yields:
The TRNG in the Tillitis Key 1 (TK1) we released a couple of weeks ago contain a version of the rosc entropy source. But I have now included a VN-decorrelator. And the actual oscillators are much simpler, cleaner.
[0] The other entropy source in cryptech is an avalanche noise source outside of the FPGA. Both sources can be found here:
https://git.cryptech.is/core/rng/avalanche_entropy/ https://git.cryptech.is/core/rng/rosc_entropy/
The complete TRNG samples both sources (round robin) and creates a seed using SHA-512, with previous seed a part of the input. The seed is then used to initialize ChaCha20 as CSPRNG:
Yeah, but Von-Neuman decorrelators have one major drawback: their throughput is unpredictable.
The OneRNG uses a more regular SoC, which is theoretically susceptible to supply chain issues like fakes or deliberate tampering. To their credit, they do mention this:
There is one complex chip on the OneRNG which cannot be verified by eye. The CC2531 SoC (from Texas Instruments) is small, and it is theoretically possible that the chip fitted to your device has been tampered with or even been outright substituted for an alternative before you received your device.
[1]: https://www.crowdsupply.com/13-37/infinite-noise-trng/update...
Previous discussion, with the designer in the thread (2014): https://news.ycombinator.com/item?id=8519801
Unfortunately, these diodes in avalanche mode degrade over time and it is unclear how stable the quality of the entropy derived from this analog circuit is over long periods of time.
http://blog.cros13.net/2014/08/cheap-entropy-using-your-rtl-...
Really? What about the ChaosKey? https://altusmetrum.org/ChaosKey/
As far as generation, old webcams sealed inside of coffee cans painted as dark as possible on the inside, and then sealed to ensure no light gets in, can be used to generate bits pretty quickly.
I haven't had time or inclination to mess with avalanching diodes/transistors/resistors to verify the randomness and immunity to environment, but i have used the above methods to test their entropy, and used it to generate One Time Pads. As per my HN profile, i used to be very into entropy research and methods; but lately my home - and homestead - life take up most of my time.
and RDRAND et al use thermals from the dark silicon to generate ~1mhz of entropy (as of 2018,) which should be sufficient for practically any normal usage of entropy. A hardware entropy / RNG should only be needed if you are running something like a "lottery", you still need a verifiable "whitener", and you never touch "CSRNG" or "PRNG" anywhere.
Hopefully adequately built computational security is sufficient for any purpose, but this is a certificational difference-- hopefully not one in practice but potentially one in the kind of guarantees that you can give. (E.g. you can't prove that someone doesn't secretly know how to invert a HMAC-DRBG to get its state given a large chunk of its output)
It would be pretty foolish to use a IT security scheme just to destroy the property by using a DRBG to source its random numbers.
That said, since TRNGs are mostly interesting to snake oil drinkers there is good reason to expect most TRNG to be poorly constructed. (E.g. it's really common to see then dropping output based on a NIST SP 800-22, thus technically resulting in a biased output).