Is there any proof that Dual_EC_DRBG is backdoored?
All I know is that Dual_EC_DRBG can be backdoored. And there are indeed suspicions, it was known from the start that not only Dual_EC_DRBG could be backdoored, but that it was rather weak to begin with. So, how could it be adopted as a standard?
Now it seems that everyone takes the backdoor as a given. Is there any proof? Ideally the keys themselves (that would make it undeniable), but more credibly, leaks that show usage or potential usage of the backdoor.
But what seems surprising to me about that story is that the potential for a backdoor was known even before the adoption of Dual_EC_DRBG as a standard. Any credible enemy of the state would know that and use something else, and be very suspicious of imported products using it. The ones following NIST recommendations would be allies, but why would you want allies to use weak ciphers?
> Is there any proof that Dual_EC_DRBG is backdoored?
The algorithm is bad: it's complicated and slow.
The competing algorithms were much simpler, much more secure by construction, and much faster. Most importantly, there was no obvious way to backdoor the competing algorithms, but there's a hilariously trivial way to backdoor Dual_EC_DRBG.
Ergo: the only reason you would ever devise or use Dual_EC_DRBG is to introduce a backdoor capability. There is no other believable benefit or reason.
But rest assured, the NSA promised that they destroyed all copies of the private key they used to generate the public key for Dual_EC_DRBG.
Oh wait, you thought you could generate your own pair and throw away the private key? Ha-ha... haaa. No. That's not compliant with the "standard", which the NSA forced upon the industry, and/or literally bribed companies with millions of dollars to accept willingly.
It's as obvious a backdoor as you could possibly have.
Why would you need proof that it has been backdoored? The fact that it can be backdoored should be enough to disregard it for all uses right from the start.
There are some algorithms where there's no obvious way to back door it, but it's always conceivable -- the person designing it may know some clever mathematics that you don't.
With Dual_EC_DRBG, everyone knew that it could be back doored. It's not some guess, or "maybe it could have". It was obviously designed to be back doored. It should have been called "NSA_BACKDOOR_RNG", because that's literally what it is.
And yes, all organisations that are not under the thumb of the US Government laughed at the transparent attempt to introduce a back door and rejected Dual_EC_DRBG. Only US-based companies use it, which ought to give you a hint.
No, not really. If the data you hold is precious enough that you may have an actor with near infinite resources after you then you don't wait for proof to arrive, you assume the holes are there and act accordingly. Paranoia is fine if you have actual enemies, banking on the theory that evidence that a backdoor exists in a tool that you are using today will never surface is entirely the wrong approach.
Knowledge that this environment exists is also strong evidence that it was a backdoor.
If you propose a clearly questionable security practice in some arbitrary bureaucracy, the assumption is it's incompetence because that happens all the time and no one detects it until it's already in production.
If you propose a clearly questionable security practice to a cryptography standards body, the expectation is that you get laughed out of the room. Even the possibility of a backdoor would make everyone skeptical, which would be useless in a standard because no one would trust it.
And yet it made it through the standards process for some reason, but there is only one plausible reason.
> In this way, entire sections of industry will auto-assume the backdoor was both deliberate, and used both both friendlies & hostiles.
That’s fine. But they should be equally paranoid of all substitute products/services that use other recommendations from NIST, right? Are there greater than zero products on the (US) market with no encryption in the system recommended by NIST?
Also, I don’t think I was limiting my thinking to a customer of the weak encryption product. I was also thinking through the lens of legal implications.
If, for example, SHA2 had a backdoor or a weakness known only to the NSA, then random contractors (like Snowden) could use that to extract money from the Bitcoin network, which uses SHA256 as its core cryptographic primitive.
That's easily a billion dollar motivation right there, and I can't imagine a bunch of low-paid government drones resisting that cash prize. Everyone has a price.
Hence, there's a level of trust that can be gained through observation of failures to abuse backdoors. If they don't exist, they can't be abused. If they exist, then they must be used/abused, otherwise what's the point? Such usage will be eventually discovered. E.g.: The use of the Dual_EC_DRBG back-door to tap into Juniper VPN connections by the Chinese government was discovered and made public.
I'm not advocating in either direction here, but let's assume backdoors like this do exist: Just because they haven't been abused doesn't mean that they wont in the future.
Of the people I know that work with highly privileged materials, none would take advantage or abuse something like this, even with such a high payout. Even if they did, how would they continue to live comfortably? That said, it just takes one person under the right circumstances to act maliciously, which is why screening and compartmentalization is critically important for these organizations.
We use computers because it is pretty much impossible to live in modern society without using computers.
But by the time Dual_EC_DRBG was published, we already had alternatives that were better in just about every way, including being much less likely to contain a backdoor.
Interestingly, Trusting Trust style attacks on compilers was later (theoretically, idk to what degree it's been put into practice) solved by "diverse double compiling": https://dwheeler.com/trusting-trust/
I like the link and the explanations about the weaknesses.
I detest the only evidence being circumstantial and the _argument from ignorance_ being the one that you lean on. Make the simple observations and don’t try to oversell it.
It has constants chosen with NSA input which weaken it - and which were called out a long time ago as doing so.
It isn’t a back door in the sense of ‘poke the code in a certain way and voila’, rather ‘if you know the counterpart to this constant, you can guess what values the RNG spits out at statistically improbable rates’.
You’d never know if someone was doing so unless they admitted it or someone got arrested in a way that was only possible if they’d used
it. Which good luck.
If you believe you are the only one who can break the cipher, then it doesn't really matter if your allies are using them - after all, spying happens even among ostensibly allied or friendly countries.
I think most people's source of proof is the Snowden leaks, but I haven't actually read it or corroborated, and most backdoors should be deniable anyway - it'd be real dumb if they weren't. I think strong circumstantial evidence is really the only thing one can go on.
All I know is that Dual_EC_DRBG can be backdoored. And there are indeed suspicions, it was known from the start that not only Dual_EC_DRBG could be backdoored, but that it was rather weak to begin with. So, how could it be adopted as a standard?
Now it seems that everyone takes the backdoor as a given. Is there any proof? Ideally the keys themselves (that would make it undeniable), but more credibly, leaks that show usage or potential usage of the backdoor.
But what seems surprising to me about that story is that the potential for a backdoor was known even before the adoption of Dual_EC_DRBG as a standard. Any credible enemy of the state would know that and use something else, and be very suspicious of imported products using it. The ones following NIST recommendations would be allies, but why would you want allies to use weak ciphers?