# Text partially decrypted regardless of IV

I'm trying to work out which AES cipher is best to use. I'm working with the OpenSSL ruby gem.

While testing the various options I noticed that most of the ciphers result in partial or even full decryption regardless of the IV value.

I'm just wondering if this is something I should be concerned about, or even if it is a bug that the gem maintainers should be aware of.

Eg: CBC, CFB8, CFB1, CFB, CBC-HMAC-SHA256, and CBC-HMAC-SHA1, only the first 16 bytes remain encrypted.

Eg: ECB allows full decryption regardless of IV

This is the ruby code I've used for testing.

ciphers = [
'AES-256-CBC', 'AES-256-CTR', 'AES-256-XTS',
'AES-256-OFB', 'AES-256-OCB', 'AES-256-ECB',
'AES-256-CFB8', 'AES-256-CFB1', 'AES-256-CFB',
'AES-256-CBC-HMAC-SHA256', 'AES-256-CBC-HMAC-SHA1',
]

def encrypt(plain_text, pwd, salt, cipher_name)
cipher = OpenSSL::Cipher.new(cipher_name)
cipher.encrypt
cipher.random_iv # purposefully set to random
cipher.key = OpenSSL::PKCS5.pbkdf2_hmac(pwd, salt, 20000, cipher.key_len, OpenSSL::Digest::SHA256.new)
encrypted = cipher.update(plain_text)
encrypted << cipher.final
end

def decrypt(encrypted, pwd, salt, cipher_name)
cipher = OpenSSL::Cipher.new(cipher_name)
cipher.decrypt
cipher.random_iv # purposefully set to random
cipher.key = OpenSSL::PKCS5.pbkdf2_hmac(pwd, salt, 20000, cipher.key_len, OpenSSL::Digest::SHA256.new)
decrypted = cipher.update(encrypted)
decrypted << cipher.final
end

ciphers.each do |cipher_name|
pwd = 'some hopefully not to easily guessable password'
salt = OpenSSL::Random.random_bytes(16)
plain_text = "Spicy jalapeno tail ribeye dolore ut. Pork belly ut porchetta culpa aliquip brisket shank est. Pastrami ribeye porchetta cow qui."
begin
puts
puts '== %s ==' % cipher_name
encrypted = encrypt(plain_text, pwd, salt, cipher_name)
puts decrypt(encrypted, pwd, salt, cipher_name)
rescue => e
puts e.message
end
end


For those without ruby, this is the output of the above code:

== AES-256-CBC ==
��l�~��u@�=o� ail ribeye dolore ut. Pork belly ut porchetta culpa aliquip brisket shank est. Pastrami ribeye porchetta cow qui.

== AES-256-CTR ==
/&  q]$���{�YhwH�X*�N���.p�E�̕;�� 3|t�L v�'�﬉�T�KCأ���y�X���ՎR/��]dL�WI�"�?P���Ǖ�B|E�u5������Zq����LϠ�4 == AES-256-XTS == ^��:ok @6�4^O�cNJ��'� C/ ���V�(�)k5��)��S ^�3���4�r��A���q�=����p�^�d3;� �.U˕|k�U/�ʝ��y��qd�/���7HΒ����l�e == AES-256-OFB == iH�"�=�tL�eG��Z~o ��moӦQ!��<z��vր2}�#6� ���%�oM��XI#y�t���($���"~

== AES-256-OCB ==

== AES-256-ECB ==
Spicy jalapeno tail ribeye dolore ut. Pork belly ut porchetta culpa aliquip brisket shank est. Pastrami ribeye porchetta cow qui.

== AES-256-CFB8 ==
�xYa���ShR�
ail ribeye dolore ut. Pork belly ut porchetta culpa aliquip brisket shank est. Pastrami ribeye porchetta cow qui.

