Ed25519 vs ML-DSA: keys, signatures, sizes

Ed25519 in one page#

Ed25519 is EdDSA instantiated over the twisted Edwards form of Curve25519, specified in RFC 8032 and approved for US federal use in FIPS 186-5. It is the signature scheme behind every Solana transaction, a common choice for SSH keys, and widely used in other modern protocols and software-signing tools.

A private key is a 32-byte random seed. Hashing it with SHA-512 yields two halves: one becomes a secret scalar a (after a fixed bit-clamping step), the other a secret prefix used to derive nonces. The public key A is the curve point a·B for a fixed base point B, compressed into 32 bytes.

To sign a message M, the signer derives a nonce r = H(prefix ‖ M), computes the point R = r·B, and then S = r + H(R ‖ A ‖ M)·a modulo the group order. The signature is the 64-byte concatenation R ‖ S. Verification checks that S·B = R + H(R ‖ A ‖ M)·A.

seed (32 B) ──SHA-512──► scalar a  +  prefix
public key  A = a·B                      → 32 bytes
nonce       r = SHA-512(prefix ‖ M)       (deterministic)
signature   R = r·B
            S = r + SHA-512(R ‖ A ‖ M)·a  mod ℓ
            sig = R ‖ S                  → 64 bytes

Two design choices make Ed25519 pleasant in practice. The nonce is derived deterministically from the key and message, which removes the catastrophic "reused random nonce" failure that has leaked ECDSA keys in the past. And the arithmetic is designed to be implemented in constant time without special care. Against classical attackers it offers roughly 128 bits of security.

One subtlety matters for blockchains: RFC 8032 leaves some freedom in exactly which edge-case signatures a verifier accepts (for example, cofactored versus cofactorless verification equations and handling of non-canonical encodings). In a consensus system, every node must accept exactly the same set of signatures, so these rules are pinned down by the implementation rather than the RFC. Any post-quantum scheme added to a chain needs the same level of precision.

ML-DSA in one page#

ML-DSA, the Module-Lattice-Based Digital Signature Algorithm, is standardised in FIPS 204 (August 2024). It descends from CRYSTALS-Dilithium, one of the winners of NIST's post-quantum competition. Its security rests on two problems over module lattices: Module Learning With Errors (MLWE) protects the secret key, and Module Short Integer Solution (MSIS, in a variant called SelfTargetMSIS) protects against forgery. No efficient quantum algorithm is known for either.

Very roughly: the public key contains a seed ρ that expands into a public matrix A of polynomials, plus a vector t ≈ A·s1 + s2, where s1 and s2 are secret vectors with small coefficients. Recovering the small secrets from t is the MLWE problem. To keep the public key smaller, only the high-order bits of t (called t1) are published.

Signing uses a technique called Fiat–Shamir with aborts. The signer picks a random masking vector y, computes w = A·y, hashes the high bits of w together with the message to get a sparse challenge c, and outputs z = y + c·s1. If z or a related value would leak information about the secret, the attempt is thrown away and the signer tries again. On average it takes a handful of attempts. The signature carries a compressed challenge, the vector z, and a small hint that lets the verifier reconstruct the high bits it needs.

• Randomness. FIPS 204's default signing is "hedged": it mixes fresh randomness with the key and message, so a weak random number generator does not leak the key. A deterministic variant is also specified.
• Seeds. Key generation is defined from a 32-byte seed. Storing only the seed is a valid way to store a key, which matters for wallets (see chapter 05).
• Context strings. ML-DSA accepts an optional context string of up to 255 bytes for domain separation, so a signature made for one purpose cannot be replayed for another.
• Pre-hash variant. HashML-DSA signs a digest of the message instead of the message. It is a separate algorithm with distinct signatures, not an implementation detail.

The numbers#

These are the published parameter sizes from RFC 8032, FIPS 204 and FIPS 205. They are fixed properties of the schemes, not benchmarks. NIST security categories compare the effort of an attack to breaking AES-128 (category 1), finding a SHA-256 collision (2), breaking AES-192 (3), and breaking AES-256 (5).

Three observations follow. First, ML-DSA grows both the public key and the signature: a single ML-DSA-44 public key is 41 times larger than an Ed25519 key, and its signature is about 38 times larger. Second, SLH-DSA moves all of the cost into the signature: its public key is as small as Ed25519's, but its signatures are enormous. The "s" (small) variants trade slower signing for smaller signatures than the "f" (fast) variants. Third, there is no standardised drop-in scheme that matches Ed25519's 32 + 64 byte footprint.

Speed is not the problem#

It is tempting to assume post-quantum signatures are slow. For ML-DSA, verification is fast: it is mostly hashing and polynomial multiplication using the number-theoretic transform, and in optimised native code it is in the same general range as elliptic-curve verification. Signing is a few times more work because of the rejection loop, but still fast enough for interactive use. SLH-DSA verification is quick; SLH-DSA signing, especially for the "s" variants, is much slower because it computes many hash-tree nodes.

Exact timings depend heavily on the implementation, CPU, and whether you are in native code, WebAssembly or plain JavaScript. Rather than quoting numbers that would not match your environment, the Lab measures keygen, sign and verify live in your browser for each scheme, next to the Ed25519 baseline. Treat browser timings as relative, not absolute.

On a blockchain the cost that actually bites is size. Every byte of signature and public key travels through the network, is stored in blocks, and counts against per-transaction limits and fees. Chapter 04 works through what that means for Solana's 1232-byte packet.

Choosing between them#

• ML-DSA-44 or ML-DSA-65 are the natural general-purpose choices. ML-DSA-65 gives a larger security margin; ML-DSA-44 is smaller. Pick based on the lifetime and value of what the key protects.
• ML-DSA-87 is for keys that must hold up for a very long time or where policy demands category 5.
• SLH-DSA is the conservative hedge. If a structural weakness were ever found in lattice problems, a hash-based scheme would be unaffected. Its small public key also suits cases where keys are stored often but signatures are rare, such as root or recovery keys.
• Hybrid (Ed25519 + ML-DSA) signs with both and requires both to verify. It protects against a flaw in the newer scheme during the transition, at the cost of carrying both sets of bytes. Chapter 05 discusses when it is worth it.