Hubbry Logo
EdDSAEdDSAMain
Open search
EdDSA
Community hub
EdDSA
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
EdDSA
EdDSA
EdDSA
View on Wikipedia
from Wikipedia
EdDSA
General
DesignersDaniel J. Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, Bo-Yin Yang, et al.
First published26 September 2011 (14 years ago) (2011-09-26)
Detail
StructureElliptic-curve cryptography

In public-key cryptography, Edwards-curve Digital Signature Algorithm (EdDSA) is a digital signature scheme using a variant of Schnorr signature based on twisted Edwards curves.[1] It is designed to be faster than existing digital signature schemes without sacrificing security. It was developed by a team including Daniel J. Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, and Bo-Yin Yang.[2] The reference implementation is public-domain software.[3]

Summary

[edit]

The following is a simplified description of EdDSA, ignoring details of encoding integers and curve points as bit strings; the full details are in the papers and RFC.[4][2][1]

An EdDSA signature scheme is a choice:[4]: 1–2 [2]: 5–6 [1]: 5–7 

  • of finite field over odd prime power ;
  • of elliptic curve over whose group of -rational points has order , where is a large prime and is called the cofactor;
  • of base point with order ; and
  • of cryptographic hash function with -bit outputs, where so that elements of and curve points in can be represented by strings of bits.

These parameters are common to all users of the EdDSA signature scheme. The security of the EdDSA signature scheme depends critically on the choices of parameters, except for the arbitrary choice of base point—for example, Pollard's rho algorithm for logarithms is expected to take approximately curve additions before it can compute a discrete logarithm,[5] so must be large enough for this to be infeasible, and is typically taken to exceed 2200.[6] The choice of is limited by the choice of , since by Hasse's theorem, cannot differ from by more than . The hash function is normally modelled as a random oracle in formal analyses of EdDSA's security.

Within an EdDSA signature scheme,

Public key
An EdDSA public key is a curve point , encoded in bits.
Signature verification
An EdDSA signature on a message by public key is the pair , encoded in bits, of a curve point and an integer satisfying the following verification equation, where denotes concatenation:

Private key
An EdDSA private key is a -bit string which should be chosen uniformly at random. The corresponding public key is , where is the least significant bits of interpreted as an integer in little-endian.
Signing
The signature on a message is deterministically computed as where for , and This satisfies the verification equation

Ed25519

[edit]

Ed25519 is the EdDSA signature scheme using SHA-512 (SHA-2) and an elliptic curve related to Curve25519[2] where

  • is the twisted Edwards curve

  • and
  • is the unique point in whose coordinate is and whose coordinate is positive.
    "positive" is defined in terms of bit-encoding:
    • "positive" coordinates are even coordinates (least significant bit is cleared)
    • "negative" coordinates are odd coordinates (least significant bit is set)
  • is SHA-512, with .

The twisted Edwards curve is known as edwards25519,[7][1] and is birationally equivalent to the Montgomery curve known as Curve25519. The equivalence is[2][7][8]

Performance

[edit]

The original team has optimized Ed25519 for the x86-64 Nehalem/Westmere processor family. Verification can be performed in batches of 64 signatures for even greater throughput. Ed25519 is intended to provide attack resistance comparable to quality 128-bit symmetric ciphers.[9]

Public keys are 256 bits long and signatures are 512 bits long.[10]

Secure coding

[edit]

Ed25519 is designed to avoid implementations that use branch conditions or array indices that depend on secret data,[2]: 2 [1]: 40  in order to mitigate side-channel attacks.

As with other discrete-log-based signature schemes, EdDSA uses a secret value called a nonce unique to each signature. In the signature schemes DSA and ECDSA, this nonce is traditionally generated randomly for each signature—and if the random number generator is ever broken and predictable when making a signature, the signature can leak the private key, as happened with the Sony PlayStation 3 firmware update signing key.[11][12][13][14]

In contrast, EdDSA chooses the nonce deterministically as the hash of a part of the private key and the message. Thus, once a private key is generated, EdDSA has no further need for a random number generator in order to make signatures, and there is no danger that a broken random number generator used to make a signature will reveal the private key.[2]: 8 

Standardization and implementation inconsistencies

[edit]

Note that there are two standardization efforts for EdDSA, one from IETF, an informational RFC 8032 and one from NIST as part of FIPS 186-5.[15] The differences between the standards have been analyzed,[16][17] and test vectors are available.[18]

Software

[edit]

Notable uses of Ed25519 include OpenSSH,[19] GnuPG[20] and various alternatives, and the signify tool by OpenBSD.[21] Usage of Ed25519 (and Ed448) in the SSH protocol has been standardized.[22] In 2023 the final version of the FIPS 186-5 standard included deterministic Ed25519 as an approved signature scheme.[15]

Ed448

[edit]

Ed448 is the EdDSA signature scheme defined in RFC 8032 using the hash function SHAKE256 and the elliptic curve edwards448, an (untwisted) Edwards curve related to Curve448 in RFC 7748. Ed448 has also been approved in the final version of the FIPS 186-5 standard.[15]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

EdDSA

View on Grokipedia
from Grokipedia
The Edwards-curve Digital Signature Algorithm (EdDSA) is a scheme based on s in Edwards form, serving as a variant of the adapted for high-performance cryptographic applications. It was standardized in RFC 8032 in January 2017 by the (IETF), providing a framework for generating and verifying signatures using recommended parameters for security and efficiency. EdDSA is instantiated primarily as Ed25519, which uses the over a 255-bit prime field to achieve approximately 128 bits of security with 32-byte public keys and 64-byte signatures, and Ed448, which employs the Edwards448 curve over a 448-bit prime field for about 224 bits of security with 57-byte public keys and 114-byte signatures. These instances were originally proposed in separate works: Ed25519 in a 2011 by , Niels Duif, Tanja Lange, Peter Schwabe, and Bo-Yin Yang, emphasizing high-speed signing and verification on commodity hardware, and Ed448 in a 2015 by Mike Hamburg, focusing on enhanced security against certain attacks while maintaining performance. EdDSA's design incorporates deterministic nonce generation, eliminating the need for random numbers during signing to avoid vulnerabilities from poor sources, and uses a (SHA-512 for Ed25519 and SHAKE256 for Ed448) to derive ephemeral keys from the private key and . This approach, along with complete addition formulas for the underlying Edwards curves, enhances resistance to side-channel attacks, such as timing and , making it suitable for resource-constrained environments like embedded systems and protocols including TLS and SSH. Variants include PureEdDSA for direct signing without prehashing, HashEdDSA for prehashed messages (e.g., Ed25519ph and Ed448ph), and context-supporting options like Ed25519ctx to enable domain separation in multi-protocol deployments. The algorithm's efficiency stems from its use of twisted Edwards curves, which allow for faster and uniform ladder implementations compared to traditional Weierstrass curves used in schemes like ECDSA. EdDSA signatures are compact and malleable only in controlled ways, with built-in protections against collisions in the for PureEdDSA, ensuring robustness in practice. Since its standardization, EdDSA has been integrated into numerous cryptographic libraries and standards, including , GnuPG, and Java's security API, reflecting its balance of security, speed, and simplicity.

