4
$\begingroup$

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`/��]d`L�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.
$\endgroup$
3
$\begingroup$

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)

ECB encrypted image

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.

CBC encrypted image

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.

CBC encrypted image CBC encrypted image

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.

CBC encryption algorithm

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)

CBC decryption algorithm

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.

$\endgroup$
  • $\begingroup$ 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. $\endgroup$ – zaph Mar 26 '18 at 13:23
  • $\begingroup$ @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. $\endgroup$ – Filip Franik Mar 26 '18 at 13:32
2
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ 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. $\endgroup$ – zaph Mar 26 '18 at 13:28
  • $\begingroup$ @zaph That sentence is in the context of ECB mode, which does not have an IV parameter. $\endgroup$ – CodesInChaos Mar 26 '18 at 14:52
  • $\begingroup$ Yes and that could be more clear. $\endgroup$ – zaph Mar 26 '18 at 15:02
2
$\begingroup$

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.

$\endgroup$
  • 1
    $\begingroup$ 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. $\endgroup$ – Lery Mar 26 '18 at 10:44
0
$\begingroup$

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.

$\endgroup$

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.