OpenBSD forks, prunes, fixes OpenSSL
zdnet.com
zdnet.com
That said, many opensource projects ignore the vast majority of compilation warnings. Many projects do the same.
Do they not realize that clients also need SSL support? Servers that don't have anyone to talk to them are kind of useless, so at best this is half of solution (unless it really is the year of the linux desktop, of course). There are a ton of applications out there that run on Windows and use OpenSSL for handling SSL connections.
That being said this may be a great replacement for servers, and there really isn't a requirement for there to be "one library to rule them all". This may be a great step towards diversifying the encryption-library ecosystem a bit.
The act of stripping the library down is worthwhile though: OpenSSL has accumulated a lot of cruft over the years.
All they really need to do to maintain compatibility is maintain the same API. And they're doing just that. In fact, it's in their best interests to maintain the same API as deviating in any significant way is just going to complicate porting software that uses OpenSSL over to use their implementation. So long as they do that, there's little to worry about.
And maybe some day their fork will end up becoming the dominant SSL/TLS implementation, much as OpenSSH became the dominant SSH implementation.
Keep in mind that first and foremost they're doing this for OpenBSD: all other platforms are secondary.
Maybe Theo is thinking only about the "OpenBSD community".
That said, later on folks can create compatibility layers (like OpenSSH) to make it work elsewhere. It's better to keep that code outside the core anyway.
(I realize the issues previously expressed about the state of change within the OpenSSL project, as well as the lack of general give back from the many people that use it).
Those down voting, have you actually dealt with getting a product through government certification? Specifically in security would be more useful.
What have the USA done for us lately? Oh yes, fought a long battle against cryptography in the hands of world citizens, spied on everyone and their dog, canceled OpenBSD funding, started multiple illegal wars and threatened every single country into submission (except for the one with nukes pointed at the White House).
Does it get any more selfish? Bah.
"Forcible certification conflicts with the goals of a free software project."
Windows support? There are more than a couple of applications out there running on Windows that make use of OpenSSL.
Theo's quote -- "99.99% of the community does not care for VMS support, and 98% do not care for Windows support." -- is, at least to me, narrow minded in the scope of what he defines as "community" -- unless he specifically means the OpenBSD community.
But right now OpenSSL is a VERY VERY messy and dangerous library.
The OpenBSD devs need to get a working implementation, that catches up on 15 years of refactoring and clarity in (optimistically) 2 months -- or risk the bulk of the world's sensitive information leaking yet again (perhaps even sooner, depending on what is discovered!)
It seems that with the kind of things they're finding, there are a lot lesser understood vulnerabilities in the code.
With the kind of standardization they're working on, a Windows port will be a LOT easier and a LOT simpler after they're finished. Best let them make haste, tear out everything that's leaky, unclear, or dangerous -- and with that will come a lot of simplification and fixes for the entire implementation.
Once it's clean, focus on a Ports. The code is too bloated to even consider ports right now. Quite frankly you might even be safer using Microsoft's SSL/TLS and other crypto implementation for the time being... (Only time will tell!)
More than one company I have worked at built on top of OpenSSL and went for FIPS compliance. Sometimes, if you want to be able to qualify for contracts that require things like FIPS, building off a base is better than starting from complete scratch.
Of course you can argue that they brought it upon themselves, but man would I love to watch a 60-minute documentary on how OpenSSL came to be, the people behind it, and how it went wrong.
Beside good verifiable coding practice to have a quality implementation, it seems that the issue is with the many side channels attack that needs to be obfuscated and make the whole thing a lot harder to maintain and verify.
So I'm guessing the issue is probably more about the very badly engineered protocols with blurry designs and too many bells and whistles rather than with the basic cryptographic building blocks?
"Of necessity, some crypto code will be a bit scary to look at. anything that has to do regular jobs, like building a pathname, in a security library, should be a thing of beauty, not something that makes you want to throw up in your mouth."
Take a look at the hand-optimized for speed immplementations in assembly sometime.
AES is defined on a 4x4 byte state, and every operation (even the sbox) is defined over GF(2^8). However, fast implementations resemble very little of that definition, and end up being a large number of xor and (large) table lookups. This is a much faster way to do it, on general-purpose machines, but it often leaves you open to cache-timing attacks.
So to come up with a fast and secure AES implementation you need to transpose the state in a way that resembles processing 8 blocks in parallel, and emulate hardware-level bitwise arithmetic on software. This is a so-called bitsliced implementation. By this point the code is much more complex and tricky than the original specification, and it will only actually be fast for parallel modes of operation such as CTR, leaving CBC hanging. Thankfully processors now implement AES round instructions, which simplifies secure implementations, but makes portable implementations difficult.
Cryptographers have learned from this state of affairs, though. New algorithms being created (like Keccak, aka SHA-3) now try harder to make the straightforward implementation secure and reasonably fast by default.
Public-key algorithms, on the other hand, are always tricky to implement, even if the arithmetic itself is not very complicated. One of the appeals of curve25519 (and other so-called "safe curves") is precisely that it is rather easy (but still not trivial) to implement them in a safe manner.
http://www.opensource.apple.com/source/OpenSSL098/OpenSSL098...
Note: it's Perl.
We need everything after the comma, sure, but there's no particular logical connection with the bit before your comma. A drop-in, API-compatible replacement (or at least one where the bits of the API thrown out are carefully chosen and generally unused) with OpenSSL that isn't scary and has been vetted is by far the fastest way to get to the second bit. This is probably the best thing that could have happened to OpenSSL, and I predict a decent chance this will be the dominant branch in under a year.
Also, I think that an OpenSSL cleanup is needed even if we get a new awesome library too. We can't drop OpenSSL overnight, and as you said it's bad. So this at least make it less bad, until there's something we can switch to.
"NaCl ships with constructions that were just prototypes, and that shouldn’t be used any more."
What does "shouldn't be used any more" mean? Certainly not security, or djb would have released an update. Compatibility with other products? Something else?
For authentication, there is CurveCP.
People seem confident with OpenSSH's authentication mechanism. Why not use that?
At some point one has to trust that the IP address one is sending/retrieving data to/from is the correct one. That's easier said than done if some host wants to keep changing its IP address every few days.
The SSL PKI scheme (the SSL approach to authentication), as implemented for public websites, is not much of a confidence-builder, IMO. Opinions may differ.
If websites maintained consistent IP addresses and we could authenticate these machines using OpenSSH keys, I would be more willing to believe we could verify their "authenticity".