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


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?


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy