NeuG USB True Random Number Generator(shop.fsf.org)
shop.fsf.org
NeuG USB True Random Number Generator
https://shop.fsf.org/storage-devices/neug-usb-true-random-number-generator
101 comments
> Controversial opinion: Hardware Random Number Generators don't solve any real problem.
Good one; how often has encryption (of any sort) been broken due to not enough randomness? I mean I'm a noob but I can imagine that it'd only become a risk over communications that were tracked for a very long time. or something.
Good one; how often has encryption (of any sort) been broken due to not enough randomness? I mean I'm a noob but I can imagine that it'd only become a risk over communications that were tracked for a very long time. or something.
The classic example of "not enough randomness" is the Debian openssl vulnerability: https://www.debian.org/security/2008/dsa-1571 . But it isn't what you are imagining -- they didn't run out of entropy -- they just broke their RNG by removing all entropy sources.
There are no known issues with running out of randomness over time. The main reason to re-seed a CSPRNG is as a defense-in-depth against implementation flaws leaking state.
There are no known issues with running out of randomness over time. The main reason to re-seed a CSPRNG is as a defense-in-depth against implementation flaws leaking state.
Probably all rng-related vulnerabilities in modern crypto are caused by unnecessary complexity added in order to prevent "running out of entropy" and not by not having enough entropy in the first place.
I remember some broken SSL certs generated during boot of some routers.
HWRNGs make sense to me as a source of scalable boot-time entropy for hypervisors to distribute to their guests. But, in all likelihood, one HWRNG is good enough to feed the concurrent requests of an entire datacenter’s worth of hypervisors.
No, this is exactly the misconception Hanno is talking about. You don't need a "scalable source" of entropy. Entropy doesn't (practically) deplete. Spool off as many uncorrelated bits as you need for each guest, from your standard kernel RNG, as and when needed.
So, they solve the problem of having to ensure those issues are not present?
Also, it's not exactly unheard of of "good" prngs having bugs making them bad.
Also, it's not exactly unheard of of "good" prngs having bugs making them bad.
When's the last time a kernel CSPRNG in a mainstream operating system had an exploitable vulnerability?
We hear about "good" CSPRNGs going "bad" all the time, but invariably these are instances of people adding new userland CSPRNGs to their systems as rubber chicken security measures that later blow up.
We hear about "good" CSPRNGs going "bad" all the time, but invariably these are instances of people adding new userland CSPRNGs to their systems as rubber chicken security measures that later blow up.
Well, we all know about Debian, there is also Windows XP. And we all hear about bad PRNGs - maybe all those issues can be explained with userland implementations. I don't know. My point is, I don't have to know the answer to any of those questions if I opt for a hardware random generator.
Yes, I have to place trust in the hardware random generator instead. From a user perspective it seems like the attack surface (from the perspective of bad configuration, start seed, misuse etc.) is much smaller with a hardware generator.
And, conceptually it sounds like a safer option. Is it? Well, we arrive at yet another "I don't know".
Note, I'm not advocating the use of a hardware random generator at all, I'm merely responding to the statement that they don't solve any problem at all.
Yes, I have to place trust in the hardware random generator instead. From a user perspective it seems like the attack surface (from the perspective of bad configuration, start seed, misuse etc.) is much smaller with a hardware generator.
And, conceptually it sounds like a safer option. Is it? Well, we arrive at yet another "I don't know".
Note, I'm not advocating the use of a hardware random generator at all, I'm merely responding to the statement that they don't solve any problem at all.
Debian didn't break the kernel CSPRNG — they broke entropy seeding for OpenSSL. Debian could have unbroken OpenSSL seeding by reading from /dev/urandom.
Debian was OpenSSL's RNG, not the kernel RNG. So, it sounds like your response is that we have to go all the way back to Windows XP to see an example of a "good" RNG going "bad".
My bad, but sounds like your response is ignoring all but one of my points.
Keep in mind that the issue was present in Windows 2000 yet remained undetected for 7 years after the release of Windows 2000.
Keep in mind that the issue was present in Windows 2000 yet remained undetected for 7 years after the release of Windows 2000.
Not only that, but the Windows CryptGenRandom bug you're referring to (1) affects an ancient userland implementation of the Windows RNG, and (2) is principally effective as a second-order attack when someone has compromised the entropy pool. And this is the best example we've thus far come up with for a "kernel CSPRNG going bad".
I'm very comfortable with the validity of the argument I'm making, which is that we don't generally need to layer rube goldberg hardware onto our systems to hedge against the likelihood of the LRNG going bad.
I'm very comfortable with the validity of the argument I'm making, which is that we don't generally need to layer rube goldberg hardware onto our systems to hedge against the likelihood of the LRNG going bad.
So, would you be equally comfortable with stating that a hardware random generator doesn't solve any problems related to boot time entropy and the use of insecure RNGs by mistake?
How does plugging this device into a broken Debian system fix it?
The problem with the Debian issue was that of a bad seed to the RNG.
And I'd argue that getting good seed values is one of the main things that is appealing with a hardware generator (especially at system boot).
You'd still have to use it though.
And I'd argue that getting good seed values is one of the main things that is appealing with a hardware generator (especially at system boot).
You'd still have to use it though.
No, that's not the Debian problem. The Debian problem was that they literally ifdef'd out the RNG refresh code.
And, again, Debian's problem was in their version of the OpenSSL userland RNG. Applications that simply relied on /dev/urandom rather than OpenSSL's janky mess weren't impacted by the bug at all.
And, again, Debian's problem was in their version of the OpenSSL userland RNG. Applications that simply relied on /dev/urandom rather than OpenSSL's janky mess weren't impacted by the bug at all.
"Removing this code has the side effect of crippling the seeding process for the OpenSSL PRNG."
https://www.schneier.com/blog/archives/2008/05/random_number...
https://www.schneier.com/blog/archives/2008/05/random_number...
What's your point? The OpenSSL CSPRNG is a userland RNG, not Debian's built-in RNG.
This might be a controversial opinion on HN, but it's not controversial in crypto engineering circles. Consumer TRNGs are silly.
Your "Consumer" modifier made me curious: what non-consumer situations make TRNGs not silly?
Only external TRNGs, or even ones built into SoCs or CPUs, like RDRAND?
I think RDRAND is well worth the negligible cost of including it. It can give you entropy immediately, even during early boot (e.g. for ASLR); no need to wait or have any logic to deal with entropy not being ready yet (at least if you can rely on it being available, which should be true in the future). And compared to other approaches, it’s a lot harder to screw up or misuse, eliminating a whole class of potential vulnerabilities (especially if you use it directly rather than just seeding a kernel PRNG with it).
I think RDRAND is well worth the negligible cost of including it. It can give you entropy immediately, even during early boot (e.g. for ASLR); no need to wait or have any logic to deal with entropy not being ready yet (at least if you can rely on it being available, which should be true in the future). And compared to other approaches, it’s a lot harder to screw up or misuse, eliminating a whole class of potential vulnerabilities (especially if you use it directly rather than just seeding a kernel PRNG with it).
I'm not here to litigate how big a deal embedded cold start entropy problems are, so much as to point out that USB devices to increase "entropy" for consumer devices are silly and don't solve a real security problem, but do contribute to the misapprehension people have about the importance of "true randomness".
How are you supposed to get entropy into a system with no (good for RNG) inputs and no sources of noise? (think: embedded)
It is very hard to find system that has CPU powerful enough for doing any kind of cryptography while not having any usable entropy source, there is always something non-deterministic that you can measure (hash contents of memory at start of boot, time accesses to EEPROM, ADC noise, timing of events, the actual data that your system processes...).
Chaotic oscillators to seed a CSPRNG. Either on-chip[1] or discrete[2].
[1] http://forums.xilinx.com/xlnx/attachments/xlnx/EDK/27322/1/H...
[2] http://ieeexplore.ieee.org/document/7111269/
[1] http://forums.xilinx.com/xlnx/attachments/xlnx/EDK/27322/1/H...
[2] http://ieeexplore.ieee.org/document/7111269/
read the internal temp and Vref ADCs over and over, and hash the result, the same way this widget works?
Not with a USB HWRNG.
I don't understand this part of your criticism. Your core criticism has been that we don't really need hardware TRNGs because the math of CSPRNGs doesn't lead to "entropy depletion" in the way that people's mistaken mental models might suggest.
That's fine, but boot-time seeding problems are also a real source of RNG-related security problems, as described in the "Mining Your Ps and Qs" paper. (E.g. "The removal of IRQs as an entropy source has likely exacerbated RNG problems in headless and embedded devices, which often lack human input devices, disks, and multiple cores. If they do, the only source of entropy—if there are any at all—may be the time of boot.") Having a hardware TRNG for seeding in this case would presumably prevent these problems.
That's fine, but boot-time seeding problems are also a real source of RNG-related security problems, as described in the "Mining Your Ps and Qs" paper. (E.g. "The removal of IRQs as an entropy source has likely exacerbated RNG problems in headless and embedded devices, which often lack human input devices, disks, and multiple cores. If they do, the only source of entropy—if there are any at all—may be the time of boot.") Having a hardware TRNG for seeding in this case would presumably prevent these problems.
I'm speaking generically, I don't expect my embedded system to have a USB RNG plugged in
And it's not a theoretical problem either.
And it's not a theoretical problem either.
Weird how they specifically point out "free as in freedom", but then the real brain of this entire thing is a proprietary STM32F103 MCU.
They say the design of the product, not the components are free, if we're going to be pedantic.
To be fair, yes, the proprietary nature of a particular chip is bad for open source, but on the other hand, the marginal cost of a chip is not zero, like it is for software. There's the chip fabrication costs which only goes down in quantity. That means there's an inherent risk in developing a new chip.
However, if you're that concerned about it, there are open source designs which create free truly random bits, so you are free to choose a design that meets your need.
However, if you're that concerned about it, there are open source designs which create free truly random bits, so you are free to choose a design that meets your need.
Additionally, and I'm not positive that they've actually done this, but the chip also has fully open toolchain. While the guts of the chip aren't open source, it's possible for the firmware to be 100% open source without any binary blobs.
Yeah, we don't trust RDRAND but we trust this?
This is also available at Seeed Studio: https://www.seeedstudio.com/FST-01-without-Enclosure-p-1276.... By the time you read this, it'll probably be sold out, but I coincidentally signed up about a week ago to be notified when they were in stock, and I got that notification yesterday.
It's also possible to have MacroFab https://macrofab.com/ manufacture these for you on demand, using the KiCad files: http://git.gniibe.org/gitweb/?p=gnuk/gnuk.git The cost for a single unit is about $45, and it drops quickly to around $30 if you order a few.
It's also possible to have MacroFab https://macrofab.com/ manufacture these for you on demand, using the KiCad files: http://git.gniibe.org/gitweb/?p=gnuk/gnuk.git The cost for a single unit is about $45, and it drops quickly to around $30 if you order a few.
The FST-01 USB sticks can also be used as gnuk tokens for GnuPG:
http://www.fsij.org/doc-gnuk/
The NitroKey Start has the same STM32F103TB (IIRC) and is more readily available:
https://github.com/Nitrokey/nitrokey-start-firmware
https://shop.nitrokey.com/shop/product/nitrokey-start-6
Not sure if an RNG is accessible with the standard firmware (though the NeuG RNG is part of the gnuk firmware).
http://www.fsij.org/doc-gnuk/
The NitroKey Start has the same STM32F103TB (IIRC) and is more readily available:
https://github.com/Nitrokey/nitrokey-start-firmware
https://shop.nitrokey.com/shop/product/nitrokey-start-6
Not sure if an RNG is accessible with the standard firmware (though the NeuG RNG is part of the gnuk firmware).
Blast. I read this, it was in stock, I added to my cart...then the office lunch order showed up and I had to deal with the delivery for 5 minutes. Came back, out of stock. So sad.
If your goal was a small hardware RNG and you don't mind spending some time hacking, then I can save you some money.
Buy an ST103F development board ($1.72 shipped to US from China): https://www.aliexpress.com/item/1pcs-STM32F103C8T6-ARM-STM32...
Also buy an STLink programmer for it ($1.98 shipped): https://www.aliexpress.com/item/ST-Link-V2-Programming-Unit-...
Build https://github.com/texane/stlink/ or install OpenOCD.
Clone the NeuG repo and build for the Maple Mini target: https://anonscm.debian.org/cgit/gnuk/gnuk/neug.git/
Now flash neug.bin to the development board via the STLink, then unplug it and plug the board into your nearest micro-USB cable.
You now have a hardware RNG running the same NeuG software on the same processor family as the FST-01.
This board doesn't have enough program space to run GnuK, I think. Nor is it in the tiny form factor of the FST-01 that makes it more suitable as a hardware token.
Buy an ST103F development board ($1.72 shipped to US from China): https://www.aliexpress.com/item/1pcs-STM32F103C8T6-ARM-STM32...
Also buy an STLink programmer for it ($1.98 shipped): https://www.aliexpress.com/item/ST-Link-V2-Programming-Unit-...
Build https://github.com/texane/stlink/ or install OpenOCD.
Clone the NeuG repo and build for the Maple Mini target: https://anonscm.debian.org/cgit/gnuk/gnuk/neug.git/
Now flash neug.bin to the development board via the STLink, then unplug it and plug the board into your nearest micro-USB cable.
You now have a hardware RNG running the same NeuG software on the same processor family as the FST-01.
This board doesn't have enough program space to run GnuK, I think. Nor is it in the tiny form factor of the FST-01 that makes it more suitable as a hardware token.
Hardware random number generators sound like a great idea (I've bought an Entropy Key, long ago), until you realize all the problems they intrinsically have (besides all that "you don't need them stuff"):
* software has /no/ random failures, hardware does
* hardware ages and breaks down, often in subtle ways
* a broken down randomness engine is very hard to detect, since all HWRNGs do some whitening: your randomness source can output 1's all the livelong day, when you only see the output of some stream cipher operation or some chained hashes, no statistic tests are going to save you
* probably many more things
Hm, I really should consolidate my notes into that long-planned HWRNG article someday.
* software has /no/ random failures, hardware does
* hardware ages and breaks down, often in subtle ways
* a broken down randomness engine is very hard to detect, since all HWRNGs do some whitening: your randomness source can output 1's all the livelong day, when you only see the output of some stream cipher operation or some chained hashes, no statistic tests are going to save you
* probably many more things
Hm, I really should consolidate my notes into that long-planned HWRNG article someday.
Or just grab some hotbits: https://www.fourmilab.ch/hotbits/
Don't we already have "true" random number generators embedded on most modern processors? I was under the impression most motherboards have some sensors strictly for this purpose--to read data from static or thermal sensors in order to add entropy to the pool.
Intel CPUs do indeed have a random number generator onboard: https://en.wikipedia.org/wiki/RdRand
Probably the safest thing to do is to use a combination of this and other sources (multiple entropy sources), just in case there's an NSA backdoor or it's otherwise broken. Things like microphones, cameras, input devices, and other sensors are nearly ubiquitous now.
Probably the safest thing to do is to use a combination of this and other sources (multiple entropy sources), just in case there's an NSA backdoor or it's otherwise broken. Things like microphones, cameras, input devices, and other sensors are nearly ubiquitous now.
Is there any trick to combining entropy sources? Do you just add the numbers together, or is it something more involved, to make sure that you -- I don't know -- collapse entropy away in the combination, or something.
For cryptographic applications you generally just hash every input you have together with secure hash function.
Somewhat philosophical corollary to that is that when you have hash function that is secure enough for your application you can just build CSPRNG from it and use small (eg. 128 or 256 bit) seed and you have no need for hardware RNG.
Somewhat philosophical corollary to that is that when you have hash function that is secure enough for your application you can just build CSPRNG from it and use small (eg. 128 or 256 bit) seed and you have no need for hardware RNG.
Yes, modulo the fact that you want to update the CSPRNG with new entropy continuously to re-key it. Not to improve the cryptographic strength of the output or (for God's sake) to avoid "depletion", but to create forward secrecy. For instance: if the interval between reseedings is short enough, because updates are super cheap, you can make your RNG state churn too fast to be a useful target for something like Meltdown.
How does reseeding the CSPRNG create forward secrecy? I thought that if someone lifts your CSPRNG internal state (after it's been seeded and the seed tossed), they wouldn't be able to play it backwards to get previous output you've used as session keys or whatever.
I'm abusing the term, I know. But the idea is simple, right? Even a minuscule update to the kernel entropy pool makes a previously compromised state unusable. So you don't want your CSPRNG to just be a bit generator, like HMAC or CTR.
(Zvi Gutterman refers to the property I'm talking about as "backwards security", so my abuse of the term is particularly egregious).
(Zvi Gutterman refers to the property I'm talking about as "backwards security", so my abuse of the term is particularly egregious).
Hah, I was really asking what you meant, not trying to chide you about about terminology. Makes sense, thanks.
https://en.wikipedia.org/wiki/Hardware_random_number_generat...
https://en.wikipedia.org/wiki/Randomness_extractor
...the easiest is the von Neumann extractor where you just extract a zero if both randomness sources are zero, do the same thing for ones and discard all the differences. Half the output with more entropy than any single connected source (if they can't read or influence each other).
https://en.wikipedia.org/wiki/Randomness_extractor
...the easiest is the von Neumann extractor where you just extract a zero if both randomness sources are zero, do the same thing for ones and discard all the differences. Half the output with more entropy than any single connected source (if they can't read or influence each other).
Isn't this something different?
I thought the simple solution was to xor the two sources, which is at least a secure the best source?
I thought the simple solution was to xor the two sources, which is at least a secure the best source?
You might be interested in reading about Fortuna https://www.schneier.com/academic/fortuna/. It's an example of a class of PRNGs that are explicitly designed to generate cryptographically secure random numbers from a pool of sources including sources under an attacker's control.
I don't know the first thing about cryptanalysis, but what I gather from skimming the PDF is that yes, it's possible to advantageously influence a PRNG with bad inputs if the mixer sucks.
I don't know the first thing about cryptanalysis, but what I gather from skimming the PDF is that yes, it's possible to advantageously influence a PRNG with bad inputs if the mixer sucks.
This is a feature of basically every modern CSPRNG and a basic consequence of the crypto primitives we use to design CSPRNGs.
That's good to hear. It seems intuitive that it should be impractical to usefully influence randomness; if I can predict anything after a whitening step, isn't that whitening step horribly broken? But I've learned to squelch my intuition when it comes to cryptography.
(Now would be a great time to plug Matasano...)
(Now would be a great time to plug Matasano...)
You can basically just feed the various inputs in to a hash function. Of course, this imposes an upper bound on the amount of entropy if the output in the form of the length of the hash function output, but this is rarely an issue in practice.
Edit: Of course, this introduces the assumption that your hash function is secure, but again, not a problem in practice.
Edit: Of course, this introduces the assumption that your hash function is secure, but again, not a problem in practice.
The joint entropy of two random variables is never less than the individual entropies.
While that's true, just blindly mixing all you've got is a bad idea. Let's say you have "randomness" sources A, B, C and D, and you just use A+B+C+D. Now an attacker has total control over D. Then she could adaptively feed you with a D value that is canceling out A, B and C. Result is deterministic output.
Just adding in more is not always good. You need to trust every source. Or more precisely: You need at least one source in the mix that an attacker can't predict/read out.
Just adding in more is not always good. You need to trust every source. Or more precisely: You need at least one source in the mix that an attacker can't predict/read out.
> While that's true, just blindly mixing all you've got is a bad idea. Let's say you have "randomness" sources A, B, C and D, and you just use A+B+C+D. Now an attacker has total control over D. Then she could adaptively feed you with a D value that is canceling out A, B and C. Result is deterministic output.
This is only true if the attacker knows A, B, and C, in which case you have already lost.
> Just adding in more is not always good. You need to trust every source. Or more precisely: You need at least one source in the mix that an attacker can't predict/read out.
You sort of contradict yourself here. The fact that you need a source that the attacker cannot predict is a reason why it is good to just add more. The more sources you have, the more likely there will be one that the attacker can't predict.
This is only true if the attacker knows A, B, and C, in which case you have already lost.
> Just adding in more is not always good. You need to trust every source. Or more precisely: You need at least one source in the mix that an attacker can't predict/read out.
You sort of contradict yourself here. The fact that you need a source that the attacker cannot predict is a reason why it is good to just add more. The more sources you have, the more likely there will be one that the attacker can't predict.
Perhaps a better explanation of what randomnumber42 is getting at comes from Dan Bernstein: https://blog.cr.yp.to/20140205-entropy.html
It's an interesting attack, but as I mentioned, it requires an attacker to know every input to the hash function, which in many ways is strong argument for including as many sources of entropy as possible. It is certainly a much stronger argument than the other argument he refutes farther down.
There is also another more pressing issue, which is that if an attacker can see all of your RNG inputs, than they can predict your RNG output anyway, and they can predict your keys anyway. This renders Dan Bernstein's attack against DSA/ECDSA mute.
There is also another more pressing issue, which is that if an attacker can see all of your RNG inputs, than they can predict your RNG output anyway, and they can predict your keys anyway. This renders Dan Bernstein's attack against DSA/ECDSA mute.
I think his point is that continuously adding entropy might make it easier for an active attacker to exfiltrate data undetected.
The point isn't that continuously drawing entropy is necessarily worse. The point is to illustrate that it's not as risk-free as we may think. Furthermore, it doesn't provide much, if any value. In other words, why bother with the added complexity?
And there is added complexity. Linux[1] and OpenBSD use ad hoc mixing schemes for injecting entropy into their PRNGs, with no proof of security. There are schemes with proofs of security, but they're more complex. More over, the ones with the strongest proofs are the most complex of all and often relatively slow, which is why Linux and OpenBSD have been resistant to simply using, e.g., Fortuna.
Similarly, if you give up on constantly trying to inject data, then multiple CPU implementations are easier--just keep a simple PRNG state per CPU, without any fancy waterfall schemes.
These days collecting, even without a hardware RNG, 128 bits of entropy should happen in very short order. Estimates are of no matter, you either have it or you don't, and there's no way to prompt a user, "Do you really want to proceed?" If you can't collect 128 bits of entropy by the time /bin/init loads, you're probably screwed. The best example is a VM--if you have no access to a TRNG or to the host's entropy source, you shouldn't expect the situation to appreciably improve 10 seconds or even 10 minutes later. At the very least, you should assume you're screwed and that the environment isn't a place where you should put services and assets that depend, directly or indirectly, on secure entropy generation.
The logic is, why? Why bother? Especially in security, we normally shouldn't be doing things without well-quantified justifications, especially considering that engineers invariably underestimate the cost of complexity, particularly in the security domain. History has shown that not only do these behaviors create a false sense of security (they're often inadequate in ways we never initially understand[2]), but they can make matters much worse.
[1] At least I think it still does.
[2] No coincidence when the reason for adding them is to solve some ill-defined and poorly understood problem. If you can't quantify the solution you should be wary of relying on it. If you can neither quantify the problem nor the value of the solution (as in the case with constantly adding entropy), it's arguably poor judgment to apply the solution at all.
Of course, the malicious device will also be able to see
other sensitive information, not just x and y. But this
doesn't mean that it's cheap for the attacker to exfiltrate
this information! The attacker needs to find a communication
channel out of the spying device. Randomness generation
influenced by the device is a particularly attractive choice
of channel, as I'll explain below
The point isn't that continuously drawing entropy is necessarily worse. The point is to illustrate that it's not as risk-free as we may think. Furthermore, it doesn't provide much, if any value. In other words, why bother with the added complexity?
And there is added complexity. Linux[1] and OpenBSD use ad hoc mixing schemes for injecting entropy into their PRNGs, with no proof of security. There are schemes with proofs of security, but they're more complex. More over, the ones with the strongest proofs are the most complex of all and often relatively slow, which is why Linux and OpenBSD have been resistant to simply using, e.g., Fortuna.
Similarly, if you give up on constantly trying to inject data, then multiple CPU implementations are easier--just keep a simple PRNG state per CPU, without any fancy waterfall schemes.
These days collecting, even without a hardware RNG, 128 bits of entropy should happen in very short order. Estimates are of no matter, you either have it or you don't, and there's no way to prompt a user, "Do you really want to proceed?" If you can't collect 128 bits of entropy by the time /bin/init loads, you're probably screwed. The best example is a VM--if you have no access to a TRNG or to the host's entropy source, you shouldn't expect the situation to appreciably improve 10 seconds or even 10 minutes later. At the very least, you should assume you're screwed and that the environment isn't a place where you should put services and assets that depend, directly or indirectly, on secure entropy generation.
The logic is, why? Why bother? Especially in security, we normally shouldn't be doing things without well-quantified justifications, especially considering that engineers invariably underestimate the cost of complexity, particularly in the security domain. History has shown that not only do these behaviors create a false sense of security (they're often inadequate in ways we never initially understand[2]), but they can make matters much worse.
[1] At least I think it still does.
[2] No coincidence when the reason for adding them is to solve some ill-defined and poorly understood problem. If you can't quantify the solution you should be wary of relying on it. If you can neither quantify the problem nor the value of the solution (as in the case with constantly adding entropy), it's arguably poor judgment to apply the solution at all.
[deleted]
How you weight the entropy sources should be a function of the entropy sources, making it much more difficult to predict.
Weighting functions are useless. If you mix entropy properly, in the absence of an _active_ attacker, the output will be no worse than the best entropy source. In the presence of an attacker they're just as useless, if not pernicious.
Modern PRNG frameworks moved away from weighting years ago[1] because it not only has dubious benefit, but engineers suck at estimating entropy, so the estimates created a false sense of security. For example, the entropy estimates for hard drives were for a long time based on a single research publication, which as hard drives evolved over the years became increasingly irrelevant--assuming it wasn't irrelevant the day after it was published. Kernel engineers would try to add conservative margins, but if the original quantity has no basis in reality those efforts are just hand-waving.
This is pretty much how all entropy estimates go. The research that goes into the estimates can be extremely rigorous and sound. The problem is not only ensuring the estimates are relevant to your mix of hardware, but that they remain relevant over time. New designs and new manufacturing methods come online on an almost daily basis, even for what appear to be identical products. Combined with the dubious benefit at the outset, trying to maintain the integrity of the estimates is little more than a fool's errand.
With the exception of first-boot behavior, where you want to ensure there's "enough"[1] initial entropy, even accurate estimates don't provide any substantive value. Rather, mixing in a continuous stream of new entropy after you've gathered 128 or 256 bits can actually expose you to other issues, like exfiltration attacks that are more difficult to detect than they otherwise would be. (See https://blog.cr.yp.to/20140205-entropy.html)
Because of the intrinsic difficulty of maintaining accurate estimates, some people would argue that the proper way to solve the first-boot issue is to not solve it at all. The only proper solution is an on-board, robust entropy source. Anything else provides a false sense of security (eventually if not initially), disincentivizing demand for and supply of systems with an on-board source.[2] The Via C3, circa 2003, provided the first on-chip source in the commodity x86 space. Unfortunately it took Intel over a decade to add the similar RDRAND, and longer still to make it ubiquitous across their product line. Now that AMD provides RDRAND and most ARM chips have something similar, we're nearly at a point where there's no excuse for entropy collection and estimation contrivances.
IoT devices and other lower-end devices are still problematic, but those devices provide little if any hardware that entropy collection and estimation proponents can play with.
Dealing with the long tail of legacy hardware is also a PITA. The PCEngines ALIX used an AMD SoC platform (Geode LX800) with an RNG source, but the more recent APU (G-series T40 and GX-412) lacks any on-board source.[3] This issue will eventually pass, but in the meantime solutions like the NeuG provide a solution. Which isn't to say that's the only use for NeuG. There's nothing wrong with using NeuG to supplement the vendor's RNG, just keep in mind issues like exfiltration attacks for trying to use too much of a good thing.
[1] Compare Yarrow (1999) to Fortuna (2003).
[2] By on-board I mean either on the chip, on a controller (both AMD and Intel put RNG sources on some select I/O controllers), or on a pre-installed device (e.g. HSM module on high-end Unix boxes).
[3] There might actually be one on the NIC controller. I haven't been able to confirm, and in any event it's not detected by the OS and thus unsupported presuming there is one. Which alludes to another issue--the complexity created by supporting so many different mechanisms. All these device drivers and frameworks add attack surface.
Modern PRNG frameworks moved away from weighting years ago[1] because it not only has dubious benefit, but engineers suck at estimating entropy, so the estimates created a false sense of security. For example, the entropy estimates for hard drives were for a long time based on a single research publication, which as hard drives evolved over the years became increasingly irrelevant--assuming it wasn't irrelevant the day after it was published. Kernel engineers would try to add conservative margins, but if the original quantity has no basis in reality those efforts are just hand-waving.
This is pretty much how all entropy estimates go. The research that goes into the estimates can be extremely rigorous and sound. The problem is not only ensuring the estimates are relevant to your mix of hardware, but that they remain relevant over time. New designs and new manufacturing methods come online on an almost daily basis, even for what appear to be identical products. Combined with the dubious benefit at the outset, trying to maintain the integrity of the estimates is little more than a fool's errand.
With the exception of first-boot behavior, where you want to ensure there's "enough"[1] initial entropy, even accurate estimates don't provide any substantive value. Rather, mixing in a continuous stream of new entropy after you've gathered 128 or 256 bits can actually expose you to other issues, like exfiltration attacks that are more difficult to detect than they otherwise would be. (See https://blog.cr.yp.to/20140205-entropy.html)
Because of the intrinsic difficulty of maintaining accurate estimates, some people would argue that the proper way to solve the first-boot issue is to not solve it at all. The only proper solution is an on-board, robust entropy source. Anything else provides a false sense of security (eventually if not initially), disincentivizing demand for and supply of systems with an on-board source.[2] The Via C3, circa 2003, provided the first on-chip source in the commodity x86 space. Unfortunately it took Intel over a decade to add the similar RDRAND, and longer still to make it ubiquitous across their product line. Now that AMD provides RDRAND and most ARM chips have something similar, we're nearly at a point where there's no excuse for entropy collection and estimation contrivances.
IoT devices and other lower-end devices are still problematic, but those devices provide little if any hardware that entropy collection and estimation proponents can play with.
Dealing with the long tail of legacy hardware is also a PITA. The PCEngines ALIX used an AMD SoC platform (Geode LX800) with an RNG source, but the more recent APU (G-series T40 and GX-412) lacks any on-board source.[3] This issue will eventually pass, but in the meantime solutions like the NeuG provide a solution. Which isn't to say that's the only use for NeuG. There's nothing wrong with using NeuG to supplement the vendor's RNG, just keep in mind issues like exfiltration attacks for trying to use too much of a good thing.
[1] Compare Yarrow (1999) to Fortuna (2003).
[2] By on-board I mean either on the chip, on a controller (both AMD and Intel put RNG sources on some select I/O controllers), or on a pre-installed device (e.g. HSM module on high-end Unix boxes).
[3] There might actually be one on the NIC controller. I haven't been able to confirm, and in any event it's not detected by the OS and thus unsupported presuming there is one. Which alludes to another issue--the complexity created by supporting so many different mechanisms. All these device drivers and frameworks add attack surface.
You pretty much just mash everything together, then feed the output back into itself, and do it again, and again, and again...
Keyboard typing, mouse/camera movements, timings, sure.
But arbitrarily reading data from my camera or microphone, even for the well-intentioned purpose of generating entropy… no thank you.
But arbitrarily reading data from my camera or microphone, even for the well-intentioned purpose of generating entropy… no thank you.
Cameras are actually a fantastic source of entropy because the CMOS sensors produce high quality and very random data in the form of noise. You can crank up the sensitivity (ISO) and get even more.
Increasing the ISO is just a multiplication of the raw sensor value - it doesn't lead to more noise - it just makes it visible to the human eye. Also on my DSLR I can see all kinds of stripes and cross patterns in the noise, so a lot of it is not really random but based on static sensor properties.
Fair enough, it is indeed just an amplifier, but what I was trying to say is that the noise becomes quite visually apparent when you increase the ISO.
you can cancel out static noise with multiple readings
The hardware is open, so you can put other programs on it as well, such as Gnuk http://www.fsij.org/doc-gnuk/, which is more or less like the OpenPGP smart card feature of a Yubikey.
As with a lot of OSHW products, they often don't make financial sense when compared to mass-market equivalents. But they have intangible advantages over them, not all of which everyone cares about.
As with a lot of OSHW products, they often don't make financial sense when compared to mass-market equivalents. But they have intangible advantages over them, not all of which everyone cares about.
> Don't we already have "true" random number generators embedded on most modern processors? I was under the impression most motherboards have some sensors strictly for this purpose--to read data from static or thermal sensors in order to add entropy to the pool.
Paranoid people might fear that those have been compromised à la Dual_EC_DRBG.
Paranoid people might fear that those have been compromised à la Dual_EC_DRBG.
I like how they call it a 'true' RNG... unless it's got a cesium core and a Geiger counter mounted on the USB, I'd hardly call it 'true' :). At best, it's good enough.
Why do you think that radioactive decay is the only "true" noise source?
Shot noise, avalanche noise etc. are just as true. Even throwing a die would be in the same category.
Shot noise, avalanche noise etc. are just as true. Even throwing a die would be in the same category.
Even the roll of a die could be called non-random, since the numbers that come up are actually the result of a number of forces acting together on the die, including the force of the rollers hand, gravity, air gusts, the surface they fall on, etc.
Same principle would apply to all the other methods you mentioned since there's always a definite seed value, regardless of how difficult it is for you or another observer to capture it.
All the approaches you listed would result in quality pseudo-random numbers, however, a genuine random number at the source has no apparent cause or series of events leading up to it. Cesium is one such source of genuine, uninspired and uninfluenced source of randomness. Cosmic radiation is probably another although that's probably a lot harder to capture.
Here's a more detailed explanation of why radiation from radioactive decay is bona fide random.
https://www.symmetrymagazine.org/breaking/2009/03/30/real-ra...
https://engineering.mit.edu/engage/ask-an-engineer/can-a-com...
The NeuG is best described as a high quality PRNG as are most others unless they truly capture some random, cosmic phenomena, like echoes from the big bang detectable as cosmic background radiation.. Allegedly nothing tops the big bang as a random number generator.
Same principle would apply to all the other methods you mentioned since there's always a definite seed value, regardless of how difficult it is for you or another observer to capture it.
All the approaches you listed would result in quality pseudo-random numbers, however, a genuine random number at the source has no apparent cause or series of events leading up to it. Cesium is one such source of genuine, uninspired and uninfluenced source of randomness. Cosmic radiation is probably another although that's probably a lot harder to capture.
Here's a more detailed explanation of why radiation from radioactive decay is bona fide random.
https://www.symmetrymagazine.org/breaking/2009/03/30/real-ra...
https://engineering.mit.edu/engage/ask-an-engineer/can-a-com...
The NeuG is best described as a high quality PRNG as are most others unless they truly capture some random, cosmic phenomena, like echoes from the big bang detectable as cosmic background radiation.. Allegedly nothing tops the big bang as a random number generator.
From your article: "So how does this lead to random numbers? Statistically, a cesium-137 atom has a fifty-fifty chance of decaying in 30.17 years. BUT, there is absolutely, positively no way to predict exactly when any individual atom will decay."
Still no difference to shot noise or avalanche noise. You have a statistic that says how many electrons you exppect to see, but no foundational knowledge which electron will be seen at what point in time.
I find your point of view very esoteric.
Still no difference to shot noise or avalanche noise. You have a statistic that says how many electrons you exppect to see, but no foundational knowledge which electron will be seen at what point in time.
I find your point of view very esoteric.
[deleted]
I agree, this is a misleading use of the word "true". It's more like "relatively true RNG" than "true".
Why so? I see this written quite a bit, but it doesn't square with what my phys undergrad...
There are many sources of truly random events (as in quantum), including tunneling in diodes.
Then there are chaotic systems which are good enough to be random. There, even in a deterministic universe (it doesn't appear to be) and given infinite amount of computational power (impossible), you'd still be unable predict the future (due to measurement error).
TRNG are hard to do correctly, but why are they limited to geiger counters and radioactive mtls? Is it because you can't "hack" the nuclear core (not exactly true, but sure)? Again that would be a doing the TRNG right, not a lack of randomness in physical systems.
There are many sources of truly random events (as in quantum), including tunneling in diodes.
Then there are chaotic systems which are good enough to be random. There, even in a deterministic universe (it doesn't appear to be) and given infinite amount of computational power (impossible), you'd still be unable predict the future (due to measurement error).
TRNG are hard to do correctly, but why are they limited to geiger counters and radioactive mtls? Is it because you can't "hack" the nuclear core (not exactly true, but sure)? Again that would be a doing the TRNG right, not a lack of randomness in physical systems.
Shoot some photographs (or video frames), make sure there are no duplicates, take hash functions of them, delete the images - and voila, you have the finest true random bits of data.
It's not that simple.
Some years ago I used an analog TV card tuned to an empty channel that was giving seemingly white noise and captured frames to generate entropy. I only used the least significant bit of each RGB value of each pixel.
When I supplied the bits to the diehard testsuite, it complained about a number of patterns and failing tests.
The hash function will of course save you, but it's hard to tell the amount of real randomness that's coming from the sensor.
update: Oh, I may have misunderstood. If the whole images changes in random ways and is secret, then of course this is fine.
Some years ago I used an analog TV card tuned to an empty channel that was giving seemingly white noise and captured frames to generate entropy. I only used the least significant bit of each RGB value of each pixel.
When I supplied the bits to the diehard testsuite, it complained about a number of patterns and failing tests.
The hash function will of course save you, but it's hard to tell the amount of real randomness that's coming from the sensor.
update: Oh, I may have misunderstood. If the whole images changes in random ways and is secret, then of course this is fine.
That's exactly what CloudFlare does with their lava lamps. https://blog.cloudflare.com/lavarand-in-production-the-nitty...
You need some additional processing, otherwise ‘intellectual image processing’ in modern digital cameras will fuck you up big time.
Why not just sample a noise diode, or thermal noise from a highly amplified resistor? Is the process of amplification (i.e. periodic power supply noise) enough to influence the randomness?
Yes this is exactly what you need to do. And yes it takes some careful design to eliminate power supply noise.
NeuG has some low quality sources of entropy, and also provides analog input for the user to supply with whatever they wish. It does not address the design of a good white noise generator, unfortunately.
NeuG has some low quality sources of entropy, and also provides analog input for the user to supply with whatever they wish. It does not address the design of a good white noise generator, unfortunately.
why do you think that's simpler than what they're doing?
you'd still have to feed that through something to get it into a PC. the STM32 is about the cheapest way of doing that. and it turns out it comes with some ADCs that are so noisy they're good sources of randomness themselves.
you'd still have to feed that through something to get it into a PC. the STM32 is about the cheapest way of doing that. and it turns out it comes with some ADCs that are so noisy they're good sources of randomness themselves.
The cheapest way is to use good old soundcard, an opamp and passives. You could fit in $1 easily.
most of HN readers are not familiar with EE, unfortunately.
The problems they're supposed to solve are entirely fictional and usually stem from a poor understanding of the real problems there are with random numbers (which can mostly be traced back to a few issues: boot time entropy, userspace RNGs and use of insecure RNGs by mistake).