6 ms·
Controversial opinion: Hardware Random Number Generators don't solve any real problem. The problems they're supposed to solve are entirely fictional and usuall
by hannob 9y ago
Controversial opinion: Hardware Random Number Generators don't solve any real problem.
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).
- raverbashing 9y agoHow are you supposed to get entropy into a system with no (good for RNG) inputs and no sources of noise? (think: embedded)
- tptacek 9y agoNot with a USB HWRNG.
- schoen 9y agoI 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.
- raverbashing 9y agoI'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.
- sigstoat 9y agoread the internal temp and Vref ADCs over and over, and hash the result, the same way this widget works?
- dfox 9y agoIt 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...).
- SAI_Peregrinus 9y agoChaotic oscillators to seed a CSPRNG. Either on-chip[1] or discrete[2]. [1] http://forums.xilinx.com/xlnx/attachments/xlnx/EDK/27322/1/HighSpeedTrueRandomNumberGeneratorsinXilinxFPGAs.pdf http://forums.xilinx.com/xlnx/attachments/xlnx/EDK/27322/1/H... [2] http://ieeexplore.ieee.org/document/7111269/ http://ieeexplore.ieee.org/document/7111269/
- Cthulhu_ 9y ago> 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.
- dfox 9y agoProbably 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.
- loeg 9y agoThe classic example of "not enough randomness" is the Debian openssl vulnerability: https://www.debian.org/security/2008/dsa-1571 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.
- Ded7xSEoPKYNsDd 9y agoI remember some broken SSL certs generated during boot of some routers.
- tjoff 9y agoSo, 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.
- tptacek 9y agoWhen'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.
- tjoff 9y agoWell, 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.
- tptacek 9y agoDebian 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".
- tjoff 9y agoMy 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.
- derefr 9y agoHWRNGs 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.
- tptacek 9y agoNo, 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.
- tptacek 9y agoThis might be a controversial opinion on HN, but it's not controversial in crypto engineering circles. Consumer TRNGs are silly.
- kej 9y agoYour "Consumer" modifier made me curious: what non-consumer situations make TRNGs not silly?
- comex 9y agoOnly 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).
- tptacek 9y agoI'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".
- deleted 9y ago[deleted]
- comex 9y agoAh - by “consumer TRNGs” did you mean TRNGs sold separately to consumers, as opposed to TRNGs that happen to be embedded into a consumer device? That would make more sense / would be the source of my confusion.