On Tue, Oct 13, 2015 at 6:05 AM, <[email protected]> wrote: > So NIST is requiring that products up for FIPS certification must > supply a DRBG that autoseeds. But that brings up the question, how can > one test an implementation? With 186-2, it was possible to come up > with seed/expected output pairs. But with 800-90, there's > autoseeding. We can't guarantee what any seed will be in > advance. Furthermore, if we enter a seed, we won't get the expected > output because the autoseed will be different every time we run the > test.
We have run into the same problem with autoseeding when doing static PRNG verification. We had to patch the code so as to allow manual seeding. For the curious (comments welcome): http://formal.iti.kit.edu/~klebanov/pubs/vstte2015.pdf I can understand the autoseeding dilemma, though, and I do not see a perfect solution for it. Yet, on this occasion, it makes sense to point out a related issue: general lack of code structuring and modularity in PRNG implementations. Most of the PRNGs we looked at had very poor separation of concerns in the code - all the logic is pressed into as few functions as possible. Such a non-modular design decreases understandability and maintainability - and this way creates a very real security risk. Vladimir _______________________________________________ RNG mailing list [email protected] https://lists.bitrot.info/mailman/listinfo/rng
