Turn a message you can read into bytes only a key reopens.
“hello world”anyone can read this
sealing…sealed — gibberish without the key
🔓
That’s the whole idea: readable → sealed, and only the matching key turns it back. The rest of this page is where that key comes from, and what happens when it crosses a wire Eve is watching.
scroll ↓
First, Alice & Bob meet in person
Face to face — nothing on the wire yet.
👩🤝🧔
…=…
one shared secret — only these two hold it
😈 Eve wasn't at the meeting — she never gets this secret
The secret is made in person, so it never crosses the wire. Update it as often as they like — Eve still can't copy what she never sees. The catch: they had to meet at all (more at the end).
Alice locks the message with that secret
Type below — watch the bytes react ↓
seal( msg, secret, nonce )
sealing…
🔑 secret …🎲 nonce …
nonce12 B · random · public · fresh every message
ciphertextyour message, encrypted · same length as the text
tag16 B · authentication — detects any change
Change one character, the secret, or the nonce — the highlighted bytes scramble. Tiny input change → totally different output.
Alice sends it — and Eve is tapping the wire
Every byte on the wire, Eve copies. Watch the midpoint.
👩Alice🧔Bob🔒🔒😈Evetaps the wire
🔒 Eve's copy: — no key, no message
Eve gets a perfect copy of the sealed bytes — but with no secret they’re gibberish. The plaintext never crossed the wire.
Only Bob's matching secret unlocks it
🧔 Bob … ✓ has the secret
“Meet me at the pier at 9”
✓ authentic
😈 Eve no secret
🔒 can't open — junk
Same sealed bytes reach both. Bob’s matching secret turns them back into the message; Eve’s copy is useless.
The catch — and how to escape it
All of this worked only because Alice and Bob met in person to share that secret. Two strangers on the internet can’t do that.
Asymmetric cryptography fixes exactly this: Alice and Bob can agree on a shared secret over Eve’s own wire, having never met. The trade-offs — it’s much slower, and it only holds if you can trust whoyou’re really talking to (Eve could pose as Bob), so it leans on identities, certificates, and signatures.
AES-GCM is the right tool once you already share a key. Everything it doesn’t do maps to another buffer-crypto primitive — these are the pieces real systems (TLS, Signal, HPKE) combine. See the Cryptography recipe for the API.
AES-GCM alone doesn’t…
…reach for
You must already share the key — but how, if you’ve never met?
→
Swap public keys on the open wire; each side derives the same secret (Eve can’t).
Key agreement · X25519/ECDHscene soon
…or seal to someone with no round-trip at all.
→
Encrypt directly to a recipient’s public key.
HPKEscene soon
Can’t prove which key-holder sent it — Alice and Bob can forge to each other.
→
Sign with a private key; anyone verifies with the public key. Non-repudiable.
Signatures · Ed25519/ECDSAscene soon
A raw Diffie–Hellman secret isn’t a uniform key.
→
Run it through a KDF before use as an AES key.
HKDF
Replay isn’t prevented — a valid packet stays valid forever.
→
Bind a sequence number or timestamp into the AAD; track used nonces.
Protocol-layer freshness
Hides content, not length — Eve still learns the byte count.
→
Pad messages to a fixed bucket when length is sensitive.
Padding
Reusing a (key, nonce) pair is catastrophic.
→
Draw a fresh nonce every message — buffer-crypto’s seal does this for you.
Fresh nonce
Want the theory? Symmetric vs. asymmetric
Two problems, two tools
Cryptography here answers two different questions. Pick the tool by which situation you’re in.
“We already share a secret key.”
→ Symmetric AEAD — AES-GCM
Seal a message so only key-holders can read it, and any tampering is rejected. Fast and compact — this is what protects the actual data.
“We’ve never met — how do we get a key, and who are you?”
→ Asymmetric (public-key)
Key agreement — swap public keys, each derives the same secret (Eve can’t)
HPKE — seal to a recipient’s public key, no round-trip
Signatures — sign with private, verify with public → proves which party
Real systems use both: asymmetric to establish the key & prove identity, then symmetric (AES-GCM) for the bulk data — that’s TLS, Signal, and HPKE.
Symmetric (AES-GCM)
Asymmetric (ECDH / HPKE / signatures)
use when
you already share a key
you’ve never met / need identity
pros
fast, compact, simple
no pre-shared secret; public keys are shareable; signatures prove who
cons
key distribution; can’t prove which key-holder
slower, larger; you must trust the public key (MITM risk)
✓ good practice
Draw a fresh nonce every message (buffer-crypto does this for you).
Run any shared / Diffie–Hellman secret through a KDF (HKDF) before using it as a key.
Authenticate the peer’s public key (certificate or known fingerprint) before trusting it.
Always authenticate, not just encrypt — use AEAD/HPKE, never bare encryption.
Pick the tool for the job: secrecy → AEAD/HPKE; who signed it → signatures.
✗ footguns
Reuse a (key, nonce) pair — catastrophic for AES-GCM (it leaks the auth key).
Use a raw DH output directly as a key (it isn’t uniform — KDF it first).
Trust a public key you got over the same wire Eve controls → MITM.
Encrypt without authenticating (padding / decryption-oracle attacks).
Use a signature to hide data, or encryption to prove identity — wrong tool.