A file encrypted with OpenSSL (with, for example, AES 256-bit mode CBC) using the Linux command

openssl enc -aes-256-cbc -in texte -out encrypted_texte -k password

has a salt in the first 16 bytes — with the bytes 8-15 being the salt itself. When the file is decrypted, if the salt is modified, OpenSSL will throw a

bad decrypt 140338977786624:error:0606506D:digital envelope routines:EVP_DecryptFinal_ex:wrong final block length:evp_enc.c:520:

error, while if the file was encrypted in mode CFB doesn't give you that error.

Why does this happen? What is different about CFB so that it does not produce an error when the salt is modified, compared to the other blockcipher modes of encryption which bluntly fail? Has it something to do with the padding (CBC and ECB do use padding)?

Here's an example of what I'm trying to do: With dd, just one byte is changed in the salt. When trying to decrypt, openssl with throw the error.

echo 'spam' > food.txt
openssl enc -aes-256-cbc -in food.txt -out food.enc -k IDONTLIKENOSPAM!
printf '?' | dd of=food.enc bs=1 seek=12 count=1 conv=notrunc &> /dev/null
openssl enc -d -aes-256-cbc -in food.enc -out food.bad -k IDONTLIKENOSPAM!
  • 2
    $\begingroup$ Chances are indeed that the padding is to blame, given that the last block will essentially decrypt to gibberish, you won't get the e.g. 03 03 03 sequences the padding mandates. $\endgroup$
    – SEJPM
    Sep 30, 2018 at 18:26

1 Answer 1


In your command:

openssl enc -aes-256-cbc -in texte -out encrypted_texte -k password

a password is supplied, which will be used to derive the key and IV for encryption. The salt stored in the file is used in conjunction with your password for this purpose. Therefore when you change the salt, you will get both a different IV and a different key in the decryption process, not just the IV. Then you will get problem decrypting in block modes such as CBC and ECB because the padding in the decrypted plaintext will not be correct (decrypted with a wrong key). While in stream modes like CFB, there is no padding, so modifying the salt won't cause a problem, but you will get wrong plaintext back.

Edit to add: the EVP_BytesToKey() function is used to turn the password and salt into the key and the IV.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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