10

I'm doing a code review for a crypto solution that reuses the same key with a constant IV. I want to demonstrate that this is not the right way to do things by figuring out the key and decrypting all of their test data.

  • I have access to lots of ciphertext.
  • I know the same key is used.
  • I know the same IV is used.
  • Cipher is AES/CBC/PKCS5
  • Plaintext is 16 bytes.
  • Ciphertext is 32 bytes (PKCS5 padding?)
  • I can put whatever plaintext I want through the system and then get that ciphertext.

What's the high-level pseudo code or process to break this system?

Heathkit7
  • 101
  • 1
  • 1
  • 3

3 Answers3

6

Well, there is no really good way; the encryption of the plaintext is $E_k( Plaintext \oplus IV)$ (followed by 16 bytes which are a deterministic function of the first ciphertext block). The AES function $E_k$ is designed to be totally unpredictable if you don't know the key, there's nothing to leverage there. The only thing that allows you to gain any advantage is that the encryption function itself is deterministic; that is, about the best you have available is:

  • Make a guess as to what the plaintext might be

  • Ask that be encrypted

  • Check to see if that ciphertext happens to match anything on your list

  • Rinse and repeat

Not by any means an ideal solution; however it's the best option you have available.

Now, if the plaintext had been longer than 16 bytes, you could use the above procedure to confirm a guess on the first 16 bytes of the plaintext, and then work on the next 16 bytes -- with your specified parameters, that's not an option.

poncho
  • 154,064
  • 12
  • 239
  • 382
5

If the last 16 bytes of the ciphertext are the padding, then you actually have the simple ECB (Electronic CodeBook) mode. ECB is secure as long as all your plaintexts are 1 block long and never repeat.

Dmitry Khovratovich
  • 5,737
  • 23
  • 25
1

You do not mention any authentication of the ciphertexts. If you could change the IV (which sounds highly unlikely) then you could make rather precise changes to the plaintext (as if it was a stream cipher).

Ideally from your point of view, there may be a padding oracle attack (which I don't understand and so won't describe here).

If you can change the first ciphertext block and figure out what padding scheme they are using, then you can cause decryption to output a plaintext that is longer than 16 bytes, in which the first 16 bytes are garbled and the rest of the output is chosen by you. If you can change both ciphertext blocks and learn what plaintexts those ciphertexts decrypt to and figure out what padding scheme they are using, then you can cause decryption to output a plaintext that is longer than 16 bytes, in which you have a tiny bit of control over the first 16 bytes of plaintext and the rest of the plaintext is chosen by you.

If you change the first ciphertext block and figure out what padding scheme they are using, and their unpadding is implemented in a way that will not reject when the final block decrypts to all-zero, then for each ciphertext there is a plaintext of less than 16 bytes that you can cause decryption to output.

Community
  • 1