HPKE Playground — bac à sable HPKE : chiffrement hybride à clé publique et Oblivious HTTP
Choisissez une suite (DHKEM(X25519), DHKEM(P-256), ML-KEM ou X-Wing, avec HKDF et AES-GCM ou ChaCha20-Poly1305), scellez un message pour une clé publique, puis ouvrez-le avec la clé privée. Chaque valeur intermédiaire de la dérivation des clés (key schedule) de la RFC 9180 est affichée, et l’onglet Oblivious HTTP décode la configuration de clé d’une passerelle et exécute un échange complet, requête et réponse.
100 % local : les clés, les PSK et les textes clairs restent dans votre navigateur ; HPKE s’exécute dans un Web Worker chargé depuis ce site et n’envoie rien nulle part
Suite de chiffrement
0x0041 · 0x0001 · 0x0001 · draft-ietf-hpke-pq-05
Chiffrement pour la clé publique du destinataire ; n’importe qui pourrait être l’expéditeur. Le KEM ML-KEM-768 n’a pas de mode authentifié ; auth et auth_psk exigent un KEM Diffie-Hellman.
enc 1 088 octets · clé publique 1 184 octets · clé privée 64 octets · secret partagé 32 octets
| KEM | enc (clé encapsulée) |
|---|---|
| ML-KEM-768 | 1 104 octets |
| DHKEM(X25519, HKDF-SHA256) | 48 octets |
| DHKEM(P-256, HKDF-SHA256) | 81 octets |
Destinataire
Message
Chiffrement déterministe (vecteurs de test uniquement)
Aléa d’encapsulation : 32 octets pour ML-KEM, 64 pour X-Wing. Si le champ est vide, un aléa neuf est tiré. Quiconque connaît cette valeur peut déchiffrer.
Texte chiffré
HPKE in one paragraph
Hybrid Public Key Encryption, RFC 9180, encrypts a message to someone's
public key. It is a recipe built from three parts named by IANA code points. A
key encapsulation mechanism (KEM) agrees on a shared secret and outputs enc, the value the
sender transmits. A key derivation function (KDF, here HKDF) stretches that secret into keys.
An AEAD (AES-GCM or ChaCha20-Poly1305) encrypts and authenticates the message itself.
"Hybrid" means public-key and symmetric cryptography together, not classical and post-quantum: that second kind of
hybrid comes from the KEM. HPKE sits under TLS Encrypted Client Hello, Messaging Layer Security
(RFC 9420) and Oblivious HTTP.
Four modes and the key schedule
RFC 9180 defines four modes. base only encrypts: anyone who knows the recipient's public key could be the
sender. psk mixes in a pre-shared key of at least 32 bytes, which authenticates the sender and keeps the
message confidential even if the KEM is broken. auth authenticates the sender's own key pair through
Diffie-Hellman, and auth_psk does both. The playground enforces the RFC's rules: a PSK and its identifier come
together, auth modes need a sender key, and they need a KEM that supports authentication.
Whatever the mode, the shared secret passes through the key schedule of RFC 9180 §5.1. The mode, the hash of
the PSK identifier and the hash of info form key_schedule_context. The shared secret and the PSK form
secret. From these come the AEAD key, the base_nonce (message n uses base_nonce XOR n) and the
exporter_secret, from which both sides can derive further secrets without sending anything. The playground
recomputes every one of these values next to the reference implementation, @hpke/core, and shows them.
That makes it easy to see where an interoperability bug sits: in the KEM output, in info, in the PSK, or only
in the associated data.
Post-quantum HPKE
With DHKEM(X25519) or DHKEM(P-256), a message recorded today can be decrypted once a large quantum computer
exists (harvest now, decrypt later). Swapping the KEM is all it
takes to fix that, and the playground runs the post-quantum KEMs of
draft-ietf-hpke-pq: ML-KEM-512,
-768 and -1024 (KEM ids 0x0040–0x0042) and X-Wing (0x647A), the hybrid of ML-KEM-768 and X25519. Their
identifiers are in the IANA HPKE registry, but the document that defines how to use them is still an
Internet-Draft as of 20 October 2026, so details such as key derivation could still change. The cost is size:
enc grows from 32 bytes to 1,088 for ML-KEM-768 or 1,120 for X-Wing, which the chart beside the suite picker
compares.
Two limits come with them. ML-KEM and X-Wing have no authenticated mode, so auth and auth_psk stay
Diffie-Hellman-only and are not post-quantum. And the draft's private keys are seeds (64 bytes for ML-KEM, 32
for X-Wing), expanded on use, while derived keys come from a SHAKE256 labeled derivation that the playground
computes itself, because @hpke does not implement it yet.
Oblivious HTTP
RFC 9458 uses HPKE so that a relay sees who is asking but not what,
and the gateway sees what is asked but not who. A gateway publishes a key configuration: a key id, a KEM and
its public key, and the KDF and AEAD pairs it accepts, served as application/ohttp-keys. The client
encapsulates a Binary HTTP request into a header, enc and a ciphertext. The gateway decapsulates it and answers
with a response encrypted under keys exported from the same HPKE context.
The Oblivious HTTP tab decodes any key configuration or list, byte by byte. It says whether the KEM is post-quantum, and with the gateway's private key it runs both sides of an exchange. The RFC 9458 Appendix A example reproduces the RFC's encapsulated request, response keys and encapsulated response exactly.
Test vectors
The examples are the RFC 9180 vectors for DHKEM(X25519) in base mode and DHKEM(P-256) in auth_psk mode, the
draft-ietf-hpke-pq vectors for ML-KEM-768 and X-Wing, and RFC 9458 Appendix A. Each carries the sender's
ephemeral input, which makes encryption deterministic, so Seal must reproduce enc, the ciphertext, the key
schedule and an exported secret byte for byte; the page checks and says which value differs if one does.
Outside test vectors, leave that field empty: whoever knows the ephemeral input can decrypt.
For the KEMs on their own, the ML-KEM lab takes key shares apart byte by byte. Post-quantum migration in 2026 explains why application-level encryption such as HPKE belongs on the migration list next to TLS.