From your link: "ChaosKey is now out of production. They work great, but it took several years to sell our first production run, and shipping them from the US to other countries one at a time ended up dominating the net cost to most users. We might make more some day, but no promises!"
Usual caveat: Hardware RNGs don't really solve any practical problem, and are mostly based on urban legends about cryptography, e.g. the idea that you have to constantly refeed "lost" entropy in an RNG.
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.
I remember Linux running into a bunch of issues with boot time entropy. Some things were sometimes getting stuck on boot due to that.
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.
All Intel and AMD chips come with a hardware RNG today: the RDRAND and RDSEED instructions.
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?
You can (and are required to in certain environments) test for basic failures in your hardware RNG. The AMD bug was bad not because of the bug, but because it was obvious they had no built-in-test functionality.
>RDRAND is kinda-sorta like /dev/urandom, while RDSEED is /dev/random with stronger entropy guarantees.
/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.
Any hardware RNG that is included in a CPU or any other complex integrated circuit cannot be trusted, because it is impossible to verify that it is truly a RNG and not a pseudo-RNG that implements backdoors.
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.
It is completely impractical to store a table of hash values that is large enough to be able to reverse the hash. No HDD will be big enough.
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.
> 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
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.
A sufficiently adversarial CPU could detect the sha256 hash you're using as a random number generator (and no other sha256 hash) and set its result to a known value as well.
This sounds excessively paranoid to me. If you’re worried about backdoors and the threat model includes the ability to compromise the CPU, you probably need to back up a few steps and figure out how the CPU got compromised? What am I missing?
Any CPU can be compromised by its designers, and the owner cannot verify whether this is true or not.
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.
> Any hardware RNG that is included in a CPU or any other complex integrated circuit cannot be trusted, because it is impossible to verify that it is truly a RNG and not a pseudo-RNG that implements backdoors.
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.
For the RNG to be backdoored there is no need for something as unlikely as "rewriting assembly instructions".
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.
It wasn't that RDAND wasn't trusted as source of randomness in Linux. It wasn't trusted enough to replace the whole RNG chain - with entropy collection, seed extraction and DRBG/CSPRNG. Which to me was and is perfectly reasonable.
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 device itself isn't useful, but the design could be incorporated into systems that need a better source of early boot time entropy. Lots of embedded systems don't such a source, though it is getting better as more SoC vendors incorporate HW RNG.
For the full story, I was trying to reduce the boot time on my Linux system. One of the things that takes the most time is systemd-random-seed. From what I understand, it takes this long because my computer is not generating entropy fast enough, so it has to wait for a while.
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.
You are correct. However, history teaches us important lessons.
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.
Xorshift, lfsr, Mersenne, and LCG were never intended to be secure as far as I know, and were never cryptographically broken because they were never secure to begin with. They discovered flaws that could bias some large scientific simulations and such in some of them.
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.
They have applications beyond cryptography. One use case is to generate a unique random ID at startup. You can't do that without some sort of entropy source.
In many embedded systems and constrained devices, there is a lack of proper randomness. And often the system environment is too stable to use as source of entropy (by connecting a sensor). This makes it hard to set up secure sessions.
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.
A reason is if you're using a scheme that has information theoretic security, rather than computational, when instantiated with a TRNG.
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).
I'm mostly interested in optical HWRNGs from a curiosity about the single photon emitter, was just skimming a paper which seemed to indicate you can make one from a std. LED, which seemed very cool to me.
I've used randio and rtl-entropy, and they work okay, but there's some - possibly legitimate - concerns that even a shielded device can be made to output arbitrary [enough] bits from a concentrated attack, should an adversary know you're using that for entropy.
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.
as Joachim mentioned; and as i thought i replied already - all sensors have enough noise to be entropy sources. If you can quiesce a sensor - by putting it in a chamber that reduces whatever it senses, or otherwise reducing the input, you can grab "noise". MEMS sensors are notorious for being "noisy", and should always be looked at for cheap entropy sources. Followed by webcams in black chambers, webcams with a single photon source in a reflective chamber, anything that can pick up any RF whatsoever (including ADCs with signal and a resistor or inductor to ground), and so on up to thermals, Geiger detectors, avalanche silicon circuits, and beyond.
One key difference (at least for some) is that the Infinite Noise project uses a completely hardware-defined USB chip[1], which has been decapped. Thus you could in theory buy a batch, decap a random selection and visually inspect to verify that it matches the reference.
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.
I don't see a FIPS certification for it? I mean, at least show us some NIST 800-22 results. We already have a DRBG RFC to account for poor-entropy systems that has considerable research behind it. This seems pointless.
I've got an FST-01 that I've been meaning to set up with NeuG as a hobby project. Not sure if it would be worthwhile or if I would be better served spending my time on something else.
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.
One of my favorite technique for building a hardware RNG uses a cheapo FPGA circuit (something like this: https://www.aliexpress.com/item/32241350256.html?spm=a2g0o.p...) with a bunch of free-running high-frequency oscillators called ring oscillators (basically loops of NOT gates, which have a lot of phase noise, especially if they run hot) that are sampled at constant frequency.
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.
I was going to say that this is what we used as one of two entropy sources [0] in the Cryptech HSM. But the second link there is the fork of the Cryptech rosc entropy source we did for the FPGA based NTS server. ;-)
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:
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:
The chip itself isn't verifiable, like the document says. It's possible that there's a backdoor. It's not likely, but it's not verifiable and you'll have to trust it.
Given a suitable app, the Tillitis Key 1 works as a RNG. I have written a first version, and will release one in the public app repository in a week or so.
50 comments
[ 3.0 ms ] story [ 105 ms ] threadPrevious discussion, with the designer in the thread (2014): https://news.ycombinator.com/item?id=8519801
Really? What about the ChaosKey? https://altusmetrum.org/ChaosKey/
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...
[4] https://github.com/altf4/untwister
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.
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).
https://github.com/pwarren/rtl-entropy
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.
https://www.crowdsupply.com/leetronics/infinite-noise-trng
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...
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.
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:
https://github.com/stnolting/neoTRNG
https://github.com/Netnod/rosc_entropy
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:
https://git.cryptech.is/core/rng/trng/
Yeah, but Von-Neuman decorrelators have one major drawback: their throughput is unpredictable.
http://blog.cros13.net/2014/08/cheap-entropy-using-your-rtl-...
https://github.com/tillitis/tillitis-key1
https://github.com/tillitis/tillitis-key1-apps