Open zeruniverse opened 3 years ago
The problem with AES-CBC is, that it's not authenticated. For that reason, I've explicitly decided to use GCM.
As the nonce is 96 bits, I think the probability of two ciphertexts sharing the same nonce is negligible.
If you think through this, you will find you don’t need authentication in this case -
Your encrypter/ decrypter are the browser. In your design, you assume browser is safe. I.e. no one can call this encrypter/decrypter except the user.
On Sat, Aug 14, 2021 at 4:11 AM Benjamin Häublein @.***> wrote:
The problem with AES-CBC is, that it's not authenticated. For that reason, I've explicitly decided to use GCM.
As the nonce is 96 bits, I think the probability of two ciphertexts sharing the same nonce is negligible.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/BenjaminHae/modern-password-manager/issues/52#issuecomment-898880709, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDO6NAJBLXNQRGVDW6O2YLT4ZFP3ANCNFSM5B7QM73Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .
Your argument sounds reasonable, I'm going think about this in the next week.
I still want authenticated encryption as I consider the probability of collisions for the nonce irrelevant (I do not have $2^31$ accounts) . But I could offer a configuration parameter for the encryption algorithm so you can change it to AES-CBC for your instance.
Although not likely, randomly generated iv can be same and using same iv + key to encrypt two messages using GCM, attacker can get xor of the raw data. It's better to use AES-CBC to make it theoretically secure.