Slashdot Mirror


New NSA-Approved Encryption Standard May Contain Backdoor

Hugh Pickens writes "Bruce Schneier has a story on Wired about the new official standard for random-number generators the NIST released this year that will likely be followed by software and hardware developers around the world. There are four different approved techniques (pdf), called DRBGs, or 'Deterministic Random Bit Generators' based on existing cryptographic primitives. One is based on hash functions, one on HMAC, one on block ciphers and one on elliptic curves. The generator based on elliptic curves called Dual_EC_DRBG has been championed by the NSA and contains a weakness that can only be described as a backdoor. In a presentation at the CRYPTO 2007 conference (pdf) in August, Dan Shumow and Niels Ferguson showed that there are constants in the standard used to define the algorithm's elliptic curve that have a relationship with a second, secret set of numbers that can act as a kind of skeleton key. If you know the secret numbers, you can completely break any instantiation of Dual_EC_DRBG."

17 of 322 comments (clear)

  1. The answering machine by Verteiron · · Score: 5, Interesting

    Anyone else reminded of the little Black Box from Sneakers? The one that used a mathematical backdoor to break any encryption based on a certain algorithm that was only used in the USA?

    --
    End of lesson. You may press the button.
  2. Re:umm by bhima · · Score: 5, Insightful

    But this is the NSA we're talking about... Not the Bush administration.

    --
    Nothing in the world is more dangerous than sincere ignorance and conscientious stupidity.
  3. From TFA: by Spy+der+Mann · · Score: 5, Informative

    * WHAT WE ARE NOT SAYING:
    NIST intentionally put a backdoor in this PRNG

    * WHAT WE ARE SAYING:
    The prediction resistance for this PRNG (as presented in NIST-SP800-90) is dependent on solving one instance of the elliptic curve discrete log problem.
    (And we do not know if the algorithm designer knew this beforehand.)

    On the last slide, the researchers add some suggestions:

    Truncate off more than the top 16 bits of
    the output block.
    - Results on extractors from x coordinates of
    EC points of prime curves suggest truncating
    off the top bitlen/2 bits is reasonable.
    * Generate a random point Q for each
    instance of the PRNG.
    1. Re:From TFA: by Saint+Aardvark · · Score: 5, Interesting
      And this bit from Bruce's article:

      If this story leaves you confused, join the club. I don't understand why the NSA was so insistent about including Dual_EC_DRBG in the standard. It makes no sense as a trap door: It's public, and rather obvious. It makes no sense from an engineering perspective: It's too slow for anyone to willingly use it. And it makes no sense from a backwards-compatibility perspective: Swapping one random-number generator for another is easy.

      My recommendation, if you're in need of a random-number generator, is not to use Dual_EC_DRBG under any circumstances. If you have to use something in SP 800-90, use CTR_DRBG or Hash_DRBG.

      In the meantime, both NIST and the NSA have some explaining to do.

  4. T-shirts by hoggoth · · Score: 5, Funny

    secret numbers appearing on T-shirts in Finland in 3.. 2.. 1..

    --
    - For the complete works of Shakespeare: cat /dev/random (may take some time)
  5. Re:Ummm...encryption standard? by ioshhdflwuegfh · · Score: 5, Informative

    What happens in the article is that one of the algorithms proposed by NSA for standardization contains possibly a major backdoor because the constants it uses to generate numbers are such that there might be other constants, unknown by looking at the algorithm itself but nevertheless possibly known to the authors at NSA that allow to get the whole generated sequence of numbers based on only 32 byte sequence of generated numbers. Maybe or maybe not, depending on whether there are such constants, which only NSA knows.

  6. Trust the Spies by Doc+Ruby · · Score: 5, Insightful

    The NSA is spying on all telecom signals passing through the US (including this message. Hi, Dick Cheney!). Despite the Constitution's prohibitions. Why would you trust them not to make your crypto crackable?

    This situation shows one of the strongest arguments for open source. Trust no one.

    --

    --
    make install -not war

  7. Re:Give everyone the key by superwiz · · Score: 5, Informative

    Read the post above. Getting the key involves solving a discrete log problem for one instance of an elliptic curve. Discrete log problem is an unsolved mathematical problem. So its solution essentially (you mileage may vary slightly) requires brute force. Either NSA has a solution and was hoping the weakness would go unnoticed, or they don't have it. If they don't have it, no one will have it for a long time. These are more difficult to compute (and therefore more time consuming) than the traditional encryption schema (discrete log problems for Z/pZ). Now the question of whether you believe malice or incompetence is at play here is essentially up to you.

    --
    Any guest worker system is indistinguishable from indentured servitude.
  8. Re:Ummm...encryption standard? by starfishsystems · · Score: 5, Insightful
    Randomness is absolutely at the heart of cryptography. So yes, to answer your question, it does matter.

    If I can predict the value of a symmetric key, or the value whose two factors constitute an asymmetric key pair, I have effectively broken the encryption. Even supposing that I can't do this deterministically, but merely somewhat better than random, I'm still that much further ahead.

    --
    Parity: What to do when the weekend comes.
  9. I can't be the only one: by rilister · · Score: 5, Interesting

    I can't be the only one who clicked on the link and was astonished to see:
    "On the Possibility of a Back Door in the NIST SP800-90 Dual Ec Prng - by Dan Shumow, Niels Ferguson, Microsoft"

    Microsoft are exposing this? Are they funding the group making these kind of claims? If this was true, wouldn't this intensely annoy the NSA to have this exposed? Am I missing something here? .

    - I see the disclaimer ("What we are NOT saying") where they seem to be saying - "No way did the NSA intentionally make this broken - maybe it was an errant developer and maybe they knew what they were doing", but it amounts to the same thing, surely?

    --
    'This writing business. Pencils and what-not. Over-rated if you ask me. Silly stuff. Nothing in it' - Eeyore
  10. Ummm, parent is right. by iknownuttin · · Score: 5, Interesting
    But this is the NSA we're talking about... Not the Bush administration.

    I wish I could remember the show I saw. But the scientist (MIT, PhD scientist) was amazed at the intellect of the NSA folks who came to see him about his research. I can't remember who it was - it was a NOVA episode (but it stuck in my head because of his fear!). And after talking to friends who work with various internet security companies and defense contractors, I have to reiterate their opinion of these guys - they're really sharp. And as much as I like to disparage Government workers, these guys aren't to be trifled with.

    And, as I was previewing, I noticed that the parent was moderated "Offtopic".

    As an Offtopic note: 2 out of 3 down mods that I meta mod are unfair. Keep that in mind. It's really pissing me off.

    --
    I prefer Flambe as apposed flamebait.
    1. Re:Ummm, parent is right. by aproposofwhat · · Score: 5, Insightful
      I think the point of Schneier's article is that everybody (i.e. everybody who means anybody in terms of cryptoanalysis) has crawled over each algorithm, and there's only one that has failed the peer review.

      It's somewhat surprising that an algorithm with a documented flaw made it through to the standard, but Schneier makes it clear that the NSA pressured NIST to let it through, so there are grounds for concern.

      --
      One swallow does not a fellatrix make
  11. Things we know we don't know. by ColaMan · · Score: 5, Interesting

    The NSA is a lot more competent than you think.
    Go google "NSA DES" sometime.

    "The NSA was embroiled in controversy concerning its involvement in the creation of the Data Encryption Standard (DES), a standard and public block cipher used by the US government. During development by IBM in the 1970s, the NSA recommended changes to the algorithm. There was suspicion the agency had deliberately weakened the algorithm sufficiently to enable it to eavesdrop if required. The suspicions were that a critical component -- the so-called S-boxes -- had been altered to insert a "backdoor"; and that the key length had been reduced, making it easier for the NSA to discover the key using massive computing power, although it has since been observed that the changes in fact strengthened the algorithm against differential cryptanalysis, which was not publicly discovered until the late 1980s."

    So they made some small changes to DES... then a *decade* later, the rest of the crypto world says, "Huh. We've just done the sums and that actually made it better."

    Not to say that in this case they're just screwing with the algorithm though :-P

    --

    You are in a twisty maze of processor lines, all alike.
    There is a lot of hype here.
    1. Re:Things we know we don't know. by Deanalator · · Score: 5, Interesting

      The same thing happened with SHA. Even creepier was that they just threw a "leftshift 1" in the middle of the algorithm. This is the difference between SHA0 and SHA1, yet 10 years later new attacks on hashing algorithms emerged that broke SHA0 wide open, but SHA1 was resistant.

      This 10 year thing starts to tickle my paranoia. NIST has the stated goal to make all of it's algorithms unbreakable for at least 10 years, and the NSA claims on their website that they are always 10 years ahead of what is known publicly (with respect to computational power and cryptographic research).

  12. alternate explanation for incompetence by Anonymous Coward · · Score: 5, Interesting

    There is another explanation; difference of opinion between management and staff

    - Management wants a backdoor in public standard, orders their very smart math geeks to make it so
    - Math geeks say it can't be done
    - Management insists
    - Math geeks go away and come up with something out of left field that technically fulfils the request of management, knowing it's vulnerabilities. They probably tell management that their solution is the best they could do, but it still has all the following problems (slow, crypto-nerds will see through it sooner or later, etc)
    - Management hears the 'best' and 'done' part, discounts possibility of anyone outsmarting their 'uber-elite' NSA math geeks

    predictable results follow.

  13. Don't Use Dual_EC_DRBG by The+Real+Nem · · Score: 5, Informative

    In my final year in CS, I wrote a lengthy paper researching various DRBGs. To my surprise, there were very few good candidates for cryptographic DRBGs, but of the 7 I looked at, Dual_EC_DRBG rated the worst. I was unable to find any theoretic proofs for Dual_EC_DRBG, but I did find a few papers exposing serious flaws in Dual_EC_DRBG including this one which describes a tractable distinguisher so efficient it can run on a modest desktop.

    The other three DRBGs recommended by NIST were all reliant on the security of various other cryptographic primitives such as SHA (Hash_DRBG), HMAC (HMAC_DRBG - which is often based on SHA) and AES or 3DES (CRT_DRBG). They were all reasonably obvious, and only really tried to set out some sort of standard for jumbling the output of their respective primitives enough that they would be resilient to any unknown vulnerabilities in said primitives (though certain paths also failed to do this). This was mostly accomplished by calling the primitives several times (HMAC_DRBG with the NIST HMAC implementation called for 6 SHA hashes per SHA sized output) which isn't very efficient.

    I suspect they only included Dual_EC_DRBG because it wouldn't have looked too good if they were unable to come up with a single number theoretic or otherwise novel DRBG. They shouldn't be too disappointed, however, as the only one I was able to find was Blum Blum Shub which is terribly inefficient. CryptMT (Cryptanalysis) also deserves a mention as it looks like a promising pseudo-number theoretic DRBG, at least a better candidate than Dual_EC_DRBG.

  14. Re:umm by bhima · · Score: 5, Informative

    No. I was replying to someone who said the NSA had put backdoors in all available Random Number Generators and I wondered how the NSA could possibly get a backdoor in all of such algorithms. My line of thinking was this

    1: Open algorithms are the mainstay of the crypto community
    2: All those algorithms described in the article have been published
    3: The NSA did not sponsor, develop, or promote all of random number generators described in article (much less all that are available)
    4: The NSA is not the sole distributor of the source or binary versions of these algorithms

    I know the NSA has a bunch of really sharp folks but how could they pull off having a backdoor in an Random Number Generator algorithm which they did not design, did not sponsor development of, and do not distribute?

    As far as Dual_EC_DRBG goes it is clear how they could have pulled off a stealthy backdoor, the algorithm is their own design.

    --
    Nothing in the world is more dangerous than sincere ignorance and conscientious stupidity.