Date: Fri, 18 Apr 2014 16:12:32 -0400 From: Thor Lancelot Simon <t...@panix.com>
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'.