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.
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.
[1] https://pkg.go.dev/crypto/rsa#pkg-index
[2] https://safecurves.cr.yp.to/ind.html