16

I have around 20000 files (around 9GB) each of which is encrypted using openssl enc -aes-256-cbc -in infile -out outfile -k mypassword command. Each file uses same password. My openssl version is 1.1.0e.

Will I be vulnerable to any known attacks if I back these file up on offsite location? If not, what are my alternatives?

Improve this question
2

1 Answer 1

Reset to default
21

You should never use OpenSSL's command line utility for general purpose encryption. It is actually designed only as a test of the library's internal encryption routines. Because of this, there are a few problems inherent in using it when real confidentiality and integrity are needed:

  • You will be vulnerable to malleability attacks, as CBC mode is unauthenticated. This can allow your files to be modified in certain predictable ways without knowing the encryption key.
  • No integrity checking means decryption with the wrong key can succeed, despite outputting corrupted gibberish. Utilities designed for file encryption will tell you if the key is wrong.
  • The default hash used to derive the master key is MD5, which is far from ideal. It is possible to change the hash, for example with -md sha512, but it still will not use key stretching.
  • New versions may not be able to decrypt previously encrypted files by default. When the default hash value was changed from MD5 to SHA-512, it required an explicit -md md5 to work again.
  • Both the key and IV are derived from your input password. Using the same password to encrypt multiple files will result in IV re-use. This is bad for CBC mode, and fatal for CTR mode.
  • It is not well tested. For many versions of OpenSSL, enc using GCM mode encryption worked, but decryption did not. This might even still be the case.

This is not unique to the enc command. The OpenSSL command line utility has other gotchas when one attempts to use it for anything other than testing the library. Another example is the s_client command, used for connecting to a server over SSL or TLS, which does not validate the certificate of the target. Overall, you should not use the OpenSSL utility. Just use GnuPG:

The only time I would ever use OpenSSL directly is if I needed to encrypt something with a completely random key or a specific raw key and IV and did not care about message integrity. For example, writing a pseudorandom stream seeded by the kernel to stdout can be done with:

openssl aes-128-ctr -nosalt -k $(xxd -l16 -c16 -ps /dev/urandom) -in /dev/zero

Likewise, decrypting a blob of plain encrypted data when you know both the raw key and the raw IV in hexadecimal (bypassing the need for -md for key derivation) could be done with:

openssl aes-128-cbc -d -nosalt -K $hex_key -iv $hex_iv -in infile -out outfile

But for general-purpose file encryption? Just use GnuPG.

Improve this answer
10
  • I was going to answer but you actually wrote everything in a better and comprehensive way. Let's not forget that openssl cli is not an encryption tool per se but it is mostly for ssl/tls. That's also why nobody should rely on the key stretching to encrypt files. I would suggest to rely on scrypt/pbkdf2. I also would agree on gnupg but it leads to bad pattern regarding cbc mode streaming un-authenticated they might have. I wrote a tool that might help people better encrypt in a streaming fashion way with aes-cbc.
    – tehmoon
    Mar 26, 2018 at 0:05
  • @tehmoon Well that's what the integrity protection measures described in sections 5.13 and 5.14 of the RFC are for. Also, scrypt and pbkdf2 are both key stretching algorithms. For your own tool though, it might be more wise to use GCM (or even Poly1305) rather than CBC, even with an HMAC.
    – forest
    Mar 26, 2018 at 1:02
  • 1
    OpenSSL 1.1.0 (which OP is using) changed the default hash for password-based enc to SHA256. But it's still only one iteration, so it's not really better (except for people doing FIPS or checklists) just incompatible. The versions with the enc-tries-AEAD-without-tag bug were 1.0.1 initial through g in '12 through '14 (plus betas).
    – dave_thompson_085
    Mar 26, 2018 at 9:44
  • @forest, sorry I meant I was using aes-gcm :D
    – tehmoon
    Mar 26, 2018 at 11:48
  • Decryption of AES-GCM requires validation of the auth tag, the problem with enc is that it is a streaming tool that outputs ciphertext before it is even validated. OpenSSL recommends to use the openssl cms interface instead for GCM mode, but its interface is horrible.
    – Lekensteyn
    Mar 26, 2018 at 15:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .