Why did we implement Dual EC DRBG in the first place?
- ----------------------------------------------------
It was requested by a sponsor as one of several deliverables. The
reasoning at the time (my reasoning and call as the project manager)
was that we would implement any algorithm based on official published
standards. SP800-90A is a more or less mandatory part of FIPS 140-2,
for any module of non-trivial complexity. FIPS 140-2 validations are
expensive and difficult, taking on average a year to complete and we
have to wait years between validations. So, there is an incentive to
pack as much as possible into each validation and our sponsors (dozens
of them) had a long list of requirements they were willing to fund.
We knew at the time (this was the pre-Snowden era) that Dual EC DRBG
had a dubious reputation, but it was part of an official standard (one
of the four DRBGs in SP800-90A) and OpenSSL is after all a comprehensive
cryptographic library and toolkit. As such it implements many algorithms
of varying strength and utility, from worthless to robust. We of course
did not enable Dual EC DRBG by default, and the discovery of this bug
demonstrates that no one has even attempted to use it.
Where did our implementation come from?
- --------------------------------------
The client requirement was simply "Implement all of SP800-90A". Our code
was implemented solely from that standard.
Additionally, given the trouble Theo's got into on a number of occasions for criticisng bits of the government, it seems fairly unlikely that he would've been comfortable with the project taking NSA money.
Most plausible situation: Corporation said "here's money, implement ALL the things", OpenSSL figured it was a good way to get the useful things paid for plus some stuff that potential future sponsors might find useful in marketing material.
As for whether said Corporation had additional, non-obvious motives, I make no guess either way.
But misdirection does not, frankly, seem appropriate to describe the explanation given, and your scare quotes suggest you're appealing to emotion rather than presenting an actual argument. Do feel free to present one if you have one, though, it's entirely possible I misunderstood.
1) Were flaws introduced into the technology which potentially reduce the strength of the encryption?
2) Did OpenSSL know about it?
It seems the answers can be yes and no without any real stretch.
If you are, say, the NSA, asking / paying for a whole standard to be implemented (a) gets the bit you want implemented and (b) hides what you're really interested in from anyone wondering and looks less suspicious. Once it's in they could either start pushing for it to become a default, push for people to voluntarily choose it (get people speaking at conferences to recommend it or whatever), or just leave it knowing that a few people would use it and that works for them too.
But the fact that OpenSSL probably weren't complicit doesn't change the fact that elements of the product need to be considered potentially flawed.
1) the mailing list post states that OpenSSL wants to be comprehensive, even when that means providing implementations of algorithms that you probably shouldn't use. The inclusion of weak, or even broken, algorithms does not undermine the product as a whole given this mission. It has no impact on the effectiveness of other, stronger algorithms in OpenSSL.
2) OpenSSL knew that one of the algorithms in the standard was weak, but thought it was still valuable to implement the standard. again, the comprehensiveness goal means it's up to the end users to utilize OpenSSL in a manner consistent with their use case.
I believe you need to be compliant with everything in the spec to be validated.
Not that it matters much anyway. The result is the same.
It had a bug anyways, nobody ever used dual ec with openssl.
I don't think you can tar the OpenSSL folks with this without much better evidence.
I wonder: is the client which paid for the non-functional implementation, which if I understand correctly is now scheduled for deletion rather than fix, entitled to a refund?
"Our product is compatible with all of <impressive sounding standard>" may, indeed, have been worth the money to the customer even if the value was marketing rather than technoloogy
$600k is a lot of money to implement an existing standard. That's 4-5 annual engineer salaries. I'm wondering exactly how much work was actually undertook for $600k and whether those doing it (/charging for it/taking the money) felt it was unusual size remuneration.
Not if such a requirement includes things like FIPS validation, which is entirely possible in this case.
Plus, in some cases, these things are done in liu of donations, etc.
I can think of plenty of cases where well known contractors on open source projects have been paid very well simply as a way of showing support for that project.
They're under NDA and cannot reveal the customer's name. The thread doesn't say how much the customer paid, does anybody know? A friend told me 600k USD last night, but I cannot find any sources that back this up.