15

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?

yasar
  • 261
  • 2
  • 5

1 Answers1

19

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.

Community
  • 1
forest
  • 64,616
  • 20
  • 206
  • 257
  • 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](https://github.com/tehmoon/cryptocli). – tehmoon Mar 26 '18 at 00: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 '18 at 01: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 '18 at 09:44
  • @forest, sorry I meant I was using `aes-gcm` :D – tehmoon Mar 26 '18 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 '18 at 15:00
  • MD5 is actually not much of a problem for key derivation. Funny enough, it's also the only thing that can be changed, leaving your with all the other issues :) – Maarten Bodewes May 19 '18 at 22:26
  • @MaartenBodewes MD5 is not a problem if the password is reasonably strong (which it should be, since even SHA-256 is terrible as a KDF), but it's not as good as a real KDF. The real problem is that the defaults change from version to version leading a file encrypted with one version to be incompatible with the next version unless `-md md5` is passed to it manually. – forest May 19 '18 at 22:30
  • Re edit: both key and IV are derived (by one iteration of hash) from pw _plus salt of random 64 bits_ by default, although there are options (not used in Q) to turn off salt or use a specified value (which might be duplicated or otherwise poor). With the default there's not much chance of duplication (and broken CTR) until maybe 2^22 instances. – dave_thompson_085 Jan 25 '19 at 05:18
  • @dave_thompson_085 That's true, but for raw encryption, `-nosalt` is usually necessary. But you're right, that's not an issue when a salt is used. – forest Jan 25 '19 at 05:20
  • If by raw you mean `-K(upper)` with key and not password, and `-iv` if applicable, that entirely ignores all salt-related options so they aren't ever necessary or even useful. – dave_thompson_085 Jan 27 '19 at 05:32