Using RSA encryption with OpenSSL library: secure? I'm working on a small program (in C) that writes encrypted log files, but there are a lot of articles out there that say you should avoid RSA whenever possible. However, most of these articles also seem to refer specifically to home-cooked algorithms involving RSA, because in such cases inexperienced crypto-devs tend to pick insecure parameters.

In my case I'm simply using the OpenSSL library and its RSA_public_encrypt() function, along with OAEP padding. The plaintext is received over the network and never fed directly to the program, any error messages will be reported only to people having local access to the machine it's running on. The private key can be either 2048 or 4096 bits long and will be stored offline and far away from the public key. The key pair is generated outside of the application, but also through OpenSSL:

openssl genpkey -aes-256-cbc -algorithm RSA -out foo.key -pkeyopt rsa_keygen_bits:4096
openssl rsa -pubout -in foo.key -out bar.pub


Is this setup:


Considered cryptographically secure? I know you could still attach a debugger and just read the plaintext strings from memory, but in that case you have bigger problems anyways so it's not really relevant for this question.
Future-proof (i.e. do I need to migrate it over to something else sooner rather than later)?
New systems should not use RSA unless interoperability requires it. See for example this twitter thread for current zeitgeist: https://twitter.com/veorq/status/1148258833896263680

With RSA, the recommendation is to not even have a mode where data is encrypted using RSA directly, even if it fits. Always use hybrid encryption to not have two code paths. The symmetric encryption part should use a modern AEAD, and unless the performance difference between AESGCM (up to 5GB/s) and ChaPoly (up to 2GB/s) is important, use the ChaPoly since a random implementation of ChaPoly is more likely to be secure than a random implementation of AESGCM.

Instead of RSA-OAEP, I would use Curve25519 ECDH in ephemeral-static mode. Meaning you create a Curve25519 keypair, store the private safely offline and copy the public to the system that will encrypt.

Every time it needs to encrypt a file it generates a new Curve25519 keypair, writes the public into the beginning of the encrypted file, does ECDH between the private and the destination's public to get a shared secret, forgets the newly generated Curve25519 keypair, uses KDF over the DH shared secret, and uses the result of the KDF to generate key and nonces for the AEAD. If the cleartext is long, use chunks.

To decrypt, use the private key stored offline to do the ECDH with the ephemeral public, KDF, AEAD.

Oh wait, I'm describing libsodium. Use libsodium. It is the embodiment of 20 years of lessons learned in cryptography and misuse resistant crypto API design, it is production quality, it is portable, it is fast, etc.

If large quantum computers ever happen, both Curve25519 and RSA would be broken. Details about the future quantum computer are not available to judge whether using larger RSA would give you more safety margin (unless you use post quantum RSA, which is a joke).