Protocol Simulations / TLS 1.3 Simulator
What you will do: Configure the client and server panels — cipher suites, key exchange groups, an RSA-2048 or ML-DSA identity, optional client verification — then Start Full Interaction to run a real OpenSSL TLS 1.3 handshake.
Worked example: With the defaults (X25519MLKEM768 offered first, RSA-2048 certificates) the summary names the negotiated cipher and key exchange, how many KB the handshake moved, and notes that hybrid ML-KEM plus ECDH was used.
Runtime and privacy: The cryptographic exercise runs in this browser. Review the site privacy terms before entering sensitive material; use synthetic inputs for learning and evaluation.
For your role
- Developer / Engineer
- Choose a key share such as X25519MLKEM768 and a signature algorithm such as mldsa65 on the client and server panels, then Start Full Interaction: the TXT and HEX views show every handshake message and the Config File tab is the OpenSSL configuration that produces it.
- Security Architect
- Compare the handshake with P-256 against ML-KEM-768 and a hybrid: the message sizes and the Trusted Root CA and mTLS options show what a PQC certificate chain adds to every connection.
- Researcher / Academic
- The supported set is listed at the top (pure ML-DSA certificates, hybrid key shares per the IETF drafts); use INSPECT and the HEX view to check the key share and signature encodings against the drafts.
- IT Ops / DevOps
- Set the server side the way your edge is configured, tick Require Client Certificate (mTLS) if you use it, and run the interaction: the Config File tab is the snippet shape you will deploy, and the Learn module holds the Apache, nginx, HAProxy and Caddy versions.
- ✓ Pure PQC keys — ML-DSA-44 / ML-DSA-65 / ML-DSA-87 server & client certs (FIPS 204)
- ✓ Hybrid KEM — X25519MLKEM768, SecP256r1MLKEM768, SecP384r1MLKEM1024 (TLS 1.3 key share, IETF draft-ietf-tls-ecdhe-mlkem); pure ML-KEM-512/768/1024 groups (draft-connolly-tls-mlkem)
- ✓ Classical certs — RSA-2048, ECDSA-P256, Ed25519 (bundled PEMs, OpenSSL native sign)
- ✓ Pure PQC certs — ML-DSA-44 / ML-DSA-87 cert + key bundled, real ML-DSA CertificateVerify
- ⚠ Hybrid (composite) certs — not supported yet — LAMPS composite-sig (ML-DSA + RSA-PSS / ECDSA / Ed25519) is on the roadmap. The dropdown rows for composite are currently a placeholder that substitutes the nearest pure ML-DSA PEM (the wire signature is ML-DSA, not composite). Provider machinery for composite is built in the vendored pkcs11-provider fork (composite.c) but the runtime cert-minting path is not yet wired here.
- ⚠ HSM-backed signing — removed — The previous "HSM ON" toggle never produced a successful handshake for end-users and was misleading. Removed pending a deliberate revival. softhsm v3 + pkcs11-provider remain statically linked into openssl.wasm; the wiring just isn't user-facing.
TLS Client
Application Data (Messaging)
Needed if the Server requests a client certificate (mTLS).
Import the Root CA that signed the server's certificate.
▸ Key share size reference (FIPS 203, RFC 9846)
| Group | Key Share (ClientHello) |
|---|---|
| X25519 | key share: 32 B |
| P-256 | key share: 65 B |
| P-384 | key share: 97 B |
| P-521 | key share: 133 B |
| ML-KEM-512 | pk: 800 B · ct: 768 B |
| ML-KEM-768 | pk: 1,184 B · ct: 1,088 B |
| ML-KEM-1024 | pk: 1,568 B · ct: 1,568 B |
| X25519MLKEM768 | 1,216 B combined (ML-KEM-768 1,184 + X25519 32) |
| SecP256r1MLKEM768 | 1,249 B combined (P-256 65 + ML-KEM-768 1,184) |
| SecP384r1MLKEM1024 | 1,665 B combined (P-384 97 + ML-KEM-1024 1,568) |
SLH-DSA (FIPS 205) is not listed: OpenSSL registers no SLH-DSA TLS signature schemes, so it cannot be negotiated here. No IETF draft standardizes SLH-DSA for TLS 1.3 (signatures are 7–50 KB).
▸ Signature size reference (FIPS 204)
| Algorithm | Signature | Public Key |
|---|---|---|
| mldsa44 | 2,420 B | 1,312 B |
| mldsa65 | 3,309 B | 1,952 B |
| mldsa87 | 4,627 B | 2,592 B |
| ecdsa_secp256r1_sha256 | ~72 B | 64 B |
| rsa_pss_rsae_sha256 | 256 B | 256 B |
| rsa_pss_pss_sha256 | 256 B | 256 B |
| ed25519 | 64 B | 32 B |
Configuration will be generated automatically based on selection.
TLS Server
Application Data (Messaging)
Selects the Key/Certificate pair used by the server.
▸ Key share size reference (FIPS 203, RFC 9846)
| Group | Key Share (ClientHello) |
|---|---|
| X25519 | key share: 32 B |
| P-256 | key share: 65 B |
| P-384 | key share: 97 B |
| P-521 | key share: 133 B |
| ML-KEM-512 | pk: 800 B · ct: 768 B |
| ML-KEM-768 | pk: 1,184 B · ct: 1,088 B |
| ML-KEM-1024 | pk: 1,568 B · ct: 1,568 B |
| X25519MLKEM768 | 1,216 B combined (ML-KEM-768 1,184 + X25519 32) |
| SecP256r1MLKEM768 | 1,249 B combined (P-256 65 + ML-KEM-768 1,184) |
| SecP384r1MLKEM1024 | 1,665 B combined (P-384 97 + ML-KEM-1024 1,568) |
SLH-DSA (FIPS 205) is not listed: OpenSSL registers no SLH-DSA TLS signature schemes, so it cannot be negotiated here. No IETF draft standardizes SLH-DSA for TLS 1.3 (signatures are 7–50 KB).
▸ Signature size reference (FIPS 204)
| Algorithm | Signature | Public Key |
|---|---|---|
| mldsa44 | 2,420 B | 1,312 B |
| mldsa65 | 3,309 B | 1,952 B |
| mldsa87 | 4,627 B | 2,592 B |
| ecdsa_secp256r1_sha256 | ~72 B | 64 B |
| rsa_pss_rsae_sha256 | 256 B | 256 B |
| rsa_pss_pss_sha256 | 256 B | 256 B |
| ed25519 | 64 B | 32 B |
Server preference will prioritize these ciphers.
Try it
Choose X25519MLKEM768 as the key share and mldsa65 as the signature, then Start Full Interaction. Where does the certificate chain size appear?
Next step
Turn it into a plan: MTI NegotiatorThis tool practises the TLS Basics module, phase 5 (Pilots & Migration); MTI Negotiator produces a deliverable of that phase.
Related content
Next in Protocol Simulations