[cryptography] Intel RNG
dj at deadhat.com
Wed Jun 20 00:17:34 EDT 2012
On 6/19/2012 7:35 PM, coderman wrote:
> On Tue, Jun 19, 2012 at 1:54 PM, Marsh Ray <marsh at extendedsubset.com> wrote:
>> ... Just a sanity check that the output is
>> actually changing once in a while would go a long way towards
>> eliminating the most common failure modes.
> On Tue, Jun 19, 2012 at 6:58 PM, <dj at deadhat.com> wrote:
>> ... Actually having a perfect source is a problem. It's much easier to
>> test for a source with known defects that meet a well defined statistical
> is there any literature on the typical failure modes of TRNG/entropy
> sources in deployed systems?
> my understanding is that they tend to fail catastrophically, in a way
> easily detected by FIPS sanity checks. E.g. clearly broken.
> is it exceedingly rare for subtle / increasing bias to occur due to
> hardware failure or misuse in most designs? are there designs which
> fail hard rather than fail silent when error is encountered?
If an entropy source in a closed system is producing an apparently non
repeating, unbiased sequence and its output is deterministic (or low
entropy) then there must be internal memory in the entropy source that
is enabling the non repeating behavior. The more memory, the longer you
have to watch before you can identify repeating behavior.
So make your entropy source have a very small amount of memory and be
sufficiently simple that you can model it mathematically. Then you can
show all the SPOF and DPOF failure modes and show that your health check
circuitry catches them. You can also show your health check circuitry
catches all repeating patterns up and beyond some size that is
determined by the internal memory of the ES.
So the answer is yes..
Minimal memory (E.G. fewer registers) => Fails hard.
Lots of memory (E.G. lots of registers, like an LFSR) => opportunity to
I can't point to literature. I think it's obvious. Without memory, non
repeating behavior has to come from non determinism. Perhaps I should
write a paper :) Mistrust an ES with many flops.
I don't approve of FIPS sanity checks. These are algorithms you can't
specify independent of the generation process. Or in other words, you
can't test for randomness, you can only test for functionality. You need
to use other arguments to show that what you have is random. FIPS sanity
checks are a chore to implement after you've implemented a real health
test algorithm matched to the failure modes of the source.
More information about the cryptography