Yeah, devs aren't meant to roll their own crypto (tm) but most open source libraries for doing crypto are dangerous (and lack clear guide lines for using them.) So then, what do you expect people to do? OpenSSL is hugely over complicated and hard to use. Having it as a dep almost certainly means breaking your software at some point, too. Libsodium is damn good but you still have to go out of your way to work with it if you're not using its baby-tier box design.
There are safe / standard ways to use certain primitives. But then there's no guarantee that such algorithms will be made available in the libraries that you're trying to use. E.g. lets say you want to use RSA (for x509 certs or something like that.) You'll get access to RSA but no algorithm to handle padding and no mention of it. So the dev uses RSA as-is and then gets a lecture for padding.
Point is: I don't see many "cryptography experts" putting effort into improving developer documentation resources for libraries. But plenty of them ranting and acting butthurt that developers aren't educated enough to use the primitives. The same crypto experts will also release these libraries and then cry that people use them. Lol, lmao even?
> I don't see many "cryptography experts" putting effort into improving developer documentation resources for libraries.
This isn't a "documentation resources for libraries" problem. It's a what libraries get bundled into the "crypto" module for your programming language problem, and that's largely a political decision rather than a technical one.
For example: Node's crypto module will always be a thin wrapper around OpenSSL, due to backwards compatibility. I cannot change that reality. There will always be a way to shoot yourself in the foot with Node.js's crypto module, and that is what most developers will reach for.
Even if I introduce new APIs for Node crypto and update the official docs to recommend the newer, safer ways of doing things, I won't be able to update the long tail of Stack Overflow answers with 10+ years of incumbency and hundreds of upvotes. This was tried years ago in the PHP community, and you still find bad PHP code everywhere.
Updating the developer documentation only serves to blame the poor user when they fuck up, so you can dismiss their pain with "RTFM".
> But plenty of them ranting and acting butthurt that developers aren't educated enough to use the primitives. The same crypto experts will also release these libraries and then cry that people use them.
I have never contributed a line of code to OpenSSL. You do not hear Eric A Young "ranting and acting butthurt". What empirical evidence do you have for this assertion?
Sure, even RSA can be used safely. This site's root certificate is still 4096-bit RSA, and that's probably OK (if we trust Let's Encrypt and our TLS implementations). If what your library exposed was a function called validate_x509_certificate_for_domain() that receives an X.509 certificate and a domain name and then validates it against your trusted root CAs then sure - you could write simple documentation on how to use it safely.
But if you want to use the general-purpose RSA functions, you're out of luck. The design of OpenSSL and Java's cryptography APIs is the stuff of nightmares, so let's take Go, which has a more modern RSA API[1]. Padding for encryption is not only mentioned, but mandatory (you either call rsa.EncryptPKCS1v15 or rsa.EncryptOAEP, you cannot use encrypt or decrypt RSA without padding if you really wanted to). The documentation would even nicely warn you not to use rsa.EncryptPKCS1v15 unless you need to maintain compatibility with a legacy protocol.
So can you just go ahead and use Go's "crypto/rsa" safely? No, of course not. RSA encryption (even with OAEP padding built-in) is such a low level operation that it would almost never be used alone. For instance, to encrypt a file with RSA, you will need to first encrypt an ephemeral random symmetric key, and then choose a symmetric algorithm and chaining mode. And in most cases, you also want to sign the envelope with your own public key.
So at the very least, if you want to build something like your own mini-PGP that is using legacy crap that can be somehow made safe just for the sake of sticking it to elitist cryptographers, you would need: A good RNG, RSA encryption (with OAEP), RSA signatures (with PSS), AES-CBC with PKCS#7 padding and SHA-256 (for the RSA signature). The documentation will have to mention all of that, and we still have only covered just a single use case: a toy mini-PGP. And let's not forget how to generate key. Go would always use e=65537, so we've got that covered, but you still need to know at least the recommended key size.
Unfortunately, unlike the baby-tier box design, our toy-tier mini-PGP doesn't have even perfect forward secrecy. So if we want to make it safe, and our requirements are to use prime number cryptography (because prime numbers are cool?) we'd have to add Diffie Hellman and that is it's own can of worms. But even with ecdh, we'd need to select a curve. Should the documentation should just tell the user to just select use ecdh.X25519, or should it go on explaining about Montgomery Ladder and Weierstrass scalar multiplication, invalid curve attacks and indistinguishability from uniform random strings[2]?
In the end of the day, we would end up with documentation the size of a couple of book chapters explaining how you could safely use a bunch of cryptographic primitives for one single thing (a toy mini-PGP). If we'd want to go further than that and explain how to safely implement something more complex, we'd end up with a couple of applied cryptography books. And if heavens forbid you'd want to implement a new protocol for secret messaging, we might have to include a few hundreds of research papers and perhaps a masters' degree program in cryptography.
And here we're back again to where we've been at the start. We've solved the issue by converting the random developer into an elitist cryptographer.
There are safe / standard ways to use certain primitives. But then there's no guarantee that such algorithms will be made available in the libraries that you're trying to use. E.g. lets say you want to use RSA (for x509 certs or something like that.) You'll get access to RSA but no algorithm to handle padding and no mention of it. So the dev uses RSA as-is and then gets a lecture for padding.
Point is: I don't see many "cryptography experts" putting effort into improving developer documentation resources for libraries. But plenty of them ranting and acting butthurt that developers aren't educated enough to use the primitives. The same crypto experts will also release these libraries and then cry that people use them. Lol, lmao even?