# Keeping IV secret for AES CFB mode

I'm developing a security/encryption software and I'm using AES CFB (block size: 16 and key size: 32 bytes).

I want to know, if I also keep IV (32 bytes) secret like the key itself (32 bytes), would it add to security or not?

Encryption key and IV will not be specified by user, it will be generated and then encrypted with RSA and stored in safe storage. So I'm thinking to generate randomly key and IV. So if I also keep IV and key (both generated) in secure place would it make my crypto stronger or it's preferred to make IV constant in my application code?

-
possible duplicate of Initialization Vector Properties –  Gilles Dec 22 '13 at 20:57
See also Why is the IV passed in the clear when it can be easily encrypted? You neither keep the IV secret nor make it constant: you write it together with the ciphertext (generally just before the ciphertext). By the way, the IV is 16 bytes (1 block). –  Gilles Dec 22 '13 at 20:58
I disagree with the "possible duplicate" comment; it's about CFB mode, which is subtly different than the modes discussed there; those subtle differences merit examination. –  poncho Dec 22 '13 at 21:04

Actually, for CFB mode, the IV is the same size as the block size, 16 bytes.

As for your question "does keeping the IV secret help security", the answer is "not really".

CFB mode processes the message in blocks, and for each block of plaintext, combines that with the previous block of ciphertext to generate the next block of ciphertext. What the IV is used for is for the initial block of plaintext; there is obviously no previous ciphertext block, and so you use the IV instead.

What this means that if you keep the IV secret, it doesn't really hinder any particular attack in any way. One way to see that is to assume the contrary; let us assume that, if we expose the IV to the attacker, that he can exploit some weakness. If we assume that, then the attacker can use that weakness to attack a CFB mode encrypted text without the IV; what he does is take the ciphertext (without the IV), and treat the initial ciphertext block as the IV, and the rest of the ciphertext as the "real" ciphertext; the plaintext this corresponds to is the normal plaintext with the initial block omitted.

Because of this, if exposing the IV with CFB mode lead to a weakness, CFB mode in general is weak. Now, written this way, this might not sound very comforting; however athat statement is logically equivalent to "if CFB mode is strong, then CFB mode with the IV mode exposed is strong", which is really what we want to show.

It's preferred to make IV constant in my application code

It is absolutely a bad idea to have a constant IV with CFB mode; he's why: the initial ciphertext block is:

$C_0 = P_0 \oplus AES( IV )$

What this means is that if an attacker sees two encrypted messages with the same IV and key, then he knows the above and also knows:

$C'_0 = P'_0 \oplus AES( IV )$

Even though is might not know what the IV is, he can combine the two equations to form:

$C_0 \oplus C'_0 = P_0 \oplus P'_0$

In other words, by examining the bit differences between the two initial ciphertext blocks, he can deduce the bit differences between the two initial plaintext blocks; that is far more information than we want an attacker to know.

Instead, you are far better off either using random IVs or possibly using a counter (if randomness is a problem for you).

-
Thank you for such detailed explanation. Just last question, I've seen you and some others doesn't suggest CFB mode, so for encrypting 32 bytes of plain text, which method you suggest? –  72DFBF5B A0DF5BE9 Dec 24 '13 at 2:46
@M.C.: Actually, there's nothing wrong with CFB mode if you know what you're doing; you pick unique IVs, and perform some form of integrity checking (e.g. use a MAC). –  poncho Jan 3 at 0:37

For CFB mode:

1. NEVER make the IV constant, it must be unique for every message.
2. The IV does not need to be secret or impossible to predict, only unique. It can be a simple counter, for example.
3. The IV may not be chosen by the attacker.

I can not emphasis UNIQUE enough, if your IV is not unique you've basically lost all security.

-
...unless they never reuse the key for two different messages; in that specific case (and only in that case) using a constant IV is safe. –  Ilmari Karonen Dec 22 '13 at 21:07
Thank you for answer, just a final comment, if you think CFB is not so secure, which mode of AES is the strongest for encrypting just 32 bytes of strings? –  72DFBF5B A0DF5BE9 Dec 24 '13 at 22:27
@M.C.: What makes you think I think that CFB is not secure? –  nightcracker Dec 25 '13 at 8:53
@nightcracker, I don't know, I just felt like that from other answer, do you think CFB is so secure and one of bests for 32 byte data encryption? –  72DFBF5B A0DF5BE9 Dec 27 '13 at 0:41
@M.C. With all due respect, I'm going to refrain from saying "the best" about this. Most things are secure if used properly, but what defines properly changes from mode to mode. I can't say what the best mode is for 32 byte data encryption because it's a non-existing question. There's always many other considerations such as speed, parallelizability, changing keys/iv's, database capacity, latency, cipher requirements, etc, etc. It always depends on the application. –  nightcracker Dec 27 '13 at 1:32