On 6/19/2012 7:35 PM, coderman wrote:
On Tue, Jun 19, 2012 at 1:54 PM, Marsh Ray <[email protected]> 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, <[email protected]> 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.
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
