Re: Towards design criteria for cprng_fast()

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

   Date: Fri, 18 Apr 2014 16:12:32 -0400
   From: Thor Lancelot Simon <tls%panix.com@localhost>

   With those observations in mind, I offer these design criteria for
   cprng_fast():

           Strength criterion: At the time of the selection of an algorithm
                                 for cprng_fast(), there should be no known,
                                 practical cryptographic attack which either:

This is too stringent a criterion to *reject* a crypto algorithm -- it
would not reject a freshly baked cipher nobody has analyzed yet.
Analogous criteria would also not reject, e.g., SHA-1, because nobody
has published collisions.

We ought to have stringent criteria for *adopting* crypto algorithms,
not for rejecting them.

In general, if we're going to adopt a crypto algorithm, then I think
it had better

(a) have substantial review (more than one or two papers discussing
how immature the cryptanalysis is);
(b) not have warning signs, such as secret-dependent array indices or
branches; and
(c) have positive support from professional crypto wizards (not just
crypto tinkers like me).

Even if it is not being used for key material, I don't think we ought
to have it lying around tempting anyone to use it for anything else.


Concerning HC-128, I asked Samuel Neves, a crypto researcher, for his
opinion on HC-128 in this context.  He said he supposed it's `ok as a
a cipher' but `the secret indexes are a no-no' and `my opinion is that
it would require a damn good rationale to adopt HC-XXX, not the other
way around'.