# Length of password requirement using openssl aes-256-cbc

I am using the following OpenSSL command to AES 256 encrypt a file:

openssl aes-256-cbc -salt -in secret-file -out secret-file.aes
Verifying - enter aes-256-cbc encryption password:


As far as I understand, the encryption password should be 32 characters/256 bits, but passing a single character a seems to work just fine.

What is happening behind the scenes here? Can you really pass any length encryption password? What are the trade offs?

• AUUUUUUGH don't use the openssl command-line tool for anything but toys! If you must use a password-based file encryption tool, use the scrypt(1) utility. Mar 26 '19 at 3:50
• @SqueamishOssifrage thanks, did not know about scrypt. I assume it uses a KDF as well, and you can provide any length passphrase? Mar 26 '19 at 4:03
• @Justin It uses a memory-hard KDF called scrypt (same name as the utility). You can provide a passphrase of virtually any length and it will convert it into a key that it will use for encryption. Mar 26 '19 at 4:10

When using a utility to encrypt data, you are not directly using the password you enter as the encryption key. Instead, the key is passed through a KDF, or Key Derivation Function, which converts it into the appropriate length. This allows you to use a password smaller or larger than the cipher's key size. In the case of OpenSSL, a single iteration of either MD5 or SHA-256 (depending on version) is used.

A very simple example of a KDF (although not one considered secure for these purposes) would be the SHA-256 function applied directly on the input. Your one-letter password is hashed into a 256-bit value which can then be used directly as the key. The same thing happens if your password is longer.

SHA-256("a") = ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb


Note that the OpenSSL command line utility is not secure, as it is designed for testing the library's functions. It is not to be used for general purpose encryption. The biggest issue is that the KDF it uses is not slow (it uses only one hash iteration, whereas a secure one like PBKDF2 can use tens of thousands or more), which makes brute force and dictionary attacks far more efficient. However, it has other problems such as the lack of integrity. You should use a tool designed specifically for secure encryption, such as GnuPG (which uses a secure KDF called S2K) with its symmetric encryption functionality.

• Thanks for the reply. Since I am also using a salt -salt, doesn't that mitigate brute force and dictionary attacks? Mar 26 '19 at 3:40
• @Justin No. A salt only protects from rainbow tables, not other forms of brute force. Mar 26 '19 at 3:40
• Specifically, a salt prevents an adversary from saving effort by simultaneously attacking multiple passwords. If each password is independently easy to guess, the salt cannot prevent that. Mar 26 '19 at 3:49
• @SqueamishOssifrage Indeed, and because OpenSSL uses only one hash iteration, brute force attacks can be done at the rate of many billions per second on a few GPUs. A good KDF like Argon2 prevents this (though the scrypt utility's scrypt and the GnuPG's utility's S2K are also adequate). Mar 26 '19 at 3:52
• @Justin: -salt has been the default (you don't need to specify it) since 0.9.8 in 2005. forest: FWIW 1.1.1 (2018-09) finally adds -pbkdf2 -iter N which you can set to something half reasonable, as long as you remember it since it isn't stored in the file. Still no integrity check. Mar 27 '19 at 2:32