Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


NIST Removes Dual_EC_DRBG From Random Number Generator Recommendations 86

Posted by Soulskill
from the cryptic-announcement dept.
hypnosec writes: "National Institute of Standards and Technology (NIST) has removed the much-criticized Dual_EC_DRBG (Dual Elliptic Curve Deterministic Random Bit Generator) from its draft guidance on random number generators following a period of public comment and review. The revised document retains three of the four previously available options for generating pseudorandom bits required to create secure cryptographic keys for encrypting data. NIST recommends that people using Dual_EC_DRBG should transition to one of the other three recommended algorithms as quickly as possible."
This discussion has been archived. No new comments can be posted.

NIST Removes Dual_EC_DRBG From Random Number Generator Recommendations

Comments Filter:
  • by Anonymous Coward on Tuesday April 22, 2014 @04:03PM (#46817877)

    OpenBSD has already removed that nonsensical algorithm from LibreSSL, has OpenSSL yet??? NOPE!!!!

  • Not the only change (Score:3, Interesting)

    by TechyImmigrant (175943) on Tuesday April 22, 2014 @04:05PM (#46817909) Journal

    They also made many other changes. See appendix F of draft 1. I'm in the middle of reviewing them

    The announcement and RFC is here.
    The comments from the previous round addressed far more than just the Dual_EC_DRBG.

    There are structural issues in the spec. My comments on the previous draft address them:
    1) Flow control: ES pushing, vs conditioner pulling. Reseeding on demand vs when entropy is available.
    2) A purely software centric API, when all nondeterministic random number generators need a hardware component.
    3) Online testing that is too onerous for resource constrained solutions, when effective technical solution exists that have been ignored.
    4) Conditioners (really an SP800-90B thing, but A, B and C go hand in hand) are all single source conditioners based on large crypto functions. The current state of math [] tells us multiple input conditioners can be implemented with non cryptographic methods in fewer gates with higher lower-bounds for min entropy out.

    There's more. See the comments [].

  • by TechyImmigrant (175943) on Tuesday April 22, 2014 @06:58PM (#46818989) Journal

    >no one can know if Intel could have a backdoor into it.

    Except me and my colleagues, who have full visibility of it and know if a back door was put in it and no, a back door was not put in it.

    If there was a back door, it would only take one person out of several hundred of those people who would know, to tell the world about a backdoor. If there isn't a backdoor (which there isn't), then there's no back door to tell the world about.

    We are a company full of techies most of whom like open source principles and personal data security. So if there was a back door, you would find out about it because you could pretty much guarantee that someone would bleat, and justly so.

  • by erikkemperman (252014) on Tuesday April 22, 2014 @07:00PM (#46819001)

    Operating by suspicion can be hazardous when it comes to encryption.

    I would argue that operating by suspicion should be the default when it comes to encryption.

"Most of us, when all is said and done, like what we like and make up reasons for it afterwards." -- Soren F. Petersen