TLS 1.3: keys are not enough

Exact cryptographic evidence

Separate agreement, identity and authenticated data

This lab performs real browser cryptography for an opening-handshake exercise. Two fresh P-256 ECDH key pairs independently derive a shared value. SHA-256 fingerprints let you compare the results without displaying private keys. The key schedule derives different client and server traffic secrets. A separate server signing key authenticates the handshake transcript, Finished values confirm transcript agreement, and a final AES-GCM record either decrypts successfully or fails authentication. These are different checks: deriving the same secret alone does not establish who the other endpoint is.

Choose identity and a fault

Requested hostname selects lab.example or other.example. The synthetic server identity names lab.example only. Trust this pinned server key controls whether the local identity policy accepts that signing key. This is a deliberately explicit fixture, not your browser certificate store. Tamper at selects no fault, CertificateVerify signature, server Finished or application ciphertext. Each fault flips one byte in the corresponding real cryptographic output before verification. Application message accepts at most 512 UTF-8 bytes; the live byte counter helps distinguish bytes from characters. Every edit begins a fresh cryptographic run and pauses inspection at its first stage.

Inspect a successful run

Keep lab.example, trust enabled and no tampering. Step to Derive handshake keys: the client and server agreement hashes match, while the directional traffic-secret fingerprints differ. Continue to Check server identity, Verify CertificateVerify, Verify server Finished and Verify client Finished. These checks succeed for the fresh fixture. At the application record, compare your input with the recovered plaintext. The encrypted byte string includes a sixteen-byte authentication tag, so its length exceeds the UTF-8 plaintext length even for an empty message. The displayed output is computed locally by WebCrypto, not selected from a success template.

Find the first failing gate

Disable trust or choose other.example. The run stops at identity rejection before accepting the server signature. This shows why a valid cryptographic signature cannot supply an external trust decision by itself. Restore the identity settings and tamper with the signature: actual ECDSA verification fails. Select server Finished instead: the signature succeeds, but the received HMAC differs from the independently derived expected value. Select application ciphertext: the handshake completes, but AES-GCM rejects the altered record and no plaintext is released. A later failure does not retroactively turn earlier checks into failures.

Explore text and fresh keys

Enter a short message containing the euro symbol or an emoji and compare its visible character count with the UTF-8 byte counter. Empty text is a valid message here and still produces an authentication tag. Oversized text is rejected before a run begins. New ephemeral keys regenerates the fixture without changing the chosen inputs. Public shares, fingerprints and ciphertext change between runs, so compare success conditions and relationships rather than expecting fixed hexadecimal strings. The key pairs are generated inside this page; no environment key, account credential, remote server or network connection is used.

Playback is inspection, not measured latency

Play reveals the selected run across sixty inspection seconds. Pause holds a stage, Next stage advances one, Restart rewinds the same completed cryptographic run and Speed changes inspection pace. Inspect time scrubs recorded evidence and Show final result jumps to the last stage. Restore defaults resets identity, fault and message settings and generates a new run. The diagram highlights the current message or local computation; peer-state cards and exact evidence show the matching verified result. Cryptography is prepared before playback, so a pause cannot alter its outcome. This is not a timing benchmark and does not imply a fixed percentage latency improvement over another protocol.

Read the implementation boundary carefully

The derivation uses SHA-256, HMAC, HKDF labels and fresh P-256 agreement with AES-128-GCM. Handshake messages are stable JSON teaching records, not TLS binary encodings. Certificate identity is a pinned-key and hostname fixture: there is no X.509 chain parser, expiry checking, revocation or public CA validation. The ECDSA signature is in WebCrypto raw format, and the application record uses synthetic additional authenticated data instead of a TLS record header. Handshake records themselves are not serialized and encrypted on a real transport. No version negotiation, HelloRetryRequest, resumption, zero-RTT, client certificate, key update, connection close or TCP delay is modeled. Do not copy this exercise as a production TLS implementation; use a maintained platform TLS stack.

Mechanism reference: TLS 1.3 specification, RFC 8446.