Edwards-curve Digital Signature Algorithm (EdDSA)
SJD ABsimon@josefsson.orghttp://josefsson.org/Independentilariliusvaara@welho.comThe elliptic curve signature scheme Edwards-curve Digital
Signature Algorithm (EdDSA) is described. 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 in the Internet community of EdDSA,
this document describe the signature scheme in an
implementation-oriented way, and provide sample code and test
vectors.The advantages with EdDSA include:
High-performance on a variety of platforms.Does not require the use of a unique random number for each
signature.More resilient to side-channel attacks.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.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. The document 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
sufficently 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 field.finite 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 jsubstraction of j from idivision of i by jcartesian product of i and jElliptic curve point with x coodiate u and y coordinate v The y first octets of
SHAKE256 output for input x.The octet with value xThe number of octets in string xThe octet string "SigEd448" || octet(x) || octet(OLEN(y)) || y,
where x is in range 0-255 and y is octet string of at most 255
octets. "SigEd448" is in ASCII (8 octets).Use of parenthesis (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 and packing those from least significant
bit of each octet to most siginficant 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. E.g. the 16-bit bit
string:Is converted into two octets x0 and x1 (in this order) as:Little-endian encoding into bits places bits from left to right
from least significant to most significant. If combined with bit
string to octet string conversion defined above, this results in
little-endian encoding into octets (if length is not multiple of
8, the most significant bits of last octet remain unused).EdDSA is a digital signature system with eleven
parameters.The generic EdDSA digital signature system with its eleven
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 re-use 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 non-intuitive steps of the algorithm.This description closely follows .EdDSA has eleven 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 multiple of 8, so public key and
signature lengths are 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 nonzero 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 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,
which 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 is an element 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. Signature is rejected if parsing
fails or 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 signature is validated, which needs a pass on the
entire message.This document specify parameters resulting in the HashEdDSA
variants Ed25519ph and Ed448ph, and the PureEdDSA variants
Ed25519 and Ed448.This section instantiate the general EdDSA algorithm for the
edwards25519 and edwards448 curves, each for the PureEdDSA and
HashEdDSA variants. Thus four 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(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)Ed25519ph is the same but with PH being SHA-512 instead,
i.e., the input is hashed using SHA-512 before signing with
Ed25519.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 advise 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).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 nonzero 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 using the following trick, to use 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 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 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. and in .
They are complete, i.e., they work for any pair of valid input points.
The secret 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 secret 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 3 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 a. Perform a fixed-base scalar
multiplication [a]B.The public key A is the encoding of the point [a]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 [a]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.
Hash the private key, 32-octets, using SHA-512. Let h
denote the resulting digest. Construct the secret scalar a
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(prefix || 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(R || A || M), and interpret the 64-octet
digest as a little-endian integer k.Compute S = (r + k * a) 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, three most
significant bits of the final octet are always zero).To verify a signature on a message M, 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. If the decoding fails, the signature is
invalid.Compute SHA512(R || A || 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(dom(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(dom(2,context)||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
basepoint, which preserves difficulty of the discrete logarithm.
For advise 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).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 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 nonzero 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 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 and in .
They are complete, i.e., they work for any pair of
valid input points.
The secret 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 secret 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 8 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 a. Perform a known-base-point scalar
multiplication [a]B.The public key A is the encoding of the point [a]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 [a]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 a
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(dom(F, C) || prefix || 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(dom(F, C) || R || A || M, 114),
and interpret the 114- octet digest as a little-endian integer
k.Compute S = (r + k * a) 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, with F
being 0 for Ed448, 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. If the decoding fails, the signature is
invalid.Compute SHAKE256(dom(F, C) || R || A || 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 appendix A for the complete implementation and appendix B
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.First some preliminaries that will be needed.Then follows functions to perform point operations.Now follows functions for point compression.These are functions for manipulating the secret key.The signature function works as below.And finally the verification function.This section contains test vectors for Ed25519ph, Ed448ph,
Ed25519 and Ed448.Each section contains sequence of test vectors. The octets are
hex encoded and whitespace is inserted for readability. Ed25519
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 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 .EdDSA and Ed25519 was initially described in a paper due to
Daniel J. Bernstein, Niels Duif, Tanja Lange, Peter Schwabe and
Bo-Yin Yang. The Ed448 curves is due to Mike Hamburg.This draft is based on an earlier draft co-authored by Niels
Möller.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 3 separate implementations (one based on TweetNaCl and 2
different implementations based on code from SUPERCOP).None.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 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 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, effects of which
can depending on algorithm range up to full private key compromise.
It can be surprisingly hard to ensure good-quality random numbers
and there have been numerious security failures relating to this.Obviously, private key generation requires randomness,
but due to the fact that private key is hashed before use, a few
missing bits of entropy aren't 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.Most signing functions do not support contexts, so those
SHOULD NOT be relied to perform security-critical separations.
Contexts are an extra input, which percolates out of APIs,
as such, even if 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 protcol.
The Ed25519 and Ed25519ph have nominal strength of 128 bits,
whereas Ed448 and Ed448ph have strength of 224. While the lower
strength is sufficient for the forseeable 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 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 vulernable to weaknesses in hash functions
used. These variants SHOULD NOT be used.On implementation front, Ed25519 is widely implemented, and has
many high-quality implementations. The others have much worse
support.As summary, if high 128-bit security level is enough, use of
Ed25519 is RECOMMENDED, otherwise Ed448 is RECOMMENDED.Using the same keypair with different prehashes is a bad idea.
The most obvious problem is that identity transform can produce
message values colliding with hashes of interesting messages
(or vice versa). Additionally, even if it is infeasible to find
collisions in two hash functions, there is nothing guaranteeing
that finding collisions between hashes is infeasible.For these reasons, the same private key MUST NOT be used for
multiple algorithms (including prehashes) without protocol
or scheme (such as Ed448/Ed448ph pair) preventing messages
output by different prehash algorithms from colliding.Avoid signing large amounts of data at once (where "large"
depends on expected verifier). In practicular, 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 becuse most of the time, it is unsafe to
process unverified data, and verifying the signature makes
a pass through whole message, causing ultimately at least
two passes through.As API consideration, this means that any IUF (Initialize
Update Finalize) verification interface is prone to misuse.US Secure Hash Algorithms (SHA and HMAC-SHA)The United States of America has adopted a suite of Secure Hash Algorithms (SHAs), including four beyond SHA-1, as part of a Federal Information Processing Standard (FIPS), specifically SHA-224 (RFC 3874), SHA-256, SHA-384, and SHA-512. The purpose of this document is to make source code performing these hash functions conveniently available to the Internet community. The sample code supports input strings of arbitrary bit length. SHA-1's sample code from RFC 3174 has also been updated to handle input strings of arbitrary bit length. Most of the text herein was adapted by the authors from FIPS 180-2.Code to perform SHA-based HMACs, with arbitrary bit length text, is also included. This memo provides information for the Internet community.Elliptic Curves for SecurityThis memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.SHA-3 Standard: Permutation-Based Hash and Extendable-Output FunctionsNational Institute of Standards
and Technology, U.S. Department of CommerceRandomness Requirements for SecuritySecurity systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.High-speed high-security signaturesEdDSA for more curvesFaster addition and doubling on elliptic curvesTwisted Edwards Curves RevisitedEFD / Genus-1 large-characteristic / Extended coordinates with a=-1 for twisted Edwards curvesCurve25519: new Diffie-Hellman speed recordsEd448-Goldilocks, a new elliptic curveEd25519 test vectorsEd25519 Libgcrypt test vectorsExplicit-Formulas Database / Genus-1 large-characteristic / Projective 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. Altough it
should produce correct results for every input, it is slow and
makes no attempt to avoid side-channel attacks.[A note to RFC-Editor: Please don't change the relative
indentations here: This code is written in programming language
where relative indentations are meaningful, so changing those
changes program meaning (authors: check this still works in
AUTH48). Remove this note before publication.]Below is a command-line tool that uses the library above to
perform computations, for interactive use or for
self-checking.[A note to RFC-Editor: Please don't change the relative
indentations here: This code is written in programming language
where relative indentations are meaningful, so changing those
changes program meaning (authors: check this still works in
AUTH48). Remove this note before publication.]