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

[Junxiao Shi]

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.

[Matheus Cardoso]

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

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

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

[Matheus Cardoso]

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

Edit: done