# Ed25519 vs Ed448: Higher Security Twin Explained **Source**: https://quantumsequrity.com/blog/ed25519-vs-ed448 **Category**: Cryptography Foundations --- [← Back to Blog](../../blog.html) Cryptography Foundations # Ed25519 vs Ed448: Higher Security Twin Explained 10 min read Ed25519 is the most popular signature scheme in modern protocols. SSH, OpenPGP, Tor, Signal, and almost every Linux package signing chain uses it. The cousin Ed448, much rarer in deployment, sits at the higher-security tier in the same family. Together they form EdDSA, the Edwards-curve Digital Signature Algorithm, specified in IETF RFC 8032 (2017). This article explains the design choices behind both curves, where each is appropriate, why Ed25519 dominates and Ed448 has its niche, and how both fare in the post-quantum world. ## EdDSA: The Concept EdDSA was introduced by Daniel J. Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, and Bo-Yin Yang in 2011. The design goals were: - Constant-time computation by default. The signing and verification routines do not branch on secret data. - Deterministic signatures. The "nonce" used in each signature is derived from the message and the secret key, eliminating the need for high-quality randomness at signing time. - Twist secure curves. The curves are chosen so that invalid-curve attacks have no meaningful surface. - Fast verification. Batch verification of many signatures is significantly faster than ECDSA. The first two points address the most painful failure modes of classical ECDSA. ECDSA signatures need a fresh random nonce for every signature. If the nonce is biased, repeated, or predictable, the private key leaks. Real-world disasters include the 2010 Sony PS3 breach (where a single fixed nonce gave the world the platform's signing key) and the 2013 Bitcoin wallet thefts (where weak Android randomness allowed key recovery). EdDSA derives its nonce from a hash of the secret key and the message, which makes the signature deterministic and immune to entropy failures. The same private key always produces the same signature for the same message. ## Ed25519: The Workhorse Ed25519 is EdDSA over the twisted Edwards curve birationally equivalent to Curve25519, using SHA-512 as the hash function. The curve provides approximately 128 bits of classical security. The signature size is 64 bytes (two 32-byte components, R and S). The public key size is 32 bytes. The private key is 32 bytes (with internal expansion to 64 bytes via SHA-512). These are smaller than RSA signatures and on par with ECDSA over P-256. Where Ed25519 lives in the wild: - OpenSSH (since version 6.5, 2014). Default key type for new installations. - TLS 1.3 (RFC 8446) supports Ed25519 alongside ECDSA P-256 and RSA-PSS. - Tor's onion service descriptors. Ed25519 keys identify v3 hidden services. - Signal Protocol's identity keys. - WireGuard's peer authentication. - The Sigstore project for software supply-chain signing. - Ethereum 2.0 (Beacon Chain) validator key signatures. Performance on modern x86_64 with the AVX2-optimized libsodium implementation: - Signing: roughly 70,000 to 100,000 signatures per second per core. - Verification: roughly 30,000 to 50,000 verifications per second per core. - Batch verification: 2 to 3 times faster per signature than single verification. ## Ed448: The Higher-Security Twin Ed448 is EdDSA over the Edwards form of Curve448 (also called the Goldilocks curve), using SHAKE256 as the hash function. The curve provides approximately 224 bits of classical security. Curve448 was designed by Mike Hamburg in 2015 specifically to fill the gap between 128-bit and 256-bit security tiers. The "Goldilocks" name reflects the choice of the prime modulus 2 to the 448 minus 2 to the 224 minus 1, which sits at a sweet spot for both efficiency and a clean field structure. The signature size is 114 bytes (much larger than Ed25519). The public key is 57 bytes. The private key is 57 bytes (expanded to 114 bytes via SHAKE256). Where Ed448 appears: - TLS 1.3 (RFC 8446) lists Ed448 as an optional signature algorithm. - The Tor project has discussed Ed448 for highest-security onion services but Ed25519 remains the default. - Some embassy-grade and government-mandated cryptographic suites that require the 224-bit security tier. Ed448 is significantly slower than Ed25519. Approximate single-core figures: - Signing: roughly 5,000 signatures per second. - Verification: roughly 2,500 verifications per second. That is 10 to 20 times slower than Ed25519 for the same throughput-class hardware. ## Why Ed25519 Dominates For most applications, 128 bits of classical security is plenty. The exhaustion of a 128-bit key space requires roughly 2 to the 128 operations, which is far beyond any conceivable classical adversary even with planet-scale resources. The argument for higher-security curves comes from two directions: - Long-term confidentiality. Data signed in 2026 might still need to be verifiable in 2080. If the curve has any weakness that emerges over decades, the higher-security tier provides margin. - Compliance. Some standards (CNSA, certain ISO documents) require higher security tiers for top-secret or long-archived data. Most real-world deployments accept the 128-bit security of Ed25519 because: - The 32-byte public key and 64-byte signature are small and fit comfortably in TLS handshakes, certificate chains, and embedded device storage. - The performance is excellent on commodity hardware. - Library support is universal. - The curve has survived a decade of intense public analysis without any meaningful attack. Ed448 wins when the deployment specifically demands the higher security tier and is willing to accept the size and performance costs. ## SHA-512 vs SHAKE256: Why the Hash Difference? Ed25519 uses SHA-512, a fixed-output hash function from the SHA-2 family (FIPS 180-4). Ed448 uses SHAKE256, an extendable-output function from the SHA-3 family (FIPS 202). The choice reflects when each curve was designed. Ed25519 came out in 2011, before SHA-3 was finalized. SHA-512 was the natural choice. Ed448 came out in 2015, after SHA-3 was published. SHAKE256 fits Ed448's larger field naturally and is part of the modern hash family. Both are cryptographically strong. The hash function difference does not affect the security guarantees of either signature scheme, just the implementation surface. Read more in [BLAKE3 Hashing](blake3-hashing) for an alternative modern hash family. ## Determinism vs Randomness EdDSA signatures are deterministic by default. The nonce used in each signature is computed as a hash of the secret key and the message, so the same input always produces the same output. This is a controversial design choice. The benefit is immunity to randomness failures. The drawback is that it makes the implementation a target for fault injection attacks. If an attacker can flip a bit in the secret key during the second of two signatures of the same message, they can recover information by comparing the differing outputs. Real-world EdDSA implementations have been hit by fault injection in smart cards. The mitigation is to add a small amount of fresh randomness to the nonce derivation, producing "hedged EdDSA" or randomized EdDSA. The IETF draft draft-irtf-cfrg-det-sigs-with-noise has discussed this. For most server and network use cases, deterministic Ed25519 is fine. For embedded smart cards exposed to fault attacks, hedged variants are preferred. ## Side-Channel Resistance EdDSA's structure makes it harder to write a leaky implementation than ECDSA. The signing operation does not use secret-dependent branches or memory accesses. The Edwards form supports unified addition formulas that avoid the special cases (point-at-infinity, doubling, addition of inverse points) that plague short Weierstrass curves like the NIST P-curves. This is why Ed25519 has had far fewer side-channel CVEs than ECDSA over P-256. Read more in [NIST P-Curves vs Curve25519](nist-p-curves-vs-curve25519). ## Quantum Resistance Ed25519 and Ed448 are both broken by Shor's algorithm on a sufficiently large quantum computer. The relevant numbers: - Ed25519 needs roughly 2400 logical qubits to break with Shor's. - Ed448 needs roughly 4000 logical qubits. Higher curve order means more qubits, but the polynomial-time speedup of Shor's algorithm makes both eventually broken. The post-quantum migration from EdDSA goes to ML-DSA (Module Lattice DSA, NIST FIPS 204) or SLH-DSA (Stateless Hash-Based DSA, NIST FIPS 205). ML-DSA is the general-purpose replacement. SLH-DSA has very large signatures but provides post-quantum security based purely on hash function properties. Read more in [ML-DSA vs SLH-DSA](mldsa-vs-slhdsa). The NSA's CNSA 2.0 program (announced 2022) requires migration of US government top-secret signature workloads to ML-DSA or SLH-DSA by 2030. ## What QNSQY Uses QNSQY uses Ed25519 as the classical half of its hybrid signature scheme. The post-quantum half is ML-DSA. Signatures over QNSQY-encrypted files combine both: an attacker would need to forge signatures under both Ed25519 and ML-DSA simultaneously, which means breaking both Curve25519 and the lattice security of ML-DSA. QNSQY does not use Ed448. The 224-bit security tier is not currently a requirement, and the additional signature size is meaningful for the file format. Read more in [Hybrid Encryption](hybrid-encryption), [ML-DSA vs SLH-DSA](mldsa-vs-slhdsa), and [X25519 and Ed25519 Explained](x25519-ed25519-explained). ## Picking Between the Two Choose Ed25519 when: - You are building a TLS server, an SSH client, a code-signing pipeline, a messaging app, or any general-purpose system. - Signature size matters (32-byte pubkey, 64-byte signature). - Performance matters. - You expect to migrate to post-quantum within the lifetime of the deployment anyway. Choose Ed448 when: - You have a compliance requirement specifically calling for 224-bit classical security. - The data is signed once and archived for decades. - The signature size cost (114 bytes versus 64) is acceptable for your protocol. For most engineers, Ed25519 is the answer. Ed448 is a specialty curve. ## Verification Throughput at Scale For high-volume verification scenarios (TLS termination, certificate transparency log auditing, blockchain validators), the verification cost adds up quickly. A TLS load balancer terminating one million connections per minute spends real CPU time validating client certificate signatures. Ed25519 has a useful trick called batch verification. Instead of verifying signatures one at a time, the verifier can combine many signatures into a single check. The math involves random linear combinations, and the result is a 2 to 3 times speedup per signature. Libsodium and noble-curves both expose batch verification APIs. ECDSA over P-256 also supports batch verification but with a more complex setup. RSA-PSS does not. For protocols that produce many signatures (such as blockchain proof-of-stake validators emitting hundreds of votes per minute), the batch advantage compounds. Ethereum 2.0's beacon chain, for example, can verify tens of thousands of Ed25519 signatures per second per core using batch optimization. ## Migration Notes from ECDSA to Ed25519 Many systems built in the early 2010s use ECDSA over P-256 and now want to migrate to Ed25519 for the safety and performance benefits. The migration is straightforward but has gotchas: - Key format. ECDSA P-256 keys are 32 bytes (private) plus 33 to 65 bytes (public). Ed25519 keys are 32 bytes (private seed) plus 32 bytes (public). The wire formats are not interchangeable. - Signature format. ECDSA signatures are typically DER-encoded (variable length, 70-72 bytes). Ed25519 signatures are fixed 64 bytes. - Verification semantics. ECDSA allows multiple valid signatures of the same message. Ed25519 has a single deterministic signature. Some applications (like Bitcoin) explicitly normalize ECDSA signatures to a canonical form, which Ed25519 gets for free. - Hash dependency. ECDSA is hash-agnostic. Ed25519 always uses SHA-512. Make sure your protocol can pin the hash function. For new systems, skip ECDSA and start with Ed25519. For migrating systems, plan a dual-key transition window where verifiers accept both old ECDSA signatures and new Ed25519 signatures. Read more in [DSA Legacy Status](dsa-legacy-status). ## FAQ **Is Ed25519 NIST approved?** Yes. NIST FIPS 186-5 (2023) added Ed25519 and Ed448 to the approved signature algorithms list. Before 186-5, Ed25519 was widely deployed but not formally FIPS-blessed. **Can I convert an Ed25519 key to use ECDSA?** Mathematically, the underlying curve is birationally equivalent to Curve25519, but the key formats and signature schemes differ. You cannot use the same private key bytes for both. Ed25519 keys are derived through a specific clamping procedure that excludes them from being valid ECDSA keys directly. **Why is Ed25519 deterministic?** To eliminate the catastrophic failure mode of ECDSA where weak random nonces leak the private key. Sony PS3 (2010) and several Bitcoin wallets (2013) lost keys this way. EdDSA's deterministic nonce removes the foot-gun. **Can I sign the same message twice and get different Ed25519 signatures?** Not by default. The signature is deterministic. Some implementations offer a "randomized" mode that mixes in fresh randomness, producing different signatures. The IETF draft on hedged signatures discusses this. **Does Ed448 use a different field than P-521?** Yes. Ed448 uses 2 to the 448 minus 2 to the 224 minus 1 (Goldilocks prime). P-521 uses 2 to the 521 minus 1 (Mersenne prime). They are different curves at different security tiers. ## Sources 1. IETF RFC 8032: Edwards-Curve Digital Signature Algorithm (EdDSA). https://www.rfc-editor.org/rfc/rfc8032 2. NIST FIPS 186-5: Digital Signature Standard (DSS). https://csrc.nist.gov/pubs/fips/186-5/final 3. Bernstein, Duif, Lange, Schwabe, Yang, "High-Speed High-Security Signatures" (CHES 2011). https://ed25519.cr.yp.to/ed25519-20110926.pdf 4. Mike Hamburg, "Ed448-Goldilocks, a new elliptic curve" (2015). https://eprint.iacr.org/2015/625 5. IETF RFC 7748: Elliptic Curves for Security. https://www.rfc-editor.org/rfc/rfc7748 6. NSA, Commercial National Security Algorithm Suite 2.0 (2022). https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF ## Related Articles - [X25519 and Ed25519 Explained](x25519-ed25519-explained) - [Curve25519 Deep Dive](curve25519-deep-dive) - [NIST P-Curves vs Curve25519](nist-p-curves-vs-curve25519) - [ML-DSA vs SLH-DSA](mldsa-vs-slhdsa) - [Hybrid Encryption](hybrid-encryption) --- ### Protect Your Data Before Q-Day Arrives QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats. [Try QNSQY](../../pricing.html)