AES 256 Encryption/Decryption without IV

Question

I'm developing an application that communicates with a DB located on a VPS. I need to store an information, encrypted with AES-256, in my DB.

If I'm correct, when I encrypt, there's an IV parameter which is generated and is different for each encryption. However when I decrypt, I don't have this parameter because I only have the key and the encrypted text in the DB.

What can I do to solve this problem?

Solution 1

You must store the initialization vector somewhere. Because, conceptually, in CBC mode the IV is the "zeroth" block of ciphertext, some people store it as prefix to the ciphertext. Most low-level decryption libraries don't expect this, however, so the application usually needs to provide a wrapper that handles adding this prefix after encryption and removing it before decryption.

Ideally, you should store encrypted values with some metadata that specifies the encryption algorithm that was used, any parameters that are needed, and indicates what key (note below!) is used. This would include the IV for a block cipher that used CBC. A standard format for this is the Cryptographic Message Syntax, or PKCS #7. Because it's a standard, you will likely have several options for an open-source library to handle the format.

By including this metadata, you can do things like rotate keys over time, or migrate data to new algorithms. You don't have to have every value encrypted the same way with the same key.

Note: When I say that the metadata indicates the key used, this doesn't mean the key itself is included, of course! For pre-shared keys, it's just an label that tells you which key on your big keyring will decrypt the payload. For password-based encryption, there would be information about how to derive a proper key from the implied password.

Solution 2

You can concatenate the IV with the ciphertext (its length is known and constant), or you can store them next to each other in the DB. The IV isn't a secret; it just ensures that the block cipher is initialized differently per encryption so that brute-forcing one file decryption doesn't compromise all the others.

Comments

[Maarten Bodewes]

"so that brute-forcing one file decryption doesn't compromise all the others" is wrong for obvious reasons. Brute forcing would mean retrieving the key (which is next to impossible for AES anyway, given a well-chosen key). If the key is known by the attacker the other ciphertexts will also be compromised. For CBC mode repeating the IV would mean you can distinguish (partially) identical plaintext from (partially) identical ciphertext. For e.g. CTR mode the ramifications would be much larger, up to nullifying the confidentiality.

[David S.]

Nope. IV is the "zeroth" block of a chain cipher. An IV needs to be (1) random, (2) Unpredictable, but (3) not secret. stackoverflow.com/questions/5796954/…

[Maarten Bodewes]

That's all correct. The fact that a unique IV is required so that "brute forcing one file decryption doesn't compromise all the others" isn't correct. You would be able to compromise CTR mode through simple XOR'ing if you reuse the IV, but that attack would not be brute forcing. Brute forcing is about finding the right key to the permutation of the block cipher. The IV doesn't protect anything when the attacker has found the key. But OK, it seems you didn't confuse IV and salt, so I'll remove that comment.