6

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?

Maarten Bodewes
  • 92,551
  • 13
  • 161
  • 313
72DFBF5B A0DF5BE9
  • 188
  • 1
  • 6

2 Answers2

9

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.

In addition, you ask whether:

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).

poncho
  • 147,019
  • 11
  • 229
  • 360
  • 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 02: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 03 '14 at 00:37
4

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.

orlp
  • 4,230
  • 20
  • 29
  • ...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? – orlp Dec 25 '13 at 08: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 00: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. – orlp Dec 27 '13 at 01:32
  • @nightcracker, I know, I'll take care of rest, but I don't want to see a review about "weak cipher usage in app", so do you think CFB will not cause "weak cipher use" type of reviews? – 72DFBF5B A0DF5BE9 Dec 27 '13 at 01:43
  • @M.C. Depends on how you use it. Sorry. – orlp Dec 27 '13 at 02:30
  • @nightcracker, I'll encrypt 32 bytes of strings with it, key will be managed properly, IV and keys will be generated using cryptographically secure algorithm and will be stored safe, now? – 72DFBF5B A0DF5BE9 Dec 27 '13 at 02:35
  • @M.C. Please stop. There's too many factors/details that can go wrong so I can't simply say your usage is secure. I'd have to look at the actual code/application (and sorry, I'm not doing free work). I'm answering crypto questions in my free time, not doing security audits. I have given you the parameters for correct CFB usage in my answer - it's your job to make it so. And please do not use weasel words while communicating about crypto - there's no such thing as a "cryptographically secure algorithm" that generates IVs and keys. Did you mean a CSPRNG? – orlp Dec 27 '13 at 03:07
  • This answer is incorrect. The IV in the CFB mode must be impossible to predict, otherwise you lose the security. Consider, for instance, that you choose one of intermediate ciphertext blocks of any encryption as the IV. Then the first plaintext block can be recovered easily. See http://www.cs.ucdavis.edu/~rogaway/papers/modes.pdf , page 36 for more details. – Dmitry Khovratovich Jan 24 '14 at 12:23
  • @DmitryKhovratovich I don't think my answer is incorrect. I clearly stated in my answer that the IV may not be chosen by an attacker. So the attack "Consider, for instance, that you choose one of intermediate..." does not apply. – orlp Jan 24 '14 at 12:45
  • A legitimate user might do the same, and all the security will ruin. – Dmitry Khovratovich Jan 24 '14 at 12:59
  • @DmitryKhovratovich Any "impossible to predict" algorithm, such as a random number generator, might also generate previously encrypted intermediate blocks as IVs. It's irrelevant to the choice of generating IVs - it's a weakness of CFB in general. But this is no reason to downvote my perfectly valid answer. – orlp Jan 24 '14 at 13:26
  • The probability that some RNG generates an IV equal to any ciphertext block is exactly the quantifier of the security of CFB. It is not a weakness, it is a property. CFB is secure (up to $2^{n/2}$ generated blocks) if you generate IVs at random, and is insecure if you (a legitimate user or an adversary) chooses it at your own. Your recommendation allows a very fast and easy attack, and this is dangerous. – Dmitry Khovratovich Jan 24 '14 at 15:02
  • There are modes of operation, which are secure if IV is predictable but unique. These are nonce-based CTR, GCM, OCB, or nonce-less SIV. – Dmitry Khovratovich Jan 24 '14 at 15:04