Encrypt-then-MAC Envelope Visualizer

About This Tool

Every file in the vault is an encrypt-then-MAC envelope: [ver][iv][hmacTag][cipher]. This tool builds one for real in your browser — it derives separate encKey and macKey sub-keys, encrypts the secret with AES-256-CBC, and authenticates the version byte, IV, and ciphertext together with HMAC-SHA256.

It is the interactive companion to the article A Vault File That Fails Closed: Encrypt-then-MAC on an MCU.

How do I use it?

1. Type a secret and a passphrase, and set the authenticated context (record type, slot, generation). The envelope re-seals live as you type.

2. Click any byte to flip it, or pick one of the seven attacks: flip a cipher/IV byte, forge the tag, truncate the ciphertext, move the file to another slot, change its record type, or roll back its generation.

3. Watch the read-path verdict. Under encrypt-then-MAC every attack fails closed — and the tool tells you why each one fails (a different reason for each).

4. Flip the read path to decrypt-first and press Run the padding-oracle attack: a real Vaudenay attack recovers the last plaintext block byte-by-byte using only the padding-valid/invalid signal — no key. Switch back to encrypt-then-MAC and the same attacker goes silent.

What does it show?

• Key separation — one passphrase becomes a master key, which fans out into distinct encKey and macKey sub-keys.

• Context binding — the tag covers ver ‖ recordType ‖ slotId ‖ generation, so relocating, retyping, or rolling back a file breaks the MAC even though the ciphertext is pristine.

• Verify-before-decrypt & fail-closed — the tag is checked first, so a tampered file never reaches the AES-CBC decrypt path, and any failure returns nothing.

• The doom path — decrypt-first runs the cipher on attacker bytes before the MAC, exposing a genuine padding oracle.

• CBC malleability — flipping an IV byte flips the matching plaintext byte of block 0 by the same amount: the attacker’s lever.

The construction, in formulas

Sealing (write path):

encKey = HMAC(master, "vault-enc")
macKey = HMAC(master, "vault-mac")
C      = AES-256-CBC-Encrypt(encKey, IV, PKCS7(P))
tag    = HMAC-SHA256(macKey, ver ‖ recordType ‖ slotId ‖ generation ‖ IV ‖ C)
file   = [ver] [IV] [tag] [C]

Reading under encrypt-then-MAC (verify, then decrypt):

tag' = HMAC-SHA256(macKey, context ‖ IV ‖ C)
if not constant_time_equal(tag', tag): reject   // fail closed, no plaintext
P    = unpad(AES-256-CBC-Decrypt(encKey, IV, C))

Why the order is the whole game — the work an attacker faces:

• Forge a tag without macKey: a brute force of 2^256 (HMAC-SHA256) — infeasible.

• Padding oracle (decrypt-first): ~1 bit per query, ≤ 256 queries per byte → a 16-byte block in ≤ ~4096 queries.

• Encrypt-then-MAC removes the oracle outright: for a forged file the decrypt step is unreachable, so the attack drops from linear to impossible.

Why CBC malleability is the lever

In CBC, P_i = Decrypt(C_i) ⊕ C_(i-1) (with C_(-1) = IV). So ΔP_i = ΔC_(i-1): flipping a byte of the previous block — or of the IV, for block 0 — flips the same byte of the plaintext by the same amount, predictably. That controlled change is exactly what lets a padding oracle walk the plaintext out one byte at a time.

References & further reading

• Bellare & Namprempre — Authenticated Encryption: Relations among Notions and Analysis of the Generic Composition Paradigm

  (encrypt-then-MAC is the generically secure composition)

• Krawczyk — The Order of Encryption and Authentication for Protecting Communications

• Vaudenay (2002) — Security Flaws Induced by CBC Padding

  (the original padding-oracle attack)

• Moxie Marlinspike — The Cryptographic Doom Principle

• RFC 2104 — HMAC ·

  RFC 5652 §6.3 — PKCS#7 padding

• NIST SP 800-57 Part 1

  (one key, one purpose) ·

  FIPS 180-4 — SHA-256

Privacy

All cryptography runs entirely in your browser via the Web Crypto API. Nothing you type is transmitted to any server.