up:: Classical Cryptography MOC

Ed25519

Ed25519 is a public-key digital signature algorithm, the most widely deployed instance of EdDSA (the Edwards-curve Digital Signature Algorithm), standardized in RFC 8032, that proves a message, file, or piece of software was signed by the holder of a specific private key and has not been altered since. It runs over edwards25519, a twisted Edwards curve equivalent to Curve25519, and it is prized because it is fast, produces tiny 32-byte keys and 64-byte signatures, and generates its per-signature secret deterministically, which sidesteps the single most dangerous implementation trap in ECDSA.

Its security rests on the elliptic-curve discrete logarithm problem, the exact problem a large quantum computer running Shor’s algorithm solves efficiently, so Ed25519 is squarely on the list of algorithms the post-quantum transition has to retire.

The short version:

1. Ed25519 does one job, digital signatures. It proves authenticity and integrity (who signed, and that nothing changed). It never encrypts data or establishes a shared key.
2. It secures modern trust plumbing: SSH keys, TLS handshakes, code and package signing, Git signing, and the Signal messaging protocol.
3. Its headline advantage over ECDSA is deterministic nonces. Ed25519 derives its per-signature secret from a hash of the key and the message, so it never needs a random number generator at signing time and cannot fall to the nonce-reuse key-recovery flaw that has drained wallets and cracked game consoles.
4. A quantum computer running Shor’s algorithm recovers the private key from the public key, which lets an attacker forge any signature. This is a total structural break, not a weakening, and being an efficient elliptic-curve scheme it falls to a smaller quantum computer than RSA of comparable classical strength.
5. The standardized replacements are ML-DSA (general purpose) and SLH-DSA (conservative, hash-based), with FN-DSA (draft) for compact roles. NIST’s schedule (NIST IR 8547) disallows classical signatures for federal use by 2035.

Think of a signet ring pressed into wax. Anyone who sees the seal recognizes the crest and knows the letter is genuine, but only the person holding the ring can produce that exact impression. Ed25519 is the mathematical version of that ring: the private key is the ring, the public key is everyone’s shared knowledge of the crest, and the Edwards-curve math makes the impression impossible to counterfeit. Ed25519’s refinement over older signature schemes is that the “how you press it” step is fixed and automatic, so a clumsy hand can’t accidentally reveal the ring’s shape. The quantum problem is that Shor’s algorithm hands the forger a perfect copy of the ring anyway.

What is Ed25519?

Ed25519 is the edwards25519 instantiation of EdDSA, a public-key signature scheme defined by Daniel J. Bernstein and colleagues and standardized by the IETF in RFC 8032 and by NIST in FIPS 186-5. It signs and verifies data; it does not encrypt anything and it does not establish keys. Where Curve25519 is used for key agreement (under the name X25519), the same underlying curve, rewritten in Edwards form, is used by Ed25519 for signatures. They are siblings from one curve family with two different jobs.

Its defining design choices, all fixed rather than left to the implementer, are what make it popular:

1. Deterministic signing. The per-signature secret is computed from a hash of the private key and the message, not drawn from a random source, so signing needs no runtime randomness.
2. A single fixed parameter set. Ed25519 is one curve, one hash (SHA-512), one encoding. Implementers do not pick curves or parameters, which removes a whole category of misconfiguration.
3. Twisted Edwards curve arithmetic. The Edwards form supports fast, complete addition formulas that behave uniformly, which helps constant-time, side-channel-resistant implementations.
4. Compact keys and signatures. A 32-byte public key and a 64-byte signature make it attractive wherever storage, bandwidth, or simplicity matter.

Its security rests on the classical hardness of the elliptic-curve discrete logarithm problem over the prime field of edwards25519, and it provides roughly 128-bit classical security, comparable to ECDSA on the P-256 curve.

Sources: S. Josefsson, I. Liusvaara, “Edwards-Curve Digital Signature Algorithm (EdDSA),” RFC 8032, IRTF/IETF, January 2017, RFC 8032.

NIST, “Digital Signature Standard (DSS),” FIPS 186-5, February 2023, FIPS 186-5.

