[cryptography] Intel RNG

David Johnston 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
>> model.
> 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 
fail soft.

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 mailing list