Introduction

Definition and Purpose

EdDSA, or the Edwards-curve , is a scheme that leverages elliptic curves in Edwards form to produce signatures based on a variant of Schnorr signatures. It operates over a EE defined on a Fq\mathbb{F}_q, utilizing a HH, a base point BB on the curve, and a private key aa to generate public keys and signatures in the form of pairs (R,S)(R, S). The primary purpose of EdDSA is to deliver fast and secure digital signatures for applications, addressing key vulnerabilities in earlier schemes like DSA and ECDSA. Unlike ECDSA, which relies on random nonces that can lead to security breaches if poorly generated—as seen in the Sony PlayStation 3 incident—EdDSA employs deterministic nonce generation via r=H(a~,M)r = H(\tilde{a}, M), where a~\tilde{a} is a hashed representation of the private key and MM is the message, ensuring reproducibility without introducing randomness flaws. This design targets high-speed verification, with implementations achieving up to 71,000 verifications per second on standard hardware, while providing equivalent security levels around 21282^{128} bits against existential forgery under chosen-message attacks. Furthermore, EdDSA emphasizes resistance to side-channel attacks, such as timing, cache, and branch-prediction exploits, by avoiding secret-dependent operations like conditional branches or array indexing based on private data; all computations use uniform-time algorithms on twisted Edwards curves. Compared to ECDSA, EdDSA offers significantly faster performance in signing and verification speeds— with signing up to over 20 times faster and batch verification up to over 15 times faster in benchmarks from the original paper—while maintaining comparable security margins, making it suitable for resource-constrained environments like embedded systems and high-throughput protocols. Detailed security comparisons are explored in subsequent analyses.

Historical Development

EdDSA, or Edwards-curve Digital Signature Algorithm, was developed by , Niels Duif, Tanja Lange, Peter Schwabe, and Bo-Yin Yang as a high-speed, high-security scheme based on . The scheme was first specified in their paper "High-speed high-security signatures," initially released as a on September 26, 2011. This work introduced EdDSA as an instantiation of the adapted for twisted Edwards curves, emphasizing deterministic nonce generation to mitigate risks associated with failures. The primary motivations for EdDSA stemmed from observed vulnerabilities in existing elliptic curve signature schemes like ECDSA, particularly the catastrophic consequences of nonce reuse, as exemplified by the 2010 Sony PlayStation 3 incident where poor randomness in ECDSA nonces led to private key recovery. Developers sought a more robust alternative that avoided such pitfalls through fully deterministic signing processes while leveraging the complete Edwards addition law on twisted Edwards for faster, more constant-time arithmetic operations, enabling efficient implementations without compromising security. These design choices addressed both practical performance needs and the demand for verifiable security in resource-constrained environments. Key milestones in EdDSA's evolution include its formal specification in the 2011 paper, followed by efforts that culminated in RFC 8032, published in January 2017 by the , which detailed EdDSA for curves Ed25519 and Ed448 with precise encoding and decoding rules. Separately, in 2015, Mike Hamburg proposed Ed448 as another instantiation of EdDSA, which was included alongside Ed25519 in the RFC 8032 . Further adoption came with its approval in NIST's Federal Information Processing Standard (FIPS) 186-5, released on February 3, 2023, incorporating EdDSA as an approved technique for digital signatures alongside additional requirements for federal use. As of late 2025, no major updates have extended EdDSA into quantum-resistant contexts, as it remains based on elliptic curves vulnerable to quantum attacks. EdDSA's development was closely tied to the SafeCurves project, led by and Lange, which guided the selection of secure elliptic curves by evaluating criteria such as resistance to side-channel attacks, fast ladder implementations, and complete addition formulas—properties exemplified by the birationally equivalent to Ed25519. This collaboration ensured that EdDSA's underlying curves met rigorous security standards beyond mere hardness, promoting safe deployment in cryptographic protocols.

Mathematical Foundations

Edwards Curves

Edwards curves are elliptic curves presented in a form that simplifies the group law, making them particularly suitable for cryptographic protocols. The curve is defined by the equation −x2+y2=1+dx2y2-x^2 + y^2 = 1 + d x^2 y^2 over the Fp\mathbb{F}_p, where pp is an odd prime and d∈Fpd \in \mathbb{F}_p is a nonzero scalar ensuring the curve is nonsingular (specifically, ad(a−d)≠0ad(a - d) \neq 0 in the generalized presentation, but here with the coefficient of x2x^2 as −1-1). This equation represents a birationally equivalent transformation of traditional Weierstrass-form elliptic curves y2=x3+Ax+By^2 = x^3 + Ax + B, allowing the same underlying group structure while offering computational benefits. A key property of Edwards curves is the complete addition law, which can be implemented in projective coordinates (X:Y:Z)(X : Y : Z) (where x=X/Zx = X/Z and y=Y/Zy = Y/Z) without exceptional cases or branchings for distinct points, inverses, or the identity. This unified approach avoids the need for separate handling of point doublings, mixed additions, or identity elements, reducing implementation complexity and potential errors. The curves also exhibit symmetry in xx and yy, facilitating efficient parameterization and arithmetic. These features stem from the geometric interpretation of the curve as a normalized form that aligns addition with simple rational functions. The group law is explicitly given by formulas for point and doubling in projective coordinates. For two points (X1:Y1:Z1)(X_1 : Y_1 : Z_1) and (X2:Y2:Z2)(X_2 : Y_2 : Z_2), the sum (X3:Y3:Z3)(X_3 : Y_3 : Z_3) uses intermediate computations such as A=Z1Z2A = Z_1 Z_2, B=A2B = A^2, C=X1X2C = X_1 X_2, D=Y1Y2D = Y_1 Y_2, E=dCDE = d C D, F=B−EF = B - E, G=B+EG = B + E, yielding X3=AF((X1+Y1)(X2+Y2)−C−D)X_3 = A F ((X_1 + Y_1)(X_2 + Y_2) - C - D), Y3=AG(D+C)Y_3 = A G (D + C), Z3=FGZ_3 = F G (adapted for the −1-1 on x2x^2). A simplified view of the dehomogenized form gives the affine formulas x3=x1y2+y1x21+dx1x2y1y2x_3 = \frac{x_1 y_2 + y_1 x_2}{1 + d x_1 x_2 y_1 y_2}, y3=y1y2+x1x21−dx1x2y1y2y_3 = \frac{y_1 y_2 + x_1 x_2}{1 - d x_1 x_2 y_1 y_2}, illustrating the compact rational without requiring field inversions during projective computation. Doubling formulas follow similarly, with costs around 3M + 4S (multiplications and squarings) for efficiency. These inversion-free operations enable fast ladder implementations. In cryptographic contexts, Edwards curves excel due to their support for constant-time, side-channel-resistant arithmetic, essential for secure schemes. The unified formulas ensure uniform execution paths, mitigating timing and simple attacks, while the overall speed surpasses many Weierstrass-based alternatives—additions cost approximately 10M + 1S in general projective coordinates. This makes them ideal for high-performance applications like digital signatures, where repeated group operations must balance security and . The form admits extensions to twisted variants for optimized parameter selection over various fields.

