
The Strange Story of Dual_EC_DRBG – suspected NSA backdoor (2007) - sfscs
http://www.schneier.com/blog/archives/2007/11/the_strange_sto.html
======
dhx
There was significant discussion and concern in the academic
community[1][2][3] during the early 90's in response to NIST's draft standard
for digital signatures (DSS). The academic community was concerned that field
parameters could have been carefully selected such that they contained hidden
properties (weak primes, etc). This is why "nothing up my sleeve numbers"[4]
must be used in cryptography. The same issue impacts the selection of prime
field parameters for use in ECDSA/ECDH (TLS, S/MIME, etc). Worth noting is
that NIST P-256 and NIST P-384 elliptic curves were selected from "verifiable
random numbers" generated in accordance with ANSI X9.62. This standard is not
freely available so I am not sure which PRNG was used to generate the curve
parameters and why the PRNG seed is considered a "nothing up my sleeve
number".

[1] Daniel M Gordon. Designing and detecting trapdoors for discrete log
cryptosystems (1993).
[http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.97.3...](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.97.3546)

[2] Yvo Desmedt, Peter Landrock, Arjen K. Lenstra, Kevin S. McCurley, Andrew
M. Odlyzko, Rainer A. Rueppel, Miles E. Smid: The Eurocrypt '92 Controversial
Issue: Trapdoor Primes and Moduli (Panel). 194-199.
[http://link.springer.com/content/pdf/10.1007%2F3-540-47555-9...](http://link.springer.com/content/pdf/10.1007%2F3-540-47555-9_17.pdf)

[3] Miles E. Smid, Dennis K. Branstad. Response to Comments on the NIST
Proposed Digital Signature Standard.
[http://link.springer.com/content/pdf/10.1007%2F3-540-48071-4...](http://link.springer.com/content/pdf/10.1007%2F3-540-48071-4_6.pdf)

[4]
[https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number](https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number)

------
marshray
This is one of my favorite examples showing the need for 'Nothing up my
sleeve' numbers.
[https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number](https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number)

I believe NIST learned their lesson, and it was applied in the design of
SHA-3: [http://crypto.stackexchange.com/questions/6444/why-are-
the-c...](http://crypto.stackexchange.com/questions/6444/why-are-the-
constants-so-simple-in-keccak/6449#6449)

~~~
nightcracker
Nothing up my sleeve numbers are very hard to create for asymmetric crypto.
Asymmetric crypto is filled with mathematical relationships and it's almost
impossible to prove that a certain set of parameters have no "hidden"
properties.

~~~
pbsd
In this case, it could have been done. Dual_EC_DRBG hinges on the discrete log
of two points being unknown; P and Q could have been both generated verifiably
at random.

~~~
marshray
Perhaps something like "The smallest prime number not less than the base-2
expansion of pi*2^(n - 2)".

------
contingencies
I'm no mathematician, so this is probably a dumb question that will serve as a
great example for why random programmers shouldn't write cryptosystems.
However, here goes anyway.

Could a cryptographer please explain why it's not feasible to use multiple
such PRNG algorithms in both series and parallel, perhaps even shuffling their
order dynamically, at, err, random?

Surely most attacks on PRNGs are based upon the assumption that their state
can be modelled to expose weaknesses. By viewing an entire, shifting,
'topology' of PRNGs as a single polymorphic source for pseudorandom data,
surely this class of attack becomes much more difficult and we avoid either
placing absolute trust in a single PRNG author, input entropy source, or a
single mathematical approach.

I suppose this has already been done to the extent reasonable and that
tradeoffs versus performance and available entropy input rates are probably
responsible. But I'd still be keen to hear someone thrash this out in
understandable prose.

~~~
cdumler
Any one who considers arithmetical methods of producing random digits is, of
course, in a state of sin. - John von Neumann

The very definition of a pseudo-random number generator is that it's
deterministic, i.e. an algorithm. If you know in what the state of the
algorithm is, you know what the next number will be. Attempting to add some ad
hoc behavior on top of crypto has two common issues:

First, adding of deterministic behavior to deterministic behavior does not in
any way spontaneously add randomness (see quote). In fact, it can expose
additional state on which an attack can be focused. For instance, perhaps when
I learn that the system you are using is an interleaved set of numbers, I can
use the starting set from each to guess the seed on which all PRNGs started.
Second, crypto PRNGs that are well vetted are already at the top of the game
for being apparently random in output. There shouldn't be a need to do
anything like what you're suggesting, ever, with a valid PRNG. What Schneier
is pointing out is that good crypt doesn't have a whiff of smell. Dual_EC_DRBG
does. And, badly. Just use the others, instead.

Importantly, learn the first rule of crypto: Unless you're well versed in
crypto, presume you will do a very bad job of trying to implement something
yourself. Understand for what the crypto library is meant to be used,
understand how to use it properly, and don't try to do something on your own.
It is hard for even the experts to do it well. Some simple "why don't I
just.." is practically guaranteed to have a flaw. Adding your own
deterministic behavior is a sin.

~~~
malandrew
How about using a stream of true random numbers and putting it through a set
of deterministic functions that "multiply" the quantity of random numbers.

e.g. make thousands upon thousands of functions, where the function names are
sequential. Use the data itself to determine which of the functions will be
called. Allow functions to call each other based on the random number values
it calculates from its true random input. To figure out how much random data
to produce, simply add an extra bit that is passed along to all the functions
that indicates depth (how much show the true random data be processed before
returning it to the program that needs a random number). This approach would
produce a lot more random data that could only be determined if you knew the
original true random data input and the amount of entropy that was required at
the time since you'd need to know the depth used to know when to exit the
functions.

~~~
contingencies
Err, I think you'll find what you described is roughly the definition of a
PRNG (though usually more mathematical in its verbiage). The problem is, we
don't trust any particular PRNG. My question was, why not combine them so as
to remove the need for absolute trust in any given PRNG.

~~~
cdumler
When part of your system becomes flawed (part or whole), the whole can be
attacked. Thus, adding more deterministic behavior doesn't add more randomness
(i.e. more safety). Generally, when crypto falls down, it falls somewhat
gracefully (i.e. there are a class of known attacks under certain particular
situations.) As Crypto is an on-going war between those creating the security
and those trying to break it, expect to have to change your crypto over time.

~~~
contingencies
> When part of your system becomes flawed (part or whole), the whole can be
> attacked.

This is the most concise and meaningful argument against the proposed approach
thus far. Hats off.

------
tptacek
The most important thing to know about Dual_EC_DRBG is that practically nobody
uses it (I'd say "nobody ever uses it", but who knows, maybe something did?).
It's a CSPRNG that involves bignum elliptic curve point multiplication. It's
not something that's maybe slower than an alternative; it's something
noticeably, horrendously slower than its alternatives. Even systems that use
number theoretic crypto use it sparingly; nobody uses it to generate random
numbers.

------
nikcub
Intercepting signals is only half of the NSA mandate, the other half is
securing national communications against interception by foreign governments
and organizations.

It is possible that the NSA want other nations to have the impression that NSA
audited communications protocols _are_ insecure or _may_ contain backdoors.
They have never expressly come out to deny any of these accusations.

The involvement of the NSA thus doesn't imply that they wish to weaken
standards. Perhaps they want people like Schneier to question the security of
these protocols and create a false aura of potential vulnerability so that
their opponents don't make use of them.

------
trotsky
_NSAKEY discovered two years before patriot act is passed? coincidence? i
think not!!1

said another way, what relates the two events in the editorialized title? Just
an end of the innocence type vibe? Trusting the sigint guys to design your
crypto has always been a well acknowledged double edged sword.

~~~
anigbrowl
The Patriot Act was passed in late 2001. It was renewed in 2009.

~~~
trotsky
[http://en.wikipedia.org/wiki/NSAKEY](http://en.wikipedia.org/wiki/NSAKEY)

------
damarquis
So either the NSA wanted a backdoor, in which case we learn that even the NSA
can't build a backdoor that academic cryptographers can't detect.

Or, much more likely I think, it was just a project that some NSA employees
had sitting around and they wanted to get something out of it. In that case we
learn that the NSA isn't so far ahead of academic cryptographers that their
designs will always be better.

Either way I don't find this as scary a story as Schneier does.

~~~
makomk
They might be able to build backdoors that academic cryptographers can't
detect, but this backdoor was special - even after the academics figured it
out, the NSA are still the only ones that could use it because it requires a
secret key whose public counterpart was baked into the Dual_EC_DRBG
specification. Backdoors with that special property are going to be much
harder to create.

------
malandrew
Out of curiosity, why can't we just use a series of sensors on the computer to
generate random numbers? Between mouse movements, touch inputs, video camera
input, microphone movements, the behavior of applications in your system and
how they use resources like RAM, CPU, hard-disk, listening to all the wifi +
bluetooth signals around you and munging them, etc. I would imagine that there
is enough entropy coming in through input and being generated by whatever the
computer is doing to be able to have lots of unpredictable random numbers.

I don't know much at all about cryptography, but why aren't all the natural
sources of entropy an adequate source of random numbers?

~~~
croikle
This sort of thing is used, e.g. [0]. It collects entropy at a limited rate,
though, so for demanding applications (SSL servers, say) you want dedicated
hardware: [1], [2].

[0]:
[https://en.wikipedia.org/wiki/Hardware_random_number_generat...](https://en.wikipedia.org/wiki/Hardware_random_number_generator#Using_observed_events)

[1]:
[https://en.wikipedia.org/wiki/RdRand](https://en.wikipedia.org/wiki/RdRand)

[2]: [http://www.entropykey.co.uk/](http://www.entropykey.co.uk/)

~~~
malandrew
How do those Entropy Keys work? What sort of environmental random data does it
rely on for creating random bits?

~~~
wiml
Thermal noise of various kinds, usually.

(Edit: that is, the noise introduced in a circuit by the fact that it's not at
absolute zero, e.g. Johnson noise. Not just gathering entropy from a
temperature sensor reading or something like that.)

------
Myrmornis
OK I have a probably naive/nonsensical cryptography question. It seems that
one good way of transmitting a secret would be to do so with everyone thinking
it is encrypted one way (or possibly believing it has not been encrypted) when
the truth is it has been encrypted some other way. I.e. it would be a
difficult problem to know when the message has truly been decrypted. So
basically there would be multiple decrypted versions which are plausible as
the true decrypted message. Is there any parallel to that sort of thing in
modern mathematical cryptography?

~~~
rogerbinns
Encrypted traffic should be indistinguishable from random numbers. A quick
test is trying to compress it, as true randomness has no patterns and hence
nothing to compress.

In general you can tell exactly what compression was used because protocols
start out in the clear and include some sort of negotiation.
[https://en.wikipedia.org/wiki/Transport_Layer_Security#Proto...](https://en.wikipedia.org/wiki/Transport_Layer_Security#Protocol_details)

However both ends can separately agree that if they select one cipher suite,
they will be secretly using a different one.

------
jokoon
I'll always question any cryptographic standard adopted or advised by
government.

I have an hard time even trusting AES.

[http://crypto.stackexchange.com/questions/579/how-can-we-
rea...](http://crypto.stackexchange.com/questions/579/how-can-we-reason-about-
the-cryptographic-capabilities-of-code-breaking-agencies)

Honestly I think those issues (like cryptanalysis) are totally out of reach by
the public to comprehend, it's hard to really know how to make strong
assumptions.

------
brokentone
Can anyone confirm that 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 is not
the the backdoor sequence?

Seriously though, have we the people figured out this sequence yet? If there
is a base sequence, and a relationship to a second sequence, I feel like this
can't be too difficult to figure out mathematically, or through brute force
means. Can someone who actually knows what they're talking about properly
rebut me?

------
efm
The ANU Quantum Random Number generator
[http://qrng.anu.edu.au/](http://qrng.anu.edu.au/) can be used as a source of
additional randomness for your server's pseudo RNG, or directly. They monitor
quantum fluctuation of a vacuum to generate the random numbers at a high rate.

~~~
arkem
While it's an interesting project (I had fun playing with it) you really
shouldn't be relying on remote sources of entropy for security purposes.

Generally the entropy needs to be secret to be effective so sourcing remote
entropy reduces your security to that of the transport security (if any). It's
hard to imagine a situation where you have a secure transport mechanism but do
not have enough entropy since most encryption schemes that you might use to
secure the transmission require secure random number generation.

Disclaimer: I am not a cryptographer, cryptology frightens and confuses me.

~~~
lloeki
> _most encryption schemes that you might use to secure the transmission
> require secure random number generation._

If I understand this correctly, most channel securing schemes require RNG for
key exchange (e.g "no prior knowledge" DH key exchange) or pair generation
(RSA), then you can move on to a symmetric cipher (whose key is derived from
the resulting DH shared secret, or exchanged encrypted via RSA), which
requires no RNG (until you want to change the key for PFS).

So one can assume scenario where only a quantum of entropy is needed to
establish a secure connection, then refuel the entropy bucket with random data
transmitted over the now secure yet "non entropy consuming" channel.

------
geophile
Much of the discussion in previous comments has to do with the generation of
true random numbers. Does this need to happen on a client or on a server? If
it's on a client, then isn't a cell phone an ideal source of randomness, due
to all of the sensors on board?

------
btipling
This random generator is found in some versions of Windows:

[http://www.schneier.com/blog/archives/2007/12/dual_ec_drbg_a...](http://www.schneier.com/blog/archives/2007/12/dual_ec_drbg_ad.html)

I don't know if it's in Windows 8 or not.

~~~
w-m
The link to msdn in your post is still working.

 _> The dual elliptic curve random-number generator algorithm. Standard:
SP800-90

> Windows 8: Beginning with Windows 8, the EC RNG algorithm supports FIPS
> 186-3. Keys less than or equal to 1024 bits adhere to FIPS 186-2 and keys
> greater than 1024 to FIPS 186-3._

------
pitiburi
Great reading. Have you any idea how things evolved after that with those 4
proposed methods?

------
gcb0
No mention on authors from nsa or reviewers from nist...

