Forgot your password?
typodupeerror
Encryption

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:
  • Trust... (Score:3, Insightful)

    by Anonymous Coward on Tuesday April 22, 2014 @03:53PM (#46817791)

    ... So much more easily lost than won. How is anyone supposed to take these new recommendations seriously?

    • by Anonymous Coward

      What do you mean? The weakness in Dual_EC_DRBG is publicly known. Just because you don't trust the organization recommending you not use it, doesn't mean you should use it.

      • by erikkemperman (252014) on Tuesday April 22, 2014 @04:11PM (#46817953)

        NIST recommends that people using Dual_EC_DRBG should transition to one of the other three recommended algorithms as quickly as possible.

        Presumably GP worries that if one out of four options selected by this body is not just flawed but apparently deliberately subverted, what does that say about how well the other three were vetted?

        • Re: (Score:1, Informative)

          by cold fjord (826450)

          Presumably GP worries that if one out of four options selected by this body is not just flawed but apparently deliberately subverted, what does that say about how well the other three were vetted?

          That isn't quite the issue. All of the options in the standard were vetted. The Dual_EC_DRBG option is controversial for performance, the correction to it, and one other reason. Some people claim that it has a backdoor, but that isn't what has been proven. What has been proven is that a backdoor is possible with the technology and you wouldn't know either way. You can generate values for the curve without creating a backdoor, and that would be less work. If there was a backdoor created, only the perso

          • With any state authority these days, as their true nature slowly becomes exposed, you have to assume the worst.

            • by cold fjord (826450) on Tuesday April 22, 2014 @06:16PM (#46818781)

              The problem is that by assuming the worst you can go down the wrong path is the situation isn't in fact worst case. Consider the example of DES encryption. The NSA tweaked the S-box values before the standard was approved. Nobody outside of NSA knew why. Many people suspected some sort of backdoor, but nobody could find one. As a result of the suspicion there were people that refused to use DES. Eventually it emerged that NSA had strengthened DES against secret cryptanalysis techniques that weren't generally known at the time. Many of the people that refused to use DES ended up using encryption schemes that were vulnerable to the secret techniques because they assumed the worst and were wrong. DES held up remarkably well against attacks over time, including attacks that were either invented or reinvented long after DES was approved.

              • Eventually it emerged that NSA had strengthened DES against secret cryptanalysis techniques that weren't generally known at the time. Many of the people that refused to use DES ended up using encryption schemes that were vulnerable to the secret techniques because they assumed the worst and were wrong.

                An excellent illustration of the downfalls of security through obscurity. The NSA could have known that would happen and that their secrecy might decrease the average security situation due to people not using the actually more secure crypto. They should have been transparent about why they tweaked the S-box values. People shouldn't have to assume anything, best or worst.

                And now of course the NSA have demonstrated that they cannot be trusted at all and nobody should ever accept magic numbers from them ever

              • That was back when people still trusted the NSA to do its job properly i.e. secure US communications and decipher those of US opponents.

                Today they seem to think everyone is an opponent which needs to have its communications deciphered.

          • by erikkemperman (252014) on Tuesday April 22, 2014 @05:57PM (#46818681)

            Some people claim that it has a backdoor, but that isn't what has been proven. What has been proven is that a backdoor is possible with the technology and you wouldn't know either way.

            The difference is academic, but I suppose you mean as in this [slashdot.org] story about the proof of concept?

            An algorithm for which a backdoor is possible should be considered backdoored. Especially for crypto PRNGs. Anyway, taken in context, which is to say the RSA connection and those unexplained constants P and Q which you couldn't change in certified implementations.. Guess I'm inclined to being just slightly more paranoid these days.

            • So, what are these algorithms that are impossible to backdoor either through design or implementation? No chance of another something like heartbleed, or Reflections on Trusting Trust [bell-labs.com]?

              There is actually nothing wrong with the algorithm for Dual_EC_DRBG, the issue is with people's trust of the constants that define the curve for it in the standard. The only issue there is that people don't trust them just like they didn't trust the NSA generated S-boxes that strengthened DES against secret cryptanalysis tech

              • by GuB-42 (2483988)

                There *is* something wrong with Dual_EC_DRBG, the possibility of a backdoor is the most serious flaw but it isn't the only one : http://blog.cryptographyengine... [cryptograp...eering.com]

                • I don't remember if I've seen that link before, but thanks for sharing it. That is a great explanation, and reinforces the point I've been making.

                  The Many Flaws of Dual_EC_DRBG [cryptograp...eering.com]

                  The 'back door' in Dual-EC comes exclusively from the relationship between P and Q -- the latter of which is published only in the Dual-EC specification.

          • by gweihir (88907)

            It is basically a compromised design, i.e. a design that makes an implementation compromise intentionally hard or impossible to spot. That does not actually mean the implementation is necessarily compromised.

            People have real trouble understanding the distinction or why this is a compelling reason not to use it.

      • by kasperd (592156)

        The weakness in Dual_EC_DRBG is publicly known.

        Sometimes it may be difficult to tell the difference between a weakness and a backdoor. But in the case of dual EC DRBG there is so much evidence indicating that it is an actual backdoor, and not (just) a weakness, that I think it is no longer fair to label it as a weakness. Who placed the backdoor is not officially confirmed, but we all know who the prime suspect is.

      • by sjames (1099)

        No, but it does leave you wondering about the other things they recommended.

  • I really wish people would stop using the word "random" for things that are anything but.

    • by PRMan (959735)
      That comment was random...
      • Pseudo random, as it could be predicted based on the headline alone.

        When we say rng we mean prng unless otherwise noted. That is the common usage, and it is hard to correct the common.

        • "Pseudorandom" isn't correct either. There is nothing random about the numbers.
          They're just statistically flat.

    • by Anonymous Coward

      I really wish people would stop using the word "random" for things that are anything but.

      Ah, to be fair, I did see the word pseudorandom used at least once here...which would be accurate.

  • by Russ1642 (1087959) on Tuesday April 22, 2014 @03:58PM (#46817827)
  • by Anonymous Coward

    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 [ias.edu] 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 [nist.gov].

  • by medv4380 (1604309) on Tuesday April 22, 2014 @04:22PM (#46818027)
    I know they can be a bit cost prohibited, but psudo RNG's always look like you're just waiting for them to eventually become broken. Are the real RNG's out there so cost prohibitive?
    • Not sure if their implementation is better, but VIA seems to have something different and hardware-based [via.com.tw].

      If it's truly good, maybe it could be licensed and added to all future Intel, AMD and ARM CPUs?

      • by gman003 (1693318)

        Intel has a hardware RNG (RdRand) as well, although I don't think AMD does (and I'm sure there are ARM implementations that have something similar). There was a spat a while back over it - because neither Intel nor VIA's microcode for it is public, they can't be trusted as a sole source of randomness. AFAIK nobody uses them as the sole source of randomness - they're either ignored, or mixed into the entropy pool with other PRNGs.

    • >Are the real RNG's out there so cost prohibitive?

      No a real RNG on a modern silicon process takes only a tiny sliver of silicon and a few very smart designers and at least one very smart cryptographer.

    • There is no such thing as a "real" RNG.
    • by sjames (1099)

      Hardware RNGs are in the same boat. Was it subverted by the manufacturer? Does it have a subtle bias we haven't discovered yet? Can it be biased by external conditions?

    • There are a couple of issues with hardware RNGs

      1: Pretty much every hardware RNG will have biases in the output. So you still tend to end up needing a prng-like layer to clean things up.
      2: If the RNG is integrated into a processor or similar (which is the only way it will gain mass deployment) then it raises the question of whether you trust the processor vendor to implement it properly and without the influence of the spooks. The more paranoid members of the crypto community don't trust hardware vendors th

    • by AmiMoJo (196126) *

      They are pretty cheap, and there are a number of projects on the web if you fancy building your own. The problem is that you need more than one, because relying on a single source of randomness is a bad idea. They need to be different types too, in case the non-randomness is systemic.

      I suppose that's why there are so few commercial solutions. For them to be used seriously in encryption they would have to be sold as "you need this and a couple of our competitors' products too".

Nothing is faster than the speed of light ... To prove this to yourself, try opening the refrigerator door before the light comes on.

Working...