3 ms·
perhaps it is related to this point, since that bug causes the algorithm to get "stuck". Why wasn't this bug caught in the FIPS 140-2 validation testing?
by timtadh 13y ago
perhaps it is related to this point, since that bug causes the algorithm to get "stuck".
Why wasn't this bug caught in the FIPS 140-2 validation testing?
- ---------------------------------------------------------------
Not only the original validation (#1747) but many subsequent validations
and platforms have successfully passed the CAVP[5] algorithm tests ...
several hundred times now. That's a lot of fail.
In test mode the implementation works fine both with and without
additional data. In free running mode the bug is triggered by additional
data on the first call, which is done automatically by the "FIPS capable"
OpenSSL.
Frankly the FIPS 140-2 validation testing isn't very useful for catching
"real world" problems.
- aris_ada 13y agoHonestly I don't know why. I generate 60 bytes of pseudorandom and that worked on first try.
- rsync 13y agoMy understanding thus far has been that openssl has gotten a pass because their implementation was always broken ... so nobody was at risk. Has that changed ?
- aris_ada 13y agoNo, they plan on removing the PRNG from their release. I understand better why my POC worked without triggering the bug. From the mail archive: ". When the discard occurs the data must not be output and the Dual EC DRBG state must be updated, but that state update isn't done. In the case of no additional input this has no effect, but additional input is used by the "FIPS capable" OpenSSL. Note that additional input does not effectively defeat the backdoor vulnerability[3]." I do not use the reseed functionality either, because I only generate two or three output blocs and never call an explicit reseed.