I tried to encrypt file using this command:

openssl enc -aes-256-cbc -in $infile -out $outfile -pass file:$keyfile

For the same input file, Why the output files has different hashes.


CBC requires an IV: the very first block of data should be random. It is sent with the data so that the recipient has what they need to decrypt the message. The IV for CBC should be uniformly random and unpredictable. The openssl enc command creates an IV with 8 fixed bytes and 8 random bytes (it should be 16 random bytes). When you encrypt the same message twice, the IV changes. (There's an option -nosalt to use a fixed IV, which is even worse for security and shouldn't be done unless the password was itself generated randomly for a single message.)

All non-broken modes of encryption have an IV or equivalent, so that encrypting the same message twice results in different ciphertexts. This is necessary, at least, so that an adversary cannot detect whether two encrypted messages have the same plaintext. Repeating the IV for distinct messages can open other attacks; for example, with CBC, a common prefix to two messages is visible in the ciphertext if the IV is reused. If you ever find that encrypting the same message twice leads to the same ciphertext, something is broken.

Don't use the openssl command for serious work. It's meant only as a showcase of the library functions, and it's badly designed even for that. As we've seen, the enc command doesn't quite do things securely since its IV isn't as random as it should. A worse problem is the way the key is derived from the password: openssl enc uses a single round of MD5, which is bad — deriving a key from a password should use an intrinsically slow function (a key stretching function) to slow down brute force cracking attempts where the attacker tries likely passwords (dictionary words, 1337 variations, etc.).

The primary user-level encryption tool is GPG, available in Ubuntu in the gnupg or gnupg package. To encrypt a file with a password, use

gpg -c filename

You'll get prompted for the passphrase. The encrypted file will be stored in filename.gpg. To decrypt, run gpg filename.gpg and enter the passphrase.

| improve this answer | |

(I think you accidentally added the -d decryption option in the command in your question.)

The encrypted files differ because of the random 64-bit cryptographic salt that OpenSSL generates and includes in each encrypted file by default. This can be disabled with the -nosalt option, but as the documentation in OpenSSL's man enc states, this is generally a very bad idea:

The -salt option should ALWAYS be used if the key is being derived from a password unless you want compatibility with previous versions of OpenSSL and SSLeay.

Without the -salt option it is possible to perform efficient dictionary attacks on the password and to attack stream cipher encrypted data. The reason for this is that without the salt the same password always generates the same encryption key. When the salt is being used the first eight bytes of the encrypted data are reserved for the salt: it is generated at random when encrypting a file and read from the encrypted file when it is decrypted.

| improve this answer | |
  • Also, the IV is derived from the password. It would then be a problem if you reuse the password for more than a single ciphertexts (never repeat key with same IV!). This also applies to specifying the raw key; then always provide OpenSSL with a random IV. This will render your ciphertext random for the same combination of key and plaintext, but that's part of the security in AES encryption. – gertvdijk Jul 12 '15 at 9:17
  • @gertvdijk No, the IV isn't derived from the password. OpenSSL is broken but not that broken. – Gilles 'SO- stop being evil' Jul 13 '15 at 2:04
  • @Gilles My OpenSSL enc manpage tells me so. "When a password is being specified using one of the other options, the IV is generated from this password." – gertvdijk Jul 13 '15 at 8:01
  • @gertvdijk Fortunately this seems to be a bug in the documentation. If the IV was generated from the password, it would be deterministic and this question wouldn't have been asked. – Gilles 'SO- stop being evil' Jul 13 '15 at 9:25

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.