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


Forgot your password?

NIST Removes Dual_EC_DRBG From Random Number Generator Recommendations 86

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) Homepage 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) Homepage 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.

Kill Ugly Processor Architectures - Karl Lehenbauer