How does Ed25519 actually sign and verify something?

Ed25519 turns a private secret into an unforgeable stamp using arithmetic on the edwards25519 curve, and its whole security comes from one hard-to-reverse operation: multiplying the curve’s fixed base point by a secret scalar is easy, but working backward from the result to the scalar is the elliptic-curve discrete logarithm problem, for which no efficient classical method is known.

1. Key generation. The signer starts from a 32-byte secret seed and hashes it with SHA-512. Half of that digest becomes the secret scalar; the public key is that scalar multiplied by the base point, encoded as a 32-byte value. Publishing the public key reveals nothing usable about the scalar, because recovering it is the hard problem.
2. Signing. To sign a message, Ed25519 computes the per-signature secret r deterministically as SHA-512 over a private prefix (the other half of the key hash) concatenated with the message, then produces the signature pair (R, S) using curve arithmetic. Because r comes from a hash of fixed inputs, the same key and message always yield the same safe value, and no random number generator is consulted.
3. Verification. Anyone holding the 32-byte public key recomputes the relevant hash and checks a single curve equation against (R, S). If it holds, the signature is valid, which proves both that the signer’s private key produced it and that the message is byte-for-byte what was signed.

The contrast with ECDSA is the whole point of the design. ECDSA also needs a per-signature secret, but it expects the signer to generate a fresh random one every time, and if that randomness is ever repeated or biased, the private key falls straight out of the math. Ed25519 removes the random source entirely by deriving the secret from the message, which is why RFC 8032 states plainly that “the use of a unique random number for each signature is not required.”

Source: S. Josefsson, I. Liusvaara, “Edwards-Curve Digital Signature Algorithm (EdDSA),” RFC 8032, January 2017, section 5.1 (Ed25519), RFC 8032.

What is Ed25519 used for?

Ed25519 sits inside the machinery that decides whether a system should trust a login, a piece of code, a commit, or a message. Its small keys, fast verification, and safer signing made it the modern default in infrastructure and developer tooling, so it now anchors a large share of everyday trust that is easy to overlook because it lives outside the public web-certificate world:

1. SSH. Ed25519 host keys and user keys authenticate servers and administrators over SSH; ssh-ed25519 is standardized for SSH in RFC 8709 and is a common default in modern OpenSSH deployments. These keys gate remote access to infrastructure.
2. TLS. TLS 1.3 registers ed25519 as a signature scheme for certificate and handshake authentication (RFC 8446), so a server or client can prove its identity during the handshake with an Ed25519 key.
3. Code, package, and Git signing. Software releases, package repositories, and Git commit or tag signing increasingly use Ed25519 to prove an artifact came from a trusted source and was not tampered with. A forged signature here means malware that the platform treats as legitimate.
4. Secure messaging. The Signal protocol uses an Ed25519-derived signature construction (XEdDSA) for identity keys, so a signature backs the claim that a message came from a genuine identity.
5. DNSSEC and other protocols. Ed25519 is a registered signing algorithm for DNSSEC (RFC 8080) and appears across newer application-layer trust systems.

Because this is the trust layer, an Ed25519 break is mainly a trust and integrity problem rather than a secrecy problem. The failure mode is forgery: signatures, releases, tokens, and identities that look authentic but are not.

Sources: J. Harris, S. Josefsson, “Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH) Protocol,” RFC 8709, February 2020, RFC 8709.

E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.3,” RFC 8446, August 2018, RFC 8446.

O. Sury, R. Edmonds, “Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC,” RFC 8080, February 2017, RFC 8080.

Is Ed25519 quantum-vulnerable?

Yes, completely. Ed25519 is broken by Shor’s algorithm, the quantum algorithm that efficiently solves the discrete logarithm problem, including its elliptic-curve form. A cryptographically relevant quantum computer running Shor’s algorithm takes the 32-byte public key and recovers the private scalar in polynomial time. Once an attacker holds that scalar, they hold the signet ring: they can produce valid Ed25519 signatures for anything they choose, indistinguishable from the real signer’s.

