With close to years of C under my belt, I believe it's a major error, today, to write a critical cryptographic library in C.
OK, do the codecs in C if it's the only way to meet performance requirements. But the rest must be written in a language that's reasonably analyzable statically, and with adequate abstractions. Seriously, have you looked at the filthy mess of leaky abstractions that OpenSSL's BIO system is? How many bugs could be found and/or planted by a 3-letters agency in that crap? Is there anyone who's comfortable with its #ifdef labyrinths?
Finally, I don't think you can retrofit clarity in OpenSSL any better than you could, say, retrofit virus-resilience in a Microsoft OS that hasn't been originally designed for hostile network environments. I used to believe OpenSSL was made messy in order to sell consulting hours, since Snowden I have a more paranoid hypothesis.
Like we always have to ask when somebody says what you have, "What's the alternative?"
Whatever it is, it'll need to be very portable (well beyond just Linux, OS X and Windows), and it'll presumably need a free implementation on each of those platforms, and it'll need to be quite fast, and it'll need to support native compilation, and it'll need to support interoperability with existing code, and it'll need to be "safer" in some way.
At this time, there are very, very few languages that meet every one of those criteria sufficiently. We're looking at C, or C++. Maybe Ada. But that's about it. Rust doesn't cut it yet, and probably won't for some time. Other candidates are lacking severely in one or more of those important areas.
C++ using modern techniques appears to be the only feasible alternative to C today.
They're making a fork of OpenSSL, and removing all the cruft.
Porting it to a completely different language would be an error.
There are several alternatives to OpenSSL available and/or popping up right now. They might or might not be a better choice for new developments. But refactoring OpenSSL (where a lot of currently used software depends upon) is certainly not a dumb decision.
Agreed, there's no realistic way to port OpenSSL to a new language. What I'm saying is, I think a clean-up fork of OpenSSL will divide the workforce per project, without dramatically improving security.
So it's not "dumb", but I expect the net result to be negative. At least a clean reimplementation featuring XXI-th century technologies would have a non-zero chance to produce something great.
> At least a clean reimplementation featuring XXI-th century technologies would have a non-zero chance to produce something great
There are no guarantees of anything working out or being great, regardless of technology. And whatever language/tech you use would require a couple of layers of control. For example, ensuring the low-level features of the language don't betray entropy to statistical analysis, or managing (and ensuring) the virtual memory used is cleaned up properly, or being as efficient as possible lest the crypto become a performance barrier to use.
It's not like high level languages can't implement crypto as well as lower level ones; they can. But it's a lot easier to ensure the various attack vectors are mitigated in a low-level language where there's no glue [outside of that included in your source] to get in the way, obscure, or otherwise subvert the security and performance of the applications using your code. The Heartbleed bug happened because the glue they chose to use was crappy; this was an implementation problem, not a low-level-language problem.
I don't agree at all. I am betting that once LibreSSL is "done" it will get adopted heavily and the community will have a cleaner and more secure code base to work from going forward.
I'm going to quote somebody out of context. Please bear with me...
What I am seeing is that we have a ridiculously upside-down trust
model -- "Trust the developers".
We never asked for people to trust us. We might have "earned some" in
some people's eyes, but if so it has always been false, even before
this. People should trust what they test, but the world has become
incredibly lazy.
We build this stuff by trusting each other as friends, and that is
done on an international level. If anything, the layers and volume of
trust involved in software development should decrease trust. Oh
right, let's hear some of that "many eyes" crap again. [..] All the
many eyes are apparently attached to a lot of hands that type lots of
words about many eyes, and never actually audit code.
If anything, the collaborative model we use should _decrease_ trust,
[..]
Before anyone gets the wrong idea, I'm not trying to attack any individual here. But so many software vulnerabilities, goto fail included, Heartbleed included, have caused such angry response from people. That the bug was trivial. It should've been caught by static analysis, smart compilers, correct review process, careful third party readers, TDD, UFOs, ADHD, <insert favorite tech here>. It is easy to say all that in hindsight, because you are for most part right. So why weren't these techniques used?
You can't blame the developers for everything, they have work on their hands and you are not entitled to anything more from them. You also can't trust developers. If there's sloppy code, someone has to notice it and point it out. Someone has to fix it. If there are sloppy development practices and it is evident that the upstream developers do not care, someone has to notice that and let the world know. Then maybe create a fork and try to do better.
So anyone capable of reviewing code and diffs: please try to do it if you haven't before. Try to do more if you're already doing it. And remeber, you do not have to be an expert programmer to notice a duplicated goto fail line.
Or if you can write tests, why don't you contribute?
OK, do the codecs in C if it's the only way to meet performance requirements. But the rest must be written in a language that's reasonably analyzable statically, and with adequate abstractions. Seriously, have you looked at the filthy mess of leaky abstractions that OpenSSL's BIO system is? How many bugs could be found and/or planted by a 3-letters agency in that crap? Is there anyone who's comfortable with its #ifdef labyrinths?
Finally, I don't think you can retrofit clarity in OpenSSL any better than you could, say, retrofit virus-resilience in a Microsoft OS that hasn't been originally designed for hostile network environments. I used to believe OpenSSL was made messy in order to sell consulting hours, since Snowden I have a more paranoid hypothesis.