What Are The Best Practices (Application Security Policy) For Modifying Rijndael Salt, IV, Pass Phrase

Question

(Note: originally posted in SO - advised to post on SSE)

With regards to Rijndael encryption, what (if any) are the best practices (and consequences) regarding the periodic modification of one or more of these values (specifically in a C# .NET web application):

• Salt
• Initialisation vector (IV)
• Pass phrase

Is it common practice (or in fact necessary) to change any of these values over the lifetime of an application? (For example, if one or more are compromised, or just as part of a general policy.)

If so, what will be the impact upon existing data in a database which was encrypted using the original (prior) values? By changing these values, one would think that the decryption of existing data would no longer 'work' (or return false information?).

(I imagine the scope of this question might include the way in which such values are stored - e.g. using third-party or otherwise secure storage mechanisms - so initially let us say the aforementioned values are currently stored in plain text in a class named RijndaelCryptography, and go on from there.)

To illustrate my question, please see the following link: How To: Encrypt and Decrypt Data Using a Symmetric (Rijndael) Key (C#/VB.NET)

Is that particular example in any way good practice (fixing the pass/salt/IV at code level)?

Update 1

• Removed "AES" from question.

Update 2

• I read that Microsoft advise using AES instead of Rijndael:

"The Rijndael class is the predecessor of the Aes algorithm. You should use the Aes algorithm instead of Rijndael. For more information, see the entry The Differences Between Rijndael and AES in the .NET Security blog." (Link - see half-way down that page)

Answer 1

AES only takes a key and an IV. The IV should be random and different for each encryption. Just prepend it to the ciphertext. I also strongly recommend adding authentication.

Concerning passphrases, I'd avoid them where possible in favour of a simple random key. Keys are simple secure and avoid the cost of key derivation. Only use passwords when the user needs to enter them.

When you really need a password, a sufficient iteration count, generate a random salt, and use PBKDF2(or better). This hashing and salting is only there to compensate for weak passwords.
When to choose a new salt in key derivation is more complicated. Ideally use a new random one for each encryption, but that might be too expensive. Sometimes you can reuse them, sometimes you can cache the key, but that's application dependent.

I wouldn't hardcode the key in your source-code. The web.config file seems like a more appropriate place. You can't really hide the key, since your application needs it.

Answer 2

You should not be implementing the crypto yourself. Given your questions, there are too many things you could get wrong. Instead, use a high-level library like GPG (to encrypt data at rest) or TLS (for data in motion).

(If you were implementing your own, you shouldn't generate encryption keys from a password; instead, you should be using a true-random key. You should be choosing a random IV for each message as required by the mode. And you should be using authenticated encryption / message authentication. But really, you shouldn't implement your own, as there's too much to learn.)

Answer 3

The existing answers are great, but ignore one important aspect of your question: migration to new IVs, modes, and keys.

The most straightforward way to do this is to add new columns to your database. One for an encryption key ID (a unique value to identify the encryption key used), one for the encryption algorithm, and one for the IV.

With your current setup, you would generate a UUID that will be an indirect reference to your current encryption passphrase. This will go in the key ID column for all existing ciphertexts. The full algorithm name, bit size, and mode (e.g., "AES-128-ECB" if that's the one you're using) will go in the algorithm column. And your current static IV goes in the IV column.

For new encryptions, create a new key from a CSPRNG (cryptographically-secure pseudorandom number generator) and a new UUID that will identify this key. Choose an appropriate mode (CBC and CTR are good choices; CBC requires, for all intents and purposes, random numbers from a CSPRNG while CTR requires only a unique nonce, which can be a simple counter). For each new encryption, generate a unique IV according to the IV requirements for the mode you've chosen. Encrypt the data using the key and IV, and store the key ID, the algorithm, the IV, and the ciphertext in your database.

For decryptions, use the key (referenced by ID), algorithm, IV, and ciphertext as recorded in the database. If the key ID matches the key you're currently using, you should also reencrypt the data using the process outlined above.

Answer 4

Generally, you create a new salt every time you re-encrypt whatever it is you're protecting with the salt (typically, a password).

A new IV should be used every time you encrypt a message. Duplicate IVs should never be used, i.e., every encrypted message should use a different IV value.

Passphrases are changed periodically, as frequently as is practical for the users. This can range from once a month to once a year. Most places I've worked at required us to change our login passphrases every 90 days. Changing passphrases too often leads to sloppy user habits (i.e., using post-it notes to keep track of them), while not changing them often enough increases the chance of a security breach.