X25519 and Ed25519: Classical Crypto in the Quantum Age

Two Tools Built on One Beautiful Curve

Encryption is a two-step dance. First, two people who have never met need to agree on a shared secret over an open channel where anyone might be listening. Second, one person needs to prove they are who they claim to be, in a way that cannot be forged. These are fundamentally different problems, and they require different tools.

X25519 solves the first problem. It lets two parties agree on a shared secret, even if an eavesdropper is recording every byte that passes between them. The eavesdropper, despite having all the transmitted data, cannot figure out the shared secret. This is called key exchange (or key agreement).

Ed25519 solves the second problem. It lets someone attach a mathematical proof to a message saying, "I wrote this, and it has not been altered since I signed it." Anyone can verify the proof using the signer's public key, but no one can forge the proof without the signer's private key. This is called a digital signature.

Both algorithms are built on the same mathematical foundation: an elliptic curve called Curve25519, designed by cryptographer Daniel Bernstein in 2005. The fact that a single mathematical structure powers both key exchange and signatures is elegant, but the real significance of Curve25519 is in the design choices Bernstein made and why he made them.

What Is an Elliptic Curve? (Without the Heavy Math)

An elliptic curve is a special type of mathematical equation that, when graphed, looks like a smooth, looping curve. The exact shape does not matter for understanding how it is used. What matters is a property that cryptographers exploit: you can define a way to "add" two points on the curve and get a third point on the curve. And you can "multiply" a point by a number, which means adding it to itself repeatedly.

Here is the key trick. If you pick a starting point G on the curve and multiply it by a secret number (your private key), you get a new point (your public key). Going forward is easy: multiply G by your secret number and you get the public key instantly. Going backward, knowing G and the public key but trying to figure out the secret number, is extraordinarily hard. This is called the elliptic curve discrete logarithm problem (ECDLP), and there is no known efficient way to solve it on a classical computer.

Think of it like mixing paint. If you know the starting color (G) and the amount of a secret pigment to add (private key), you can easily produce the resulting color (public key). But if someone shows you the starting color and the resulting color, figuring out exactly how much pigment was added is effectively impossible.

Why Curve25519 Specifically?

There are many elliptic curves used in cryptography. NIST published several standard curves in the early 2000s (P-256, P-384, P-521). So why did Bernstein design a new one? Several reasons:

Designed for constant-time implementation. One of the most dangerous attacks against cryptographic software is a timing attack. If your code takes slightly longer to process certain inputs, an attacker can measure those timing differences and use them to deduce your private key. Curve25519 was specifically designed so that every operation takes the same amount of time regardless of the input values. This property is built into the mathematics of the curve itself, not just the software implementation. NIST curves do not have this property inherently, making constant-time implementations much harder to write correctly.

Transparent parameter selection. The NIST curves were published with parameters that appeared somewhat arbitrary. Some cryptographers raised concerns that the NSA might have selected parameters with hidden properties that could enable a backdoor. These concerns were amplified by the later revelation that the NSA had indeed backdoored a different NIST standard (the Dual_EC_DRBG random number generator). Curve25519 uses the prime 2²⁵⁵ - 19 (hence the name), which is the largest prime below 2²⁵⁵. There is nothing arbitrary about it. The parameter choice is fully explained and justified.

128-bit security level. Curve25519 provides approximately 128 bits of security against classical attacks. This is the same level targeted by AES-128. For the past 20 years, 128-bit security has been the standard benchmark for "secure enough against all foreseeable classical computation."

Compact keys. Public keys are just 32 bytes. Private keys are 32 bytes. Signatures (Ed25519) are 64 bytes. Compare this to RSA-2048, where public keys are 256 bytes and signatures are 256 bytes. Or to the new post-quantum algorithms, where ML-KEM-768 public keys are 1,184 bytes and ML-DSA-65 signatures are 3,309 bytes. Curve25519 is remarkably compact.

X25519: Key Exchange in Detail

Suppose Alice and Bob want to encrypt a file that only they can read. They have never met in person and cannot exchange secrets face-to-face. Here is how X25519 solves this:

1. Alice generates a random 32-byte private key and computes her 32-byte public key by performing the elliptic curve multiplication.
2. Bob does the same: generates his own private key and public key.
3. Alice sends her public key to Bob. Bob sends his public key to Alice. These can be sent in the open. An eavesdropper seeing both public keys cannot derive the shared secret.
4. Alice takes Bob's public key and multiplies it by her private key on the curve. Bob takes Alice's public key and multiplies it by his private key on the curve. Due to the mathematical properties of elliptic curves, they both arrive at the same point. This shared point is their shared secret.

The shared secret (32 bytes) is then used to derive an encryption key (typically via a key derivation function like BLAKE3 or HKDF). This key encrypts the actual data using a symmetric cipher like AES-256-GCM.

