Or maybe it's just a bug. There's really no need for tinfoil hat theories unless you have any evidence for a possible conspiracy.
That being said I agree that OpenSSL could do with a good code cleaning, but that's a massive undertaking, especially for such a popular library. You have to be backwards compatible.
Maybe a big name in software could go and write a modern crypto library without all the cruft of OpenSSL but for now we have to deal with it.
Unfortunately with the Snowden disclosures, there isn't much that I rule out of bounds for the NSA when it comes to things critical to internet security. OpenSSL is so widely used and critical, it would be silly to think that it would escape scrutiny by the NSA.
There is a difference between infiltrating companies and deliberately introducing a bug that compromises a large chunk of the Internet. I would assume the NSA is interested in gaining access to systems in a way that doesn't allow basically anyone to ride on their coattails.
> I would assume the NSA is interested in gaining access to systems in a way that doesn't allow basically anyone to ride on their coattails.
Don't we actually already have evidence of other cases of the NSA adding backdoors to widely used systems, exploitable by anyone aware of them? Isn't that what the elliptic curve backdoor was? http://www.wired.com/2013/09/nsa-backdoor/all/
Apparently your assumption is quite not safe to assume.
I guess the NSA either figures nobody else will notice the backdoor, or just doesn't care. I guess only they know their motivations.
The mooted backdoor in the Dual-ECDRBG involves the possibility that the public parameters were generated based on some secret values, such that knowing the secret values allows you to break the generator.
It doesn't allow just anyone to break it - merely knowing the backdoor is there isn't enough.
I don't see why people think that NSA is simultaneously genius-level forces of the Illumanti architecting events that will culminate years later, and yet would make the rookie level mistake of introducing a backdoor that is protected only by obscurity.
They know other security services understand how to decompile code (or read the original source).
More importantly, they know that critical government services they can't predict will end up possibly running things like their broken version of OpenSSL. There's a FIPS standard, of course, but note that the Heartbleed page made quite clear that FIPS is vulnerable too.
> the NSA is interested in gaining access to systems in a way that doesn't allow basically anyone to ride on their coattails.
If possible, yes. However, if they were indeed responsible for this, they'd probably have a couple honeypots to detect exploitation by third parties. If they considered the third party harmless, they could decide whether the vulnerability should be "independently discovered" or not.
Planting a complicated exploit would be harder and increase the risk it could be traced back to them.
Interesting. However, your sources are rather obscure, and I'm not sure what you mean by "a weak form."
I'd say a Baysian analysis is a way to evaluate the veracity of an argument from ignorance, not necessarily a replacement of that argument. An argument from ignorance is a strict subset of a baysian analysis in which there is no causal relationship between the missing evidence, and the conclusion. This is such a case. So we can conclude by using a baysian analysis that this is in fact an argument of ignorance.
Unless, of course, you have additional statistical samples that show a non zero relationship between not knowing about NSAs activity and the fact that they are engaged in that activity.
> Or maybe it's just a bug. There's really no need for tinfoil hat theories unless you have any evidence for a possible conspiracy.
But we do have "evidence for conspiracy". We known for certain that there are organizations with huge budgets that have introducing such vulnerabilities pretty much written into their mission statements. Why would we assume they would not be involved in something they obviously should be (however perverted their goals are)? It would be grossly incompetent of the NSA not to try introducing bugs into OpenSSL.
You have kept up to date with the news, right? Truecrypt, RSA... OpenSSL is low-hanging fruit by comparison. Of course it's back doored - probably more than once.
You're right that it needs cleaning - it needs a full audit. I'm surprised in the light of the Snowden revelations that none of us have suggested this sooner, but hindsight is a bitch and all that.
Lots of people have suggested it. Very few people have dedicated their time to helping do it, though. Welcome to the 'other people should do this' club!
I don't know what the gp's skills are, but assuming he's not a computer security professional then the 'other people should do this' club is exactly the club he should be in. Would you trust his audit of the code if he wasn't heavily experienced? it's the same case as "don't roll your own crypto".
There's a difference between "trusting his audit of the code" and "trusting his code". Any interested and motivated person can audit code. If nothing is found, that might not prove much. But if a vulnerability is found, the audit was worthwhile from some perspective.
Sure, so long as the bug is a genuine bug and not a misunderstanding. Debian's openssh valgrind warning springs to mind. Crypto implementations can be subtle and non obvious. Maybe it's crap design for that reason, but it seems like it's what we've got to work with currently.
What would evidence of conspiracy look like? Do we need comments in the code, "this is an NSA back door...", seriously?
>You have to be backwords compatible
we have been making this trade off for years and it wont get any easier in the future, its about time we started a fresh initiative that doesn't make backwords compatibility a priority, except of course in the sense of maintainability moving forward.
There are very few competent FOSS crypto implementers, and unfortunately, they're spread very thinly. I'm not sure that having yet one another crypto library is going to be helpful unless we actively move our users to the new library and kill the old projects.
That being said I agree that OpenSSL could do with a good code cleaning, but that's a massive undertaking, especially for such a popular library. You have to be backwards compatible.
Maybe a big name in software could go and write a modern crypto library without all the cruft of OpenSSL but for now we have to deal with it.