> Use a pre-existing cryptography package that has been written properly instead.
Okay, name one that has been written properly that the average web developer is going to encounter.
I'm going to focus on PHP because that's what I know best, it has an enormous market share, and I'm not a fan of blowing smoke (which I would be if I tried to speak to, e.g. Perl development).
PGP? OTR? Axolotl? These aren't part of your standard dev environment.
Mcrypt? Hasn't been touched since 2007. There is at least a patch for a bug in the 64-bit implementation of CAST-256 that has been sitting, unmerged, for six years.
Libsodium is the best we have, and you need PECL access to install it.
Maybe Python, Ruby, and Node developers have better options available to them. But 83% of the Internet runs PHP, and having a properly written cryptography package just isn't a trivial bar to leap over.
His point does bear consideration - the expert-written libraries are only expert-usable. You can still badly mess up encryption even if your basic building blocks are written perfectly. It's not just the algorithms that need to be expertly written, it's the way they're combined that also needs to be expertly written and the latter part doesn't exist. OpenSSL allows you to shoot yourself in the foot pretty easily, like choosing very weak ciphers, calculating the mac of the plaintext, etc.
OpenSSL is still too low-level for the generic developer. You want things like HTTPS, using which is still too complicated for most people (hello certificate management), but you can get it right more easily by following an online tutorial. Basically anything that is more complicated than "open socket to destination, here's my certificate" is doomed to be misused by non-experts. Oh, and it better have strong default settings so it won't pick RC4 as the cipher or something.
> you seem to be responding to an argument that wasn't made.
I seem to be, but I'm not.
> I think there's a more fundamental cryptographic principle. Don't implement cryptography, unless you are an absolute top expert. Even then, think twice, and get another absolute top cryptography expert to check your working. Use a pre-existing cryptography package that has been written properly instead.
This is written towards ALL developers. In the scope of web developers that I reside, this is my rebuttal.
Some crypto experts are quick to demand people use something that isn't necessarily available to the developer. Then the language elitists tell them to switch to their preferred language instead of improving what the developers already know. End result? People just use insecure or badly designed crypto libraries.
We need better libraries. Someone has to write them. Or just make libsodium the standard. I'd be okay with that.
Looks legit. My apologies. I was unsure of how they would even go about determining that, but after reading their methodology and limitations, it seems that is a somewhat representative number.
Okay, name one that has been written properly that the average web developer is going to encounter.
I'm going to focus on PHP because that's what I know best, it has an enormous market share, and I'm not a fan of blowing smoke (which I would be if I tried to speak to, e.g. Perl development).
PGP? OTR? Axolotl? These aren't part of your standard dev environment.
Mcrypt? Hasn't been touched since 2007. There is at least a patch for a bug in the 64-bit implementation of CAST-256 that has been sitting, unmerged, for six years.
Libsodium is the best we have, and you need PECL access to install it.
OpenSSL is labyrinthine. http://stackoverflow.com/a/29331937/2224584
It's still messy, despite the past year of attention from the security industry, but it's getting better.
This library offloads its underlying cryptography to OpenSSL because it's the best we got:
https://github.com/defuse/php-encryption/
Maybe Python, Ruby, and Node developers have better options available to them. But 83% of the Internet runs PHP, and having a properly written cryptography package just isn't a trivial bar to leap over.