This is a structural collapse of the security assumption, not a shrinking safety margin. It is the same class of break that ends RSA, ECDSA, and Diffie-Hellman, because all of them rest on hard problems that Shor’s algorithm dissolves. Being a modern, clean, deterministic design buys Ed25519 nothing here, since the vulnerability is in the underlying elliptic-curve math, not the implementation. This is the roadmap lesson teams most often miss: a newer elliptic-curve signature scheme is not automatically future-safe.

Grover’s algorithm, the other headline quantum attack, is close to irrelevant to Ed25519. Grover speeds up brute-force search and only halves the effective strength of symmetric primitives like AES and hash functions. It does nothing to rescue a public-key scheme whose private key can be computed directly. So the honest one-line verdict is that Shor’s algorithm ends Ed25519, and Grover’s is beside the point here.

Source: P. Shor, “Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer,” SIAM J. Computing, 1997, quant-ph/9508027.

Why does Ed25519 fall to a smaller quantum computer than RSA?

This is the counterintuitive part, and it matters for anyone tempted to treat elliptic-curve crypto as the safer place to wait out the transition. Elliptic-curve keys are compact precisely because the elliptic-curve discrete logarithm problem is harder per bit than integer factorization, so a 256-bit-class curve like edwards25519 matches the classical strength of a 3072-bit RSA key. That efficiency is a virtue against a classical attacker and a liability against a quantum one, because the quantum machine only has to work over the far smaller number.

A widely cited resource estimate puts figures on it. Breaking the elliptic-curve discrete logarithm over an n-bit prime field takes roughly 9n + 2⌈log₂(n)⌉ + 10 logical qubits, which for the 256-bit-class curves behind Ed25519 and most ECDSA works out to about 2,330 logical qubits. Factoring an RSA modulus of comparable classical strength needs a larger quantum computer, because the modulus is far bigger. The authors’ own conclusion is blunt: at comparable classical security levels, elliptic curves need fewer qubits to attack than RSA.

The practical takeaway is direct. If a partial or early quantum computer arrives, the elliptic-curve algorithms, Ed25519 among them, are likely to fall first. Migrating deeper into elliptic-curve signatures is a move in the wrong direction.

Source: M. Roetteler, M. Naehrig, K. Svore, K. Lauter, “Quantum Resource Estimates for Computing Elliptic Curve Discrete Logarithms,” ASIACRYPT 2017, arXiv:1706.06752.

How does Ed25519 compare to ECDSA?

Ed25519 and ECDSA are both elliptic-curve signature schemes and both fall to Shor’s algorithm, so from a post-quantum standpoint they migrate together. The classical difference that made Ed25519 the modern favorite is entirely about the nonce and the implementation surface:

Property	Ed25519	ECDSA (P-256)
Per-signature secret	Deterministic, hashed from key and message; no RNG needed	Fresh random nonce required every signature
Worst failure mode	Structurally avoids nonce-reuse key recovery	Reused or biased nonce leaks the private key
Public key size	32 bytes	65 bytes (uncompressed point)
Signature size	64 bytes (fixed)	about 64 to 72 bytes (DER-encoded, variable)
Parameter choices	One fixed curve, hash, and encoding	Multiple curves and options to select
Quantum status	Broken by Shor’s algorithm	Broken by Shor’s algorithm

The deterministic nonce is the substance of the advantage. ECDSA’s most notorious real-world failures, recovering signing keys from repeated or predictable nonces, are structurally impossible in Ed25519 because there is no random nonce to repeat. That is why RFC 8032 notes that deterministic EdDSA “protects against attacks arising from signing with bad randomness.” ECDSA can close the same gap by generating its nonce deterministically per RFC 6979, but Ed25519 bakes the safe behavior into the standard rather than leaving it to the implementer.

Sources: S. Josefsson, I. Liusvaara, “Edwards-Curve Digital Signature Algorithm (EdDSA),” RFC 8032, January 2017, RFC 8032.

T. Pornin, “Deterministic Usage of DSA and ECDSA,” RFC 6979, IETF, 2013, RFC 6979.