Twisted Edwards Curves

Twisted Edwards curves generalize the form to ax2+y2=1+dx2y2ax^2 + y^2 = 1 + d x^2 y^2, where aa and dd are distinct nonzero scalars in the base field kk (with characteristic not 2), allowing a≠1a \neq 1 unlike the standard Edwards curves where a=1a = 1. This generalization covers a broader class of elliptic curves while preserving desirable geometric properties, such as the curve being nonsingular as long as a≠da \neq d. A key advantage of twisted Edwards curves is their support for complete and unified addition laws, which apply uniformly to all pairs of points without exceptional cases, provided aa is a square and dd a nonsquare in the field; this ensures resistance to certain side-channel attacks and simplifies implementation in cryptographic protocols. Additionally, they enable highly efficient ladder algorithms for , achieving costs as low as 10 multiplications plus one squaring and two doublings in projective coordinates, or 9 multiplications plus one squaring and two doublings in inverted coordinates, making them suitable for high-speed . To further optimize arithmetic, twisted Edwards curves often employ extended projective coordinates (X:Y:Z:T)(X : Y : Z : T), where x=X/Zx = X/Z, y=Y/Zy = Y/Z, and the relation XY=ZTXY = ZT holds, allowing the storage of the product T=xyT = xy alongside the other coordinates. This representation doubles computational speed for addition and doubling operations by enabling parallelizable formulas: unified addition requires only 9M + 2D (or 8M + 1D when a=−1a = -1), while dedicated doubling uses 4M + 4S + 1D, with mixed additions at 8M + 1D; such efficiencies can improve by 4% to 18% compared to prior methods and support simple protections. Twisted Edwards curves are birationally equivalent to Montgomery curves via explicit maps, and in fact isogenous to them, permitting x-coordinate-only arithmetic for applications like while retaining full (x, y)-coordinate operations essential for digital signatures that require y-coordinate verification. This duality expands the range of secure curves available for , as every twisted Edwards curve corresponds to a Montgomery form, facilitating between different representations.

Parameter Selection

Parameter selection for EdDSA involves choosing elliptic curve parameters that balance security, efficiency, and resistance to known attacks, primarily for twisted Edwards curves of the form ax2+y2=1+dx2y2ax^2 + y^2 = 1 + dx^2 y^2 over a Fp\mathbb{F}_p. The field is defined by a prime pp such that the curve order #E(Fp)≈p\#E(\mathbb{F}_p) \approx p, ensuring the group is large enough for cryptographic security; specifically, the order factors as #E(Fp)=ℓ⋅2c\#E(\mathbb{F}_p) = \ell \cdot 2^c, where ℓ\ell is a large prime (providing approximately 12log⁡2ℓ\frac{1}{2} \log_2 \ell-bit security against the Pollard rho attack) and the cofactor 2c2^c is small with c≤8c \leq 8 to facilitate efficient cofactor during signing while avoiding excessive vulnerability to small-subgroup attacks. Curve constants aa and dd are selected to optimize arithmetic speed and security: a=−1a = -1 is commonly chosen when p≡1(mod4)p \equiv 1 \pmod{4} for faster computations via the negation map, while dd must be a non-square (not a ) modulo pp to ensure the curve equation defines a secure group structure without exceptional cases in the addition ; additionally, parameters should be chosen in a rigid, verifiable manner to ensure transparency and prevent potential backdoors, as recommended by criteria such as those outlined on SafeCurves. The base point BB is an arbitrary generator of the large-order , typically chosen to have a small x-coordinate for encoding efficiency, but verified to lie in the correct (order ℓ\ell); cofactor cleavage techniques, such as multiplying by 2c2^c during , ensure operations stay within the secure . The HH outputs 2b2b bits, where b≈12log⁡2ℓb \approx \frac{1}{2} \log_2 \ell, using a conservative cryptographic hash like SHA-512 to derive nonces and compress messages securely. Security goals guide these choices to mitigate specific threats: the embedding degree kk must satisfy k>log⁡pℓk > \log_p \ell (typically k>20k > 20 for 128-bit ) to resist MOV and Smart attacks, which exploit Weil/ pairings to reduce the problem to a ; this is verified computationally for candidate curves. The curve must have a complete torsion over Fp\mathbb{F}_p, meaning all points of order dividing 2c2^c are defined without anomalies, to prevent invalid curve attacks. Small attacks are avoided by the small cofactor and by ensuring the and scalar encoding clamp to multiples of 2c2^c, confining operations to the prime-order . These criteria, drawn from rigorous analysis, prioritize curves with fast, complete addition formulas while excluding those vulnerable to pairing-based or exceptional-case exploits.

Algorithm Specification

Key Generation

In EdDSA, key generation begins with the selection of a private key seed, which is a uniformly random b-bit string kk, where b is the specified bit length for the curve (256 for Ed25519, 456 for Ed448). This string kk serves as a seed for the deterministic derivation of the signing scalar. The scalar ss is then computed from kk using the curve's hash function with clamping to ensure it lies in the appropriate range modulo ℓ\ell. For Ed25519, ss is the clamped little-endian integer from the first 32 bytes of SHA-512(kk); for Ed448, from the first 57 bytes of SHAKE256(kk, 114). Clamping for Ed25519 clears the lowest three bits and sets the second-most significant bit; for Ed448, it clears the lowest two bits and sets a specific high bit. The scalar is then reduced modulo ℓ\ell. This deterministic process enhances security by avoiding direct use of raw randomness in scalar multiplication. The public key AA is derived by performing : A=sBA = s B, where BB is the fixed base point of the curve. The point AA is encoded into a b-bit string, typically in little-endian format consisting of the y-coordinate (b-1 bits) followed by a for the x-coordinate. This encoding facilitates compact representation and efficient verification. The full key generation process follows these steps:
  1. Generate a uniform random b-bit string kk as the private key seed.
  2. Compute the clamped hash-based scalar ss from kk as described.
  3. Perform the scalar multiplication to obtain the public key point A=sBA = s B and encode it accordingly.
These steps ensure that the key pair is securely generated and uniquely tied to the curve parameters.

Signature Generation

