What's the best option for encrypting a file with openssl and a password?

Question

I'm using a command to encrypt and decrypt files based on a password:

openssl aes-256-cbc -a -salt -in secrets.txt -out secrets.txt.enc --pass pass:mypassword

and

openssl aes-256-cbc -d -a -in secrets.txt.enc -out secrets.txt.new -pass pass:mypassword

Someone had mentioned that this may be susceptible to brute force attacks (to try and decrypt the file via a password).

Is there a safer/better way to encrypt a file with a password than this? a -pbkdf2 option was also mentioned, but I can't seem to find much on it.

I was under the impression that AES-256 with salt was a really good option to choose for password encrypting a file.

If the password is long and very complex, would that also help the situation?

Answer 1

The best option? Don't use openssl, use gpg instead

Apparently your command uses the enc command (even though openssl's man page doesn't even mention aes-256-cbc at all, and openssl help outputs to stderr so simply piping it to less is a chore, also FYI it has an undocumented -v feature) and it leave a lot to be desired, see my other answer for more details, but they're basically:

• Non-standard encryption format.
• No indication of the encryption algorithm; you are supposed to keep track of that yourself.

• The process by which the password and salt are turned into the key and IV is not documented, but a look at the source code shows that it calls the OpenSSL-specific EVP_BytesToKey() function, which uses a custom key derivation function with some repeated hashing. This is a non-standard and not-well vetted construct (!) which relies on the MD5 hash function of dubious reputation (!!); that function can be changed on the command-line with the undocumented -md flag (!!!); the "iteration count" is set by the enc command to 1 and cannot be changed (!!!!). This means that the first 16 bytes of the key will be equal to MD5(password||salt), and that's it.

  This is quite weak ! Anybody who knows how to write code on a PC can try to crack such a scheme and will be able to "try" several dozens of millions of potential passwords per second (hundreds of millions will be achievable with a GPU). If you use "openssl enc", make sure your password has very high entropy ! (i.e. higher than usually recommended; aim for 80 bits, at least). Or, preferably, don't use it at all; instead, go for something more robust (GnuPG, when doing symmetric encryption for a password, uses a stronger KDF with many iterations of the underlying hash function).

GPG has decades of secure tested use, all the simple mistakes have been avoided/fixed, and could stump a major world superpower if used correctly.