To use crypto right requires knowledge of crypto systems. You're not going to know how to use crypto schemes correctly without knowing about common flaws and a range of side channel attacks. The crypto code itself is usually relatively easy to use (OpenSSL may have a clunky interface, but there are tons of examples out there). The problem here, and I'd argue actually in most cases, isn't that the libraries don't exist or are hard to use. The problem is that the people using said libraries don't know what they're doing.
There are great books out there that will tell you everything you need to know to understand and write safe crypto code. It's not some kind of closely guarded secret kept by an exclusive elite, it just requires reading. Pirate the books if you want to stop information hoarding among the rich, it's trivially easy to do with libgen.
You can roll your own crypto if you're capable of doing so, and have someone as competent as you check your work.
Some of these flaws aren't that bad (== vs === shouldn't matter too much in this case, though it's a sign of bad PHP code when the types are supposed to be well known). Others are either bad code practice (allowing a variable to be uninitialized) or well-known cryptographic mistakes that you'll learn to catch after reading a book or two (timing attack, shared keys). I won't pretend I would've spotted all of those at a glance, but I can admit that my crypto course has been too long ago for me to write or review such code.
I've got a basic grasp of electrical cirtuits but that doesn't mean I should be allowed to design highly secure electronic security circuits. I will miss important problems and dangerous flaws because I lack in-depth knowledge and experience. It's not because there's not an easy 1-2-3 guide on how to design safe circuits or because a cabal of academic elites are keeping this knowledge to themselves and pretending to do so just shifts the blame for my lack of effort to others.
Feel free to do your own crypto. Tons of companies do. You'd better put in the work to make sure you're doing it right, though! If you're working on some kind of new cryptographic structure and an academic writes up a theoretical attack in a paper somewhere, you're doing it right, assuming that you extend your scheme to solve the problems discovered. If you make textbook mistakes in important code, you're clearly doing it wrong.
If you're interested in learning cryptography so you can try to roll your own, I recommend starting with books like these:
- Cryptography Made Simple by Nigel Smart
- Applied Cryptography by Bruce Schneier
- Cryptography Engineering: design principles and practical applications by Neil Ferguson, Bruce Schneier, and Tadayoshi Kohno
These books require some prerequisite mathematical knowledge (like all crypto does) which you can probably pick up on Khan Academy. They go in depth into how common cryptography works, why these schemes are secure and how they can be broken (in theory and in practice). Some of them are getting old, though, so you may need to find some newer material if you're doing stuff like modern elliptic curve or post-quantum cryptography.
> The problem is that the people using said libraries don't know what they're doing.
I would like to suggest that the problem is that the skilled people that understand how to write crypto systems are providing libraries that are easy to misuse. Instead of providing a library that is likely to be used incorrectly without a lot of specialized knowledge, provide infrastructure that manages the crypto so the average developer doesn't need to become an expert on crypto systems.
HTTPS is a useful example. Instead of providing webapp authors a library of cypher/hash functions and warning that they shouldn't roll their own transport layer security and then acting shocked when those authors try to use that library and make a lot of mistakes, we instead separate the crypto step into a separate layer of infrastructure so the average webapp author can easily use crypto without having to learn a lot of specialized knowledge. Someone writing a Ruby on Rails app shouldn't have to write functions like pervade_encrypt($data)/pervade_decrypt($data) to move out of the plaintext world of HTTP and utilize encrypted transport. They only need to buy/LetsEncrypt a cert they can install in their webserver. They can even delegate that to their hosting provider.
"If it's possible for a human to hit the wrong button and [cause a catastrophic failure] by accident [or inexperience], then maybe the problem isn't with the human - it's with that button. [...] People make mistakes, and all of our systems need to be designed to be ready for that."
> I would like to suggest that the problem is that the skilled people that understand how to write crypto systems are providing libraries that are easy to misuse. Instead of providing a library that is likely to be used incorrectly without a lot of specialized knowledge, provide infrastructure that manages the crypto so the average developer doesn't need to become an expert on crypto systems.
I agree, but for the encryption basics, those libraries are available. Higher level languages like Python/Ruby/etc. all have libraries that do TLS transparently. Lower level languages have libraries like BoringSSL/GnuTLS/OpenSSL/(Windows|macOS) APIs available which are relatively straight forward; you need to do error handling yourself so there's a whole bunch of API calls, but that's because an application needs to deal with errors and thrown exceptions aren't always available/desirable.
In the example, the code authors wanted to encrypt a file and then sign it using their own algorithm. There are open source utilities for this, of course, but they chose to implement it their own way. They didn't build a bad implementation of AES, they didn't write a bad hashing algorithm, they didn't mess up RSA.
They could've done this perfectly safely by switching the order around, adding a second key, and picking a better file format, they were very close! They could've prevented all these problems by just using GCM instead of CBC+HMAC inside their own format.
Personally, I would've used GPG and skip the custom implementation all together. This is a software product that exposes an endpoint that will execute the command in a GET query, so why not use a bit of exec() to do all the weird crypto for you.
> HTTPS is a useful example. Instead of providing webapp authors a library of cypher/hash functions and warning that they shouldn't roll their own transport layer security and then acting shocked when those authors try to use that library and make a lot of mistakes, we instead separate the crypto step into a separate layer of infrastructure so the average webapp author can easily use crypto without having to learn a lot of specialized knowledge. Someone writing a Ruby on Rails app shouldn't have to write functions like pervade_encrypt($data)/pervade_decrypt($data) to move out of the plaintext world of HTTP and utilize encrypted transport. They only need to buy/LetsEncrypt a cert they can install in their webserver. They can even delegate that to their hosting provider.
For TLS you still need to configure a proxy. You need to make sure not to paste the private key in the cert field or every browser will receive your private key; you need to have _some_ crypto knowledge and this is the easiest process you can probably think of. You also need to check your auth/blacklisting/security code to accept the proxy and make sure you use the right headers for checking the remote user IP against blacklists etc. Enabling TLS is easy, but it's still not a transparent process, simply because it's not an easy task.
There are great books out there that will tell you everything you need to know to understand and write safe crypto code. It's not some kind of closely guarded secret kept by an exclusive elite, it just requires reading. Pirate the books if you want to stop information hoarding among the rich, it's trivially easy to do with libgen.
You can roll your own crypto if you're capable of doing so, and have someone as competent as you check your work.
In this case, this tweet has listed the flaws that the custom crypto implementation has: https://mobile.twitter.com/gsuberland/status/153811763597137...
Some of these flaws aren't that bad (== vs === shouldn't matter too much in this case, though it's a sign of bad PHP code when the types are supposed to be well known). Others are either bad code practice (allowing a variable to be uninitialized) or well-known cryptographic mistakes that you'll learn to catch after reading a book or two (timing attack, shared keys). I won't pretend I would've spotted all of those at a glance, but I can admit that my crypto course has been too long ago for me to write or review such code.
I've got a basic grasp of electrical cirtuits but that doesn't mean I should be allowed to design highly secure electronic security circuits. I will miss important problems and dangerous flaws because I lack in-depth knowledge and experience. It's not because there's not an easy 1-2-3 guide on how to design safe circuits or because a cabal of academic elites are keeping this knowledge to themselves and pretending to do so just shifts the blame for my lack of effort to others.
Feel free to do your own crypto. Tons of companies do. You'd better put in the work to make sure you're doing it right, though! If you're working on some kind of new cryptographic structure and an academic writes up a theoretical attack in a paper somewhere, you're doing it right, assuming that you extend your scheme to solve the problems discovered. If you make textbook mistakes in important code, you're clearly doing it wrong.
If you're interested in learning cryptography so you can try to roll your own, I recommend starting with books like these:
- Cryptography Made Simple by Nigel Smart
- Applied Cryptography by Bruce Schneier
- Cryptography Engineering: design principles and practical applications by Neil Ferguson, Bruce Schneier, and Tadayoshi Kohno
These books require some prerequisite mathematical knowledge (like all crypto does) which you can probably pick up on Khan Academy. They go in depth into how common cryptography works, why these schemes are secure and how they can be broken (in theory and in practice). Some of them are getting old, though, so you may need to find some newer material if you're doing stuff like modern elliptic curve or post-quantum cryptography.