The signature generation process in EdDSA produces a signature on a given message using the signer's private key and corresponding public key, ensuring determinism to prevent reuse of nonces that could compromise security. The algorithm relies on a hash-based nonce derivation, elliptic curve point multiplication, and a Fiat-Shamir transform to bind the signature to the message without interactive protocols. The inputs to signature generation are the private key kk (a , typically 32 octets for Ed25519 or 57 for Ed448), the public key AA (the point derived from kk), and the MM (of arbitrary length). First, a deterministic nonce rr is computed using the curve's on the second half of the hash of kk concatenated with MM, reduced ℓ\ell. For Ed25519, this is the integer from SHA-512(SHA-512(kk)[32:64] ∥M\parallel M); for Ed448, SHAKE256(SHAKE256(kk, 114)[57:114] ∥M\parallel M, 114). This nonce derivation uses a portion of the hash of the private combined with the to ensure uniqueness per signing instance while avoiding external randomness. Next, the point RR is calculated as R=rBR = r B, where BB is the fixed base point of the curve, performed via efficient with rmod  ℓr \mod \ell. The point RR is then encoded as a bb-bit string (e.g., 32 octets for Ed25519 using little-endian coordinates). A challenge value hh is derived using the curve's hash on the encoded RR, encoded AA, and MM, reduced ℓ\ell. For Ed25519, hh is the integer from SHA-512(R∥A∥MR \parallel A \parallel M); for Ed448, from SHAKE256(R∥A∥MR \parallel A \parallel M, 114). The signature scalars are then combined using the private scalar ss, which is derived during by clamping the integer representation of the first half of the hash of kk (SHA-512(kk)[0:32] for Ed25519; first 57 bytes for Ed448). The second signature component SS is computed as S=(r+hs)mod  ℓS = (r + h s) \mod \ell, yielding the core equation of EdDSA signatures: S≡r+H(R∥A∥M)⋅s(modℓ).S \equiv r + H(R \parallel A \parallel M) \cdot s \pmod{\ell}. This linear combination ensures the signature's validity ties back to the without revealing ss. The output signature is the pair (R,S)(R, S), encoded as a concatenated string: the bb-bit encoding of RR followed by the little-endian bb-bit encoding of SS (e.g., 64 octets total for Ed25519). This format provides compact, fixed-length s suitable for protocols like TLS and SSH.

Signature Verification

To verify an EdDSA , the verifier requires the key AA, the MM, and the (R,S)(R, S), where RR is a point on the and SS is an integer scalar in [0,ℓ−1][0, \ell - 1]. The key AA is the curve point corresponding to the signer's private key, while the components RR and SS are provided by the signer. The verification process begins by decoding the encoded representations of RR and AA to ensure they are valid points on the curve; invalid decodings cause rejection. Next, compute the challenge hash h=H(R∥A∥M)h = H(R \parallel A \parallel M), where HH is the hash function defined in the EdDSA parameters and ∥\parallel denotes concatenation of the encoded values (using SHA-512 for Ed25519, SHAKE256(114) for Ed448). The core check then verifies the group equation SB=R+hAS B = R + h A on the curve, where BB is the fixed base point; however, to account for the curve's cofactor 2c2^c (with c≥0c \geq 0), the full equation is 2cSB=2cR+2chA2^c S B = 2^c R + 2^c h A (c=3 for Ed25519, c=2 for Ed448). Checking without the cofactor multiplication is sufficient for security but using it provides additional protection against certain attacks. This scalar multiplication and point addition are performed using the curve's group operation, and the equation holds if and only if the signature is valid. In detail, the steps are: (1) decode RR and AA from their byte encodings to curve points, rejecting if either fails; (2) compute the integer hh from the hash of the concatenated encoded RR, AA, and MM; (3) compute the point 2cSB2^c S B via of the base BB by 2cSmod  ℓ2^c S \mod \ell, and the point 2cR+2chA2^c R + 2^c h A via point addition after scaling RR and hAh A by 2c2^c; (4) check equality between these points, rejecting otherwise. If c=0c = 0, the cofactor multiplications are identities and can be omitted. For efficiency in scenarios with multiple signatures, batch verification combines several instances using random scalars ziz_i to form a single : (−∑iziSimod  [ℓ](/page/Ell))B+∑iziRi+∑i(zihimod  [ℓ](/page/Ell))Ai=O(- \sum_i z_i S_i \mod [\ell](/page/Ell)) B + \sum_i z_i R_i + \sum_i (z_i h_i \mod [\ell](/page/Ell)) A_i = \mathcal{O}, where O\mathcal{O} is the identity point and hi=H(Ri∥Ai∥Mi)h_i = H(R_i \parallel A_i \parallel M_i); this reduces the number of scalar multiplications proportionally, such as verifying 64 Ed25519 signatures with roughly the cost of two individual verifications when using appropriate random ziz_i.

Specific Curves

Ed25519

Ed25519 is a specific instance of the Edwards-curve Digital Signature Algorithm (EdDSA) defined over the known as , providing 128 bits of security with compact keys and signatures suitable for high-performance applications. It operates in the Fq\mathbb{F}_q where q=2255−19q = 2^{255} - 19, enabling efficient arithmetic on 64-bit architectures. The curve equation is given by −x2+y2=1+dx2y2-x^2 + y^2 = 1 + d x^2 y^2, with the curve constant d=−121665/121666mod  qd = -121665 / 121666 \mod q. The prime order of the base point subgroup is ℓ=2252+27742317777372353535851937790883648493\ell = 2^{252} + 27742317777372353535851937790883648493, ensuring a large for secure . Ed25519 employs the , with parameter b=256b = 256 bits, resulting in public keys of 32 bytes and signatures of 64 bytes. During , the private scalar is derived from the seed by hashing and clamping: the lowest 3 bits are cleared, the second-highest bit (bit 254) is set to 1, and the highest bit (bit 255) is cleared, which mitigates small attacks and ensures the scalar lies in the range [2254,2255−1][2^{254}, 2^{255} - 1]. Encoding uses little-endian byte order for scalars and points, with public keys storing the y-coordinate and the least significant bit of x in the most significant bit of the final octet. Ed25519 is optimized for x86-64 processors, leveraging vector instructions for fast computations, and supports batch verification of up to 64 signatures using the Bos–Coster identity, achieving verification times around 134,000 cycles per signature on contemporary hardware. A prehash variant, Ed25519ph, incorporates an arbitrary-length message prehash using SHA-512 before the signing process, allowing integration with domain-specific hashing for added flexibility in protocols.

Ed448

