Question

Best practice is to use unique ivs, but what is unique? Is it unique for each record? or absolutely unique (unique for each field too)?

If it’s per field, that sounds awfully complicated, how do you manage the storage of so many ivs if you have 60 fields in each record.

Answer 1

I started an answer a while ago, but suffered a crash that lost what I’d put in. What I said was along the lines of:

It depends…

The key point is that if you ever reuse an IV, you open yourself up to cryptographic attacks that are easier to execute than those when you use a different IV every time. So, for every sequence where you need to start encrypting again, you need a new, unique IV.

You also need to look up cryptographic modes – the Wikipedia has an excellent illustration of why you should not use ECB. CTR mode can be very beneficial.

If you are encrypting each record separately, then you need to create and record one IV for the record. If you are encrypting each field separately, then you need to create and record one IV for each field. Storing the IVs can become a significant overhead, especially if you do field-level encryption.

However, you have to decide whether you need the flexibility of field level encryption. You might – it is unlikely, but there might be advantages to using a single key but different IVs for different fields. OTOH, I strongly suspect that it is overkill, not to mention stressing your IV generator (cryptographic random number generator).

If you can afford to do encryption at a page level instead of the row level (assuming rows are smaller than a page), then you may benefit from using one IV per page.

---

Erickson wrote:

You could do something clever like generating one random value in each record, and using a hash of the field name and the random value to produce an IV for that field.

However, I think a better approach is to store a structure in the field that collects an algorithm identifier, necessary parameters (like IV) for that parameter, and the ciphertext. This could be stored as a little binary packet, or encoded into some text like Base-85 or Base-64.

And Chris commented:

I am indeed using CBC mode. I thought about an algorithm to do a 1:many so I can store only 1 IV per record. But now I’m considering your idea of storing the IV with the ciphertext. Can you give me more some more advice: I’m using PHP + MySQL, and many of the fields are either varchar or text. I don’t have much experience with binary in the database, I thought binary was database-unfriendly so I always base64_encoded when storing binary (like the IV for example).

To which I would add:

• IBM DB2 LUW and Informix Dynamic Server both use a Base-64 encoded scheme for the character output of their ENCRYPT_AES() and related functions, storing the encryption scheme, IV and other information as well as the encrypted data.

• I think you should look at CTR mode carefully – as I said before. You could create a 64-bit IV from, say, 48-bits of random data plus a 16-bit counter. You could use the counter part as an index into the record (probably in 16 byte chunks – one crypto block for AES).

• I’m not familiar with how MySQL stores data at the disk level. However, it is perfectly possible to encrypt the entire record including the representation of NULL (absence of) values.

• If you use a single IV for a record, but use a separate CBC encryption for each field, then each field has to be padded to 16 bytes, and you are definitely indulging in ‘IV reuse’. I think this is cryptographically unsound. You would be much better off using a single IV for the entire record and either one unit of padding for the record and CBC mode or no padding and CTR mode (since CTR does not require padding – one of its merits; another is that you only use the encryption mode of the cipher for both encrypting and decrypting the data).