Hardware random number generators tend to attract a lot of interest, but people should be aware that they don't solve any real problem.
Every modern OS has a secure RNG. Except for the problem of early boot time entropy (which you can avoid if you have the right API calls that block before enough entropy has been collected), there's never been any major problem with those.
Otherwise the only problems with RNGs are either simple bugs (i.e. you're not really using the secure RNG) or people calling pseudorandom functions that weren't meant to be used for secure use cases.
People don't really like their random calls to block for an arbitrary amount of time. Using a hardware random number generator to seed your PRNG quickly is a useful thing to have.
Most Intel and AMD CPUs in the last 8 years have had hardware RNGs that are based on shot noise of a reverse biased Zener diode, which is better than whatever thermal noise/RF this resistive setup is picking up.
They have a hardware RNG but it sure isn't based on a reverse biased diode. They claim to be ring oscillator based, though their operation is not independently verifiable.
Their design-- using AES as a whitening postprocessing step-- would make it extremely easy for them to return something like an aes stream based just on a counter and secret key as a result of an almost undetectable attack.
True enough, though the AES DRBG output based HWRNGs would be a great target-- a highly specific nobus or near nobus attack with just a dopant change breaking a single gate... and then the RNG is just some fixed AES stream known to the attacker.
AFAIK you can't just put a reverse bias diode generator in a processor because it requires a different process and relatively high voltages (as ICs go).
oof the calibration process seems VERY daunting, involving breadboards multimeters and tinfoils. I thought HRNGs were already included in chipsets? doesn't every CPU has it ?
17 comments
[ 0.33 ms ] story [ 39.8 ms ] threadEvery modern OS has a secure RNG. Except for the problem of early boot time entropy (which you can avoid if you have the right API calls that block before enough entropy has been collected), there's never been any major problem with those. Otherwise the only problems with RNGs are either simple bugs (i.e. you're not really using the secure RNG) or people calling pseudorandom functions that weren't meant to be used for secure use cases.
A strong statement, without much in the way of supporting evidence.
Your numbers say strictly nothing about the "secure" part.
Their design-- using AES as a whitening postprocessing step-- would make it extremely easy for them to return something like an aes stream based just on a counter and secret key as a result of an almost undetectable attack.
https://en.wikipedia.org/wiki/Noise_generator
Sure there have been, e.g.
CVE-2006-1833, CVE-2008-516, CVE-2013-5180, CVE-2014-4422, https://marc.info/?l=netbsd-current-users&m=136460321709597
... just to give some random examples.
Of course, whatever yolo hwrng people use may be even worse off.
https://github.com/waywardgeek/infnoise https://www.crowdsupply.com/13-37/infinite-noise-trng