Ed448 is a specific instantiation of the EdDSA signature scheme using a over a 448-bit prime field, designed to provide approximately 224 bits of security. The curve operates over the Fp\mathbb{F}_p where p=2448−2224−1p = 2^{448} - 2^{224} - 1, known as the Goldilocks field for its favorable properties in arithmetic implementations. The curve equation is given by −x2+y2=1+(3908239081)x2y2(modp),-x^2 + y^2 = 1 + \left( \frac{39082}{39081} \right) x^2 y^2 \pmod{p}, with parameters a=−1a = -1 and d=39082/39081(modp)d = 39082/39081 \pmod{p}. The base point BB has coordinates (xB,yB)(x_B, y_B) where xB=224580040295924300187604334099896036246789641632564134246125461686950415467406032909029192869357953282578032075146146173674602635247710x_B = 224580040295924300187604334099896036246789641632564134246125461686950415467406032909029192869357953282578032075146146173674602635247710 and yB=29881921007848149267601793044393067343754015408024080242095928241372331506189835876003536878655418784733982303233503462500531545062832660y_B = 29881921007848149267601793044393067343754015408024080242095928241372331506189835876003536878655418784733982303233503462500531545062832660. The order of the base point is the prime ℓ=2446−13818066809895115352007386748515426880336692474882178609894547503885\ell = 2^{446} - 13818066809895115352007386748515426880336692474882178609894547503885, with the full curve order being 4×ℓ4 \times \ell and cofactor h=4h = 4. Ed448 employs SHAKE256, a extendable-output function (XOF) from the SHA-3 family, for hashing, with the parameter b=456b = 456 bits determining the scalar length. Public keys are encoded as 57-byte (456-bit) little-endian representations of the y-coordinate with the least significant bit of x appended, while signatures consist of 114 bytes (R || S, each 57 bytes). Unlike fixed-output hashes, SHAKE256 allows flexible output lengths, here producing 114 bytes for the hash input to scalar operations. Ed448 supports domain separation via optional context strings up to 255 bytes, prepended to the message hash along with a domain prefix "SigEd448". A key design choice for Ed448 is its emphasis on higher security margins compared to Ed25519, targeting threats up to 224 bits while using larger keys and signatures for future-proofing against advances in . It was specifically engineered with pre-hashing in mind (as Ed448ph), where the prehash function is SHAKE256(m, 64) for arbitrary-length messages, reducing vulnerability to multi-message attacks. Ed448's parameters were selected following SafeCurves criteria for complete addition formulas, high twist security, and efficient arithmetic, as detailed in its originating proposal. It has been standardized for use in FIPS 186-5, alongside Ed25519, for applications requiring elevated assurance levels.

Security Analysis

Proven Security

