On Tue, Jun 19, 2012 at 07:35:03PM -0700, coderman wrote: > > 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.
I know of one case in which a design mistake may have caused related bits to be output. I think the FIPS statistical tests might have turned it up, but the continuous-output test might well not have. This was a design by Hifn where they reused an existing RNG block but changed the output LFSR and thus had to rework the interface to register exposed to the PCI bus in which they reported results. They left out a latch, so you could accidentally get the same bits from the LFSR twice or get an intermediate state where some bits were from the previous state and some were fresh. The COT would have caught the former, but given the clocks involved the former case would have been very, very unlikely. It would not have caught the latter. I never got a clear answer from Hifn whether they actually left the latch out of the silicon or just out of the documentation. However, I tried very hard to give them opportunities to tell me it was just the docs that were wrong, and they didn't. The workaround was to simply read the register repeatedly, discarding results, until one knew all the bits had to be fresh given the other clocks involved; inefficient, but it got the job done. Thor _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