What are Ed25519’s key and signature sizes?

Ed25519’s sizes are small and fixed, which is a large part of why it spread. Every value below comes directly from RFC 8032, which specifies the curve, the internal hash, and the exact byte lengths:

Property	Value
Curve	edwards25519 (twisted Edwards, equivalent to Curve25519 under a change of coordinates)
Classical security strength	about 128-bit
Private key (seed)	32 bytes
Public key	32 bytes
Signature	64 bytes (fixed length)
Internal hash	SHA-512
Per-signature secret	Deterministic, no random source at signing

Hold the 64-byte signature figure, because it is the number the post-quantum replacements have to swallow. The smallest ML-DSA signature is over 2,400 bytes, and SLH-DSA signatures run into the thousands of bytes, so the replacement math is the reverse of the Ed25519 win: post-quantum signatures are far bigger, and absorbing that size is the real migration cost. It lands on artifact formats, protocol limits, parsers, and trust stores, not on CPU.

Source: S. Josefsson, I. Liusvaara, “Edwards-Curve Digital Signature Algorithm (EdDSA),” RFC 8032, January 2017, sections 5.1.5 and 5.1.6, RFC 8032.

What replaces Ed25519?

Ed25519 gets replaced by a post-quantum signature standard, not upsized or patched, because the elliptic-curve discrete logarithm problem stops being hard once Shor’s algorithm is available. There is no larger Edwards curve that helps, the way moving from AES-128 to AES-256 rescues symmetric encryption. NIST finalized the replacement signature standards, and the right one depends on the role Ed25519 was playing:

Replacement	Standard	Basis	Best fit for the Ed25519 role it takes over
ML-DSA	FIPS 204	Lattice (Module-LWE)	The general-purpose default: SSH keys, code and package signing, tokens, most everyday signing
SLH-DSA	FIPS 205	Hash-based	Conservative, long-lived roots of trust: release anchors, firmware roots, where an alternate math assumption is worth the larger signature
FN-DSA	FIPS 206 (draft)	Lattice (NTRU)	Constrained settings where compact signatures matter most; the FALCON-derived standard, not yet finalized

For most environments, ML-DSA is the direct successor to Ed25519. SLH-DSA is the deliberately conservative choice where a signing key protects something for decades and you want its security resting on plain hash functions rather than lattice math. FN-DSA is the compact option for size-sensitive roles, and it was still in draft as of NIST’s late-2024 signature work, so it is not part of the current disallowance schedule yet.

These are not drop-in swaps. Because Ed25519 often hides inside developer tooling, CI/CD pipelines, and SSH configurations rather than public certificates, it is easy to miss in a PKI-focused inventory, and the migration work lands on validators, artifact stores, and signing APIs that assume a compact 64-byte signature. The transitional pattern most estates use is dual signatures, carrying both a classical and a post-quantum signature so verifiers can upgrade at their own pace, which overlaps with hybrid cryptography and composite certificates. Designing for that flexibility is crypto-agility.

Sources: NIST FIPS 204, “Module-Lattice-Based Digital Signature Standard,” August 2024, FIPS 204.

NIST FIPS 205, “Stateless Hash-Based Digital Signature Standard,” August 2024, FIPS 205.

When does Ed25519 have to be gone?

The clock is set by NIST IR 8547, NIST’s transition roadmap, which puts every classical public-key algorithm, elliptic-curve signatures included, on a deprecation-then-disallowance schedule:

Milestone	Year	What it means for Ed25519
Deprecated	2030	112-bit-strength elliptic-curve signatures become deprecated, meaning still usable but only with the data owner formally accepting the risk
Disallowed	2035	All classical elliptic-curve signatures, Ed25519 included, become disallowed for federal use, with no exceptions

“Deprecated” and “disallowed” are different instructions. Deprecated is “you may, but you are on the clock and you own the risk.” Disallowed is a hard stop. Because insurers, sector regulators, and procurement programs align to NIST, these federal dates function as the de facto industry timeline even for organizations that never touch a government contract. Anything signed today with Ed25519 that still needs to be trusted after a quantum computer arrives is already living on Mosca’s borrowed time, since signed artifacts and identities often have to stay trustworthy for many years.

