1
$\begingroup$

I would like to simulate the CBC IV attack where the IV is predictable. It's described in the answer to this question: chosen plaintext attack on CBC, predictable iv

(Only "Yes" and "No" are valid messages and the attacker knows this)


I am using 128-bit AES, CBC mode. Everything is in hex

Key: 00112233445566778899aabbccddeeff
IV1: 12121212121212121212121212121212
Msg: Yes
Ciphertext: 030a 6eac 2641 e072 bd51 0d84 fb87 08da

I have encrypted the message like this:

printf "Yes" > yes
openssl enc -aes-128-cbc -e -in yes -out yes.aes -K 00112233445566778899aabbccddeeff -iv 12121212121212121212121212121212

The next IV (IV2) is going to be:

12121212121212121212121212121213

When an attacker knows this, it can calculate

IV1 XOR IV2 XOR "Yes"

and submit it to be encrypted with the next IV. If the ciphertexts match, then the attacker knows that the first message was in fact "Yes"

In my example the XOR calculation results to 59 65 72 which is in ASCII:

Yer

(calculated with http://xor.pw)

Now let's encrypt this and check if the ciphertexts match:

printf "Yer" > yer
openssl enc -aes-128-cbc -e -in yer -out yer.aes -K 00112233445566778899aabbccddeeff -iv 12121212121212121212121212121213

But now I get this as the ciphertext:

4378 8d70 de54 d287 8f64 1c8d ec40 de91

I was expecting it to be the same ciphertext as the one for the original "Yes"


I can't find my error. The attack should be correct, so I guess I am using OpenSSL incorrectly?

$\endgroup$
  • 1
    $\begingroup$ You are changing the last bit of the block using the IV. However, your plaintext input is much shorter than one block, so the change will fall outside the plaintext, and instead you are changing the PKCS#7 padding of the plaintext. $\endgroup$ – Maarten Bodewes Nov 3 '18 at 18:52
  • $\begingroup$ Try an IV of 12121312121212121212121212121212 instead. $\endgroup$ – Maarten Bodewes Nov 3 '18 at 18:56
  • $\begingroup$ So, in order to fix my example I would have to pad the "Yes" message in accordance with PKCS#7 and decrease the last byte by 1. Then I encrypt with IV2. When I encrypt 5965 730d 0d0d 0d0d 0d0d 0d0d 0d0d 0d0c ("Yes", followed by 13 in hex, last bit changed) I still don't get the original ciphertext. $\endgroup$ – daniel7558 Nov 3 '18 at 19:22
  • $\begingroup$ @daniel7558 is it Yer or Yes? $\endgroup$ – kelalaka Nov 3 '18 at 19:29
  • 1
    $\begingroup$ If you're doing the padding yourself, use -nopad so enc doesn't do another, extra padding. $\endgroup$ – dave_thompson_085 Nov 4 '18 at 2:52
1
$\begingroup$

Okay, I solved it.

First of all, I do not need to worry about the padding as I only care for the first block (I know that the message is either Yes or No and therefore never longer than one block) and I can just discard the added block. In reality I probably won't be able to persuade the encryption oracle to use -nopad anyway :) These are the values that I used

Key:              0011 2233 4455 6677 8899 aabb ccdd eeff

Original Message: Yes || padding
                  5965 730d 0d0d 0d0d 0d0d 0d0d 0d0d 0d0d
Original IV:      1212 1212 1212 1212 1212 1212 1212 1212
Message XOR IV:   4b77 611f 1f1f 1f1f 1f1f 1f1f 1f1f 1f1f

Encrypted Message:
                  030a 6eac 2641 e072 bd51 0d84 fb87 08da  -- Actual Message
                  25ff efd9 b2ca 90f9 9c57 7006 0e53 2437  -- this is just padding

Next IV will be:  1212 1212 1212 1212 1212 1212 1212 1213
Message:          5965 730d 0d0d 0d0d 0d0d 0d0d 0d0d 0d0c -- last byte changed!
Message XOR IV:   4b77 611f 1f1f 1f1f 1f1f 1f1f 1f1f 1f1f 
                  -- has to be the same as for the original message: check :)

Encrypted Message:
                  030a 6eac 2641 e072 bd51 0d84 fb87 08da -- Message
                  25ff efd9 b2ca 90f9 9c57 7006 0e53 2437 -- this is just padding

We see that the first block of the ciphertexts match (also all following blocks as it is deterministic). Therefore the original message must have been "Yes". We do not need to care about the padding.

$\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.