Did NSA Put a Secret Backdoor in New Encryption Standard? (2007) | Hacker News Reader

Did NSA Put a Secret Backdoor in New Encryption Standard? (2007)

wired.com

187 pointsaprescott32 comments

Yes, from the New York Times:

Classified N.S.A. memos appear to confirm that the fatal weakness, discovered by two Microsoft cryptographers in 2007, was engineered by the agency. The N.S.A. wrote the standard and aggressively pushed it on the international group, privately calling the effort “a challenge in finesse.”

“Eventually, N.S.A. became the sole editor,” the memo says.

The presentation on the vulnerability, from the two Microsoft employees, for those interested: http://rump2007.cr.yp.to/15-shumow.pdf

Amusingly, from the PDF:

> WHAT WE ARE NOT SAYING:

> NIST intentionally put a back door in this PRNG

The NYT piece today had different redactions than the Guardian, showing the NSA may have done this with commercial VPN ASICs.

The Times includes "Complete enabling for [XXXXXXX] encryption chips used in Virtual Private Network and Web encryption devices." http://www.nytimes.com/interactive/2013/09/05/us/documents-r...

(compare to http://www.theguardian.com/world/interactive/2013/sep/05/sig... )

Also keep an eye on http://cryptome.org. It looks like they're keeping track of redactions as well.

How did the difference come about? Did the Times and Guardian redact the documents themselves?

Yes. According to Reuters:

"The New York Times and ProPublica said they were asked not to publish their findings by intelligence officials who argued that their foreign targets might switch to newer forms of encryption or communications if the NSA tactics were revealed. 'Some specific facts' were removed, the New York Times said. The articles do not say which mainstream encryption systems have been effectively broken."

http://www.reuters.com/article/2013/09/05/net-us-usa-securit...

There is some precedent for the NSA backdoors in commercial VPNs ...

http://www.schneier.com/blog/archives/2008/01/nsa_backdoors_...

Backdoors were found in the devices/software sold to many governments, used by embassies and consulates all over the world.

On Schneier's blog here: https://www.schneier.com/blog/archives/2007/11/the_strange_s...

You don't even need to ask if the NSA broke the encryption to answer the question "Is this standard effectively compromised and not suitable for use?"

Based on what we already know, keeping in mind the goal of encryption in the first place, the answer is "yes."

But it is also a decent assumption to think that it is precisely the NSA that has broken the standard in light of the recent reporting by the NYT.

This is clearly exaggerated. There's no way the NSA would ever do such a thing. Surely it would weaken US communications as well, and one of their mandates is to protect US communications - not to spy on americans, which it's forbidden to do.

NIST and the NSA are obviously above reproach in this case.

[/sarcasm]

>>clearly exaggerated ?

read the article again. Why is there no way the NSA would do such a thing ? There is no silver bullet in the crypto world. If somewhere 10% or 5% or even 1% of someone uses that encryption because it is 'standardized' you have a turn key solution without wasting any time. It makes perfect sense that they would push it in there.

I think you missed the "[/sarcasm]"!

looks like i did!

So, it's six years later. Is Dual_EC_DRBG in use in any commercial products?

Is this encryption standard used in any real life applications? It sounds like people had a ton of problems with it even just right as it was released. They may have forced the standard, but it didn't look like it was adopted.

It is might be time for an audit of code submits to the encryption libararies in open source projects.

http://www.youtube.com/watch?v=W8ZETOz5Fbs

That's why my projects use RIPEMD rather than SHA. I prefer my encryption algorithms to not be developed by an organization that has a vested interested in them being broken.

> I prefer my encryption algorithms to not be developed by an organization that has a vested interested in them being broken.

While I understand the sentiment, you should not be using them for encryption in the first place. RIPEMD and SHA are cryptographic hash functions.

Unless it's SHA3, but thankfully that wasn't designed by them.

SHA3 (Keccak) is also a cryptographic hash function, and should not be used for encryption.

Why not? It's designed for indefinite output.

Are you trolling?

...no

Keccak is a generic construction suitable for more than just hashing. Here, let me copy the first bullet point off their site.

> As a sponge function, Keccak has arbitrary output length. This allows to simplify modes of use where dedicated constructions would be needed for fixed-output-length hash functions. It can be natively used for, e.g., hashing, full domain hashing, randomized hashing, stream encryption, MAC computation. In addition, the arbitrary output length makes it suitable for tree hashing.

Note that Keccak has a significant amount of hidden state, and they proved that the sponge construction itself is secure as a function of how many bits are hidden.

I think he is trolling, with just enough information to sound correct. The Keccak authors have proposed a "duplex construction"[1][2], using the arbitrary length inputs/outputs and the lack of a output transformation in the sponge construction, that could be used for authenticated encryption. The NIST has yet to included that use case in the SHA-3 standard. So, until there is enough solid understanding for its correct use and tested implementations with that use, it is just a hash function.

[1] http://sponge.noekeon.org/ (end of the page)

[2] http://sponge.noekeon.org/SpongeDuplex.pdf

> So, until there is enough solid understanding for its correct use and tested implementations with that use, it is just a hash function.

I don't understand the logic here. Isn't the use of Keccak as a hash function currently largely-untested too? I would think you'd avoid using it at all in a production system right now, but if you're willing to use the algorithm why not use all of its capabilities?

And I'm not trolling.

Would love to see an update to this with some context. So this became a government standard...but was it widely adopted in the industry (outside of government)? It had already been under suspicion of this fatal flaw before its release and Schneier says it was "also three orders of magnitude slower than its peers"...even if the security flaw didn't deter users, I would think a performance drop of three magnitudes would make it unpopular for use in anywhere but the government [insert joke about government inefficiency here].

Digital fortress anyone?

Is that a reference to the laughably inaccurate Dan Brown thriller?

Hit up a thrift store. It's kind of a fun read, well, depending on your tolerance for technobabble I guess!

No. (per Betteridge's law of headlines)

You know this is on the front page because they most certainly did?

Reply on news.ycombinator.com