X25519 is formally described in RFC 7748, published by the Internet Engineering Task Force (IETF) in 2016. The computation completes in microseconds on modern hardware. The entire key exchange adds only 64 bytes of overhead (32-byte public key from each side).

Property	X25519	Ed25519
Purpose	Key agreement	Digital signatures
Public key size	32 bytes	32 bytes
Private key size	32 bytes	32 bytes (+ 32 public)
Signature / shared secret	32 bytes	64 bytes
Security level	~128-bit	~128-bit
Standardized in	RFC 7748 (2016)	RFC 8032 (2017)

Ed25519: Digital Signatures in Detail

Digital signatures solve a different problem from key exchange. Think of them like a wax seal on a medieval letter. The seal proves who sent the letter (authentication) and that no one opened and resealed it (integrity). A digital signature does the same thing, but with mathematical certainty instead of melted wax.

When Alice signs a file with Ed25519:

1. Alice hashes the file to produce a compact digest (32 bytes).
2. Alice uses her private key and the hash to compute a 64-byte signature through a series of elliptic curve operations.
3. Anyone with Alice's public key can verify the signature by checking the mathematical relationship between the public key, the file hash, and the signature.
4. If even a single bit of the file changes after signing, the signature check fails.

Ed25519 is defined in RFC 8032 and uses a variant of Curve25519 called the "twisted Edwards form," which enables faster signature computation. Despite the different mathematical representation, it provides the same 128-bit security level.

Ed25519 has become the de facto standard for digital signatures in modern software. SSH recommends Ed25519 keys over RSA. Git supports Ed25519 for signing commits. Signal, WireGuard, and many other security-critical systems use it. The combination of small signatures (64 bytes versus 256 bytes for RSA-2048), fast verification, and strong security has made it the default choice.

Where You Already Use Curve25519

Curve25519 is not theoretical. It is running in production, at enormous scale, on billions of devices right now:

• TLS 1.3: X25519 is the most commonly used key exchange algorithm in TLS 1.3. When you visit a website, your browser likely uses X25519 to establish the encrypted connection. Google, Cloudflare, and most major web servers have X25519 as their default.
• SSH: Ed25519 is the recommended key type for SSH authentication. When system administrators connect to servers, Ed25519 is the standard.
• Signal Protocol: The encryption protocol behind Signal, WhatsApp, and Facebook Messenger uses both X25519 and Ed25519.
• WireGuard VPN: Uses Curve25519 exclusively for all cryptographic operations.
• iOS and macOS: Apple uses Curve25519 in multiple system-level cryptographic operations.
• Android: Google's cryptographic libraries use Curve25519 extensively.

How Curve25519 Compares to NIST Curves and RSA

Before Curve25519, the dominant elliptic curve standards were NIST P-256 and NIST P-384, published by NIST in the early 2000s. These curves work, but they have several properties that make them harder to implement safely:

• Variable-time operations: The mathematical formulas for point addition on NIST curves have different execution paths depending on whether the inputs are equal, zero, or general. Implementing constant-time code requires careful workarounds for each special case.
• Opaque parameter selection: The seed values used to generate the NIST curves were never fully explained. After the Dual_EC_DRBG scandal (where the NSA was found to have backdoored a NIST random number generator), trust in unexplained NIST parameters eroded significantly.
• Larger attack surface for implementation bugs: NIST curve implementations have historically been a source of security vulnerabilities. Subtle bugs in special-case handling have led to real exploits in production software.

RSA is the even older alternative. RSA-2048, still widely used, requires 256-byte public keys and 256-byte signatures. RSA key generation takes milliseconds (compared to microseconds for Ed25519). RSA-2048 provides roughly 112 bits of classical security, less than the 128 bits provided by Curve25519. And RSA is far more vulnerable to quantum computers; Shor's algorithm can break RSA-2048 with significantly fewer qubits than needed for Curve25519.

Property	Curve25519	NIST P-256	RSA-2048
Public key size	32 bytes	64 bytes	256 bytes
Signature size	64 bytes	64 bytes	256 bytes
Classical security	~128 bit	~128 bit	~112 bit
Constant-time by design	Yes	No (requires workarounds)	No (requires blinding)
Parameter transparency	Fully explained	Unexplained seed	N/A

Curve25519 won the adoption race on its merits: faster, smaller, safer to implement, and with transparent parameters. Its dominance in modern protocols (TLS 1.3, SSH, Signal, WireGuard) reflects a broad consensus in the cryptographic engineering community.

The Quantum Threat: Why These Algorithms Will Eventually Break

Here is the uncomfortable truth. X25519 and Ed25519 are vulnerable to quantum computers. Not to Grover's algorithm (which only provides a modest speedup against symmetric encryption), but to Shor's algorithm, which is far more devastating.

