6 ms·

Not sure if this tidbit made Hacker News -- the OpenSSL project added Dual_EC_DRBG support at the request of a paying customer: http://openssl.6102.n7.nabble.co

by morsch 13y ago

Not sure if this tidbit made Hacker News -- the OpenSSL project added Dual_EC_DRBG support at the request of a paying customer: http://openssl.6102.n7.nabble.com/Consequences-to-draw-from-the-latest-Snowden-revelations-td46453.html#a46455 http://openssl.6102.n7.nabble.com/Consequences-to-draw-from-... 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.

a3vioces 13y ago
Yes, it was 600k.
- jwcrux 13y ago
  Do you by chance know the source?
  - dotBen 13y ago
    And where exactly did the money go? $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.
    - DannyBee 13y ago
      "$600k is a lot of money to implement an existing standard." 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.
- andrewcooke 13y ago
  the only other comment by this acct was a weird attempt to impersonate someone else. it seems more like a troll than an anon informer.
amatix 13y ago
Some important context from the OpenSSL list last week (http://marc.info/?l=openssl-announce&m=138747119822324&w=2 http://marc.info/?l=openssl-announce&m=138747119822324&w=2 ): 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. Seems fair enough if a client says "implement all the standard" that they implemented it... it's a bit different than "just add this one algorithm"
- alttab 13y ago
  This "explanation" is misdirection. The accusation was never that the NSA wanted to add just this one bust algorithm. The NSA, acting as a client protected by privacy, could have easily invested time and money to be a significant contributor, with a small, hidden, 1 time payload.
  - mst 13y ago
    I fail to see how it's misdirection. OpenSSL have explained, clearly, what they were paid for - and it seems entirely reasonable to implement everything, especially given - as that post shows - that the duff algorithm was really quite hard to use unless you really tried. 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.
ajross 13y ago
It's worth pointing out that at the scale mentioned, there's no reason that the "paying customer" had to be The United States National Security Agency. It was a published algorithm, and OpenSSL is used in countless commercial projects. It would have been entirely reasonable for one of these to have come to OpenSSL requesting implementation (albeit as part of a NSA-funded internal project with a 400% markup), and the request would have seemed entirely reasonable. I don't think you can tar the OpenSSL folks with this without much better evidence.
- morsch 13y ago
  I agree. It's still notable, though.
- gojomo 13y ago
  OTOH, the fact that the delivered code had a bug rendering it unusable suggests whoever requested it didn't really need to use it – or they'd have discovered the bug earlier. That's vaguely suggestive the client may have paid for its inclusion for mere show, or as a favor for another entity. 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?
  - mst 13y ago
    "Implement ALL the algoirthms" sounds like a requirement drafted by somebody enamoured of the standard rather than by somebody looking at what they were actually going to use. "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

by morsch 13y ago

a3vioces 13y ago

Yes, it was 600k.

jwcrux 13y ago
Do you by chance know the source?
- dotBen 13y ago
  And where exactly did the money go? $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.
  - DannyBee 13y ago
    "$600k is a lot of money to implement an existing standard." 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.
andrewcooke 13y ago
the only other comment by this acct was a weird attempt to impersonate someone else. it seems more like a troll than an anon informer.

amatix 13y ago

Some important context from the OpenSSL list last week (http://marc.info/?l=openssl-announce&m=138747119822324&w=2 http://marc.info/?l=openssl-announce&m=138747119822324&w=2 ): 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. Seems fair enough if a client says "implement all the standard" that they implemented it... it's a bit different than "just add this one algorithm"

alttab 13y ago
This "explanation" is misdirection. The accusation was never that the NSA wanted to add just this one bust algorithm. The NSA, acting as a client protected by privacy, could have easily invested time and money to be a significant contributor, with a small, hidden, 1 time payload.
- mst 13y ago
  I fail to see how it's misdirection. OpenSSL have explained, clearly, what they were paid for - and it seems entirely reasonable to implement everything, especially given - as that post shows - that the duff algorithm was really quite hard to use unless you really tried. 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.

ajross 13y ago

It's worth pointing out that at the scale mentioned, there's no reason that the "paying customer" had to be The United States National Security Agency. It was a published algorithm, and OpenSSL is used in countless commercial projects. It would have been entirely reasonable for one of these to have come to OpenSSL requesting implementation (albeit as part of a NSA-funded internal project with a 400% markup), and the request would have seemed entirely reasonable. I don't think you can tar the OpenSSL folks with this without much better evidence.

morsch 13y ago
I agree. It's still notable, though.
gojomo 13y ago
OTOH, the fact that the delivered code had a bug rendering it unusable suggests whoever requested it didn't really need to use it – or they'd have discovered the bug earlier. That's vaguely suggestive the client may have paid for its inclusion for mere show, or as a favor for another entity. 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?
- mst 13y ago
  "Implement ALL the algoirthms" sounds like a requirement drafted by somebody enamoured of the standard rather than by somebody looking at what they were actually going to use. "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