3

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?

1

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

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


So, there is obviously no way of using the new options with the OpenSSL 1.1.0, and I'm just gonna go ahead and do the backups in Cygwin utilizing the two new options until OpenSSL gets updated in my Linux Mint.

1

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

1

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

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.