Hacker News new | past | comments | ask | show | jobs | submit login

Is it wrong to use openssl to encrypt files?

0. (Only once) generate key pair id_rsa.pub.pem, id_rsa.pem

1. Generate random key

  openssl rand -base64 32 > key.bin
2. Encrypt key

  openssl rsautl -encrypt -inkey id_rsa.pub.pem -pubin -in key.bin -out key.bin.enc
3. Encrypt file using key

  openssl enc -aes-256-cbc -salt -in SECRET_FILE -out SECRET_FILE.enc -pass file:./key.bin
-- other side --

4. Decrypt key

  openssl rsautl -decrypt -inkey id_rsa.pem -in key.bin.enc -out key.bin 
5. Decrypt file

  openssl enc -d -aes-256-cbc -in SECRET_FILE.enc -out SECRET_FILE -pass file:./key.bin

from https://www.openssl.org/docs/man1.1.1/man1/openssl-enc.html

> 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?".

`enc` doesn't support and will never support _any_ authenticated ciphers. Consider it a red flag when you see it in the future.


To start with, none of that encryption is authenticated.

So if I understand you correctly (Noob here), Alice would need to sign the pair (key.enc, file.enc) to authenticate that those files originated from her.

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"...

This is one of the problems with cryptography: with a little knowledge, you can end up making yourself completely insecure while believing yourself to be very secure.

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.

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

And yet it's effectively the default.

No, the problem is that the AES encryption step uses bare AES-CBC. An attacker can flip bits in the ciphertext to make targeted changes to the plaintext. What you want is an authenticated encryption mode, but I don't know that the OpenSSL cli supports any of them.

Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact