Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Let's say that I have three messages being encrypted by AES-128 with the same key and IV every time. Is it possible to decrypt the key being used? And more importantly, is it possible to decrypt the plaint text of those messages?

share|improve this question
1  
What mode of operation are you using? CBC, counter mode, OFB etc? –  David Wachtfogel Oct 10 '12 at 7:28
2  
I read questions like this as, "Let's say that I have a solidly-built house, and have replaced all the doors and windows with cellophane. I am concerned about burglars. Is it possible for someone to tunnel their way into the house from underneath?" –  Stephen Touset Oct 10 '12 at 15:11

2 Answers 2

Using the same IV and key for more than one message doesn't jeopardize the key but it does make it easier for an attacker to obtain the plain-text. How it does so depends on the mode of operation used.

If the mode of operation is a stream cipher (such as Counter mode or OFB) then using the same IV and key for two message is like using the same "one time pad" for two messages - the attacker can obtain a XOR of the messages by simply XORing the encrypted messages. This is should be enough information for a competent attacker to obtain the clear messages. For more details see Taking advantage of one-time pad key reuse?.

But even if the mode of operation is not a stream cipher (e.g. CBC) reusing the same IV and key will leak information about the messages - for example, if they start with the same data.

So the rule is - don't reuse IVs.

share|improve this answer
    
"more than enough" is a bit of an exaggeration. It's sometimes enough, and sometimes it isn't. | "component" != "competent" –  CodesInChaos Oct 10 '12 at 8:48
    
@CodesInChaos Thanks - I've corrected the answer accordingly. –  David Wachtfogel Oct 10 '12 at 8:53

What happens here depends on the mode of operation. As a basic rule, knowledge of the messages will not allow you to recompute the key itself, but it may give you enough information to (instantly) crack any other message encrypted with the same key and IV.

With CTR mode, a key-dependent stream is produced by encrypted the successive values of a counter, and the counter starts at the value given in the IV. The actual data encryption is performed by XORing this stream with the data to encrypt. If the same key and IV are used, then you get the same stream, so you are in the conditions of the (in)famous two-times pad. Without knowing the key, you can still compute the XOR of any two messages, which is often enough to crack them, by exploiting their internal structure. Once one of the messages is known, this reveals the key-dependent stream (up to the message length) and this allows for immediate decryption of any other message (up to that length) encrypted with the same key+IV.

OFB mode is in a similar situation: it produces a key-dependent pseudo-random stream. So it can be broken with the same level of ease as CTR.

With CBC mode, things are a bit harder for the attacker. If the messages start with the same bytes, then you will be able to see it. After the first distinct bytes, decryption becomes much harder. This is because, in effect, each block in CBC encryption is used as IV for the remainder of the message, and encryption of data with a block cipher tends to produce properly distributed IV for CBC. Generically, CBC requires a uniformly random IV which is unpredictable by the attacker, but in your situation you envision a passive-only attacker, and against such an adversary, an IV selected by encrypted a known data block is good enough for CBC, as long as the IV source is not reused; this is what you obtain with your messages, beginning with the first block at which the messages differ.

CFB mode is somewhere in between. If two messages begin with the same n bytes, then the encrypted messages will begin with the same n bytes too; then, for the remainder of the block containing the n+1-th byte, this is two-times pad. For the subsequent bytes, the streams have forked and attacker's power stops.

Important: though the paragraphs above seem to indicate that CBC or CFB would be safe for key+IV reuse as long as you include a counter in the header of each message, remember that this is for a passive attacker only. In many (most) scenarios, the attacker can be also embed a bit of data of his own in the messages which are to be encrypted, and/or alter the encrypted bytes and see what happens when they are decrypted. For these scenarios, which are realistic (many recent attacks again SSL are all about that), IV reuse, and even predictable IV selection (with CBC), are hopelessly weak. Do not reuse IV.

The only situation where a fixed IV is fine is when keys are never reused, i.e. each key is used for a single message only. This is, in practice, harder to obtain than a new per-message IV, because keys must be kept confidential: it is already challenging to have a key which is known by both the sender and the receiver, but by nobody else. At least, IV do not have this confidentiality requirement, and thus can be transmitted along with the message itself.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.