§01 · experiment · ephemeral demo keys

The lab

Generate ephemeral keypairs, sign and verify messages, and compare classical Ed25519 to NIST post-quantum signature schemes, then run X25519 and ML-KEM-768 key exchange side by side. All computation runs in your browser; nothing is stored or transmitted.

§01

Signature scheme

Pick a scheme. Classical and NIST post-quantum schemes run entirely in your browser.

FIPS 204 (Dilithium)pubkey 1,952 B · 61.0× baselinesig 3,309 B · 51.7× baselinefits 1 tx · 2.7× over

Mid-strength ML-DSA parameter set (NIST security category 3). A common middle ground between size and security margin.

§02

Keypair

Ephemeral, in-memory. Never leaves this tab.

§03

Sign a message

Any UTF-8 payload. Signatures are produced over the raw bytes.

§M

Comparison

Live measurements vs. classical Ed25519 baseline.

Scheme: ML-DSA-65
Family: lattice
Public key: 1,952 B · 61.0× baseline
Signature: 3,309 B · 51.7× baseline
Keygen (measured): —
Sign (measured): —
Verify (measured): —

Signature size compounds inside the Solana packet budget — every extra byte reduces how many instructions fit in a transaction. Current cap: 1,232 B.

§04 · devnet demo

Classical Ed25519 on Solana Devnet

Solana signs transactions with Ed25519 today. This panel generates an ephemeral Solana keypair, airdrops a small amount on Devnet, and signs a self-transfer so you can trace what a post-quantum migration will touch.

RPC: devnet

Devnet-only. Faucets rate-limit per IP; if an airdrop fails try again in ~30 s. Keys are generated in your browser, never persisted or transmitted.

§05 · key exchange

X25519 vs ML-KEM-768

Signatures prove who sent something; key exchange decides who can read it. Encrypted traffic recorded today can be decrypted later once X25519 falls, so key exchange is usually the first thing to migrate. Both run here with ephemeral in-memory keys.

X25519classicalRFC 7748

Elliptic-curve Diffie–Hellman on Curve25519. Compact and fast, but broken by a large-scale quantum computer running Shor's algorithm.

Generates two keypairs and derives the shared secret on both sides.

ML-KEM-768post-quantumNIST FIPS 203

Module-lattice key encapsulation (formerly Kyber). NIST category 3. Larger keys and ciphertexts, comparable speed.

Generates a keypair, encapsulates a fresh secret to the public key, then decapsulates it with the secret key.

HybridHKDF-SHA256(ML-KEM ss ‖ X25519 ss)

Run both exchanges to derive a combined 32-byte key.

Concatenating both secrets follows the same idea as the X25519MLKEM768 hybrid used in TLS 1.3: the combined key stays safe as long as either component holds. TLS feeds the concatenation into its own key schedule; HKDF here is for illustration.

Size & latency

Published key, ciphertext and shared secret sizes for X25519 and ML-KEM-768, with timings measured in this browser.
Scheme	Public key	Ciphertext / share	Shared secret	Keygen	Encaps / derive	Decaps
X25519	32 B	32 B	32 B	—	—	—
ML-KEM-768	1,184 B 37.0× baseline	1,088 B 34.0× baseline	32 B	—	—	—

Sizes are the published parameter values. Timings are single runs measured in this browser with performance.now() and vary by device. X25519 has no encapsulation step: the “share” is the peer's public key and both sides run the same derivation.