2
$\begingroup$

I'm trying to implement an IV that won't need to be stored on it's own. I'm considering 3 options:

  1. Since I'm using PBKDF to generate a key I could use some bytes from the generated hash
  2. I could use some bytes from the randomly generated salt and split it somehow
  3. I could generate a random separate IV, and stick it to the generated password bytes

Are there any safety guidelines of what should and should not be done when doing things like this? I'm pretty sure that options 2 and 3 are better suited, since they provide randomness

Improve this question
$\endgroup$
3
  • 1
    $\begingroup$ Which mode are you using (e.g. AES-GCM, AES-CBC, AES-CTR)? With something like AES-GCM, as long as the key is unique each encryption, you could keep the nonce as all-zeros. However, that doesn't apply to every mode and shouldn't really be the go-to. $\endgroup$
    – samuel-lucas6
    Commented Apr 5, 2023 at 12:33
  • $\begingroup$ @samuel-lucas6, I'm using AES-CBC $\endgroup$
    – snow
    Commented Apr 5, 2023 at 13:50
  • 2
    $\begingroup$ In that case, ignore what I just said unless you can swap. $\endgroup$
    – samuel-lucas6
    Commented Apr 5, 2023 at 19:08

1 Answer 1

Reset to default
3
$\begingroup$

Using PBKDF1 or PBKDF2 to generate a key from a password supplied by a user is no longer considered best practice, because adversaries with GPUs, FPGAs or (conjecturally) ASICs are able to evaluate the function (and thus test passwords from dictionaries) so much faster than legitimate users. PBKDF2 is fine for high-entropy passwords, only. For password supplied by a user, you want the extra protection of a memory hard function, e.g. Argon2.

Option 2 is perfectly fine and most standard practice IMHO: we can use the salt of the KDF as IV, or vice versa. The requirement is the same: unpredictable (and large enough that it won't repeat).

Option 1 is also fine as long as the output of the KDF is split into a key and an IV: if does not harm to make IV secret, rather than public as in 2 and standard practice.

Option 3 is fine if somewhat the password is stored.

In all cases, we need one independently chosen IV per encryption (e.g. per file). That's a must if the key is the same for multiple encryptions, and recommendable even if not (IV reuse may allow multi-target attacks).

Improve this answer
$\endgroup$
2
  • 1
    $\begingroup$ Thanks for replying. The encrypted password will need to be persisted (passwords in plaintext required for an external service). As for the hashing algorithm, I know that most hashing algorithms provide better safety due to higher resource use, however the key's hash won't be stored. It will be provided to me with each decryption request. I think a leaked key wouldn't be an issue in this case so I used the less resource consuming PBKDF2. Could you elaborate on the same password for multiple files case? Would #2 it not be fine if I was provided with same pass that had different salts? $\endgroup$
    – snow
    Commented Apr 5, 2023 at 14:04
  • 1
    $\begingroup$ @snow: I updated per your comment above (I had assumed the password is not stored). I now centralize the requirement of one IV per file. How it's met depends heavily on how things are generated/stored, and I leave that to you. If your "passwords" have high entropy, PBKDF2 is fine and uses less RAM than Argon2 (not necessarily less work: that depends on workfactor, but it can be turned down if your "passwords" have high entropy). $\endgroup$
    – fgrieu ♦
    Commented Apr 5, 2023 at 14:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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