Shor's algorithm can solve the elliptic curve discrete logarithm problem in polynomial time. In plain language: given a Curve25519 public key, a sufficiently large quantum computer could compute the corresponding private key. This breaks both X25519 (the attacker can derive the shared secret from intercepted public keys) and Ed25519 (the attacker can forge signatures).

The quantum computer required to break Curve25519 would need on the order of 2,000 to 3,000 logical qubits. With current error correction technology, this translates to millions of physical qubits. No quantum computer of this scale exists today. The most optimistic estimates place the timeline around 2030 to 2035, though some researchers believe it could take longer.

What Would Actually Happen If Quantum Computers Broke Curve25519?

Suppose a quantum computer capable of running Shor's algorithm against Curve25519 exists tomorrow. What concretely breaks?

Confidentiality of past communications. Any encrypted data where the key was exchanged using X25519 alone, and the attacker recorded the ciphertext, could be decrypted. TLS sessions from years ago, if captured, could be retroactively decrypted. This is the "harvest now, decrypt later" scenario.

Signature forgery. An attacker could forge Ed25519 signatures, impersonating anyone whose public key is known. Software updates, code signing, authentication tokens, anything relying on Ed25519 alone would be compromised.

What would NOT break: AES-256-GCM (symmetric encryption), BLAKE3 (hashing), Argon2id (password hashing), and Shamir's Secret Sharing. These are not based on the discrete logarithm problem and are not vulnerable to Shor's algorithm. Post-quantum algorithms like ML-KEM and ML-DSA would also remain secure.

This is precisely why the hybrid approach exists. The question is not "will quantum computers break Curve25519?" (they will, eventually) but "when?" The uncertainty in the timeline makes hybrid cryptography the responsible choice.

The Hybrid Approach: Belt and Suspenders

QNSQY never uses X25519 or Ed25519 alone. Every operation pairs a classical algorithm with a post-quantum algorithm. Both must participate. The combined result is at least as strong as the stronger of the two. This is called hybrid cryptography.

Key exchange: ML-KEM + X25519

1. ML-KEM (the NIST post-quantum key encapsulation standard, FIPS 203) produces a 32-byte shared secret. This secret is secure against quantum computers.
2. X25519 key exchange produces a 32-byte shared secret. This secret is secure against all classical computers.
3. Both shared secrets are combined via BLAKE3 into a single 256-bit encryption key.
4. The final key depends on both secrets. An attacker would need to break both ML-KEM and X25519 to recover it. Breaking just one is not enough.

Signatures: ML-DSA + Ed25519

1. The file is signed with ML-DSA (the NIST post-quantum signature standard, FIPS 204). This signature is secure against quantum computers.
2. The file is also signed with Ed25519. This signature is secure against all classical computers.
3. Verification requires both signatures to be valid. If either one fails, the verification fails.
4. An attacker must break both algorithms to forge a valid combined signature.

This is not a fringe recommendation. The hybrid approach is endorsed by:

• NIST: Recommends hybrid constructions during the post-quantum transition period.
• NSA CNSA 2.0: Requires hybrid key exchange for national security systems.
• BSI (Germany): Recommends hybrid TLS with post-quantum + classical algorithms.
• ANSSI (France): Mandates hybrid approaches for government use.

It is already deployed at scale. Google Chrome, Mozilla Firefox, and other major browsers use X25519MLKEM768 (the hybrid of X25519 and ML-KEM-768) for TLS 1.3 key exchange. Cloudflare enables it by default on all their servers. This is the same hybrid construction QNSQY uses for data encryption.

The overhead of the hybrid approach is minimal. X25519 adds 32 bytes per side to the key exchange. Ed25519 adds 64 bytes per signature. For data encryption, these bytes are negligible compared to the encrypted payload. The computation cost is microseconds. There is no practical reason not to include the classical layer.

Sources

1. Bernstein, D. J. "Curve25519: new Diffie-Hellman speed records." 2006. Public Key Cryptography, PKC 2006. cr.yp.to/ecdh/curve25519-20060209.pdf
2. RFC 7748: Elliptic Curves for Security (X25519, X448). IETF, January 2016. www.rfc-editor.org/rfc/rfc7748
3. RFC 8032: Edwards-Curve Digital Signature Algorithm (Ed25519, Ed448). IETF, January 2017. www.rfc-editor.org/rfc/rfc8032
4. Bernstein, D. J. and Lange, T. "SafeCurves: choosing safe curves for elliptic-curve cryptography." safecurves.cr.yp.to
5. NSA CNSA 2.0: Commercial National Security Algorithm Suite 2.0. media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF

Related Articles

• Why Hybrid Encryption Matters
• ML-KEM: Future of Key Encapsulation
• Classical vs Quantum-Safe Encryption Compared