]>
Edwards-Curve Digital Signature Algorithm (EdDSA)
SJD ABsimon@josefsson.orghttp://josefsson.org/Independentilariliusvaara@welho.comCrypto ForumThis document describes elliptic curve signature scheme Edwards-curve Digital
Signature Algorithm (EdDSA). The algorithm is
instantiated with recommended parameters for the edwards25519 and
edwards448 curves. An example implementation and test vectors are
provided.The Edwards-curve Digital Signature Algorithm (EdDSA) is a
variant of Schnorr's signature system with (possibly twisted)
Edwards curves. EdDSA needs to be instantiated with certain
parameters, and this document describes some recommended variants.To facilitate adoption of EdDSA in the Internet community,
this document describes the signature scheme in an
implementation-oriented way and provides sample code and test
vectors.The advantages with EdDSA are as follows:
EdDSA provides high performance on a variety of platforms;The use of a unique random number for each
signature is not required;It is more resilient to side-channel attacks;EdDSA uses small public keys (32 or 57 bytes) and signatures (64 or 114
bytes) for Ed25519 and Ed448, respectively;The formulas are "complete", i.e., they are valid
for all points on the curve, with no exceptions. This
obviates the need for EdDSA to perform expensive point
validation on untrusted public values; andEdDSA provides collision resilience, meaning that hash-function collisions
do not break this system (only holds for PureEdDSA).The original EdDSA paper and the
generalized version described in "EdDSA
for more curves" provide further background. RFC 7748 discusses specific
curves, including Curve25519
and Ed448-Goldilocks.
Ed25519 is intended to operate at around the 128-bit security
level and Ed448 at around the 224-bit security level. A
sufficiently large quantum computer would be able to break both.
Reasonable projections of the abilities of classical computers
conclude that Ed25519 is perfectly safe. Ed448 is provided
for those applications with relaxed performance requirements
and where there is a desire to hedge against analytical
attacks on elliptic curves.
The following notation is used throughout the document:Denotes the prime number defining the underlying fieldFinite field with p elementsx multiplied by itself y timesGenerator of the group or subgroup of interestX added to itself n timesThe i'th octet of octet stringThe i'th bit of h(bit-)string a concatenated with (bit-)string ba is less than or equal to ba is greater than or equal to bSum of i and jMultiplication of i and jSubtraction of j from iDivision of i by jCartesian product of i and jElliptic curve point with x-coordinate u and y-coordinate v The y first octets of
SHAKE256 output for input xThe octet with value xThe number of octets in string xThe blank octet string when signing or
verifying Ed25519. Otherwise, the octet string:
"SigEd25519 no Ed25519 collisions" || octet(x) || octet(OLEN(y)) || y,
where x is in range 0-255 and y is an octet string of at most 255
octets. "SigEd25519 no Ed25519 collisions" is in ASCII (32 octets).
The octet string "SigEd448" || octet(x) || octet(OLEN(y)) || y,
where x is in range 0-255 and y is an octet string of at most 255
octets. "SigEd448" is in ASCII (8 octets).Parentheses (i.e., '(' and ')') are used to group
expressions, in order to avoid having the description depend on
a binding order between operators. Bit strings are converted to octet strings by taking bits
from left to right, packing those from the least significant
bit of each octet to the most significant bit, and moving to the next
octet when each octet fills up. The conversion from octet string
to bit string is the reverse of this process; for example, the 16-bit bit
stringis converted into two octets x0 and x1 (in this order) asLittle-endian encoding into bits places bits from left to right and
from least significant to most significant. If combined with bit&nbhy;string&nbhy;to&nbhy;octet&nbhy;string
conversion defined above, this results in
little-endian encoding into octets (if length is not a multiple of
8, the most significant bits of the last octet remain unused).EdDSA is a digital signature system with 11
parameters.The generic EdDSA digital signature system with its 11
input parameters is not intended to be implemented directly.
Choosing parameters is critical for secure and efficient
operation. Instead, you would implement a particular parameter
choice for EdDSA (such as Ed25519 or Ed448), sometimes slightly
generalized to achieve code reuse to cover Ed25519 and
Ed448.Therefore, a precise explanation of the generic EdDSA is thus
not particularly useful for implementers. For background and
completeness, a succinct description of the generic EdDSA
algorithm is given here.The definition of some parameters, such as n and c, may help
to explain some steps of the algorithm that are not intuitive.This description closely follows .EdDSA has 11 parameters:
An odd prime power p. EdDSA uses an elliptic curve over the
finite field GF(p).An integer b with 2^(b−1) > p. EdDSA public keys have
exactly b bits, and EdDSA signatures have exactly 2*b bits. b
is recommended to be a multiple of 8, so public key and
signature lengths are an integral number of octets.A (b-1)-bit encoding of elements of the finite field GF(p).A cryptographic hash function H producing 2*b-bit output.
Conservative hash functions (i.e., hash functions where it is
infeasible to create collisions) are recommended and do not have
much impact on the total cost of EdDSA.An integer c that is 2 or 3. Secret EdDSA scalars are
multiples of 2^c. The integer c is the base-2 logarithm of
the so-called cofactor.An integer n with c <= n < b. Secret EdDSA scalars
have exactly n + 1 bits, with the top bit (the 2^n position)
always set and the bottom c bits always cleared.A non-square element d of GF(p). The usual recommendation
is to take it as the value nearest to zero that gives an
acceptable curve.A non-zero square element a of GF(p). The usual
recommendation for best performance is a = -1 if p mod 4 = 1,
and a = 1 if p mod 4 = 3.An element B != (0,1) of the set E = { (x,y) is a member of
GF(p) x GF(p) such that a * x^2 + y^2 = 1 + d * x^2 * y^2
}.An odd prime L such that [L]B = 0 and 2^c * L = #E. The
number #E (the number of points on the curve) is part of the
standard data provided for an elliptic curve E, or it can be
computed as cofactor * order.A "prehash" function PH. PureEdDSA means EdDSA where PH is
the identity function, i.e., PH(M) = M. HashEdDSA means EdDSA
where PH generates a short output, no matter how long the
message is; for example, PH(M) = SHA-512(M).Points on the curve form a group under addition, (x3, y3) =
(x1, y1) + (x2, y2), with the formulasThe neutral element in the group is (0,1).Unlike many other curves used for cryptographic applications,
these formulas are "complete"; they are valid for all
points on the curve, with no exceptions. In particular, the
denominators are non-zero for all input points.There are more efficient formulas, which are still complete,
that use homogeneous coordinates to avoid the
expensive modulo p inversions. See
and .An integer 0 < S < L - 1 is encoded in little-endian
form as a b-bit string ENC(S).An element (x,y) of E is encoded as a b-bit string called
ENC(x,y), which is the (b-1)-bit encoding of y concatenated
with one bit that is 1 if x is negative and 0 if x is not
negative.The encoding of GF(p) is used to define "negative" elements
of GF(p): specifically, x is negative if the (b-1)-bit
encoding of x is lexicographically larger than the (b-1)-bit
encoding of -x.An EdDSA private key is a b-bit string k. Let the hash H(k)
= (h_0, h_1, ..., h_(2b-1)) determine an integer s, which is
2^n plus the sum of m = 2^i * h_i for all integer i, c <= i
< n. Let s determine the multiple A = [s]B. The EdDSA
public key is ENC(A). The bits h_b, ..., h_(2b-1) are used
below during signing.The EdDSA signature of a message M under a private key k is
defined as the PureEdDSA signature of PH(M). In other words,
EdDSA simply uses PureEdDSA to sign PH(M).The PureEdDSA signature of a message M under a private key k
is the 2*b-bit string ENC(R) || ENC(S). R and S are derived
as follows. First define r = H(h_b || ... || h_(2b-1) || M)
interpreting 2*b-bit strings in little-endian form as integers
in {0, 1, ..., 2^(2*b) - 1}. Let R = [r]B and S = (r +
H(ENC(R) || ENC(A) || PH(M)) * s) mod L.
The s used here is from the previous section.To verify a PureEdDSA signature ENC(R) || ENC(S) on a
message M under a public key ENC(A), proceed as follows.
Parse the inputs so that A and R are elements of E, and S is
a member of the set {0, 1, ..., L-1 }. Compute h = H(ENC(R)
|| ENC(A) || M), and check the group equation [2^c * S] B = 2^c
* R + [2^c * h] A in E. The signature is rejected if parsing
fails (including S being out of range) or if the group equation
does not hold.EdDSA verification for a message M is defined as PureEdDSA
verification for PH(M).One of the parameters of the EdDSA algorithm is the "prehash"
function. This may be the identity function, resulting in an
algorithm called PureEdDSA, or a collision-resistant hash
function such as SHA-512, resulting in an algorithm called
HashEdDSA.Choosing which variant to use depends on which property is
deemed to be more important between 1) collision resilience and
2) a single-pass interface for creating signatures. The
collision resilience property means EdDSA is secure even if it
is feasible to compute collisions for the hash function. The
single-pass interface property means that only one pass over the
input message is required to create a signature. PureEdDSA
requires two passes over the input. Many existing APIs,
protocols, and environments assume digital signature algorithms
only need one pass over the input and may have API or bandwidth
concerns supporting anything else.Note that single-pass verification is not possible with most
uses of signatures, no matter which signature algorithm is
chosen. This is because most of the time, one can't process the
message until the signature is validated, which needs a pass on the
entire message.This document specifies parameters resulting in the HashEdDSA
variants Ed25519ph and Ed448ph and the PureEdDSA variants
Ed25519 and Ed448.This section instantiates the general EdDSA algorithm for the
edwards25519 and edwards448 curves, each for the PureEdDSA and
HashEdDSA variants (plus a contextualized extension of the Ed25519
scheme). Thus, five different parameter sets are described.Ed25519 is EdDSA instantiated with:ParameterValuepp of edwards25519 in (i.e., 2^255 - 19)b256encoding of GF(p)255-bit little-endian encoding of {0, 1, ..., p-1}H(x)SHA-512(dom2(phflag,context)||x)cbase 2 logarithm of cofactor of edwards25519 in (i.e., 3)n254dd of edwards25519 in (i.e., -121665/121666 =
37095705934669439343138083508754565189542113879843219016388785533085940283555)a-1B(X(P),Y(P)) of edwards25519 in (i.e.,
(15112221349535400772501151409588531511454012693041857206046113283949847762202,
46316835694926478169428394003475163141307993866256225615783033603165251855960))Lorder of edwards25519 in (i.e.,
2^252+27742317777372353535851937790883648493).PH(x)x (i.e., the identity function)For Ed25519, dom2(f,c) is the empty string. The phflag value is
irrelevant. The context (if present at all) MUST be empty. This
causes the scheme to be one and the same with the Ed25519 scheme
published earlier.For Ed25519ctx, phflag=0. The context input SHOULD NOT be empty.For Ed25519ph, phflag=1 and PH is SHA512 instead.
That is, the input is hashed using SHA-512 before signing with
Ed25519.Value of context is set by the signer and verifier (maximum of
255 octets; the default is empty string, except for Ed25519, which
can't have context) and has to match octet by octet for
verification to be successful.The curve used is equivalent to
Curve25519, under a change of coordinates, which means
that the difficulty of the discrete logarithm problem is the
same as for Curve25519.For advice on how to implement arithmetic modulo p =
2^255 - 19 efficiently and securely, see Curve25519. For inversion modulo
p, it is recommended to use the identity x^-1 = x^(p-2) (mod
p). Inverting zero should never happen, as it would
require invalid input, which would have been detected before,
or would be a calculation error.For point decoding or "decompression", square roots
modulo p are needed. They can be computed using the
Tonelli-Shanks algorithm or the special case for p = 5 (mod
8). To find a square root of a, first compute the candidate
root x = a^((p+3)/8) (mod p). Then there are three cases:
x^2 = a (mod p). Then x is a square root. x^2 = -a (mod p). Then 2^((p-1)/4) * x is a square root. a is not a square modulo p.All values are coded as octet strings, and integers are
coded using little-endian convention, i.e., a 32-octet
string h h[0],...h[31] represents the integer h[0] + 2^8
* h[1] + ... + 2^248 * h[31].A curve point (x,y), with coordinates in the range 0
<= x,y < p, is coded as follows. First, encode the
y-coordinate as a little-endian string of 32 octets. The
most significant bit of the final octet is always zero. To
form the encoding of the point, copy the least significant
bit of the x-coordinate to the most significant bit of the
final octet.Decoding a point, given as a 32-octet string, is a little
more complicated.
First, interpret the string as an integer in
little-endian representation. Bit 255 of this number is
the least significant bit of the x-coordinate and denote
this value x_0. The y-coordinate is recovered simply by
clearing this bit. If the resulting value is >= p,
decoding fails.To recover the x-coordinate, the curve equation implies
x^2 = (y^2 - 1) / (d y^2 + 1) (mod p). The denominator is
always non-zero mod p. Let u = y^2 - 1 and v = d y^2 + 1. To
compute the square root of (u/v), the first step is to
compute the candidate root x = (u/v)^((p+3)/8). This can
be done with the following trick, using a single modular
powering for both the inversion of v and the square root:
Again, there are three cases:
If v x^2 = u (mod p), x is a square root.If v x^2 = -u (mod p), set x <-- x * 2^((p-1)/4),
which is a square root.Otherwise, no square root exists for modulo p, and decoding
fails.Finally, use the x_0 bit to select the right square root.
If x = 0, and x_0 = 1, decoding fails. Otherwise, if x_0 !=
x mod 2, set x <-- p - x. Return the decoded point
(x,y).For point addition, the following method is recommended.
A point (x,y) is represented in extended homogeneous
coordinates (X, Y, Z, T), with x = X/Z, y = Y/Z, x * y = T/Z.
The neutral point is (0,1), or equivalently in extended
homogeneous coordinates (0, Z, Z, 0) for any non-zero Z.The following formulas for adding two points, (x3,y3) =
(x1,y1)+(x2,y2), on twisted Edwards curves with a=-1, square a,
and non-square d are described in Section 3.1 of and in .
They are complete, i.e., they work for any pair of valid input points.
For point doubling, (x3,y3) = (x1,y1)+(x1,y1), one could just
substitute equal points in the above (because of completeness, such
substitution is valid) and observe that four multiplications
turn into squares. However, using the formulas described
in Section 3.2 of and in
saves a few smaller operations.
The private key is 32 octets (256 bits, corresponding to b) of
cryptographically secure random data. See for a discussion about randomness.The 32-byte public key is generated by the following steps.
Hash the 32-byte private key using SHA-512, storing the digest
in a 64-octet large buffer, denoted h. Only the lower 32
bytes are used for generating the public key.Prune the buffer: The lowest three bits of the first octet are
cleared, the highest bit of the last octet is cleared, and the
second highest bit of the last octet is set.Interpret the buffer as the little-endian integer,
forming a secret scalar s. Perform a fixed-base scalar
multiplication [s]B.The public key A is the encoding of the point [s]B. First,
encode the y-coordinate (in the range 0 <= y < p) as a
little-endian string of 32 octets. The most significant bit
of the final octet is always zero. To form the encoding of
the point [s]B, copy the least significant bit of the x
coordinate to the most significant bit of the final octet.
The result is the public key.The inputs to the signing procedure is the private key, a
32-octet string, and a message M of arbitrary size. For
Ed25519ctx and Ed25519ph, there is additionally a context C
of at most 255 octets and a flag F, 0 for Ed25519ctx and 1
for Ed25519ph.
Hash the private key, 32 octets, using SHA-512. Let h
denote the resulting digest. Construct the secret scalar s
from the first half of the digest, and the corresponding
public key A, as described in the previous section. Let
prefix denote the second half of the hash digest,
h[32],...,h[63].Compute SHA-512(dom2(F, C) || prefix || PH(M)), where M is
the message to be signed. Interpret the 64-octet digest as a
little-endian integer r.Compute the point [r]B. For efficiency, do this by first
reducing r modulo L, the group order of B. Let the string R
be the encoding of this point.Compute SHA512(dom2(F, C) || R || A || PH(M)), and interpret
the 64-octet digest as a little-endian integer k.Compute S = (r + k * s) mod L. For efficiency, again
reduce k modulo L first.Form the signature of the concatenation of R (32 octets)
and the little-endian encoding of S (32 octets; the three most
significant bits of the final octet are always zero).To verify a signature on a message M using public key A,
with F being 0 for Ed25519ctx, 1 for Ed25519ph, and if
Ed25519ctx or Ed25519ph is being used, C being the context,
first split the
signature into two 32-octet halves. Decode the first half as
a point R, and the second half as an integer S, in the range
0 <= s < L. Decode the public key A as point A'. If any of
the decodings fail (including S being out of range), the
signature is invalid.Compute SHA512(dom2(F, C) || R || A || PH(M)), and interpret
the 64-octet digest as a little-endian integer k.Check the group equation [8][S]B = [8]R + [8][k]A'. It's
sufficient, but not required, to instead check
[S]B = R + [k]A'.Ed448 is EdDSA instantiated with:ParameterValuepp of edwards448 in (i.e., 2^448 - 2^224 - 1)b456encoding of GF(p)455-bit little-endian encoding of {0, 1, ..., p-1}H(x)SHAKE256(dom4(phflag,context)||x, 114)phflag0cbase 2 logarithm of cofactor of edwards448 in (i.e., 2)n447dd of edwards448 in (i.e., -39081)a1B(X(P),Y(P)) of edwards448 in (i.e.,
(224580040295924300187604334099896036246789641632564134246125461686950415467406032909029192869357953282578032075146446173674602635247710,
298819210078481492676017930443930673437544040154080242095928241372331506189835876003536878655418784733982303233503462500531545062832660))Lorder of edwards448 in (i.e.,
2^446 - 13818066809895115352007386748515426880336692474882178609894547503885).PH(x)x (i.e., the identity function)Ed448ph is the same but with PH being SHAKE256(x, 64)
and phflag being 1, i.e., the input is hashed before signing
with Ed448 with a hash constant modified.Value of context is set by signer and verifier (maximum of
255 octets; the default is empty string) and has to match octet
by octet for verification to be successful.The curve is equivalent to Ed448-Goldilocks under change of
the basepoint, which preserves difficulty of the discrete logarithm.
For advice on how to implement arithmetic modulo p =
2^448 - 2^224 - 1 efficiently and securely, see
. For inversion modulo p, it is
recommended to use the identity x^-1 = x^(p-2) (mod p).
Inverting zero should never happen, as it would
require invalid input, which would have been detected before,
or would be a calculation error.For point decoding or "decompression", square roots
modulo p are needed. They can be computed by first computing
candidate root x = a ^ (p+1)/4 (mod p) and then checking if
x^2 = a. If it is, then x is the square root of a; if it isn't,
then a does not have a square root.
All values are coded as octet strings, and integers are
coded using little-endian convention, i.e., a 57-octet
string h h[0],...h[56] represents the integer h[0] + 2^8
* h[1] + ... + 2^448 * h[56].A curve point (x,y), with coordinates in the range 0
<= x,y < p, is coded as follows. First, encode the
y-coordinate as a little-endian string of 57 octets. The
final octet is always zero. To form the encoding of the
point, copy the least significant bit of the x-coordinate
to the most significant bit of the final octet.Decoding a point, given as a 57-octet string, is a little
more complicated.
First, interpret the string as an integer in
little-endian representation. Bit 455 of this number is
the least significant bit of the x-coordinate, and denote
this value x_0. The y-coordinate is recovered simply by
clearing this bit. If the resulting value is >= p,
decoding fails.To recover the x-coordinate, the curve equation implies
x^2 = (y^2 - 1) / (d y^2 - 1) (mod p). The denominator is
always non-zero mod p. Let u = y^2 - 1 and v = d
y^2 - 1. To compute the square root of (u/v), the first
step is to compute the candidate root x =
(u/v)^((p+1)/4). This can be done using the following
trick, to use a single modular powering for both the
inversion of v and the square root:
If v * x^2 = u, the recovered x-coordinate is x.
Otherwise, no square root exists, and the decoding
fails.Finally, use the x_0 bit to select the right square root.
If x = 0, and x_0 = 1, decoding fails. Otherwise, if x_0 !=
x mod 2, set x <-- p - x. Return the decoded point
(x,y).For point addition, the following method is recommended.
A point (x,y) is represented in projective coordinates
(X, Y, Z), with x = X/Z, y = Y/Z.
The neutral point is (0,1), or equivalently in projective
coordinates (0, Z, Z) for any non-zero Z.The following formulas for adding two points, (x3,y3) =
(x1,y1)+(x2,y2) on untwisted Edwards curve (i.e., a=1) with
non-square d, are described in Section 4 of
and in .
They are complete, i.e., they work for any pair of
valid input points.
Again, similar to the other curve, doubling formulas
can be obtained by substituting equal points, turning four
multiplications into squares. However, this is not even nearly
optimal; the following formulas described in Section 4 of
and in save multiple multiplications.
The private key is 57 octets (456 bits, corresponding to b) of
cryptographically secure random data. See for a discussion about randomness.The 57-byte public key is generated by the following steps:
Hash the 57-byte private key using SHAKE256(x, 114), storing the
digest in a 114-octet large buffer, denoted h. Only the lower 57
bytes are used for generating the public key.Prune the buffer: The two least significant bits of the
first octet are cleared, all eight bits the last octet are cleared,
and the highest bit of the second to last octet is set.Interpret the buffer as the little-endian integer,
forming a secret scalar s. Perform a known-base-point scalar
multiplication [s]B.The public key A is the encoding of the point [s]B. First
encode the y-coordinate (in the range 0 <= y < p) as a
little-endian string of 57 octets. The most significant bit
of the final octet is always zero. To form the encoding of
the point [s]B, copy the least significant bit of the x
coordinate to the most significant bit of the final octet.
The result is the public key.The inputs to the signing procedure is the private key, a
57-octet string, a flag F, which is 0 for Ed448, 1 for Ed448ph,
context C of at most 255 octets, and a message M of arbitrary size.
Hash the private key, 57 octets, using SHAKE256(x, 114). Let
h denote the resulting digest. Construct the secret scalar s
from the first half of the digest, and the corresponding
public key A, as described in the previous section. Let
prefix denote the second half of the hash digest,
h[57],...,h[113].Compute SHAKE256(dom4(F, C) || prefix || PH(M), 114),
where M is the message to be signed, F is 1 for Ed448ph,
0 for Ed448, and C is the context to use. Interpret the
114-octet digest as a little-endian integer r.Compute the point [r]B. For efficiency, do this by first
reducing r modulo L, the group order of B. Let the string R
be the encoding of this point.Compute SHAKE256(dom4(F, C) || R || A || PH(M), 114),
and interpret the 114-octet digest as a little-endian integer
k.Compute S = (r + k * s) mod L. For efficiency, again
reduce k modulo L first.Form the signature of the concatenation of R (57 octets)
and the little-endian encoding of S (57 octets; the ten most
significant bits of the final octets are always zero).To verify a signature on a message M using context C and
public key A, with F
being 0 for Ed448 and 1 for Ed448ph, first split the
signature into two 57-octet halves. Decode the first half as
a point R, and the second half as an integer S, in the range
0 <= s < L. Decode the public key A as point A'. If any of
the decodings fail (including S being out of range), the
signature is invalid.Compute SHAKE256(dom4(F, C) || R || A || PH(M), 114), and interpret
the 114-octet digest as a little-endian integer k.Check the group equation [4][S]B = [4]R + [4][k]A'. It's
sufficient, but not required, to instead check
[S]B = R + [k]A'.The rest of this section describes how Ed25519 can be
implemented in Python (version 3.2 or later) for illustration.
See for the complete implementation and
for a test-driver to run it through some test vectors.Note that this code is not intended for production as it is
not proven to be correct for all inputs, nor does it protect
against side-channel attacks. The purpose is to illustrate
the algorithm to help implementers with their own
implementation.This section contains test vectors for Ed25519ph, Ed25519ctx,
Ed448ph, Ed25519, and Ed448.Each section contains a sequence of test vectors. The octets are
hex encoded, and whitespace is inserted for readability. Ed25519,
Ed25519ctx, and Ed25519ph private and public keys are 32 octets;
signatures are 64 octets. Ed448 and Ed448ph private and public keys
are 57 octets; signatures are 114 octets. Messages are of arbitrary
length. If the context is non-empty, it is given as 1-255 octets.These test vectors are taken from
(but we removed the
public key as a suffix of the private key and removed the
message from the signature) and .For implementations performing signatures, secrecy of the
private key is fundamental. It is possible to protect against some
side-channel attacks by ensuring that the implementation
executes exactly the same sequence of instructions and
performs exactly the same memory accesses, for any value of
the private key. To make an implementation side-channel silent in this way,
the modulo p arithmetic must not use any data-dependent
branches, e.g., related to carry propagation. Side-channel silent point addition is
straightforward, thanks to the unified formulas.Scalar multiplication, multiplying a point by an integer,
needs some additional effort to implement in a side-channel
silent manner. One simple approach is to implement a
side-channel silent conditional assignment, and use it together
with the binary algorithm to examine one bit of the integer at
a time.Compared to other signature schemes, avoiding data-dependent
branches is easier due to side-channel silent modulo p arithmetic
being easier (with recommended curves) and having complete addition
formulas instead of having a number of special cases.Note that the example implementations in this document do
not attempt to be side-channel silent.EdDSA signatures are deterministic. This protects against
attacks arising from signing with bad randomness; the effects of which
can, depending on the algorithm, range up to full private key compromise.
It can be surprisingly hard to ensure good-quality random numbers,
and there have been numerous security failures relating to this.Obviously, private key generation requires randomness,
but due to the fact that the private key is hashed before use, a few
missing bits of entropy doesn't constitute a disaster.The basic signature verification is also deterministic. However,
some speedups by verifying multiple signatures at once do require
random numbers.Contexts can be used to separate uses of the protocol between
different protocols (which is very hard to reliably do otherwise)
and between different uses within the same protocol. However, the
following SHOULD be kept in mind when using this facility:
The context SHOULD be a constant string specified by the
protocol using it. It SHOULD NOT incorporate variable elements
from the message itself.Contexts SHOULD NOT be used opportunistically, as that kind of
use is very error prone. If contexts are used, one SHOULD require
all signature schemes available for use in that purpose support
contexts.Contexts are an extra input, which percolate out of APIs;
as such, even if the signature scheme supports contexts, those may
not be available for use. This problem is compounded by the
fact that many times the application is not invoking the signing
and verification functions directly but via some other protocol.
Some systems assume signatures are not malleable: that is, given
a valid signature for some message under some key, the attacker can't
produce another valid signature for the same message and key.
Ed25519 and Ed448 signatures are not malleable due to the
verification check that decoded S is smaller than l. Without this
check, one can add a multiple of l into a scalar part and still pass
signature verification, resulting in malleable signatures.
Ed25519 and Ed25519ph have a nominal strength of 128 bits,
whereas Ed448 and Ed448ph have the strength of 224. While the lower
strength is sufficient for the foreseeable future, the higher level
brings some defense against possible future cryptographic advances.
Both are demolished by quantum computers just about the same.The Ed25519ph and Ed448ph variants are prehashed. This is mainly
useful for interoperation with legacy APIs, since in most of the
cases, either the amount of data signed is not large or the protocol
is in the position to do digesting in ways better than just prehashing (e.g.,
tree hashing or splitting the data). The prehashing also makes the
functions greatly more vulnerable to weaknesses in hash functions
used. These variants SHOULD NOT be used.Ed25519ctx and Ed448 have contexts. However, this is balanced by
the problems noted in about contexts.On the implementation front, Ed25519 is widely implemented and has
many high-quality implementations. The others have much worse
support.In summary, if a high 128-bit security level is enough, use of
Ed25519 is RECOMMENDED; otherwise, Ed448 is RECOMMENDED.The schemes described in this document are designed to be
resistant to mixing prehashes. That is, it is infeasible to find a
message that verifies using the same signature under another scheme,
even if the original signed message was chosen. Thus, one can use the same
key pair for Ed25519, Ed25519ctx, and Ed25519ph and correspondingly
with Ed448 and Ed448ph.The "SigEd25519 no Ed25519 collisions" constant is chosen to be
a textual string such that it does not decode as a point. Because
the inner hash input in the Ed25519 signature always starts with a valid
point, there is no way trivial collision can be constructed. In the
case of seed hash, trivial collisions are so unlikely, even with
an attacker choosing all inputs, that it is much more probable that
something else goes catastrophically wrong.Avoid signing large amounts of data at once (where "large"
depends on the expected verifier). In particular, unless the
underlying protocol does not require it, the receiver MUST
buffer the entire message (or enough information to reconstruct
it, e.g., compressed or encrypted version) to be verified.This is needed because most of the time, it is unsafe to
process unverified data, and verifying the signature makes
a pass through the whole message, causing ultimately at least
two passes through.As an API consideration, this means that any Initialize
Update Finalize (IFU) verification interface is prone to misuse.It is a bad idea to modify Ed25519 or Ed448 signing to be able
to create valid Ed25519/Ed448 signatures using an IUF interface with
only constant buffering. Pretty much any error in such would cause
catastrophic security failure.The given verification formulas for both Ed25519 and Ed448
multiply points by the cofactor. While this is not strictly
necessary for security (in fact, any signature that meets
the non-multiplied equation will satisfy the multiplied one),
in some applications it is undesirable for implementations to
disagree about the exact set of valid signatures. Such disagreements
could open up, e.g., fingerprinting attacks.Ed448 uses SHAKE256 as a hash function, even if SHAKE256 is
specifically defined not to be a hash function.The first potentially troublesome property is that shorter
outputs are prefixes of longer ones. This is acceptable because
output lengths are fixed.The second potentially troublesome property is failing to meet
standard hash security notions (especially with preimages). However,
the estimated 256-bit security level against collisions and preimages
is sufficient to pair with a 224-bit level elliptic curve.
&rfc6234;
&rfc7748;
SHA-3 Standard: Permutation-Based Hash and Extendable-Output FunctionsNational Institute of Standards
and Technology
&rfc4086;
High-speed high-security signaturesEdDSA for more curvesFaster addition and doubling on elliptic curvesTwisted Edwards Curves RevisitedExtended coordinates with a=-1 for twisted Edwards curvesExtended coordinates with a=-1 for twisted Edwards curvesCurve25519: new Diffie-Hellman speed recordsEd448-Goldilocks, a new elliptic curveEd25519 test vectorsEd25519 Libgcrypt test vectorsProjective coordinates for Edwards curvesProjective coordinates for Edwards curvesBelow is an example implementation of Ed25519/Ed448 written in
Python; version 3.2 or higher is required.Note: This code is not intended for production. Although it
should produce correct results for every input, it is slow and
makes no attempt to avoid side-channel attacks.Below is a command-line tool that uses the library above to
perform computations for interactive use or for
self-checking.EdDSA and Ed25519 were initially described in a paper due to
Daniel J. Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, and
Bo-Yin Yang. The Ed448 curve is due to Mike Hamburg.An earlier draft version of this document was coauthored by Niels
Moeller.Feedback on this document was received from Werner Koch,
Damien Miller, Bob Bradley, Franck Rondepierre, Alexey Melnikov,
Kenny Paterson, and Robert Edmonds.The Ed25519 test vectors were double checked by Bob Bradley
using three separate implementations (one based on TweetNaCl and two
different implementations based on code from SUPERCOP).