How to decrypt AES / CBC with known IV

Question

I have the impossible task of decrypting encrypted AES / CBC data packets sent from a client. I did a lot of research, making me believe encryption is not secure if IV is static. For this task, in particular, IV is always statically set to 0. Is there a way to do this?

EDIT: Plain text is fragments from the Hamlet script. The client sends them in random fragments, so the length is not even consistent. Packages may end up repeating, but I'm not 100% sure.

Answer 1

Not without a key.

In particular, if you do not use registration, the vulnerability that arises when using the same IV each time is that if you run the encryption of the same data that you encrypted for the last time, you will get the same encrypted string both times. This allows attackers to infer something about the contents of the message, although it does not help to decrypt them.

Answer 2

For designation purposes only, the term “decryption” means a conventional key operation. If you do not have a key, it is usually called "hacking", "hacking" or "cryptanalysis."

A CBC with a fixed initialization vector has the property that messages (encrypted with the same key) with the same starting blocks will also show the same starting blocks in the ciphertext ... and this concerns the only weakness. Therefore, if you can force your victim to encrypt some assumptions for your message (with the same key), you can compare its encrypted text with the one used in the message you are using.

This is simpler when the message has a certain fixed format and is hopeless if the message contains enough random data in front of the interesting part (this is the “poor people initialization vector”).

Other CBC vulnerabilities that depend on the selected attacks on the ciphertext, where you select the initialization vector and observe some verification of its decryption, can also be applied (you should install the first block of ciphertext and observe if the second block has valid filling).

Answer 3

Zero IV may skip some information about the first bytes of data, however, if they differ, this should not be a problem (however, this is not recommended). For example, OpenPGP uses zero IV in some cases.

Answer 4

The main problem with nonrandom IV is that two identical starting blocks encrypted with the same key will have the same output. So, given your description of the parts from Hamlet, knowing that you use the same IV several times, I would do the following:

• I would calculate the cipher text for "To be or not to be" (16 bytes) for a wide range of probable passwords (how John the Ripper can be created).
• I would compare the resulting cipertext with all the messages, based on the premise that they can begin with these 16 bytes.
• If one matches, I know the password. Done.

I would do the same with a few other well-known phrases. This is an operation that I can do massively in parallel, even before I grab your file and cache in the database. The general term for this approach is the rainbow table .

My work becomes much easier if I know the first 16 bytes of your messages (for example, if they are emails to a famous person or HTTP requests with known headers or the like).

But what if you use random keys (or a suitable KDF, like PBKDF2)? Well, let's say I have several messages from you, and at least some of them have the same first 16 bytes (again, the headers in the protocol help me a lot). Well, the first step is that I know that these messages have the same first 16 bytes. This is very useful information. And now I have a crib to attack your messages.

Reusing an IV + key in CBC does not completely destroy its security (since reusing a Nonce + Key in CTR mode). But this gives the attacker many useful tools to simplify the attack.

I am not saying that any of them will allow you to decrypt your encrypted text in a short period of time. But all of them greatly degrade the alleged strong AES cryptography.