Tell me more ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.
up vote 1 down vote favorite

I have a need to encrypt credentials for a third-party app used by a secured internal app. Over on ITSec.SE, I was helpfully shown a scheme to encrypt the third-party credentials based on a hash of the credentials for the internal app.

I picked AES as the encryption algorithm, but the problem is that the password-based scheme doesn't produce a "secret" IV. So, the IV must at least be known to an attacker (stored alongside the encrypted data). A hash value used for password verification could work, or I could just generate a pseudorandom byte array and drop it in the DB as a new column. I was further considering, for simplicity, using a constant IV.

The question is, what adverse effect will any of these have on the security of the encryption? Does AES depend, as many block ciphers do, on an unpredictable IV? Does it matter if the IV is stored plainly?

EDIT: Thanks for the answers; the general consensus is that I should not use a fixed IV. As .NET has a CSPRNG built in (or at least hooked in from the CryptoServiceProviders) and it's easy enough to make a new one every time I re-encrypt something, I'll just do that, and store it alongside the encrypted data.

share|improve this question
1  
IVs have no requirement of secrecy. However, they do have a requirement of uniqueness, and for many modes require even more than that. CTR, for example, only requires uniqueness, so a simple counter will do. CBC on the other hand requires unpredictability prior to the encryption and no overlapping subregions. This is generally implemented with a CSPRNG. – Stephen Touset Oct 18 '12 at 17:07
I feel that the use case where a key derivation function is used together with a random salt (for each encrypt) is missing. In that case there are less constraints on the IV, as the key will be different each time it is used for encryption. – owlstead Oct 31 '12 at 0:41

2 Answers

up vote 3 down vote accepted

Do not use a fixed IV. It can have seriously negative consequences. You don't say what mode you were going to use. This would be a pretty important piece of information for us to know.

That said, a random 128-bit IV stored in plaintext is typically what you want. The IV can be known to an attacker without breaking security.

share|improve this answer
I'm probably going to use the .NET default CBC mode. – KeithS Oct 18 '12 at 16:24
1  
If you do, keep in mind that CBC mode has extra-strict requirements for the IV. Generating it with a cryptographically secure pseudorandom number generator is best practice. – Stephen Touset Oct 18 '12 at 17:04
Yeah, I wasn't going to use System.Random no matter what. .NET has a CSPRNG built in that's easy enough to use, especially to generate byte arrays – KeithS Oct 18 '12 at 18:46
1  
Keith, I would recommend you use System.Security.Cryptography.SymmetricAlgorithm.GenerateIV() instead of trying to generate your own array of bytes and loading them into the IV yourself. First, Microsoft's implementation is available and pre-tested, so you should have little business reason to reinvent that wheel. The other is that if someone discovers a weakness involving IVs next month, Microsoft would distribute a patch, and you wouldn't have to deal with the maintenance consequences yourself. – John Deters Oct 18 '12 at 21:55
... Except that in my case I'm using a PBKDF, and SymmetricAlgorithm.CreateEncryptor() doesn't have an overload accepting only a key. – KeithS Dec 13 '12 at 15:59
up vote 0 down vote

An initialization vector never needs to be secret (then it would be named "key").

Generally, the initialization vector requirements are only dependent on the mode of operation, not the choice of the block cipher (assuming you are using a secure one).

For CBC mode, you can use a fixed initialization vector when the same key is only ever used for one message (this means also: not multiple versions of the same message). If your key is calculated deterministically from the login credentials of the user, this will not work. (You could include a changing salt in the data used to create this hash, then this takes the security role of the initialization vector.)

A changing but predictable initialization vector is bad when the attacker can choose a message to be encrypted (and then observe the ciphertext). (An attacker-chosen initialization vector is equally bad, of course, even if she can't choose the message.)

A (cryptographically secure pseudo-)random initialization vector, stored together with the data, is generally safe for all modes of operations.

Please note that you'll often also want a MAC on the data, to make sure they are not changed. (If you don't do this and an attacker can modify the ciphertext and observe the reaction when you try to decrypt (multiple times), she can decrypt the ciphertext eventually.)

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.