== AES-256-CFB1 ==
+��g~ᲆ$e� ��ail ribeye dolore ut. Pork belly ut porchetta culpa aliquip brisket shank est. Pastrami ribeye porchetta cow qui. == AES-256-CFB == ���=�?)�2�96�2�ail ribeye dolore ut. Pork belly ut porchetta culpa aliquip brisket shank est. Pastrami ribeye porchetta cow qui. == AES-256-CBC-HMAC-SHA256 == _?��?���p��}ail ribeye dolore ut. Pork belly ut porchetta culpa aliquip brisket shank est. Pastrami ribeye porchetta cow qui. == AES-256-CBC-HMAC-SHA1 == [˲��H"��.qv�ail ribeye dolore ut. Pork belly ut porchetta culpa aliquip brisket shank est. Pastrami ribeye porchetta cow qui.  • These are not AES "ciphers" but "modes of operation". ECB doesn't use IV. It's less secure, but allows encrypting several blocks at the same time in parallel. Please read more here en.wikipedia.org/wiki/Block_cipher_mode_of_operation Mar 26 '18 at 9:24 ## 4 Answers You are actually not talking about "ciphers" but about "modes of operations". ECB mode does not use the IV so its value is ignored when using that mode. It's a great example of reason why do we even use modes of operation. (ECB is the fastest mode of operation, but it's the least secure one) This is an .bmp image encrypted using ECB. (and then converted to .jpeg) As you can see you can easily deduce what was on the original. Using a different mode of operation (CBC) it's usually much harder. Now the image is indistinguishable from noise, but there is still some info that can leak. If someone encrypts the same image twice the ciphertext will be identical in both cases. And this i the reason for random IV. Even if the image is identical, the different IV will cause the ciphertext to be completely different. This is useful for example when encrypting passwords. Two identical passwords should not be stored as two identical ciphertexts. In conclusion the IV is not made for preventing decryption of the ciphertext. That's the job of the key. Random IV is used to prevent leaking of "metadata" when adversary can see only raw ciphertexts. In most of the modes of operation (like CBC) the "current" block is obscured by connecting it somehow (usually by XOR) with previous blocks ciphertext. This leaves the first block which has no predecessor with no obfuscation. This is where the IV comes into play. We add a fake "previous block" into the ciphertext. (IV is usually prepended to ciphertext and is immediately visible to adversary) When deciphering we actually use the IV only for that first block. To decipher any other block all you need is the key and previous ciphertext (which is also visible to the adversary) When no IV is provided then the first block is getting decrypted into$Plaintext \oplus IV, and since this block is usually predictable (like first characters of file header) this usually allows pretty easily to guess the IV. • 1. The first block is generally not usually predictable and the IV does not need to be secret. It is rather standard practice to prefix encrypted data with the IV so it is easily available for use during decryption. 2. The IV should be a random value so that two messages with identical content with the same placement will not have the same encrypted data thus leaking information. – zaph Mar 26 '18 at 13:23 • @zaph I did not write that IV needs to be a secret. The first blocks in many cases are predictable. (File headers, opening XML tags, word "Hello", etc.) I also mentioned about IV being random to prevent metadata leakage. Mar 26 '18 at 13:32 ECB mode is not secure for general purpose encryption due to various weaknesses. It does not take an IV, so a well designed library would reject an encryption attempt where you pass an IV. As you observed, CBC and CFB mode can decrypt most of the ciphertext without IV. This is perfectly fine, since the purpose of an IV isn't being a secondary key that prevents decryption, it's ensuring that when you encrypt the same message (or similar messages) twice, you get completely different ciphertext, so an attacker doesn't learn that your messages were identical. Note however that these modes are only secure against passive attackers. CBC-HMAC-SHA256 and CBC-HMAC-SHA1 on the other hand are authenticated encryption. A modified ciphertext (or modified IV) should be rejected without releasing any attacker influenced plaintext to the application. A decryption function which fails to authenticate the IV is severely flawed in my opinion. It's important to note that we're not talking about decryption without IV being impossible, but about the decryption function deliberately rejecting such a manipulated message. • Some clarification is needed. It is incorrect to state that "a well designed library would reject an encryption attempt where you pass an IV", IVs are often passed as a prefix to encrypted data and this is acceptable. IVs do not need to be secret, they should be random data. – zaph Mar 26 '18 at 13:28 • @zaph That sentence is in the context of ECB mode, which does not have an IV parameter. Mar 26 '18 at 14:52 • Yes and that could be more clear. – zaph Mar 26 '18 at 15:02 Things are working just as expected. A property of CBC mode (occasionally desirable) is that decryption is possible for blocks after an error in the ciphertext (including in the IV), provided block alignment is not lost. The error affects the block in error, and the next one, but no other. This is apparent in the decryption equation for CBC:P_i\gets D_k(C_{i+1})\oplus C_i$, where$C_0\$ is the IV.

• It is also visually apparent on the nice graphics on the Wikipedia page dedicated to modes of operations. We can see that decryption is often using the IV only on the first block... Unless you're using OFB or CTR, for example.
– Lery
Mar 26 '18 at 10:44

See CBC mode. Note the first block uses the IV and each following block uses the encrypted data of the previous block.

Thus each block beyond the first is decrypted correctly regardless of the IV being correct or not. This provides a self correct effect if one block is corrupted but block alignment is not lost.