> The enc program does not support authenticated encryption modes like CCM and GCM, and will not support such modes in the future.

> For bulk encryption of data, whether using authenticated encryption modes or other modes, cms(1) is recommended, as it provides a standard data format and performs the needed key/iv/nonce management.

So don't use `openssl enc` to encrypt data.

`openssl cms` that is recommended above is S/MIME. Don't use S/MIME.

I can't wait for Filippo Valsorda's `age` to be done so I would have an answer to the question of "what should I use to encrypt a file?".

https://github.com/openssl/openssl/commit/c03ca3dd090c6eb739...

Without that, Bob could potentially receive any pair of (key,file), which would just decrypt into garbage data.

BTW, variations on that sequence appear all over the internet when searching for "openssl encrypt file with public key"...

People generally imagine that "encrypt this block of data" is a simple primitive that does everything you want it to. But naive encryption doesn't work like that. In the worst case, where you use ECB for the block cipher [1], you end up with the ECB penguin: https://blog.filippo.io/the-ecb-penguin/. Your secure crypto becomes a pretty trivial Caesar cipher, just on a larger alphabet. Other modes (such as the CBC mode you used) aren't so bad, but if you have some hint of the structure of the underlying data, you can start perturbing the ciphertext to manipulate the encrypted data.

The modern solution to that problem is "authenticated encryption," which means that you add in an additional guarantee that the ciphertext hasn't been tampered with. Even then, there is still room for doing things incorrectly (padding is a real pain!).

[1] This is so bad it shouldn't ever be an option in any tool.

And yet it's effectively the default.