AES-GCM Encryption Lab
Most crypto bugs are not broken math — they are confidentiality without integrity and a reused nonce. This lab runs real authenticated encryption in your browser with the Web Crypto API: generate an AES-GCM key, encrypt and decrypt, inspect the 128-bit tag, flip a bit and watch decryption fail closed, and see for yourself why reusing an IV leaks your plaintext. Then make the calls — unique IV, full tag, AAD binding, and AEAD over plain AES-CBC — and get graded.
The real job. More noise, a tighter clock.
Work the crypto bench
6 graded challenges that use real authenticated encryption in your browser via the Web Crypto API — generate an AES-GCM key, encrypt and decrypt, watch a tampered ciphertext get rejected, see why reusing an IV is catastrophic, and choose the right mode. Score on correct decisions plus a successful round-trip. Clear 75% to pass — finish under par for a speed bonus and a better grade.
What this lab is
- A free, 100% in-browser cryptography lab that runs REAL authenticated encryption via the Web Crypto API — no server, no account, nothing leaves your machine.
- Generate a 256-bit AES-GCM key, encrypt with a random 96-bit IV, and inspect the ciphertext and the 128-bit authentication tag the mode appends.
- Watch a one-bit tamper to the ciphertext get rejected at decryption — AEAD verifies the tag before releasing any plaintext, so it fails closed.
- See the nonce-reuse catastrophe live: encrypt two messages under the same key and IV and the XOR of the ciphertexts equals the XOR of the plaintexts.
- Graded decisions drill the real lessons: unique IV per message, keep the full tag, bind context in the AAD, and choose AEAD (AES-GCM / ChaCha20-Poly1305) over unauthenticated AES-CBC.
Frequently asked questions
What is the AES-GCM Encryption Lab?
A free, browser-based cryptography trainer that uses the real Web Crypto API (crypto.subtle) to do authenticated encryption. You generate an AES-GCM key, encrypt and decrypt a message, inspect the ciphertext and 128-bit tag, tamper with a ciphertext to see decryption fail, and work through graded challenges on nonce reuse, AAD binding, tag length and mode choice. Everything runs client-side — nothing is sent to a server.
Why is reusing an IV (nonce) so dangerous in AES-GCM?
GCM is a counter mode: the IV seeds the keystream. Encrypt two messages with the same key and IV and the identical keystream encrypts both, so XORing the two ciphertexts cancels the keystream and leaks the XOR of the plaintexts. Worse, nonce reuse lets an attacker recover the GHASH authentication key and forge valid tags. The fix is a unique nonce per message under a given key — a fresh random 96-bit IV is the standard choice.
What does the authentication tag actually protect?
AES-GCM is AEAD: it produces a tag computed over the ciphertext and any associated data (AAD). On decryption the tag is verified before any plaintext is released, so any change to the ciphertext, IV, tag or AAD makes decryption fail instead of returning manipulated bytes. That is what stops bit-flipping and padding-oracle attacks that affect unauthenticated AES-CBC.
Is any of this sent to a server?
No. The lab is entirely client-side and uses your browser’s built-in Web Crypto implementation. Keys, messages and ciphertext stay in the page; your best grade is saved only in your own browser’s local storage.