DEV Community

Discussion on: End-to-End Encrypted Chat with the Web Crypto API

Collapse
yoursunny profile image
Junxiao Shi • Edited

The usage of constant IV with AES-GCM completely breaks its security. With AES-GCM, the application must guarantee that the IV is never repeated. Otherwise, it's a catastrophic failure.

If you use AES-GCM, each direction needs a different key or use a different IV range, and the IV should include a counter portion that is incremented for each AES block, then the keys must be rotated once the counter reaches the maximum.

It's simpler to use AES-CBC with random IV, and send the IV together with each message.

Collapse
cardoso profile image
Matheus Cardoso Author • Edited

Hi! Thanks a lot for the feedback. I missed this information while doing my very superficial research about AES-GCM (I just saw it wasn't sensitive, but didn't see it had to change every time). I'm currently changing the tutorial's approach to this and removing the misleading info.

Edit: done

Collapse
yoursunny profile image
Junxiao Shi

Last time I designed a system using random IV with AES-GCM and it got rejected in security review. Crypto expert says IV must have three parts:

  • Sender identifier. Suppose two parties are using the same key, 1 bit should be used to identify the encrypting party.
  • Random bits, 64 bits minus sender identifier.
  • Counter bits, 32 bits. Start from zero, incremented for each AES block (not message). Key must be rotated when the counter reaches maximum.
Collapse
crimsonmed profile image
Médéric Burlet

totally agree I flipped when I read this:

It's not a sensitive parameter in basic end-to-end encryption and only changes in more advanced use cases.

Collapse
cardoso profile image
Matheus Cardoso Author • Edited

Thanks a lot for the feedback. I made wrong assumptions while reading something quickly. I'm fixing the tutorial :)

Edit: done