Slashdot Mirror
FreeBSD Developers Will Not Trust Chip-Based Encryption
New submitter srobert writes "An article at Ars Technica explains how, following stories of NSA leaks, FreeBSD developers will not rely solely on Intel's or Via's chip-based random number generators for /dev/random values. The values will first be seeded through another randomization algorithm known as 'Yarrow.' The changes are effective with the upcoming FreeBSD 10.0 (for which the first of three planned release candidates became available last week)."
Just out of curiosity: Given a "black box" implementation of a random number generator, is it possible to test its output sufficiently to gain some faith in its proper randomness?
Seeing as such a piece of hardware need not (and hopefully would not) have any inputs, only an output, it's hard to imagine how someone might hide (and later trigger) a back-door mechanism that could change its behavior post-testing. (But I'm sure there is some way to do it that I'm not thinking of ;))
I don't care if it's 90,000 hectares. That lake was not my doing.
Given that it's stated that you can't trust a chip's encryption routines, which at the basis means that you don't trust its random number generator, and given that 'a chip' extends down from the latest Intel to a relatively lowly PIC, is anybody aware of an actually available TRNG (true/hardware random number generator) built out of discrete components?
Comments to a Bruce Schneier post titled "Surreptitiously Tampering with Computer Chips" once suggested this would be the only way to 1. be certain* of no tampering and 2. have reasonably sufficient output bandwidth to be used in practical applications.
However, I haven't seen any actual implementation. My Google-fu may be failing me, though.
* Barring some pretty sweet shenanigans like those pulled by Henryk Gasperowicz; [Spoiler video](https://www.youtube.com/watch?v=-KMLmpC7-Ls). I can't see manufacturers including any crypto-defeatery bits into a basic transistor thinking that it just might possibly be used in an actual crypto application, and eat the cost somehow.
According to the OpenBSD link, OpenBSD uses the Intel and Via random-number generators, but not as the sole source of randomness. The nice thing about mixing random number generators is that if you do it right (like OpenBSD does), the result is at least as random as the most random source: a bad RNG does not reduce the overall quality of randomness.
"They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.