OpenSSL 1.1.1b warning: Using -iter or -pbkdf2 would be better while decrypting a file encrypted using OpenSSL 1.1.0g

Comparing the Synopsys of the two main and recent versions of OpenSSL, let me quote the man pages.

OpenSSL 1.1.0

openssl enc -ciphername [-help] [-ciphers] [-in filename] [-out filename] [-pass arg] [-e] [-d] [-a/-base64] [-A] [-k password] [-kfile filename] [-K key] [-iv IV] [-S salt] [-salt] [-nosalt] [-z] [-md digest] [-p] [-P] [-bufsize number] [-nopad] [-debug] [-none] [-engine id]

OpenSSL 1.1.1

openssl enc -cipher [-help] [-ciphers] [-in filename] [-out filename] [-pass arg] [-e] [-d] [-a] [-base64] [-A] [-k password] [-kfile filename] [-K key] [-iv IV] [-S salt] [-salt] [-nosalt] [-z] [-md digest] [-iter count] [-pbkdf2] [-p] [-P] [-bufsize number] [-nopad] [-debug] [-none] [-rand file...] [-writerand file] [-engine id]

---

There obviously are some greater differences, namely considering this question, there are these two switches missing in the 1.1.0:

• pbkdf2

• iter

---

You have basically two options now. Either ignore the warning or adjust your encryption command to something like:

openssl enc -aes-256-cbc -md sha512 -pbkdf2 -iter 100000 -salt -in InputFilePath -out OutputFilePath

Where these switches:

• -aes-256-cbc is what you should use for maximum protection or the 128-bit version, the 3DES (Triple DES) got abandoned some time ago, see Triple DES has been deprecated by NIST in 2017, while AES gets accelerated by all modern CPUs by a lot; you can simply verify if your CPU has the AES-NI instruction set for example using grep aes /proc/cpuinfo; win, win

• -md sha512 is the faster variant of SHA-2 functions family compared to SHA-256 while it might be a bit more secure; win, win

• -pbkdf2: use PBKDF2 (Password-Based Key Derivation Function 2) algorithm

• -iter 100000 is overriding the default count of iterations for the password, quoting the man page:

  Use a given number of iterations on the password in deriving the encryption key. High values increase the time required to brute-force the resulting file. This option enables the use of PBKDF2 algorithm to derive the key.

It sounds like OpenSSL is finally, after at least 6 years, acknowledging that the enc command has some rather serious flaws (their own man page calls them "bugs"). Maybe they're being fixed now, but if your data is at all important, why not use a (relatively) much more secure tool like GnuPG instead? You don't necessarily need to use public key encryption either, gpg does conventional (password/keyfile only) encryption as well.

Here's an excerpt from my other answer highlighting the basics:

OpenSSL should be able to do all the same things that gpg does, (OpenSSL has been around since 1998, but if version numbers mean anything it reached version 1 in 2010) but it's very easy to make a mistake that could drastically lower the security. And from this post on security.stackexchange.com (from Jan 2013) and another by a 287K reputation user, the openssl enc command might leave something to be desired:

The encryption format used by OpenSSL is non-standard: it is "what OpenSSL does", and if all versions of OpenSSL tend to agree with each other, there is still no reference document which describes this format except OpenSSL source code. The header format is rather simple:

magic value (8 bytes): the bytes 53 61 6c 74 65 64 5f 5f
salt value (8 bytes)

Hence a fixed 16-byte header, beginning with the ASCII encoding of the string "Salted__", followed by the salt itself. That's all ! 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).

man enc even had this under "BUGS":

There should be an option to allow an iteration count to be included.

One of the comments to the first post even mentions these problems have been around for almost 10 years...

This iteration count problem is a real hassle. So much so almost 10 years ago I made a "encrypt" perl script that does essentially the same thing as "openssl enc" but uses Iterative PBKDF2 hashing. ict.griffith.edu.au/anthony/software#encrypt It will decrypt salted "openssl enc" files but re-encrypts using PBKDF2 instead. I would have though OpenSSL file encryption would have improved by now! – anthony Feb 7 at 5:05

Here is an example for symmetric encryption with gpg.
In short:

gpg --symmetric --cipher-algo AES256 --output file.gpg file.txt

and

gpg --decrypt --output file.txt file.gpg

Recently I have installed the latest version of cygwin. "openssl" started to give a warning:

*** WARNING : deprecated key derivation used.
Using -iter or -pbkdf2 would be better.

So now I use the following for encrypting:

openssl aes-256-cbc -salt -pbkdf2 -in name -out name.aes

and the following for decrypting:

openssl aes-256-cbc -d -salt -pbkdf2 -in name.aes -out name