In implementing block-ciphers, I've had to calculate the initialization vector and have been stuffing those IV-bytes onto the first few bytes of the encrypted file (to be read in on the decryption process).

Should I be doing something different with the IV? Is there another strategy I should be employing?

  • 3
    It is common that IV is prepended and the authentication tag is appended. However, that is up to your implementation!. There is no security issue here! – kelalaka Oct 25 '19 at 19:30

Either prepending or appending the IV is standard practice. The IV needs to be unique (with a given key) and for some cipher modes also needs to be unpredictable, but it does not need to be secret; sending it in plain text alongside the ciphertext is fine. If you don't have a handy way to separate the IV and ciphertext in your transmission/storage system, just putting it either before or after the ciphertext is fine as long as the recipient knows where to expect the IV to be and how long it will be.

I'm a little concerned by the mention of "calculating" the IV, though. The IV should be the output of a secure random number generator, nothing more. While there might be calculation involved in the RNG, to you it should be a black box that spits out numbers suitable for use as symmetric keys or IVs.

  • 'Calculating' might be too strong of a word?? I've been using Key Derivation Functions to take in a varying length value (password) and output a standard quantity of bytes with a specified number of rounds. Once I get those KDF bytes for/from the password, I grab the next series of bytes from the same KDF instance relative to the block size of the algorithm I'm using--that's the only 'calculation'. – thepip3r Oct 28 '19 at 15:49
  • 1
    @thepip3r Ah, got it. That's not a great practice, because it ties the key and IV in a causal chain, and the IV needs to never be repeated for a given key. If you're using a sufficiently-high-entropy random salt for your KDF then you should be fine, but it's best to just draw the IV from the same high-entropy source even so. – CBHacking Oct 29 '19 at 3:57
  • I'd assumed the KDF was providing sufficiently high entropy and I don't really understand how that's a problem if I'm stuffing the IV onto the front of the file anyway?? If the bytes are visible regardless, why does it matter if it's grabbed from the KDF or an RNG? Are you saying an attacker could derive the password by way of the IV if they're pulled from the same KDF instance? Regardless, thanks for the dialogue. – thepip3r Oct 30 '19 at 15:32
  • 1
    KDFs, by themselves, do not provide any entropy. For a given set of inputs, a KDF produces a deterministic output. Now, one of those inputs is the salt, which is supposed to be highly random, but it's still best practice to not reuse the KDF for the IV if you have a secure RNG available. You should check out where the KDF's salt is coming from. Also, as with any password-based encryption, make sure the KDF is computationally expensive enough to make brute-forcing the password difficult. If the attacker can re-derive the key, it's game over. – CBHacking Oct 30 '19 at 18:54
  • 1
    Re: the IV's visibility, the IV isn't secret but it still is critical to the encryption's security that it be generated correctly. If you ever reuse a key and an IV, or (in some situations) if the attacker can even predict the IV in advance, it's much easier to break the encryption. Usually this doesn't reveal the password, or even the key, but the attacker isn't after those things; the attacker is after the message that the password/key is protecting, and a poorly-generated IV makes it much easier for the attacker to retrieve that message. – CBHacking Oct 30 '19 at 18:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.