Timeline for Hardcoded PBKDF2 salt for password based AES-GCM?
Current License: CC BY-SA 4.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 18 at 1:43 | comment | added | Tamás Bolvári | I'm the only user. | |
| Nov 18 at 1:13 | comment | added | SAI Peregrinus | Two users with the same password could then decrypt one another's ciphertexts. Not storing the key doesn't matter, it's still wildly insecure. | |
| Nov 18 at 0:37 | comment | added | Tamás Bolvári | Thank you, but is my case the same as storing password hashes of several users in a database? Without random salt, same passwords result in the same key, I see. But what's wrong with that, in my case? The key is not stored, not transmitted. Its only purpose is to use it for the encryption. Then, the key is deleted immediately. Only the ciphertext is uploaded and saved. (And the initialization vector. Which is unique for each encryption, so the AES results will differ from each other, even if the PBKDF2 keys are always the same.) | |
| Nov 17 at 19:42 | history | answered | Swashbuckler | CC BY-SA 4.0 |