EdDSA achieves existential unforgeability under chosen-message attacks (EUF-CMA) in the model, where the HH is modeled as a . This model assumes that HH produces uniformly random outputs, enabling proofs via simulation techniques. The reduction for EdDSA follows from the of Schnorr signatures adapted to s, such that a successful implies either solving the problem (ECDLP) or finding a collision in the HH. Specifically, the proof leverages the Fiat-Shamir transform to convert the interactive Schnorr identification scheme into a non-interactive scheme, with tightly reduced to the hardness of ECDLP in the underlying group. EdDSA is secure provided the prime order ℓ\ell of the subgroup satisfies ℓ>2200\ell > 2^{200}, ensuring at least 100 bits of security against generic attacks, with typical instantiations like Ed25519 achieving approximately 128 bits. The curve design resists invalid curve attacks through explicit point validation during verification, rejecting points not on the defined . Additionally, cofactor cleavage in the verification equation—multiplying points by the cofactor 2c2^c (where c=3c=3 for Ed25519)—confines operations to the large prime-order , preventing attacks via small-order subgroups. A proof sketch employs a simulator that embeds an ECDLP instance into the public key and simulates the random oracle for HH. Upon receiving a forgery (R,S)(R, S) on a new message mm, the simulator identifies the query index for the challenge hash h=H(R,A,m)h = H(R, A, m) and rewinds the adversary to obtain a second forgery (R,S′)(R, S') with a different h′h'. This yields the relation (S−S′)(h−h′)−1≡log⁡gA(modℓ)(S - S')(h - h')^{-1} \equiv \log_g A \pmod{\ell}, solving the ECDLP. The forgery success probability is bounded by 1/ℓ+1/\ell + the probability of a hash collision in HH. Compared to ECDSA, EdDSA provides equivalent asymptotic security levels against forgery but avoids reliance on high-entropy nonces through its deterministic construction, eliminating risks from nonce reuse or poor . Unlike probabilistic schemes such as standard ECDSA, EdDSA inherently resists existential forgery under the model without additional requirements.

Side-Channel Resistance

EdDSA incorporates several design features aimed at mitigating side-channel attacks, such as timing and , which exploit physical implementations rather than mathematical weaknesses. By using deterministic nonce generation, where the nonce rr is computed as the hash of the private key seed and the message, r=H(hb,…,h2b−1,M)r = H(h_b, \dots, h_{2b-1}, M), EdDSA eliminates the need for during signing. This approach avoids biases or reuse of nonces that could leak information about the private key, a common in schemes like ECDSA where poor has led to key recoveries. To further enhance resistance to timing attacks, EdDSA employs the model, which allows for complete, unified addition laws that treat all points identically without special cases for the point at infinity or doublings. The addition formula is given by (x3,y3)=(x1y2+x2y11+dx1x2y1y2,y1y2+x1x21−dx1x2y1y2),(x_3, y_3) = \left( \frac{x_1 y_2 + x_2 y_1}{1 + d x_1 x_2 y_1 y_2}, \frac{y_1 y_2 + x_1 x_2}{1 - d x_1 x_2 y_1 y_2} \right), enabling branchless implementations that prevent data-dependent execution paths. , used in both and signing (e.g., computing R=rBR = rB and sBsB), utilizes a ladder-based method like Pippenger's radix-16 ladder, which avoids secret-dependent branches and array indices, thus resisting simple and cache-timing leaks. Private scalars undergo clamping—a fixed that clears the lowest three bits, sets the second-highest bit, and clears higher bits beyond the order—to ensure consistent behavior without revealing key bits through variable operations. Verification in EdDSA is inherently side-channel resistant as it involves no secret data; computations like checking sB=R+H(R,A,M)AsB = R + H(R, A, M)A use only public elements, avoiding secret-dependent hashes. The specification recommends constant-time decoding of points and integers to prevent leaks during input processing. However, these protections rely on careful implementation; despite the design's safeguards, flawed code can still introduce vulnerabilities, such as cache leaks from non-constant-time memory access, as demonstrated in machine learning-based power analysis attacks on specific EdDSA implementations. In contrast to ECDSA, where even partial nonce leakage via side channels can enable lattice-based key recovery, EdDSA's deterministic nature reduces such risks but does not eliminate them entirely if physical leakages occur.

Implementation Vulnerabilities

Implementations of EdDSA can introduce vulnerabilities through logical errors in code, distinct from side-channel leaks, potentially leading to signature forgery, key recovery, or of signatures. Common pitfalls arise from deviations in nonce generation, point encoding, cofactor handling during verification, adherence to standards, for keys, and point validation. These issues have been identified in analyses of popular libraries, where inconsistencies enable attacks like private key extraction or malleable signatures. Nonce determinism in EdDSA relies on hashing the private key seed and with a domain separator prefix, such as "SigEd25519" for Ed25519, to prevent reuse across contexts. Mishandling this prefix, such as omitting it or using variable contexts without proper length checks, can cause nonce collisions when the same is signed under different schemes, enabling key recovery attacks similar to those in non-deterministic signatures. For instance, if an treats Ed25519 and Ed25519ph (prehashed variant) without distinct prefixes, an adversary may forge signatures by exploiting shared nonces. Encoding errors frequently occur in point and integer representations, where EdDSA mandates little-endian byte order for scalars and coordinates. Public keys and points are encoded as the y-coordinate in little-endian followed by a for x in the most significant bit; incorrect handling, such as big-endian conversion or sign-bit misplacement, results in invalid points that fail verification or allow injection of malformed . In Ed448, variable-length contexts and longer 114-byte signatures increase risks of buffer overflows if fixed-size buffers are used without bounds checking. Cofactor mishandling during signature verification poses a significant risk, as Ed25519 has a cofactor of 8 and Ed448 has 4, requiring multiplication of points by this value to ensure they lie in the main subgroup and reject small-subgroup attacks. Omitting this multiplication in the verification equation—computing B - A == R instead of B - A == [cofactor]R—allows acceptance of invalid signatures from low-order points, potentially enabling forgeries or breaking unforgeability. Some libraries, like early versions of ed25519-dalek, implemented cofactorless verification, which simplifies code but violates security proofs unless batch verification is used exclusively. Standardization inconsistencies between RFC 8032 and FIPS 186-5 create interoperability issues, such as support for prehashed modes. RFC 8032 recommends awareness of limited support for prehashed variants in software and protocols, while FIPS 186-5 mandates test vectors for validation that some implementations ignore, leading to non-compliant signatures verifiable only in specific contexts. For example, the ed25519-java library through version 0.3.0 exhibited signature malleability due to a missing scalar range check, violating SUF-CMA security. Weak random number generation (RNG) for initial private key seeds undermines EdDSA security, as the seed is hashed to produce the clamped scalar; predictable seeds from low-entropy sources allow exhaustive search or prediction of the private key. Although deterministic nonce generation mitigates RNG failures during signing, key generation requires cryptographically secure randomness. Implementation flaws, such as unsafe APIs in libraries that allow signing with unvalidated private scalars, have led to vulnerabilities enabling private key recovery in dozens of libraries. Invalid curve attacks can succeed if point decoding is not strict, as EdDSA requires computing the x-coordinate from y during decoding and verifying it lies on the equation; skipping this check permits points from invalid curves, enabling private key recovery via adaptive chosen-ciphertext-like queries. Implementations must reject decoding failures explicitly to prevent such attacks, which have been demonstrated in broader contexts but apply directly to EdDSA's twisted Edwards curves. As of 2025, recent vulnerabilities highlight ongoing risks: for instance, gnark-crypto's EdDSA lacks constraints in zero-knowledge circuits, allowing multiple valid witnesses for the same inputs (CVE-2025-57801, GHSA-fr8m-434r-g3xp); the Jenkins EDDSA Plugin suffers from signature malleability; and includes an EdDSA flaw in its April 2025 Critical Patch Update. These underscore the importance of using audited, up-to-date libraries and thorough validation.

Performance and Implementations

Performance Metrics

EdDSA is designed for high performance, particularly in , which requires only a single by the base point without modular inversions or pairings, making it faster and simpler than alternatives like ECDSA. Optimized implementations leverage complete Edwards addition formulas that avoid costly inversions during verification, further enhancing efficiency. The Ed25519 variant exemplifies this efficiency on processors, where the donna library achieves signing in approximately 64,000 clock cycles and verification in 217,000 clock cycles, compared to baseline reference implementations requiring 140,000 and 455,000 cycles, respectively. These metrics represent a of about 2.2x for signing and 2.1x for verification over the reference, and Ed25519 generally outperforms ECDSA-256 in signing (up to 2x faster in optimized cases due to deterministic nonce generation avoiding randomness overhead) while verification benefits from the absence of modular inverses, yielding up to 4x improvement in some batch scenarios relative to ECDSA's inverse-heavy process. On older Westmere CPUs, single Ed25519 verification takes 273,000 cycles, contrasting with ECDSA P-256's 312,000 cycles. Ed448, targeting 224-bit , is slower than Ed25519 due to its larger 448-bit prime field, with scalar multiplications typically 2-3x more expensive, though it remains efficient for high-security applications and benefits from SHAKE256 as an extendable-output function (XOF) for handling variable-length messages without truncation issues. On embedded Cortex-M4 processors, Ed448 signing requires about 6 million clock cycles and verification 7.4 million, reflecting the field size impact. Batch verification in EdDSA significantly boosts throughput, saving 50-70% of the time for multiple signatures by combining scalar multiplications; for example, verifying 64 signatures takes roughly 8.55 million cycles total (about 134,000 per signature), halving the per-signature cost compared to individual verifications. Hardware acceleration via AVX2 instructions enables parallel field arithmetic, yielding up to 4x throughput for multi-signature verification on processors. Overall, EdDSA variants excel in embedded and constrained environments, with verification far outperforming RSA-2048 (which requires millions of cycles for 2048-bit ) in scenarios demanding frequent checks.

Software Support

EdDSA has been integrated into several prominent cryptographic libraries, providing developers with robust tools for implementation across various programming languages and environments. The library added support for EdDSA, including Ed25519 and Ed448, starting with version 1.1.1 released in 2018, enabling key generation, signing, and verification through its EVP interface. Libsodium, a modern and portable library derived from NaCl, serves as a primary implementation for Ed25519, offering high-speed signing and verification functions with bindings for numerous languages such as , Python, and . Bouncy Castle, a widely used Java API, includes EdDSA support since version 1.60 in 2019, facilitating integration in enterprise applications with features for both Ed25519 and Ed448 curves. Similarly, the NaCl (Networking and ) library provides Ed25519 as its core signature primitive through the crypto_sign API, emphasizing simplicity and constant-time operations in . In operating systems and security tools, EdDSA enjoys broad adoption for authentication and integrity verification. OpenSSH has used Ed25519 as the default key type since version 6.5 in 2014, enhancing SSH protocol security with faster key generation and smaller key sizes compared to legacy options. GnuPG, starting from version 2.1 in 2014, supports EdDSA for OpenPGP signatures, allowing users to create and verify keys with Ed25519 for email and file signing. The Tor network employs Ed25519 for onion service authentication and directory consensus, improving resistance to certain attacks since its integration in 2014. The Signal Protocol utilizes Ed25519 for end-to-end encryption key agreements in messaging applications, ensuring secure identity keys across devices. Additionally, OpenBSD's signify tool, introduced in 2014, relies on Ed25519 for signing and verifying software releases, promoting a minimalist approach to package integrity. Hardware accelerations enhance EdDSA performance on modern processors. Intel's PCLMULQDQ instruction, available since the architecture in 2011, enables carry-less for efficient field arithmetic in Ed25519 implementations, achieving up to 2x speedups in compared to software-only methods. ARMv8-A extensions, including the PMULL instruction for , support optimized Ed25519 computations on mobile and embedded devices, as demonstrated in constant-time implementations on Cortex-A series processors. The reference implementation of EdDSA consists of public-domain C code released by and collaborators in 2011, providing a portable baseline for Ed25519 with routines. Test vectors for validation are specified in RFC 8032, published in January 2017 by the IETF, ensuring interoperability across implementations through predefined signing and verification examples. Cross-platform support extends to web environments via the Web Crypto API, which includes Ed25519 for signing and verification in major browsers: Chrome since version 137 (mid-2025), since version 129 (2024), and since version 17 (2023), allowing secure JavaScript-based cryptography without plugins.

Secure Coding Practices

Implementations of EdDSA must employ constant-time arithmetic operations to mitigate timing side-channel attacks, where variations in execution time could leak information about secret keys. This is achieved by using ladder-based algorithms, such as the Montgomery ladder or Pippenger's , which avoid conditional branches and secret-dependent memory accesses. For instance, in Ed25519, the for computing A during verification should execute the same sequence of instructions regardless of the key value, incorporating branch-free conditional assignments. Similarly, avoiding secret array indices and ensuring uniform addition formulas for points further enhances resistance to cache-timing and branch-prediction attacks. Strict input validation is essential to prevent malleability attacks and ensure points lie on the correct subgroup. During decoding, keys and components (R and S) must be parsed as little-endian octet strings, with the y-coordinate checked to be less than the field prime , and the x-coordinate recovered using the specified while validating the . For Ed25519, the 32-octet key A is decoded by extracting y from the least significant 255 bits and computing x such that x^2 = (y^2 - 1) / (d y^2 + 1) mod , rejecting if not or if the point has small order (one of eight known low-order ). The scalar S must also be verified to lie in [0, l-1], where l is the order, to maintain strong unforgeability under chosen-message attacks (SUF-CMA). Failure to check cofactor bounds or small-order points can lead to invalid signatures being accepted, compromising . Private key generation requires cryptographically secure to the key derivation process. For Ed25519, the private key consists of 32 octets of high-entropy random data obtained from an approved random number generator, which is then hashed with SHA-512 and clamped by setting specific bits (clearing the lowest three bits, setting the second-highest bit, and clearing the highest bit) to ensure the scalar is in the correct range. Ed448 uses 57 octets of secure random data, hashed with SHAKE256(m=114) under the dom4 prefix, followed by similar clamping. EdDSA's deterministic nonce derivation from the private key eliminates the need for per-signature randomness, reducing exposure to faulty RNGs compared to schemes like ECDSA. Implementers should use system-approved RNGs, such as those compliant with , to generate this initial . Proper hash handling prevents cross-protocol attacks and ensures domain separation. In Ed25519, the message hash during signing and verification is computed as SHA-512(R || A || M), but for context-aware variants (Ed25519ctx), the hash function incorporates a prefix like the octet string "SigEd25519" (ASCII-encoded), followed by a single octet flag (0x00 for no prehash) and the string, which should be a protocol-specified constant to avoid malleability. Ed448 employs SHAKE256 with a dom4 prefix ("SigEd448" + flags + ) for both key derivation and signing. Support for prehashing (Ed25519ph or Ed448ph) is recommended for long messages, where the message is first hashed separately before , allowing efficient verification without rehashing large inputs. Non-canonical point encodings must be rejected during hash input preparation to maintain consistency. Auditing EdDSA implementations should leverage standardized test vectors to verify correctness and security properties. RFC 8032 provides comprehensive test vectors for Ed25519, Ed25519ctx, Ed25519ph, Ed448, and Ed448ph, including seed keys, messages, public keys, and corresponding signatures, which must be used to confirm that signing, verification, and decoding behave as specified under both normal and edge cases. Implementers are advised to avoid custom curves or parameters outside the standardized Ed25519 and Ed448, as deviations can introduce vulnerabilities like cofactor multiplication inconsistencies or weakened security levels. Additional verification can include checking against known small-order points and ensuring rejection of malformed inputs as per the specification. To detect implementation flaws, developers should employ tools like for identifying memory leaks and buffer overflows in C-based EdDSA code, running it under memory-checking modes during signing and verification operations. tools, such as those generating random inputs for keys, messages, and signatures, are crucial for uncovering edge cases like invalid decodings or hash collisions, with coverage guided by the RFC test vectors to ensure robustness against malformed data. These practices help confirm constant-time behavior and input handling without relying on protocol-specific libraries.

Standardization and Adoption

Standards Development

The Edwards-curve Digital Signature Algorithm (EdDSA) was initially specified in a 2011 academic paper by and colleagues, which introduced the Ed25519 instantiation and outlined the generalized EdDSA framework for high-speed, secure signatures on Edwards curves. Formal standardization began with IETF RFC 8032, published in January 2017 by the (IRTF), which defines the complete EdDSA algorithm, including instantiations for Ed25519 (using ) and Ed448 (using ), along with detailed specifications for , signing, verification, encodings, and test vectors to ensure . Subsequent errata to RFC 8032, reported starting in 2017, addressed technical inconsistencies such as clarifications on cofactor handling and verification equations, with several held for potential document updates. On February 3, 2023, the National Institute of Standards and Technology (NIST) approved Ed25519 and Ed448 for federal use in FIPS 186-5, the Standard, incorporating EdDSA as a deterministic signature scheme while referencing RFC 8032 for core specifications and adding FIPS-specific requirements like key validation and security levels. FIPS 186-5 also specifies the HashEdDSA variant, which supports optional prehashing of messages using SHA-512 for Ed25519ph or SHAKE256 for Ed448ph, differing from the standard EdDSA in RFC 8032 by allowing a single hash of the message digest rather than hashing during the signing process. Looking ahead, while EdDSA remains approved under current standards, NIST's migration guidance in NIST IR 8547 identifies it as quantum-vulnerable and plans deprecation of signatures like EdDSA by 2030, with potential roles in hybrid schemes combining classical and post-quantum algorithms.

Applications in Protocols

EdDSA, particularly its Ed25519 variant, has been integrated into the (SSH) protocol as a preferred option for host and user authentication keys. OpenSSH introduced support for Ed25519 keys in version 6.5, released in January 2014, enabling their use for public key authentication in place of traditional RSA or ECDSA keys. This adoption has made Ed25519 the recommended key type for new SSH deployments due to its compact size and deterministic signing properties. In the (TLS) protocol, EdDSA is supported for digital signatures in certificates and , as specified in RFC 8422 for TLS 1.2 and extended to TLS 1.3. Major providers such as and have implemented Ed25519 signatures in their TLS stacks, allowing clients to authenticate servers using EdDSA during secure web connections. Beyond SSH and TLS, EdDSA finds application in other security protocols. For DNSSEC, RFC 8080 defines the use of EdDSA with Ed25519 and Ed448 curves for signing DNS resource records, including DS, DNSKEY, and RRSIG types, to enhance domain name integrity without relying on larger RSA signatures. Experimental implementations have explored EdDSA as an alternative to ECDSA for transactions, demonstrating its feasibility in signing while maintaining compatibility with existing script structures. In , a modern VPN protocol, Curve25519 keys—interoperable with Ed25519—are used for peer , and Ed25519 is employed for signing software updates to verify integrity. Emerging applications leverage EdDSA's structure for post-quantum migrations, where its hash-based key derivation facilitates hybrid schemes combining EdDSA with hash-based signatures like those in SLH-DSA to resist quantum attacks. In ecosystems, Solana employs Ed25519 for account addressing and transaction signing, utilizing its fixed 256-bit keys to support high-throughput operations. Adoption of EdDSA has grown significantly across operating systems following its inclusion in NIST FIPS 186-5, approved in February 2023, which standardized Ed25519 and Ed448 as approved digital signature algorithms. It is widely supported in distributions through implementations for key generation and . Apple's and macOS platforms integrate Ed25519 via the CryptoKit framework, enabling its use in keychains for secure signing and verification in applications like SSH and app updates. This FIPS approval has accelerated enterprise and government uptake, with EdDSA now commonplace in secure boot processes and certificate authorities. Despite its advantages, EdDSA deployment faces challenges in legacy systems, where fixed key sizes like 256 bits for Ed25519 may exceed protocol-imposed limits or lack native support, necessitating fallbacks to RSA or upgrades. For instance, older SSH servers prior to 6.5 reject Ed25519 keys, complicating migrations in heterogeneous environments.

References

  1. https://datatracker.ietf.org/doc/html/rfc8032
  2. https://ed25519.cr.yp.to/ed25519-20110926.pdf
  3. https://eprint.iacr.org/2015/625
  4. https://openjdk.org/jeps/339
  5. https://eprint.iacr.org/2011/368
  6. https://www.rfc-editor.org/rfc/rfc8032.html
  7. https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf
  8. https://safecurves.cr.yp.to/
  9. https://www.ams.org/journals/bull/2007-44-03/S0273-0979-07-01153-6/S0273-0979-07-01153-6.pdf
  10. https://eprint.iacr.org/2008/522.pdf
  11. https://www.hyperelliptic.org/EFD/g1p/auto-twisted-projective.html
  12. https://eprint.iacr.org/2008/013.pdf
  13. https://ed25519.cr.yp.to/eddsa-20150704.pdf
  14. https://www.ietf.org/rfc/rfc7748.html
  15. http://ed25519.cr.yp.to/ed25519-20110926.pdf
  16. https://datatracker.ietf.org/doc/html/rfc8032#section-5.1
  17. https://datatracker.ietf.org/doc/html/rfc8032#section-5.1.5
  18. https://datatracker.ietf.org/doc/html/rfc8032#section-5.1.1
  19. https://datatracker.ietf.org/doc/html/rfc8032#section-5.1.2
  20. https://datatracker.ietf.org/doc/html/rfc8032#section-5.1.6
  21. https://datatracker.ietf.org/doc/html/rfc8032#section-1
  22. https://datatracker.ietf.org/doc/html/rfc8032#section-5.1.3
  23. https://eprint.iacr.org/2020/823.pdf
  24. https://www.cryptrec.go.jp/exreport/cryptrec-ex-3003-2020.pdf
  25. https://eprint.iacr.org/2019/358.pdf
  26. https://eprint.iacr.org/2020/1244
  27. https://crypto.stackexchange.com/questions/88961/rationale-for-verification-with-cofactor-2c-in-eddsa
  28. https://www.wiz.io/vulnerability-database/cve/cve-2020-36843
  29. https://portswigger.net/daily-swig/dozens-of-cryptography-libraries-vulnerable-to-private-key-theft
  30. https://crypto.stackexchange.com/questions/88636/what-can-we-recover-with-an-invalid-curve-attack
  31. https://nvd.nist.gov/vuln/detail/CVE-2025-57801
  32. https://www.jenkins.io/security/advisory/2025-03-19/
  33. https://www.oracle.com/security-alerts/cpuapr2025.html
  34. https://eprint.iacr.org/2021/471.pdf
  35. https://crypto.stackexchange.com/questions/60257/how-fast-a-middle-class-computer-can-verify-assymetric-signatures-like-ecdsa-r
  36. https://soatok.blog/2022/05/19/guidance-for-choosing-an-elliptic-curve-signature-algorithm-in-2022/
  37. https://eprint.iacr.org/2023/168.pdf
  38. https://eprint.iacr.org/2025/1658
  39. https://docs.openssl.org/1.1.1/man7/Ed25519/
  40. https://github.com/bcgit/bc-java/issues/636
  41. https://nacl.cr.yp.to/sign.html
  42. https://ianix.com/pub/ed25519-deployment.html
  43. https://www.openbsd.org/papers/bsdcan-signify.html
  44. https://ed25519.cr.yp.to/
  45. https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto#browser_compatibility
  46. https://eprint.iacr.org/2020/1244.pdf
  47. https://www.rfc-editor.org/errata/rfc8032
  48. https://doi.org/10.6028/NIST.FIPS.186-5
  49. https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf
  50. https://www.openssh.com/txt/release-6.5
  51. https://www.rfc-editor.org/rfc/rfc8422.html
  52. https://datatracker.ietf.org/doc/rfc8080/
  53. https://ieeexplore.ieee.org/document/10956318/
  54. https://crypto.stackexchange.com/questions/111201/can-you-sign-messages-using-wireguards-keys
  55. https://eprint.iacr.org/2025/1368.pdf
  56. https://solana.com/docs/core/accounts
  57. https://csrc.nist.gov/pubs/fips/186-5/ipd
  58. https://developer.apple.com/documentation/cryptokit/curve25519/signing/privatekey/signature(for:)
  59. https://linuxconfig.org/migrate-ssh-keys-from-rsa-to-ed25519
  60. https://www.geeksforgeeks.org/devops/rsa-vs-ed25519-which-key-pair-is-right-for-your-security-needs/
Add your contribution
Related Hubs
User Avatar
No comments yet.