2 Answers
2

If the data is important to you, you could try brute-forcing the range of plausible IV values. For each guess at the IV, try decrypting and see whether the result looks like it could be your message. (Incorrect guesses will result in random gibberish.) If the number of plausible IV values is not too large, this might be successful at recovering your data.

Caveat: I am assuming you are focusing on recovering some data where the IV has been lost -- not on designing a secure cryptosystem. If you are designing a cryptosystem, you should not rely upon this for security. In other words, don't rely upon keeping the IV secret to protect your data. Attackers might be able to guess or figure out the IV; it's not a good basis for security.

Edit 10/2: Do you happen to have any known plaintext? In other words, do you know part of the message? If you know part of the message, then you may be able to recover the IV. For instance, if you know a consecutive 16 bytes of the message that corresponds to a block boundary, then you can xor those 16 bytes of plaintext against the corresponding 16 bytes of ciphertext to recover 16 bytes of keystream. Now decrypt that keystream block under AES (with the known AES key); the decryption will be the value of the counter for that block. Then you can run the counter forward/backward from there to learn the counter value for all other blocks, and decrypt the rest of the message.

The IV is 128 bit and (considered) truly random, I don't know anyway of bruteforcing with a standard aes encryption / decryption library (the lucky way doesn't count ;). My question could have been: is there something I can implement to effectively bruteforce IVs?
–
leonodeOct 2 '11 at 23:55

Answer: quantum algorithms that can try all IVs at once in superposition.
–
yfeldblumOct 2 '11 at 23:58

Yes but I don't like quantum algorithms, it make everything too easy ;) (or too complicated?). So it seems that CTR is combining the iv with the key before the key schedule. This make the iv protected by AES as much as the key is. (which is not true e.g. for CBC mode where the iv is just xored with the plaintext: easy to retrieve). Please correct if I'm wrong...
–
leonodeOct 3 '11 at 0:55

@leonode, if the IV is truly random, you're probably hosed. (No, the IV is not combined with the key as part of the key schedule -- but you're probably still hosed.) The one last hope I can see is if there is some known plaintext in the message; see my edit.
–
D.W.Oct 3 '11 at 1:45

1

@Justice: quantum computers do not exist yet, and even them cannot do that. The view of QC as "several computations all done in parallel" is simple but unfortunately rather wrong. The best a QC offers in that matter is trying out 2^128 possible keys or IV in time 2^64 (so that's quite faster than a classical computer, but still not "all at once").
–
Thomas PorninOct 3 '11 at 12:38

Please elaborate how the first block could be the IV. Is it deliberately made available there? (Please also see specific comment about bruteforce)
–
leonodeOct 2 '11 at 23:58

1

The IV is not a secret if it is unique to the encrypted message. In such a case, one might as well prepend the IV to the ciphertext so that the decryption operation can easily find the IV.
–
yfeldblumOct 3 '11 at 0:37