AES CBC with random IV but key from PBKDF2 with same salt

Daniel Aguiar

5/18/24, 3:01 PM

TL;DR: Is encrypting data with AES CBC with random IV + PBKDF2 key using the username as salt safe?

I have searched the internet, but I could not find a proper answer that encompasses the "AES CBC and random IV with PBKDF2 same salt" dilemma.

The scenario
I am developing a client/server/DB system, and my users need to have their data encrypted and accessible from multiple devices.

Users log in with a username and password. The username and password hash (bcrypt) are saved to the database.
Users create a series of items (user content) on their devices.
Each item the user creates is encrypted with AES CBC and gets its random IV. Every item will use the same key generated via PBKDF2 with 310.000 iterations using the username as salt.
Encrypted content is saved into the database along with IV (the key is not sent to DB, of course).
Users can log in to another device and get content downloaded and decrypted using a (reverse) process as described in step 3.

Maybe it is relevant to understand that users will not share data. It is individual.

Why not different salts and, therefore, different keys?
I have tried using different salts and storing the salts along IV and the encrypted item, but using different salt in PBKDF2 for every item the user creates is painfully slow (given the 310k iterations). It is slow, mainly when the user downloads his 100s of items from DB. It was unacceptable.

1 + 0

salt

aes

pbkdf-2

Score:1

Crypto

Martin Bonner supports Monica

5/18/24, 3:53 PM

The point of salting is to prevent an attacker preparing a rainbow table - that is, for every interesting password, calculate the hash, and then look to see if any of the password hashes match.

For an application which has multiple installations, there may be some usernames ("admin", "root", "jsmith") which get reused. For a very widely distributed application, it might be worthwhile constructing the rainbow table. If you can add some value into the salt which is unique per installation (e.g. some random value created at installation time), that should defeat that. Alternatively, you may decide the risk is low enough not to worry about.

I am not a cryptographer, I only play one on the internet. One of the rules I use for keeping out of trouble is "never reuse keys". However, you don't need to rerun PBKDF2 again for each object - you calculate that once, and then just feed the output of that + some value which is unique for each file into a key derivation function like HKDF, and use that to encrypt the file. Alternatively, a real cryptographer may be along shortly to say "nah, using the same key is fine".

I would not reuse the IV as your unique value for differentiating the key (without reassurance from a cryptographer), but it certainly should be safe to generate a random value, and then use HKDF on that to generate one value which is used as the IV, and another value which is used to differentiate the key (then store the root random value in the database).

+ 3

Daniel Aguiar

5/18/24, 4:53 PM

Thanks for your comments! I like the idea to add randomness to the salt. In my case IVs are unique as well; every item gets its own IV. The problem with generating a key for every item is that when the items are downloaded (think of 100s), to decrypt them, I need to regenerate 100s of keys (remember, every item was encrypted with a different key). With PBKDF2 on 310k iterations, those 100s items take 10+ seconds to be decrypted (this is too much for our users). What takes the bulk of 10 seconds is the PBKDF2 being run to find the individual key of every single item.

Martin Bonner supports Monica

5/18/24, 4:59 PM

Yes. So don't run PBKDF2 hundreds of times. Run it _once_ and then generate the actual decryption keys by running HKDF hundreds of times - that should take something less than a millisecond.

Daniel Aguiar

5/22/24, 3:47 PM

I have implemented PBKDF2 and then HKDF.

Elon Musk

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

EN: AES CBC with random IV but key from PBKDF2 with same salt

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.