Hacker News Reader

Comment by nullc | Hacker News Reader

Then where are the fixes? They spend untold billions per year... their visible bugfix output is very low, including in low level cryptographic domains that you might expect them to be power-houses.

The claim makes me think either that they're lying about sharing what they find (either intentionally or via institutional stupidity); or they're really inept and not finding much at all compared to much less well funded OSS developers and participants in industry.

It would be interesting for someone to setup a scorecard site to document NSA's infosec contributions.

View on HN

Bug volume in crypto is also very low, and the "fixes" to major crypto bugs tend to take the form of entirely new constructions... which users are not happy to get from NSA (this was a problem even in the 1970s!)

So I'm not sure this is a valid critique.

There was the SHA0 -> SHA1 thing. Which mostly illustrates what you say here, of course, just seemed to deserve mention.

Bug volume in crypto is extremely high. How many developers reuse IVs in stream ciphers? How many blindly use AES or somesuch other symmetric library and then build in no authentication whatsoever? How many antequated implementations of RSA are used in practice today (see recent Bleichenbacher flaw in NSS)? How many times are poor chaining modes for block ciphers chosen? How many implementations of [anything] fail on side cases (elliptic curves) or massively leak through side channels? How many DH-family protocols miss checks for identity inputs?

The answer is a lot.

You and I mean different things by "crypto vulnerabilities". I took the parent comment to mean things like the RC4 biases; like I said, things for which the "fix" would involve entirely new algorithms or constructions. An example of this kind of NSA disclosure would be the DES s-boxes.

Crypto software implementation vulnerabilities are very common, but the kinds of things you're talking about are most often found in obscure and/or serverside software. Look at the tempo at which bugs like the NSS e=3 bug are released; it's like once or twice a year.

I think implementation bugs are within the spirit of OP, especially provided the NSA claims to have provided an implementation fix for Heartbleed.

The sorts of bugs I'm talking about exist in client and popular software. As far as tempo is concerned this year alone has given us BERserk, gotofail, Android Master Key, OpenSSL fork(), Bitcoin's use of P256, GNUTLS X.509 parsing bug, the OpenSSL compiler optimization+processor family randomness bug, and others.

If we were to entertain OP's point maybe there would be a faster tempo if the NSA were helping out. :)

Sure, if this is what we mean by the kinds of cryptography bugs NSA is a powerhouse at, I'm sure they could be leaking more of them to industry.

It's not the NSA that is publishing cryptanalysis of proposed constructions with any frequency compared to industry/academia. Considering the number of mathematicians they employ and their focus on cryptography this is more than a little surprising.

But I did also mean that more broader than just construct attacks..., implementations of cryptosystems are often flawed in low level ways which people without special expertise are unlikely to notice... both from a design perspective (any of the great many protocol design flaws in TLS that have turned around an bitten us), or straight forward coding (e.g. it wasn't the NSA that reported reference implementations of Curve25519 had broken carry propagation).

Well, there was that time a tor developer claimed the NSA was leaking him fixes... https://news.ycombinator.com/item?id=8210319

Reply on news.ycombinator.com