Application uses AES in CBC mode with 128 bit key. In this implementation key is always same and is equal to IV. Can attacker get the key or decrypt data? If he knows:

  1. First and second blocks of plaintexts;
  2. All blocks of ciphertexts.

The software mentioned above is malicious program, it encrypts all office files on user's computer. And I now attempt to help user get his data back. Reverse engineering of this program shows that key is unknown, but is always same and is equal to IV.

  • 3
    $\begingroup$ This has got to be the most-asked cryptographic question ever. There is a special level of hell reserved for those who reuse IVs despite thousands of dire warnings from cryptographers. $\endgroup$ – Stephen Touset Dec 30 '15 at 9:50
  • 2
    $\begingroup$ You can edit your question to include additional information, but please don't use the answer box to post this information or comments that are intended to be posted on other posts. It seems you created a second account accidentally. See: I accidentally created two accounts; how do I merge them? $\endgroup$ – Artjom B. Dec 30 '15 at 10:31

In this answer I'm assuming that a key is used to encrypt more than one message.

  • The first weakness is that CBC with fixed IV leaks if messages share a common prefix.

  • The second weakness is that it makes a padding oracle attack much more severe. Consider a device that knows the key and decrypts a ciphertext you send to it. While it won't tell you the plaintext, it'll leak if the padding was valid (e.g. via an error message or timing). Such a device acts as padding oracle.

    For normal use of CBC with PKCS#7 padding and a known (variable or fixed) IV, such a padding oracle will allow an attacker to recover the message associated with plaintext, but it will not leak the key.

    When using a fixed secret IV, it doesn't recover the plaintext of the first message block directly, rather it recovers $m_1 \oplus \mathrm{IV}$. When the attacker has access to several ciphertexts, this behaves like a many-time-pad thanks to the reused IV. Due to the redundancies of natural languages this should allow recovery of the IV given only a few ciphertexts.

    If the key is reused as IV this IV recovery attack becomes a key recovery attack.

I don't expect either of these weaknesses to help a ransomware victim, since the first is only a minor leak and the second requires a padding oracle, which you probably won't have.

| improve this answer | |

Yes IV is not intended to be secret. It is given in clear with the ciphertext (usually the first block of it).

An attacker, given the ciphertext, can recover the first 128 bits, use them as the IV and as the key and recover the original plaintext.

The scheme you described is completely broken and to be considered not secure at all.

| improve this answer | |
  • 4
    $\begingroup$ I don't think the idea is that the key would be simply revealed. I think the idea is to keep it (and thus the IV) secret. This is insecure, but for a different reason. $\endgroup$ – otus Dec 30 '15 at 9:38
  • 1
    $\begingroup$ I agree @otus, but the first version of the question was unclear. $\endgroup$ – ddddavidee Dec 30 '15 at 12:16

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.