CBC IV=Key Recovery Attack

Updated 13 Sep 2026

• •

  What it is

  • •

    A CBC implementation that (mis)uses the encryption key as the IV leaks the key itself. Since CBC decryption is $P_i = D_K(C_i) \oplus C_{i-1}$ (with $C_0 = IV$), decrypting two all-zero ciphertext blocks through the oracle and XORing the resulting plaintexts cancels out the identical $D_K(0)$ term from both, leaving exactly the IV — which equals the key.

• •

  When to apply

  • •

    A CBC implementation sets IV = KEY (or otherwise derives the IV predictably/reversibly from the key), and exposes a decryption oracle you can feed arbitrary ciphertext.

• •

  Math

  • •

    $P_0 = D_K(C_0) \oplus IV,\quad P_1 = D_K(C_1) \oplus C_0$. With $C_0 = C_1 = \mathbf{0}$: $P_0 \oplus P_1 = D_K(\mathbf{0}) \oplus IV \oplus D_K(\mathbf{0}) = IV$.

• •

  Worked example

  • •

    Sending two all-zero 16-byte ciphertext blocks to a IV = KEY decryption oracle and XORing the two returned plaintext blocks recovered the exact 16-byte key (YELLOW SUBMARINE), byte for byte, with no brute-forcing at all.

• •

  Python

  • •

    plaintext = decrypt_oracle(b"\x00" * 32)  # two all-zero blocks
    key = xor(plaintext[:16], plaintext[16:32])
    

• •

  Related

  • •

    AES CBC Bit-Flipping

• •

  Cards

  • •

    Why does decrypting two all-zero ciphertext blocks reveal the IV when IV = KEY?

    • •

      Both blocks share the identical $D_K(\mathbf{0})$ term, which cancels out when the two plaintexts are XORed together, leaving just the IV (= the key).

  • •

    What's the underlying design mistake this attack exploits?

    • •

      Reusing the secret key as the IV, so recovering the IV is equivalent to recovering the key.

◌ Explore connections in Graph view