CBC Encryption with an Initialization Vector of 0

[Lucky75]

Hey!

If I have data that's been encrypted with a CBC cypher, but I know that the Initialization Vector was 0, how can I decrypt the message without having to randomly guess keys? I'm somewhat confused.

Thanks!

[laserlight]

Don't you know the key? If not, then too bad: just knowing the IV is not enough, and in fact this is why the IV can be sent in the clear.

[Lucky75]

Nope, the point of the project is to get the plaintext without knowing the key I thought CBC ciphers with a non-random IV were easier to decrypt? Or does it just turn into ECB or something, which wouldn't help except to give me a pattern for the first block of data if the Key is the same?

What would be the best way to go about getting the plaintext? Brute-forcing guesses? I'm able to vary (and know) the number of 0-bits in the AES key, and the key never changes. I mean, obviously I can set it to have all 1's or all 0's and know the key, but how would I go about decrypting the message if it's somewhere in the middle? Even if I happen upon the correct key I wouldn't necessarily be able to determine that it's correct just by looking at the plaintext.

[laserlight]

I thought CBC ciphers with a non-random IV were easier to decrypt?

Nope. It would be best if the IV was unique with respect to the key.

What would be the best way to go about getting the plaintext? Brute-forcing guesses? I'm able to vary (and know) the number of 0-bits in the AES key, and the key never changes.

Err... the aim of this project is to cryptanalyse a message encrypted with AES? At the moment, I think the best approach against AES (other than reduced round versions) is still brute force. Do you have any idea what the plaintext might be? What language is it in? What is the character encoding?

Assuming that you know these, and that the message is long enough, I believe one approach is: try every possible key on a sufficient number of blocks (starting from the first after the IV). Programmatically analyse the output. If you don't get garbage (i.e., values impossible in the known character encoding, or which are simply not in the language), and if the frequency of letters (assuming it is alphabet based) comes sufficiently close to the known frequency of letters of that language, then you record the key for further analysis. Eventually, you may need to manually check these possible keys to see if one of them decrypts the message such that it makes sense.

[Lucky75]

Yeah, I'm pretty sure the client program was written in C++, but have no idea what the plaintext might be. I would assume it would be some sort of silly message, which means probably just ascii.

Does it help if I know how many 0's there are? For example, if it's a 256-bit CBC cipher, I know how many bits are 1's. So if 128 bits are 1's, and 128 bits are 0's, I guess it would be faster to bruteforce all possible combinations of keys. Maybe then just check to see that it's within the known ascii range or something over a couple of blocks? I guess if I have something like 4 1's and the rest 0's it wouldn't be as bad, but anything more than that and it would take forever to bruteforce.


Oh, and that aside, what do I do with the key anyway? Do I just do a bitwise-XOR with the data, and then XOR the result with the data from the previous block, working my way backwards until I hit the first block of data?

Thanks for the response

[laserlight]

Does it help if I know how many 0's there are? For example, if it's a 256-bit CBC cipher, I know how many bits are 1's. So if 128 bits are 1's, and 128 bits are 0's, I guess it would be faster to bruteforce all possible combinations of keys.

If you know the number of 0 bits in the key, then that certainly means that there are fewer possible keys with which you need to brute force.

Oh, and that aside, what do I do with the key anyway? Do I just do a bitwise-XOR with the data, and then XOR the result with the data from the previous block, working my way backwards until I hit the first block of data?

No, you always start with the first block. What you do is decrypt the first block using the key, and the XOR it with the IV to get the first plaintext block. Then you decrypt the second block using the key, and XOR it with the first ciphertext block to get the second plaintext block, etc.

[Lucky75]

Whoops, yeah, you're correct.

But how do I decrypt it with the key? I.e. what do I do to the encrypted data using the key to get the plaintext back?

And is there any way of using a divide-and-conquer algorithm or something to somewhat reduce the number of combinations I need to try for the key? Something like since I can limit the range of characters to the ASCII range, some of the bits have to be zero? I would guess that if I'm limiting it to the standard 128 normal characters, that I can assume every character is something like 0XXXXXXX (where X can be 0 or 1).

[laserlight]

But how do I decrypt it with the key? I.e. what do I do to the encrypted data using the key to get the plaintext back?

Apply the AES decryption algorithm

[Lucky75]

Apply the AES decryption algorithm

Which I assume I can get from openssl libraries or something?

[laserlight]

Yes, or other libraries, or even write it yourself.

[Lucky75]

Ok, thanks