2

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?

kelalaka
  • 48,443
  • 11
  • 116
  • 196
daniel7558
  • 141
  • 1
  • 4
  • 1
    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. – Maarten Bodewes Nov 03 '18 at 18:52
  • Try an IV of 12121312121212121212121212121212 instead. – Maarten Bodewes Nov 03 '18 at 18:56
  • 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. – daniel7558 Nov 03 '18 at 19:22
  • @daniel7558 is it Yer or Yes? – kelalaka Nov 03 '18 at 19:29
  • 5965 73 = Yes Oh, when I submit the 128 bit long message, the ciphertext has an extra block. That should be because it needs to add a complete block of padding if the ciphertext already is a multiple of the blocksize. But when this is always added, how would I do the attack when the IV is just incremented? In order to change the last bit of the plaintext I need to make my plaintext to be the same size as the block size which would result in an extra block being added for padding. – daniel7558 Nov 03 '18 at 19:40
  • 1
    If you're doing the padding yourself, use -nopad so enc doesn't do another, extra padding. – dave_thompson_085 Nov 04 '18 at 02:52
  • Thanks to all of you! I solved it. The problem really was that I forgot about the padding. Once I did the padding by myself, it worked. – daniel7558 Nov 04 '18 at 07:33
  • Don't use the openssl command line for this kind of things. It's hard enough to use if you understand exactly what you're doing. Use a simpler interface. The Python toplevel with the Cryptodome library is nice. – Gilles 'SO- stop being evil' Nov 04 '18 at 10:23

1 Answers1

2

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.

daniel7558
  • 141
  • 1
  • 4