On Mon, Oct 12, 2015 at 9:05 PM, <[email protected]> wrote:
> 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, ..... > > 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. > > 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? > Testing is always difficult. Code that has command line or other operational flags that allows altering control flow are easy to subvert or even binary edit to subvert the expected control flow. Public source code that has #define ifdef preprocessor tricks can make these branch instructions and test paths go away and making it harder to binary hack. What they are looking for I suspect is a unit/function test strategy and might miss the risk of operational exploitation. A strategy in the open source world is to have a test compile mode and an operational mode. The test compile could run in production if someone demanded the test mod be live. see assert(). I would syslog the invocation of any test mode. That could be hacked as well but... layers help. Difficult topic. I had to debug a kernel where a student edited the system binary to ignore the SUID=allowed test. The student changed exactly one instruction in the kernel binary. All UID system call changes to UID=0 would succeed. In a well behaved world testing the permissions was not common so it went undetected for some time. -- T o m M i t c h e l l
_______________________________________________ RNG mailing list [email protected] https://lists.bitrot.info/mailman/listinfo/rng