Source: NIST IR 8547 (Initial Public Draft), “Transition to Post-Quantum Cryptography Standards,” November 2024, NIST IR 8547 ipd.

Common misconceptions

1. “Ed25519 is newer and cleaner than ECDSA, so it must be more quantum-safe.” It is not. Both rest on the elliptic-curve discrete logarithm problem, and both fall completely to Shor’s algorithm. Ed25519’s improvements are all about classical implementation safety, which does nothing against a quantum attacker.
2. “Ed25519 encrypts my data.” It does not. Ed25519 is a signature algorithm; it proves authenticity and integrity. Confidentiality comes from a separate key-exchange and symmetric cipher layer, so a broken Ed25519 is a forgery risk, not a data-leak risk.
3. “Ed25519 and X25519 are the same key.” They come from the same curve but do different jobs. Ed25519 signs, X25519 does key agreement, and you should not reuse one key for both roles.
4. “A bigger Edwards curve will hold up against quantum.” Shor’s algorithm scales gently with key size, so a larger curve buys almost nothing against a quantum attacker. The only real fix is a post-quantum algorithm.
5. “If quantum breaks Ed25519, it only affects future signatures.” Any long-lived artifact signed today, a firmware image, a release, a signed archive, has to stay trustworthy for years, so today’s Ed25519 signatures on long-lived things are already exposed to a future forger.
6. “Ed25519 lives in certificates, so my PKI inventory already covers it.” Ed25519 usually hides in SSH keys, CI/CD pipelines, Git config, and package signing, outside the certificate world, which is exactly why a PKI-only inventory tends to miss it.

Questions people ask

Is Ed25519 safe to use today? Against classical attackers, yes, and it is one of the safest signature schemes to implement because its deterministic design removes the nonce-randomness failure that trips up ECDSA. The concern is future quantum capability plus the reality that anything you sign now may need to stay trustworthy past the arrival of a quantum computer, so new long-lived signatures should be planned with a post-quantum path.

Is Ed25519 more secure than ECDSA? Classically, it is safer in practice, because it structurally avoids the nonce-reuse and biased-nonce flaws that have leaked real ECDSA private keys. Against a quantum computer they are equally broken, since both rely on the elliptic-curve discrete logarithm problem that Shor’s algorithm solves.

What is the deterministic-nonce advantage, exactly? ECDSA needs a fresh random secret for every signature, and if that value is ever repeated or predictable, an attacker can compute the private key from the signatures. Ed25519 derives that secret from a hash of the private key and the message, so it never uses a random source at signing and cannot suffer that failure. RFC 8032 states that a unique random number for each signature is not required.

Do I have to replace Ed25519 right now? Not overnight, but you should be inventorying it now and moving the high-stakes, long-lived uses first. Because it often anchors SSH access, release signing, and developer trust, those roles carry a large blast radius and take the longest to migrate, so they start earliest.

What is the direct replacement for Ed25519? ML-DSA for general-purpose signing, SLH-DSA for conservative long-lived roots of trust, and FN-DSA (still in draft) where compact signatures matter most.

How big are post-quantum signatures compared to Ed25519? Much bigger. An Ed25519 signature is a fixed 64 bytes; the smallest ML-DSA signature is over 2,400 bytes, and hash-based SLH-DSA signatures run into the thousands of bytes. That size jump is the main engineering cost of the migration, landing on artifact formats, parsers, and trust stores.

Is Ed25519 approved by NIST? Yes. EdDSA with Ed25519 is specified in FIPS 186-5 and RFC 8032. It remains an approved classical signature algorithm, and NIST IR 8547 sets the schedule for deprecating and eventually disallowing it as post-quantum standards take over.

---

Everything here is the map, given freely. When your team needs its own signing keys and trust workflows found, sized, and sequenced onto a post-quantum path, that is the work I do. Request an alignment briefing.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.