The uniqueness of the initialization vector
I started an answer a while ago but crashed which lost what I invested. What I said was as follows:
It depends...
The key point is that if you ever reuse an IV, you open yourself up to cryptographic attacks that are easier to perform than those when you use a different IV each time. So, for each sequence where you need to encrypt again, you need a new unique IV.
You also need to look for crypto modes - Wikipedia has a great illustration of why you shouldn't use ECB. The CTR mode can be very helpful.
If you encrypt each record separately, then you need to create and record one IV for the record. If you encrypt each field separately, then you need to create and write one bit for each field. IV storage can be a significant overhead, especially if you are doing field-level encryption.
However, you need to decide if you need field-level encryption flexibility. You can - it's unlikely, but there may be advantages to using the same key but different IVs for different fields. OTOH, I strongly suspect this is overkill, let alone stress your IV (cryptographic random number generator).
If you can afford to do page-level encryption rather than line-level encryption (assuming there are fewer lines than the page), then you can use one IV per page.
Erickson wrote:
You can do something smart like generate one random value per record and use the hash of the field name and the random value to generate an IV for that field.
However, I believe the best approach is to store the structure in a field that collects the algorithm identifier, the required parameters (such as IV) for that parameter, and the ciphertext. This can be saved as a small binary package, or encoded into some text like Base-85 or Base-64.
And Chris commented:
I am actually using CBC mode. I thought of an algorithm to do 1: many, so I can only store 1 IV per write. But now I am considering your idea of storing the cipher text IV. Can you give me some more advice: I am using PHP + MySQL and many of the fields are varchar or text. I don't have much experience with binary in a database, I thought the binary was database-unfriendly, so I always base64_encoded when storing binaries (like IV).
To which I would add:
-
IBM DB2 LUW and Informix Dynamic Server use Base-64 encoding to output the characters of their ENCRYPT_AES () and associated functions, preserving the encryption scheme, IV and other information, and encrypted data.
-
I think you should take a close look at the CTR mode - as I said before. You can create a 64 bit IV of, say, 48 bits of random data plus a 16 bit counter. You can use the counting part as an index in the record (perhaps in 16 byte blocks - one crypto block for AES).
-
I am 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 values.
-
If you are using a single IV for writing, but using separate CBC encryption for each field, then each field must be filled up to 16 bytes and you are definitely indulging in "IV reuse". I think this is cryptographically unreasonable. You would be much better off using a single IV for the entire record and one unit of indentation for the record and CBC mode, or no indentation and CTR mode (since CTR does not require padding - one of its merits, another is that you only use encryption encryption mode for data encryption and decryption).
source to share
Once again, Appendix C NIST pub 800-38 may be helpful . For example, according to this, you can generate an IV for CBC mode by simply encrypting a unique key without an encryption key. It's even easier if you use OFB, then the IV just needs to be unique.
There is some confusion about the actual requirements for a good IV in CBC mode. So I think it is helpful to briefly discuss some of the reasons behind these requirements.
Let's start by looking at why IVs are needed. IVs randomize ciphertext. If the same message is encrypted twice with the same key (but different IVs), then the ciphertexts are different. An attacker who is given two (equally long) ciphertext cannot determine if the two ciphertexts encrypt the same plaintext or two different plaintext. This property is commonly referred to as ciphertext indistinguishablility . Obviously this is an important property for database encryption, where many short messages are encrypted.
Next, let's see what can go wrong if IVs are predictable. Let's say Ericksons Suggestion:
"You could do something smart, like generate one random value per record and use the field name hash and the random value to generate an IV for that field."
It's not safe. For simplicity, assume that user Alice has a record in which there are only two possible values m1 or m2 for field F. Let Ra be the random value that was used to encrypt Alice's record. Then the ciphertext for field F would be
E K (hash (F || Ra) xor m).
The random Ra is also saved in the recording, as it would otherwise be impossible to decipher. An attacker Eve who would like to know the value of Alice's entry can proceed as follows: First, she finds an existing entry where she can add the value of her choice. Let Re be the random value used for this record and F 'the field for which Eve can represent its own value v. Since the record already exists, we can predict the IV for the field F ', i.e. It
hash (F '|| Re).
Eve can use this by choosing her v value as
v = hash (F '|| Re) xor hash (F || Ra) xor m1,
let the database encrypt this value which
E K (hash (F || Ra) xor m1)
and then compare the result with Alice's record. If the two results match, then she knows that the value m1 was stored in Alice's record, otherwise it will be m2. You can find variations of this attack by searching for "block-adaptive plaintext selected attack" (for example, in this article ). There is even a variant that worked against TLS.
The attack can be prevented. Perhaps encrypting the random one before using it in the record, output IV, encrypting the result. But then again, perhaps the simplest thing is that NIST is already offering. Create a unique nonce for each field you encrypt (it could just be a counter), encrypt the nonce with the encryption key and use the result as an IV.
Also note that the attack above is the selected plaintext attack. Even more dangerous attacks are possible if the attacker has the ability to make the chosen ciphertext attacks, i.e. Can she change your database. Since I don't know how your databases are protected, it is difficult to file any claims.
source to share
The requirements for IV uniqueness depend on the "mode" in which the cipher is used.
For CBC, the IV must be unpredictable for a given message.
For CTR, IV must be unique, period.
For the ECB, of course there is no IV. If the field is short, a random identifier that fits in one block, you can safely use ECB.
I believe a good approach is to store the structure in a field that collects the algorithm ID, the required parameters (such as IV) for that algorithm, and the ciphertext. This can be saved as a small binary package, or encoded into some text like Base-85 or Base-64.
source to share