34

We've had to extend our website to communicate user credentials to a suppliers website (in the query string) using AES with a 256-bit key, however they are using a static IV when decrypting the information.

I've advised that the IV should not be static and that it is not in our standards to do that, but if they change it their end we would incur the [big] costs so we have agreed to accept this as a security risk and use the same IV (much to my extreme frustration).

What I wanted to know is, how much of a security threat is this? I need to be able to communicate this effectively to management so that they know exactly what they are agreeing to.

We are also using the same KEY throughout as well.

Thanks

Improve this question

3 Answers 3

Reset to default
44

It depends on the chaining mode. AES is a block cipher, it is applied on blocks of 16 bytes (exactly). The chaining mode defines how input data becomes several such blocks, and how output blocks are then put together. Most chaining modes need to work with some sort of "start value", which is not secret but should change for every message: that is the IV.

Reusing the same IV is deadly if you use the CTR chaining mode. In CTR mode, AES is used on a sequence of successive counter values (beginning with the IV), and the resulting sequence of encrypted blocks is combined (by bitwise XOR) with the data to encrypt (or decrypt). If you use the same IV then you get the same sequence, which is the infamous "two-time pad". Basically, by XORing two encrypted string together, you get the XOR of the two cleartext data. This opens to an awful lot of attacks, and basically the whole thing is broken.

Things are less dire if you use CBC. In CBC, the data itself is broken into 16-byte blocks. When a block is to be encrypted, it is first XORed with the previous encrypted block. The IV has the role of the "-1" block (the previous encrypted block for the first block). The main consequence of reusing the IV is that if two messages begin with the same sequence of bytes then the encrypted messages will also be identical for a few blocks. This leaks data and opens the possibility of some attacks.

To sum up, do not do that. Using the same IV with the same key ever and ever defeats the whole purpose of the IV, the reason why a chaining mode with IV was used in the first place.

Improve this answer
4
  • 1
    Just chiming in to say that Thomas Pornin's answer (and GregS's comment) are absolutely correct. FYI, Thomas Pornin is a highly respected cryptographer and cryptanalyst.
    – D.W.
    Jan 9, 2011 at 9:46
  • 12
    This is the right answer. If you have the ability to insert random data somewhere in the message before data starts getting sensitive, you should be golden (the random data will serve as a poor man's IV). You should use at least a block's worth of random data. For example, if you're sending an XML-formatted message, and can insert an attribute random-data="#{base_64_encode(secure_random_bytes(32))}" into the XML root element (without breaking any schemas or contracts), that should substitute. But whenever possible, you should avoid poor man's crypto.
    – yfeldblum
    Jan 17, 2011 at 16:21
  • I found crypto.stackexchange.com/questions/3883 useful to learn more on why CBC with a static IV can be problematic (arguably, the two questions are duplicates).
    – Elliott Beach
    Dec 7, 2019 at 23:41
  • @yfeldblum But how long should that random data be? Is there any length as of which the encrypted messages will be equal? (And then we only need to insert random data until the byte X, as of which it doesn't matter anymore)
    – Edw590
    Sep 5, 2021 at 16:42
8

Using the same IV for all data is equivalent to not using an IV at all - the first block of ciphertext will be identical for identical plaintext. I'd be interested to hear why your supplier wants to use a constant IV, but that's beside the point. The point is that the system is susceptible in this way: if an attacker can set their own credentials and observe the ciphertext that's generated, they can compare it with other encrypted credentials to find out information about the key.

Improve this answer
3
  • 5
    The first 2 sentences of this answer are correct, but the last sentence is wrong. A static IV does not reveal information about the AES key. It does reveal information about the first block of plaintext, as you hint at.
    – D.W.
    Jan 8, 2011 at 5:08
  • 2
    @D.W. I'm not a sufficiently expert cryptanalyst to verify that, but that means I can accept I may be wrong. If you can provide a reference demonstrating that, I'll modify the answer (or you can ;-).
    – user185
    Jan 8, 2011 at 10:45
  • 2
    It's a consequence of a basic fact: there is no known feasible way to find the AES keyby ciphertext-only, known-plaintext, or chosen-plaintext attack. I wouldn't know where to give you a reference for it; a good class on cryptography, maybe, or possibly a recent textbook on cryptography. Maybe this. If AES was susceptible to a chosen-plaintext attack that revealed information about the key, it would not have been chosen by NIST: that's one of the most fundamental requirements for a block cipher.
    – D.W.
    Jan 9, 2011 at 9:41
2

I'm not a crypto guy, but my understanding is that if the IV doesn't change and the same value is re-encrypted, then the output would be the same. Therefore it would be possible to infer the content by looking for repeating values, such as a credential that gets passed with each request.

Again though, I'm not a crypto guy so I could be wrong.

Improve this answer
0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .