Re: Lightweight support for instruction RNGs

[Taylor R Campbell <campbell+netbsd-tech-security%mumble.net@localhost>,]

   Date: Mon, 28 Dec 2015 17:26:13 +0100
   From: Matthias Weckbecker <matthias%weckbecker.name@localhost>

   First and foremost: I do not disagree w/ you or anyone else in this
   discussion.

   What you may (or may not) be interested in though could be:

     The fragility of AES-GCM authentication algorithm
     http://eprint.iacr.org/2013/157.pdf

   In short: 19 known-answer tests, 18 from the NIST spec itself, none
   of them covered the implementation issue the authors discovered.

   Despite that, I personally would probably tend to the "just-run-the
   damn-thing." (dieharder) approach anyways.

The class of error you cite -- a mistake in the implementation causing
incorrect calculation of a crypto primitive -- would still not be
caught by generic statistical tests.  An analogue would be to compute
AES_k(0) || AES_k(stack garbage) instead of AES_k(0) || AES_k(1) --
anyone without k can't distinguish these, so certainly no generic
statistical tests would catch it.

But in this case, test vectors covering inputs (or, for CTR_DRBG,
outputs) of all lengths up to a certain sizeable number would have
caught the mistake.

You can call that 20-20 hindsight, but it is obvious in foresight that
with any complex batching as OpenSSL did, exercising all edge cases of
partial blocks and block alignments is critical.  So I do it in crypto
automatic tests that I write (although not always the on-line
self-tests because covering all those cases may take substantial
time).