https://www.voltage.com/security/fips-certified-prngs-part-1/
Back to the 186-2 algorithm. Over the years, several people found some issues with the this PRNG (I'm proud to say I was one of those people: I showed an example of two seeds producing the same output, and that to solve that problem an app should digest all seed material). Hence, NIST decided to develop a new algorithm NIST recenlty came out with that new algorithm and published it in NIST Special Publication 800-90. In that doc, they call the algorithm a "Deterministic Random Bit Generator" or DRBG. In fact, NIST now uses that term for the entire class of algorithms that produce random bytes from a seed. Nonetheless, there's a new algorithm to get FIPS certified. In fact, NIST has said that in the future, the old 186-2 algorithm will no longer be certifiable. In the future, a product up for certification will have to implement 800-90. https://www.voltage.com/security/prngs/ 800-90 works this way: 1. instantiate 2. collect seed material 3. return to the user. 1. the user can now enter more seed material or 2. just call on the DRBG to generate random bytes. Here at Voltage, we use the term autoseed. That means the PRNG/DRBG seeds itself. 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. The answer is to require the implementation to turn off autoseeding in order to run the test. Then, the test supplies some data that is a substitute for the autoseed material, and possibly some more material that is a aubstitute for user-supplied seed. The implementation then generates random bytes and it is compared to an expected value. This makes sense on one level. In order to test an implementation (make sure they follow the standard), make sure it produces expected output from a specific seed. However, this also means introduing a security hole. In order to get FIPS certification, an implementation must turn off autoseeding. But if a user somehow accidentally uses the PRNG/DRBG in FIPS testing mode, and they don't add their own seed, they'll get bad random output. After all, they're using a PRNG/DRBG that seeds itself, so why enter any new seed? You might declare, "Then don't release the FIPS testing mode version of the PRNG/DRBG." However, one FIPS requirement is that the code tested is the code released. Furthermore, in order to get FIPS certification, it is necessary to perform these "Known Answer Tests" (KATs) at startup. When the user first launches the product, it must run some KATs to show that it is running properly. It all means that in order to get FIPS certification, we must release the product with FIPS testing mode in there. We've written our code in such a way that the FIPS testing mode is not publicly available. There are also some hoops to go through to get to that code. So the probability is extremely low - virtually zero - that a user will accidentally instantiate in FIPS testing mode. With some research, a user could figure out how to explicitly (as opposed to accidentally) instantiate in that mode, but why would they? So I'm not too worried. Nonetheless, I don't like this requirement from NIST. I think that NIST should either not require the KAT, or allow an implementation to take out the FIPS testing mode before releasing. By the way, I can think of one reason someone might make the effor to instantiate in FIPS testing mode, and that is to intentially create a security hole. Someone writing an app that they want to break themselves would appreciate this implementation. Of course, someone wanting to do this would have many, many more ways of inserting back doors. So taking away this code would not thwart them. But no one wants to add anything to help the attackers. -- http://www.subspacefield.org/~travis/ | if spammer then [email protected] "Computer crime, the glamor crime of the 1970s, will become in the 1980s one of the greatest sources of preventable business loss." John M. Carroll, "Computer Security", first edition cover flap, 1977
pgpbNm0zfMl6u.pgp
Description: PGP signature
_______________________________________________ RNG mailing list [email protected] https://lists.bitrot.info/mailman/listinfo/rng
