Today I got this warning issued by OpenSSL in Cygwin after updating some packages, I believe openssl was included:

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

The OpenSSL version used in Cygwin was:

OpenSSL 1.1.1b  26 Feb 2019

This happened while decrypting my Backup on BluRay, which I created on Linux Mint 19.1, where the OpenSSL version is significantly older:

OpenSSL 1.1.0g  2 Nov 2017

The command used to encrypt and decrypt (just add -d to the end) was:

openssl enc -aes-256-cbc -md sha256 -salt -in "$InputFilePath" -out "$OutputFilePath"

What does this warning mean and can I do anything to avoid it in the future backups?

3 Answers 3


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 1000000 -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 a bit the faster variant of SHA-2 functions family compared to SHA-256 while it might be a bit more secure; win, win, but that likely changes with the new SHA instruction set in modern CPUs

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

  • -iter 1000000 is overriding the default count of iterations (which is 10000) 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.

The default value of iterations is not documented, but specified in apps/enc.c file like this:

case OPT_PBKDF2:
    pbkdf2 = 1;
    if (iter == 0)
        iter = 10000;

Decryption is issued simply by adding -d switch to the end of the original command-line.


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
  • 1
    The man page on openssl-enc leaves a lot to be desired about the new options. Is the -iter {count} required when you use -pbkdf2? What count does -pbkdf2 use if it is not provided. If it is 1, it makes the option on its own useless, if it is some fixed amount, then it will depreciate with time! Is that count variable? It should be randomised, and VERY large, in which case the count also needs to be added to the encrytped file format. I noticed the "Salted__" file magic does not change when you use it, so I assume a iteration count is not stored in the output file. It is a good addition!
    – anthony
    Commented Feb 6, 2020 at 6:21

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


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

You must log in to answer this question.

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