Experiment Safely With Cryptography
No wallet keys, no funds, no transactions. Compare Ed25519 with standardised post-quantum schemes and see how sizes and timings differ in your own browser.
Education and prototyping only
Section A
Signature Demonstration
Pick one of 8 signature schemes, generate a temporary key, sign a message, verify it, tamper with the message and verify again.
- Public key
- —
- Signature
- —
- Key generation
- —
- Signing
- —
- Verification
- —
- Tampered check
- —
Published: 1952 B
Exceeds Solana's 1232 B limit
Status
- Pending Original message
- Pending Tampered message
Keys are generated in your browser for this session only and are never sent anywhere. Only the algorithm, sizes and timings are recorded in your dashboard activity.
Section B
Key Encapsulation Demonstration
Walk through key generation, encapsulation, decapsulation and shared-secret agreement with 5 key-establishment schemes, including the X-Wing hybrid.
A key-encapsulation mechanism lets two parties agree on a shared secret. The recipient publishes a public key; the sender uses it to produce a ciphertext and a secret; the recipient recovers the same secret from the ciphertext.
- Public key
- —
- Ciphertext
- —
- Shared secret
- —
- Key generation
- —
- Encapsulation
- —
- Decapsulation
- —
Published: 1184 B
Published: 1088 B
Section C
Comparison View
13 classical, post-quantum and hybrid schemes side by side, with published sizes and live server timings.
Sizes are parameter sizes from the published standards, not measurements. “Measure” runs a few iterations on the Lattice server and reports wall-clock means for that environment only.
- classical · signature
Ed25519
RFC 8032; FIPS 186-5
Digital signatures (elliptic curve, EdDSA).
- Public key
- 32 B
- Signature
- 64 B
- Intended use
- Transaction and message signing. Used today by Solana for account authorization.
- Implementation status
- Widely deployed in production across many ecosystems.
- Security review status
- Mature, extensively analysed. Vulnerable to Shor's algorithm on a cryptographically relevant quantum computer.
- classical · signature
secp256k1 ECDSA
SEC 2 curve; ECDSA (FIPS 186-5)
Digital signatures (elliptic curve, ECDSA).
- Public key
- 33 B
- Signature
- 64 B
- Intended use
- Transaction signing on Bitcoin, Ethereum and EVM chains. Solana exposes a native secp256k1 program for cross-chain verification.
- Implementation status
- Widely deployed in production across many ecosystems.
- Security review status
- Mature, extensively analysed. Vulnerable to Shor's algorithm on a cryptographically relevant quantum computer.
- post-quantum · signature
ML-DSA-44
FIPS 204 (2024)
Digital signatures (module-lattice based, formerly CRYSTALS-Dilithium).
- Public key
- 1.3 KB
- Signature
- 2.4 KB
Exceeds Solana's 1,232-byte transaction limit
- Intended use
- General-purpose signatures at NIST security category 2.
- Implementation status
- Standardised. Lattice runs a pure-JavaScript implementation in your browser; native implementations exist for production.
- Security review status
- Standardised by NIST after a multi-year public evaluation. Implementations still require independent review.
- post-quantum · signature
ML-DSA-65
FIPS 204 (2024)
Digital signatures (module-lattice based, formerly CRYSTALS-Dilithium).
- Public key
- 1.9 KB
- Signature
- 3.2 KB
Exceeds Solana's 1,232-byte transaction limit
- Intended use
- General-purpose signatures at NIST security category 3, the level NIST recommends as a default.
- Implementation status
- Standardised. Lattice runs a pure-JavaScript implementation in your browser; native implementations exist for production.
- Security review status
- Standardised by NIST after a multi-year public evaluation. Implementations still require independent review.
- post-quantum · signature
ML-DSA-87
FIPS 204 (2024)
Digital signatures (module-lattice based, formerly CRYSTALS-Dilithium).
- Public key
- 2.5 KB
- Signature
- 4.5 KB
Exceeds Solana's 1,232-byte transaction limit
- Intended use
- Signatures at NIST security category 5, for keys that must stay trustworthy for decades.
- Implementation status
- Standardised. Lattice runs a pure-JavaScript implementation in your browser; native implementations exist for production.
- Security review status
- Standardised by NIST after a multi-year public evaluation. Implementations still require independent review.
- post-quantum · signature
Falcon-512
Falcon Round 3; basis of FN-DSA (FIPS 206, draft)
Digital signatures (NTRU-lattice based, compact).
- Public key
- 897 B
- Signature
- 666 B
- Intended use
- Signatures where size matters most: the most compact signature among NIST's selected post-quantum schemes.
- Implementation status
- Falcon as submitted in NIST Round 3. FN-DSA (FIPS 206) is still a draft and may not be byte-compatible.
- Security review status
- Selected by NIST. Signing uses floating-point Gaussian sampling, which is difficult to implement in constant time.
- post-quantum · signature
SLH-DSA-SHA2-128f
FIPS 205 (2024)
Digital signatures (stateless hash-based, formerly SPHINCS+), fast variant.
- Public key
- 32 B
- Signature
- 16.7 KB
Exceeds Solana's 1,232-byte transaction limit
- Intended use
- Conservative signatures where very large signatures are acceptable, such as firmware or root-of-trust signing.
- Implementation status
- Standardised. Signing is noticeably slower than lattice schemes.
- Security review status
- Security rests on well-studied hash functions. Implementations still require independent review.
- post-quantum · signature
SLH-DSA-SHA2-128s
FIPS 205 (2024)
Digital signatures (stateless hash-based, formerly SPHINCS+), small variant.
- Public key
- 32 B
- Signature
- 7.7 KB
Exceeds Solana's 1,232-byte transaction limit
- Intended use
- Rarely signed, often verified material such as release keys: smaller signatures than 128f in exchange for much slower signing.
- Implementation status
- Standardised. Expect signing to take around a second in the browser.
- Security review status
- Security rests on well-studied hash functions. Implementations still require independent review.
- classical · key establishment
X25519
RFC 7748
Key agreement (elliptic-curve Diffie–Hellman).
- Public key
- 32 B
- Ciphertext
- 32 B
- Intended use
- Establishing shared secrets, for example in TLS and messaging protocols.
- Implementation status
- Widely deployed in production.
- Security review status
- Mature, extensively analysed. Vulnerable to Shor's algorithm on a cryptographically relevant quantum computer.
- post-quantum · key establishment
ML-KEM-512
FIPS 203 (2024)
Key encapsulation (module-lattice based, formerly CRYSTALS-Kyber).
- Public key
- 800 B
- Ciphertext
- 768 B
- Intended use
- Establishing shared secrets at NIST security category 1, where bandwidth is tight.
- Implementation status
- Standardised. Lattice runs a pure-JavaScript implementation in your browser; native implementations exist for production.
- Security review status
- Standardised by NIST after a multi-year public evaluation. Implementations still require independent review.
- post-quantum · key establishment
ML-KEM-768
FIPS 203 (2024)
Key encapsulation (module-lattice based, formerly CRYSTALS-Kyber).
- Public key
- 1.2 KB
- Ciphertext
- 1.1 KB
- Intended use
- Establishing shared secrets at NIST security category 3. Already deployed in hybrid TLS key exchange by major browsers and CDNs.
- Implementation status
- Standardised and in production use in hybrid mode. Lattice runs a pure-JavaScript implementation in your browser.
- Security review status
- Standardised by NIST after a multi-year public evaluation. Implementations still require independent review.
- post-quantum · key establishment
ML-KEM-1024
FIPS 203 (2024)
Key encapsulation (module-lattice based, formerly CRYSTALS-Kyber).
- Public key
- 1.5 KB
- Ciphertext
- 1.5 KB
- Intended use
- Establishing shared secrets at NIST security category 5, for data that must stay confidential for decades.
- Implementation status
- Standardised. Lattice runs a pure-JavaScript implementation in your browser; native implementations exist for production.
- Security review status
- Standardised by NIST after a multi-year public evaluation. Implementations still require independent review.
- hybrid · key establishment
X-Wing
IETF draft-connolly-cfrg-xwing-kem
Hybrid key encapsulation combining ML-KEM-768 and X25519.
- Public key
- 1.2 KB
- Ciphertext
- 1.1 KB
- Intended use
- Hybrid key establishment that stays secure while either component holds, the same approach as the hybrid TLS key exchange browsers ship today.
- Implementation status
- Specified in an IETF draft. Combines two deployed building blocks with a fixed combiner.
- Security review status
- ML-KEM is standardised and X25519 is mature; the X-Wing combiner itself is still an IETF draft.
Section D
Solana Context
What this playground does and does not change about on-chain authorization.
How Solana authorises a transaction
A transaction carries one or more 64-byte Ed25519 signatures over its serialised message. Each signer's 32-byte public key appears in the account list, and the first signer pays the fee. Validators verify every signature before executing any instruction.
Current signature assumptions
- Account addresses are Ed25519 public keys and are visible on-chain by design.
- Transactions are limited to 1,232 bytes including all signatures.
- Native programs verify Ed25519 and secp256k1 signatures; there is no native post-quantum verifier.
Why this playground does not change blockchain-level authorization
Everything here runs in your browser or on the Lattice server. A post-quantum signature produced here is never submitted to Solana, and even a program that verified one inside an instruction would still need an Ed25519 fee-payer signature for the transaction itself.
Why migration needs protocol and wallet support
Adopting a new scheme on Solana would require a transaction format with room for larger signatures, validator-side verification with fee accounting, a way for existing accounts to designate a new key type, and support in wallets and hardware devices. Application teams can prepare for that, but cannot ship it alone. Experiment on Devnet only.
Read more: Solana Transaction Authorization Today.