PQKEM Ceremony Console

How this ceremony works

A complete guide to running a quantum-safe key establishment exchange with this console.

What you are about to do

Two organizations establish the same AES-256 key by exchanging files over email, using ML-KEM-768 (NIST FIPS 203), a key encapsulation mechanism designed to resist quantum computers. No secret ever travels in the clear: the emailed artifacts are a public key, a ciphertext, and a short check value. All cryptography runs inside this browser tab; this page makes zero network requests.

Before you start

Agree with the counterparty which exchange this is (EX1 or EX2), who initiates, and which mode to use.
Fill in the session bar: exchange id, your party name, counterparty name, your role.
Have a phone call or chat channel ready for confirming fingerprints and KCVs. Email alone cannot prove who sent a file.

The six steps

Step	Who	What happens
1 Generate	initiator	Creates the ML-KEM-768 key pair. The public key (1184 bytes) will be shared; the private key never leaves the machine.
2 Share	initiator	Downloads the public key artifact and emails it as an attachment. Both sides confirm the key fingerprint on a call.
3 Encapsulate	responder	Imports the public key, runs encapsulation, and obtains the AES-256 key plus a 1088-byte ciphertext. Shows the KCV.
4 Return	responder	Downloads the ciphertext and KCV artifacts and emails them back.
5 Decapsulate	initiator	Imports the ciphertext and recovers the AES-256 key with the private key.
6 Verify	both	Key check values are compared. A green MATCH means both sides provably hold the same key; that is the PoC success criterion.

The three modes

Mode	How the AES-256 key is obtained
`direct`	The 32-byte ML-KEM shared secret is the key. Simplest; start here.
`kdf`	The key is derived with HKDF-SHA-256 from the shared secret. Salt and info travel inside the artifact.
`wrap`	The responder generates the key and wraps it with AES-KW under the shared secret. Use when the responder must choose the key.

Files: what travels, what never leaves

Email these: *_publickey.json (or .pem), *_ciphertext.json, *_kcv.json, *_confirmation.json.
Never email: the private key and any *_key.bin. This console keeps the private key in tab memory; the optional download exists only for your own continuity.
Always send artifacts as attachments, never pasted inline: mail clients rewrap and corrupt inline text. Quote each file's SHA-256 in the email body.
Every artifact carries per-payload digests; imports are verified before any cryptography runs, so email corruption is caught immediately.

Verification and the implicit-rejection trap

ML-KEM decapsulation never fails visibly. A corrupted ciphertext quietly produces a different key (FIPS 203 calls this implicit rejection). The KCV comparison in step 6 is therefore the only real proof. Never skip Verify.

Banking KCV: first 3 bytes of AES-256-ECB over a zero block, 6 hex chars, read aloud on the call.
SHA-256 fingerprint: first 8 bytes of the key's hash, 16 hex chars.
Both values appear wherever a key is established; the counterparty needs to match either one.

Importing from other tools

The import zones accept our JSON envelope, standard PEM (-----BEGIN PUBLIC KEY-----), raw DER, bare base64, and hex. If the counterparty uses different tooling (OpenSSL, Bouncy Castle, an HSM), their public keys and ciphertexts still work; format friction is itself a documented learning objective of this PoC.

After the exchange

Use Print session report to save a PDF of the full operation log for the debrief.
Record any friction in the learnings template (docs/learnings-template.md in the repo).
Keys established here are disposable test material. Do not protect real data with them.

PQKEM Ceremony Console

Session

Ceremony

Proof points

Operation log

How this ceremony works

What you are about to do

Before you start

The six steps

The three modes

Files: what travels, what never leaves

Verification and the implicit-rejection trap

Importing from other tools

After the exchange

PQKEM Ceremony Console

Session

Ceremony

Proof points

Operation log copy

How this ceremony works

What you are about to do

Before you start

The six steps

The three modes

Files: what travels, what never leaves

Verification and the implicit-rejection trap

Importing from other tools

After the exchange

Operation log