How to decrypt AES/CBC with known IV

I have an impossible task of decrypting AES/CBC encrypted data packets sent from a client. I've done tons of research leading me to believe that the encryption is insecure if the IV is static. For this task specifically, the IV is always statically set to 0. Is there any way this can be done?

EDI开发者_运维技巧T: The plain text is snippets from the script of Hamlet. The client sends them in random chunks so the length is not even consistent. The packets may eventually repeat but I'm not 100% sure.

Not without the key.

Specifically, assuming there's no padding, the vulnerability that occurs with using the same IV every time is that if you start out encrypting the same data you encrypted last time, you'll get the same encrypted string both times. This allows attackers to infer something about the message content, though it doesn't help them decrypt it.

Just for notation, the term "decrypting" means the normal operation using the key. If you don't have the key, this is normally called "breaking", "cracking" or "cryptanalysis".

CBC with a fixed initialization vector has the property that messages (encrypted with the same key) with identical starting blocks will also show identical starting blocks in the ciphertext ... and this is about the only weakness. So if you can get your victim to encrypt some guess for your message (with the same key), you can compare its ciphertext to the one used in the message you are using.

This is easier when the message is of some fixed format, and hopeless if the message contains enough random data before the interesting part (this is "poor man's initialization vector").

Other CBC weaknesses which depend on chosen ciphertext attacks where you chose the initialization vector and observe some validation of the decryption thereof might also be applicable (you would set the first ciphertext block and observe whether the second block has valid padding).

The main problem with a non-random IV is that two identical initial blocks encrypted with the same key will produce the same output. So, given your description of pieces out of Hamlet, knowing that you are using the same IV repeatedly, I would do the following:

• I would compute the ciphertext for "To be or not to " (16 bytes) for a wide variety of likely passwords (as might be generated by John the Ripper).
• I would compare the resulting cipertext against all the messages, based on the premise that they might start with these 16 bytes.
• If one matches, I know the password. Done.

I'd do the same with several other well-known phrases. This is an operation I can do massively in parallel even before I capture your file and cache in a database. The general term for this approach is a rainbow table.

My job gets much, much easier if I happen to know the first 16 bytes of your messages (such as if they're email messages to a known person, or HTTP requests with known headers or the like).

But what if you use random keys (or a proper KDF like PBKDF2)? Well, let's say I have a few messages from you, and at least some of them have the same first 16 bytes (again, headers in the protocol help me a lot here). Well, step one is that I know that these messages have the same first 16 bytes. That's pretty useful information. And now I have a crib for attacking your messages.

Reusing an IV+Key in CBC doesn't completely destroy its security (as reusing a Nonce+Key in CTR mode does). But it gives the attacker a lot of helpful tools in simplifying the attack.

I'm not saying that any of these would allow you to decrypt your specific ciphertext in some short period of time. But they all strongly degrade the alleged strong-cryptography of AES.

Zero IV can leak some information about the first bytes of data, however, if they differ this should not be an issue (however, it is not recommended to use). For instance, OpenPGP uses zero IV in some cases.