4

I am trying to understand the choices of the following question

enter image description here

Based on my understanding, none of the choices apply because plain text for the first highlighted block is 1F2..CA2 which is the input of the second highlighted block. Similarly, for the second highlighted block, its plain text input is 60A4..388 which is input to the first highlighted block. Please correct me if i am wrong and which choice really applies here.

2

I believe none of the answers is correct. The blocks being the same means the XORs of the previous blocks and the plaintexts are the same. So 60A..388 XOR cleartext-1 is the same as 1F2..CA2 XOR cleartext-2.

So cleartext-1 XOR cleartext-2 = 7f8d68bf68fb3f.

Explanation:

  1. The cleartext data can not both be null because their XOR is not null
  2. The previous chunks (ciphertext) are clearly not identical and even if they were, it would not matter unless the cleartexts were identical as well.
  3. They are not identical (cleartext), but why the offset matter is unclear to me. It does not. Also, I would not necessarily say there is no relation, as I wrote the relation down (what they amount to if they are XOR-ed)
  4. No, they can't be identical. Identical blocks would XOR to all zeros / null.

So the "most correct" is the third one, but IMHO still incorrect.

7
  • What do you mean by neither? Am i incorrect? If so, how?
    – tulamba
    Apr 24 '18 at 19:41
  • @tulamba edited answer to include detailed explanation. Apr 24 '18 at 19:51
  • 1
    If you choose anything it should be option 4 as the cleartext before the block encrypt is identical. The block cipher is a permutation so for the block cipher there is a 1:1 relation between the plaintext and the ciphertext. However, as the question doesn't explicitly ask for the block cipher the question is indeed incorrect IMHO. Apr 25 '18 at 16:10
  • 1
    @PeterHarmann The input to the block cipher, after XORing the plaintext with the previous block's ciphertext, is the same. Apr 25 '18 at 16:17
  • 1
    @PeterHarmann He's saying that for a block cipher, each plaintext relates to exactly one ciphertext and vice versa (ie you can't decrypt a ciphertext to multiple possible plaintexts). This one to one relation is why, if you have identical ciphertext blocks, it is certain that the plaintext blocks were also identical. Really just saying explicitly what you implicitly take for granted. Apr 25 '18 at 16:24
2

Although Peter Harmann does make very good points in his answer and explains everything perfectly, I think the only correct answer can be #4.

Before the block encrypt you can only get identical ciphertext blocks if the input of the block cipher is identical in both CBC mode encryption operations. Block ciphers are permutations so there is always a 1:1 relation between a specific plaintext block and a specific ciphertext block.

The problem is that the question doesn't make it explicit that the question is about the block cipher rather than the block cipher in CBC mode. The ciphertext block directly before the block encrypt is XOR'ed with the plaintext block before the block encryption is performed. So the quality of the question is certainly up for discussion.

To make sure that identical ciphertext blocks aren't found there needs to be a maximum number of blocks that can be encrypted by CBC mode. That maximum is related to the block size of the block cipher being used. This is one of the reasons why AES (128 bit block size) should be preferred over triple DES mode or blowfish (64 bit block size).

If an identical block is found then the XOR between the two plaintext blocks is leaked, and leakage of any kind of data can be abused and breaks a cipher.


There may be a (final) move to 256 bit block ciphers in the future because of issues like this. Common/modern modes of operation such as CTR (counter mode) and GCM have limitations on the amount of message bytes and number of messages that can be encrypted with a single key, despite operating on a 128 bit block size.

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.