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?

Caning

Do you use the same key for more than one encryption operation? – Pineal

Yep I use the same key for encrypt every data on DB – Caning

The IV is not a secret value; you can store it in the clear alongside each encrypted value – Pineal

You should specify the mode of operation (such as CBC or CTR) in the question. The current answers assume CBC, but I don't see any hint in the question that that is what's being used. – Yusuk

If you cannot store the IV anywhere then you could consider Format Preserving Encryption (FPE). – Yusuk

Answer 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.

Anthracoid

Answer 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.

Margit

"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. – Yusuk

Nope. IV is the "zeroth" block of a chain cipher. An IV needs to be (1) random, (2) Unpredictable, but (3) not secret. #5797454 – Margit

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. – Yusuk

Answer 3

Without the original IV, you wont be able to decrypt first 16 bytes of the message, but you will be able to decrypt the rest of it with any random IV. If you don't want to lose the first 16 bytes and also don't want to store the original IV, you can stuff random 16 bytes at the beginning before encryption. Then after decryption with a random IV (can be different than one used for encrypting) remove the first 16 bytes, what remains is your original message.

PS: If this sounds wrong, I know, was just humbled debating the same. Try it.

Casefy

The OP does not specify the mode of operation. What you describe here only applies to the CBC mode! – Kunz