AES encryption IV that won't need to be stored

snow

4/5/24, 11:29 AM

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

Since I'm using PBKDF to generate a key I could use some bytes from the generated hash
I could use some bytes from the randomly generated salt and split it somehow
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

103

1 + 3

salt

aes

initialization-vector

pbkdf-2

samuel-lucas6

4/5/24, 12:33 PM

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.

snow

4/5/24, 1:50 PM

@samuel-lucas6, I'm using `AES-CBC`

samuel-lucas6

4/5/24, 7:08 PM

In that case, ignore what I just said unless you can swap.

Score:3

Crypto

fgrieu

4/5/24, 12:23 PM

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

+ 2

snow

4/5/24, 2:04 PM

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?

fgrieu

4/5/24, 2:45 PM

@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).

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: AES encryption IV that won't need to be stored

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.