I'm in a beginner's cryptography class and I'm trying to figure out if I'm doing something wrong, or if I just don't understand why something is the way it is.

I created a simple .txt file of 124 bytes and encrypted it with AES-CBC three times: twice with the same IV of '135797531', and once with a different IV of '246808642'. I also used the same password for all of them. Then I opened all the encrypted files in a hex editor to analyze the contents, and I saw that--aside from the header bytes--the code of each one was completely different. Even the ones that used the same IV. I was under the impression that if I use the same IV and password to encrypt a file twice, then they would both result in the same code, and that explains why an IV should be different each time. But with what I have, it's looking like it shouldn't really matter even though I know that's not the case. Did I do something wrong, or is there another explanation?

Edit: Code that was used-

openssl enc -aes-128-cbc -e -in text1.txt -out text2.txt -k '0123456789' -iv '135797531'

1 Answer 1


The properties of CBC mode are only specific to when you are actually using a key and IV as specified for AES-CBC. That means, using a 128, 192 or 256 bit key - commonly specified as 16, 24 or 32 bytes - and a 128 bit key - as 16 bytes. Many tools allow other parameters such as passwords instead. Some tools, especially online tools, forget to mention that they allow different parameters than a direct key and IV, because they have been written by utter tools.

If you're using a password instead of a key it is likely that a password based key derivation method is used to derive the key. These PBKDF's commonly use a random salt and likely an work factor or iteration count. Because the salt differs each time, the derived key will differ each time as well. So in that case it doesn't matter that your IV is the same twice.

Similarly, if you specify an IV of less than 16 bytes it is likely that memory beyond the IV is used and that the result differs. However, in that case you would not be able to decrypt the first block correctly.

OpenSSL command line - by default - uses it's own PBKDF called EVP_BytesToKey using an (insecure) single iteration and an 8 byte salt. You can see this if you look at the header, as the first bytes spell Salted__ followed by an 8 byte salt (which is indistinguishable from the rest of the ciphertext).

If you want to use CBC as it is specified, you have to use the (uppercase) -K and (lowercase) -iv option and use 32, 48 or 64 hexadecimal digits for the key and 32 hexadecimal digits for the IV. These are hexadecimal representations of the binary key and IV - they are decoded by openssl to bytes before they are used.

So try something like:

openssl enc -aes-128-cbc -e -in text1.txt -out text2.txt -K '000102030405060708090A0B0C0D0E0F' -iv '000102030405060708090A0B0C0D0E0F'

instead. With whatever keys and IV's you want to try, of course.

  • 1
    $\begingroup$ Welcome to cryptography, let me know if you had success using above line (if not, check if Salted__ is still there, you may need to have to specify -nosalt although I don't see why that would be needed). $\endgroup$
    – Maarten Bodewes
    Feb 9, 2020 at 5:15
  • $\begingroup$ Ahh yes changing it to -K did the trick. I honestly didn't think it was a case of the wrong option because in the lab manual for my class, the example my professor provided kept using -k instead of -K. He even put in the little glossary section that -k was the key. Thank you very much! $\endgroup$ Feb 9, 2020 at 5:21
  • 1
    $\begingroup$ -K, glad that worked out. I'm always happy to correct professors. $\endgroup$
    – Maarten Bodewes
    Feb 9, 2020 at 5:25
  • $\begingroup$ Small -k is used for the passphrase and -K is the raw key, in hex. $\endgroup$
    – kelalaka
    Feb 9, 2020 at 16:47
  • $\begingroup$ To add a little, you WANT the generated key to be different even with the same password, otherwise you open yourself up to attacks. $\endgroup$ Feb 12, 2020 at 17:35

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.