News for hackers. Stuff that matters.

A comment on Dual_EC_DRBG backdoor: a proof of concept. Parent comment

Re:Dual_EC_DRBG backdoor: a proof of concept by timtadh on Wednesday January 01, 2014 @10:39AM (#6995227)
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.
[ Parent | on HN ]
Re:Dual_EC_DRBG backdoor: a proof of concept by aris_ada on Wednesday January 01, 2014 @12:43PM (#6995632)
Honestly I don't know why. I generate 60 bytes of pseudorandom and that worked on first try.
[ Parent | on HN ]
Re:Dual_EC_DRBG backdoor: a proof of concept by rsync on Wednesday January 01, 2014 @12:47PM (#6995651)
My 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 ?

[ Parent | on HN ]
Re:Dual_EC_DRBG backdoor: a proof of concept by aris_ada on Wednesday January 01, 2014 @01:45PM (#6995938)
No, 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.

[ Parent | on HN ]