High-speed high-security signatures

This paper shows that a $390 mass-market quad-core 2.4GHz Intel Westmere (Xeon E5620) CPU can create 109000 signatures per second and verify 71000 signatures per second on an elliptic curve at a 2128 security level. Public keys are 32 bytes, and signatures are 64 bytes. These performance figures include strong defenses against software side-channel attacks: there is no data flow from secret keys to array indices, and there is no data flow from secret keys to branch conditions.


Introduction
This paper introduces software for public-key signatures with several attractive features: -Fast single-signature verification.The  signing.There is a slight penalty for key generation to obtain a secure random number from the operating system; /dev/urandom under Linux costs about 6000 cycles.
-High security level.This system has a 2 128 security target; breaking it has similar difficulty to breaking NIST P-256, RSA with ≈ 3000-bit keys, strong 128-bit block ciphers, etc. (The same techniques would also produce speed improvements at other security levels.)The best attacks known actually cost more than 2 140 bit operations on average, and degrade quadratically in success probability as the number of bit operations drops.-Foolproof session keys.Signatures in this paper are generated deterministically; key generation consumes new randomness but new signatures do not.This is not only a speed feature but also a security feature, directly relevant to the recent collapse of the Sony PlayStation 3 security system.See Section 2 for further discussion.-Collision resilience.Hash-function collisions do not break this system.This adds a layer of defense against the possibility of weakness in the selected hash function.-No secret array indices.The software never reads or writes data from secret addresses in RAM; the pattern of addresses is completely predictable.The software is therefore immune to cache-timing attacks, hyperthreading attacks, and other side-channel attacks that rely on leakage of addresses through the CPU cache.-No secret branch conditions.The software never performs conditional branches based on secret data; the pattern of jumps is completely predictable.The software is therefore immune to side-channel attacks that rely on leakage of information through the branch-prediction unit.-Small signatures.Signatures fit into 64 bytes.These signatures are actually compressed versions of longer signatures; the times for compression and decompression are included in the cycle counts reported above.-Small keys.Public keys consume only 32 bytes.The times for compression and decompression are again included.
We have submitted our software to the eBATS project [15] for public benchmarking, and placed the software into the public domain to maximize reusability.The numbers 87548 and 273364 shown above are from the eBATS reports for our software on a Westmere CPU (Intel Xeon E5620, hydra2).
Our signatures are elliptic-curve signatures, carefully engineered at several levels of design and implementation to achieve very high speeds without compromising security.Section 2 specifies the signature system; Section 3 explains the techniques we use for finite-field arithmetic; Section 4 discusses fast signatures; Section 5 discusses fast verification.
Comparison to previous ECC work.Carrying out highsecurity elliptic-curve signature verification in only 134000 cycles on a single core of a typical Intel CPU is unprecedented.The following paragraphs discuss previous work.
Readers should be aware of several difficulties in comparing ECC performance results.First, most papers on fast ECC have been limited to ECDH (variable-base-point singlescalar multiplication) and have not implemented ECC signature verification, although there are certainly some exceptions-for example, [21] reported verification 1.33× slower than ECDH, and [34] reported verification 1.36× slower than ECDH.Second, most implementations use secret array indices and secret branch conditions and therefore must be assumed to be breakable by side-channel attacks, as illustrated by the successful OpenSSL attack in [23]; this is not an issue for public-key signature verification but it is an issue for signing and for ECDH.Third, most papers report results for only a few CPUs, so anyone without access to the same CPUs must engage in error-prone extrapolation from one CPU to another; this is not an issue for systems included in the eBATS benchmarks, but we are aware of two recent ECC implementations (discussed below) that are not included in eBATS.
Intel's "Turbo Boost" and AMD's "Turbo Core" have added a further difficulty for new CPUs.Typical benchmarking frameworks measure performance on a single CPU core, and Turbo Boost fools most of these frameworks into reporting excessively low Westmere cycle counts-speeds that the CPU cannot actually achieve when a sensible workload is keeping all cores busy.The eBATS reports include explicit warnings regarding Turbo Boost.This corruption does not occur on hydra2: Turbo Boost is disabled on that computer.
Before this paper, the closest system to ours in eBATS was ecdonaldp256: ECDSA signatures using the NIST P-256 elliptic curve.On hydra2 this system takes 1690936 cycles for key generation, 1790936 cycles for signing, and 2087500 cycles for verification.Better speeds were reported for ECDH: -Third place was curve25519, an implementation by Gaudry and Thomé [35] of Bernstein's Curve25519 [12].-Second place was 307180 cycles for ecfp256e, an implementation by Hisil [40] of ECDH on an Edwards curve with similar security properties to Curve25519.-First place was 278256 cycles for gls1271, an implementation by Galbraith, Lin, and Scott [34] of ECDH on an Edwards curve with an endomorphism.
The recent papers [38] and [44] point out security problems with endomorphisms in some ECC-based protocols, but as far as we can tell those security issues are not relevant to ECDH with standard hashing of the ECDH output, and are not relevant to ECC signatures.Longa and Gebotys in [52] claimed 281000 cycles on a Core 2 Duo E6750 (C2 65nm) for ECDH on a curve similar to ecfp256e, and 229000 cycles for ECDH on a curve similar to gls1271.The software in [52] is not included in the eBATS benchmarks and apparently is not publicly available, so we are unable to benchmark it on a Westmere.More recently Käsper in [46] reported 457813 cycles for side-channel-protected ECDH on the NIST P-224 curve on a Core 2 Duo E8400 (C2 45nm); this software has been integrated into OpenSSL but not yet into eBATS.
To aid comparisons we also implemented ECDH, specifically curve25519, with the same side-channel defenses as our signature software (no secret array indices, and no secret branch conditions).We submitted our ECDH software to eBATS, which reports that the software uses 226872 cycles on hydra2 for variable-base-point single-scalar multiplication.This is a new speed record for public ECDH software, a new speed record for side-channel-protected ECDH (out of all the papers mentioned above, the only ones that report sidechannel protection are [12] and [46]), a new speed record for ECDH with single-size public keys (32 bytes at this security level instead of 64 bytes), and a new speed record for ECDH without endomorphisms.
We do not claim that curve25519 will maintain its current position on top of eBATS: we would expect ECDH with endomorphisms (especially with 64-byte keys and without side-channel protection) to be somewhat faster than ECDH without endomorphisms on many platforms.This expectation seems to be supported by the very recent paper [42] by Hu, Longa, and Xu: [42, Table 2] claims 194000 cycles for a curve with endomorphisms on an Intel Core 2 Duo E6750, and the accompanying web site [51] cited in [42, reference 18] claims 182000 cycles for a curve with endomorphisms on an Intel Core i5 540M (Westmere).The same web site also claims 215000 Westmere cycles for a curve without endomorphisms.However, like the software in [52], the software in [42] and [51] does not appear to be publicly available.The resulting lack of verifiability raises questions regarding accuracy.We are particularly skeptical of the Westmere speed claims, given the Turbo Boost issues discussed above.After we wrote this paragraph, the same web site was updated to claim 250000 cycles for the same software on another Westmere CPU.
Given our 226872-cycle ECDH speed, given the ECDHto-verification slowdowns reported in [21] and [34], and given the extra costs that we incur for decompressing keys and signatures, one would expect a verification speed close to 400000 cycles.We do better than this for several reasons, the most important reason being our use of batching.This requires careful design of the signature system, as discussed later in this paper: ECDSA, like DSA and most other signature systems, is incompatible with fast batch verification.
Comparison to other signature systems.The eBATS benchmarks cover 42 different signature systems, including various sizes of RSA, DSA, ECDSA, hyperelliptic-curve signatures, and multivariate-quadratic signatures.This paper beats almost all of the signature times and verification times (and key-generation times, which are an issue for some applications) by more than a factor of 2. The only exceptions are as follows: -Multivariate-quadratic signatures are competitive in speed.
For example, sflashv2 takes 124740 cycles to sign and 165884 cycles to verify; mqqsig256 takes 4212 cycles to sign and 134900 cycles to verify; smaller mqqsig versions are even faster.However, sflashv2 was broken by Dubois, Fouque, Shamir, and Stern in [30].We are not aware of any security evaluation of mqqsig, which was introduced last year in [36], but we disregard mqqsig256 for the simple reason that it has a 789552-byte public key.-donald512 (512-bit DSA) takes 334508 cycles to verify.This is comparable to our single-signature verification speed but much slower than our batch verification speed.This is also at a far lower security level, breakable in about 2 60  The conventional wisdom is that RSA signatures are much better than ECC signatures in applications where each signature is verified many times, since RSA verification is much faster than ECC verification.Our ECC speed results call this conventional wisdom into question.We do not claim that our verification speeds cannot be beaten by RSA at the same security level, but we do claim that they are fast enough to make ECC an attractive option even for verification-intensive applications such as [71].

The signature system
This section specifies the signature system used in this paper, and a generalized signature system EdDSA that can be used with other choices of elliptic curves.
There is an extensive literature on variants of the classic signature system introduced by ElGamal in [33]; notable variants include Schnorr's signature system [73], DSA, and ECDSA.Our generalized system is another of these variants.We do not claim novelty for any of the individual modifications that we use, but we emphasize that selecting a good combination of modifications is critical for top performance.The most obvious modification is that we use twisted Edwards curves rather than Weierstrass curves; this explains our choice of the name EdDSA (Edwards-curve Digital Signature Algorithm).
EdDSA parameters.EdDSA has seven parameters: an integer b ≥ 10; a cryptographic hash function H producing 2b-bit output; a prime power q congruent to 1 modulo 4; a (b − 1)-bit encoding of elements of the finite field F q ; a non-square element d of F q ; a prime between 2 b−4 and 2 b−3 satisfying an extra constraint described below; and an element B = (0, 1) of the set The condition that d is not a square implies that d ∈ {0, −1}, so this set E forms a group with neutral element 0 = (0, 1) under the twisted Edwards addition law introduced by Bernstein, Birkner, Joye, Lange, and Peters in [13].Completeness of the addition law -the fact that the denominators 1 ± dx 1 x 2 y 1 y 2 are nonzero -follows as explained in [13, Section 6]: −1 is a square in F q (since q is congruent to 1 modulo 4), so this addition law on E is F q -isomorphic to the Edwards addition law on the Edwards curve x 2 + y 2 = 1 − dx 2 y 2 , which is complete by [14, Theorem 3.3] since −d is not a square in F q .The latter follows from d being a non-square and −1 being a square in F q .The extra constraint mentioned above is that B = 0, where n B means the nth multiple of B in this group.
We use the encoding of F q to define some field elements as being negative: specifically, x is negative if the (b − 1)-bit encoding of x is lexicographically larger than the (b − 1)-bit encoding of −x.If q is an odd prime and the encoding is the little-endian representation of {0, 1, . . ., q − 1} then the negative elements of F q are {1, 3, 5, . . ., q − 2}.
An element (x, y) ∈ E is encoded as a b-bit string (x, y), namely the (b − 1)-bit encoding of y followed by a sign bit; the sign bit is 1 iff x is negative.This encoding immediately determines y, and it determines x via the equation x = ± (y 2 − 1)/(dy 2 + 1).

EdDSA keys and signatures. An EdDSA secret key is a
which in turn determines the multiple A = a B. The corresponding EdDSA public key is A. Bits h b , . . ., h 2b−1 of the hash are used as part of signing, as discussed in a moment.
The signature of a message M under this secret key k is defined as follows.Define r = H (h b , . . ., h 2b−1 , M) ∈ 0, 1, . . ., 2 2b − 1 ; here we interpret 2b-bit strings in littleendian form as integers in 0, 1, . . ., 2 2b − 1 .Define R = r B. Define S = (r + H (R, A, M)a) mod .The signature of M under k is then the 2b-bit string (R, S), where S is the bbit little-endian encoding of S. Applications wishing to pack data into every last nook and cranny should note that the last three bits of signatures are always 0 because fits into b − 3 bits.
Verification of an alleged signature on a message M under a public key works as follows.The verifier parses the key as A for some A ∈ E, and parses the alleged signature as (R, S) for some R ∈ E and S ∈ {0, 1, . . ., − 1}.The verifier computes H (R, A, M) and then checks the group equation The verifier rejects the alleged signature if the parsing fails or if the group equation does not hold.
To see that signatures pass verification, simply multiply B by the equation S = (r + H (R, A, M)a) mod , and use the fact that B = 0, to see that The verifier is permitted to check this stronger equation and to reject alleged signatures where the stronger equation does not hold.However, this is not required; checking that 8S B = 8R + 8H (R, A, M)A is enough for security.

Weak keys. Forgeries are trivial if
A is a known multiple of B. For example, an attacker who knows that A = 37B can choose r and compute S = (r + 37H (R, A, M)) mod .As an even more extreme example, an attacker who knows that A = 0B can choose r and compute S = r mod , independently of M. We could declare that 0B and 37B are "broken" by these two "attacks" and that users must check for, and reject, these "weak keys"; but the same confused logic would require rejecting all keys in all cryptosystems, and would have no relevance to the standard definition of signature security.
Legitimate users choose A = a B, where a is a random secret; the derivation of a from H (k) ensures adequate randomness.These users have negligible chance of generating any particular multiple of B targeted by the attacker (and no chance of generating 0B).The chance of the attacker randomly guessing a is far smaller than the chance of the attacker computing a by known discrete-logarithm algorithms; standard elliptic-curve security criteria are designed so that the latter algorithms have negligible chance of succeeding in any reasonable amount of time.
if we slightly modified the system then replacing S by −S and replacing A by −A (a slight variant of the "attack" of [76]) would convert one valid signature into another valid signature of the same message under a new public key; but it would still not accomplish the attacker's goal, namely to forge a signature on a new message under a target public key.One such modification would be to omit A from the hashing; another such modification would be to have A encode only |A|, rather than A.
Choice of curve.Our recommended curve for EdDSA is a twisted Edwards curve birationally equivalent to the curve Curve25519 from [12].Any efficiently computable birational equivalence preserves ECDLP difficulty, so the well-known difficulty of computing ECDLP for Curve25519 immediately implies the difficulty of computing ECDLP for our curve.We use the name Ed25519 for EdDSA with this particular choice of curve.
Pseudorandom generation of r .ECDSA, like many other signature systems, asks users to generate not merely a random long-term secret key, but also a new random secret session key r for each message to be signed.If r becomes public then, assuming H (R, A, M) mod = 0, the long-term secret key a can be simply computed as a = (S −r )/H (R, A, M) mod .If the same value r is ever used for 2 different messages the secret key can be computed as well, as ElGamal noted in [33, Note 2].It was reported in [24] that the latter failure had occurred in Sony's ECDSA implementation for codesigning for the PlayStation3, immediately revealing Sony's long-term secret key.
Furthermore, it is well known that ECDSA's session keys are much less tolerant than the long-term key of slight deviations from randomness, even if the session keys are not revealed or reused.For example, Nguyen and Shparlinski in [62] presented an algorithm using lattice methods to compute the long-term ECDSA key from the knowledge of as few as 3 bits of r for hundreds of signatures, whether this knowledge is gained from side-channel attacks or from non-uniformity of the distribution from which r is taken.
EdDSA avoids these issues by generating r = H (h b , . . ., h 2b−1 , M), so that different messages will lead to different, hard-to-predict values of r .No per-message randomness is consumed.This idea of generating random signatures in a secretly deterministic way, in particular obtaining pseudorandomness by hashing a long-term secret key together with the input message, was proposed by Barwood in [9]; independently by Wigley in [80]; a few months later in a patent application [58] by Naccache, M'Raïhi, and Levy-dit-Vehel; later by M'Raïhi, Naccache, Pointcheval, and Vaudenay in [56]; and much later by Katz and Wang in [47].The patent application was abandoned in 2003.
Standard PRF hypotheses imply that this pseudorandom session key r is indistinguishable from a truly random string generated independently for each M, so there is no loss of security.Well-known length-extension properties prevent secret-prefix SHA-512 from being a PRF, but also do not threaten the security of Ed25519-SHA-512, since r is not visible to the attacker.All remaining SHA-3 candidates are explicitly designed to be PRFs, and we will not hesitate to recommend Ed25519-SHA-3 after SHA-3 is standardized.It would of course also be safe to generate r with a cipher such as AES, combined with standard PRF-stretching mechanisms to support a long input; but we prefer to reuse H to save area in hardware implementations.

Comparison to previous ElGamal variants.
The original ElGamal system [33, Section III] predated elliptic-curve cryptography; it instead used the multiplicative group F * q .ElGamal took a large non-prime , specifically = q −1, and focused on the case of prime q.ElGamal's signatures were pairs (R, S) of integers between 0 and q − 2 inclusive satisfying ]; see also [33,Attack 6] for the introduction of H .The signer, given M, generates a random r coprime to and computes the signature (R, S), where R = B r and S = r −1 (H (M) − Ra) mod .
Schnorr in [73] pointed out that one could safely work in an order-subgroup of F * q with a prime much smaller than q, saving most of the space for S. Schnorr also introduced several other improvements to ElGamal's system, as discussed below.
ElGamal's verification equation involves R as an element of the group F * q and as a scalar, the exponent for A. For more general groups one needs a function x mapping group elements to scalars.ECDSA works this it replaces F * q with an order-subgroup of an elliptic-curve group over F q and defines x(R) as the x-coordinate of R. ECDSA also replaces A with −A, changing the signer's subtraction into an addition and obtaining the verification equation H (M)B + x(R)A = S R. ECDSA replaces this threescalar equation with the equivalent two-scalar equation S −1 H (M)B + S −1 x(R)A = R at the expense of requiring S to be invertible modulo ; note that both the signer and the verifier compute inverses here.
Schnorr used a cryptographic hash function for x.This has minimal expense and eliminates any concerns regarding the mathematical structure of simpler functions x.Schnorr also compressed the group element R to the scalar x(R): a Schnorr signature is (x(R), S) rather than (R, S).Given a compressed signature (x(R), S), the verifier recomputes R as S −1 H (M)B + S −1 x(R)A and checks that x(R) matches; at this point the verifier knows a valid uncompressed signature (R, S), so the compression cannot reduce security.
Schnorr also merged the hashing of R with the hashing of M. One way to understand this merging is to replace S with x(R)S, and to impose the extra constraint x(R) = 0, obtaining the verification equation x(R) −1 H (M)B + A = S R.There is no need for the multiplicative structure of x(R) −1 H (M) here: one can instead use the verification equation H (R, M)B + A = S R, with the signer obtaining S as r −1 (H (R, M) + a) mod .Schnorr actually used the equation S B = R + H (R, M)A, eliminating all inversions both for the signer and for the verifier; this is an obvious advantage, saving time and reducing code size.
The presence of R as input to the hash function provides collision resilience: the attacker cannot break Schnorr's system by merely finding hash collisions.Neven, Smart, and Warinschi in [61] proposed taking advantage of collision resilience by choosing H to output only b/2 bits, reducing the size of compressed signatures by 25%; but the same proposal had actually appeared twenty years earlier in Schnorr's original paper [73,Section 2].
Practical use of Schnorr's system was hampered by a patent (which expired in 2008), but the system became well known to theoreticians, because the hashing of R allowed various security proofs.Some proofs use the "forking lemma" to show that any generic-hash attack against Schnorr's system (i.e., any attack that works for arbitrary functions H ) can be converted into a DLP algorithm with a polynomially bounded, although often quite severe, loss of efficiency.There are also theorems with a different loss of efficiency for generic-group attacks (i.e., attacks that work for arbitrary groups) under mild assumptions on H , and theorems with no loss of efficiency for generic-group generic-hash attacks.See, for example, [68], [75], [11], and [61].We do not mean to exaggerate the real-world relevance of "provable security", but we find it obvious that Schnorr's system is a conservative, well-studied signature system.
Our verification equation is the same as Schnorr's verification equation with double-size hashing instead of half-size hashing, with A inserted as an extra hash input, and without Schnorr's compression of R.These modifications obviously do not compromise security.The use of double-size hashing helps alleviate concerns regarding hash-function security; the use of A is an inexpensive way to alleviate concerns that several public keys could be attacked simultaneously; and the avoidance of compression allows an important verification speedup, as discussed in Section 5. We also reuse the double-size hash to alleviate concerns regarding nonce randomness, as discussed above.

Fast arithmetic modulo 2 255 − 19
This section explains how our software represents elements of the field F 2 255 −19 , and how our software performs efficient field arithmetic.The machine instructions used in the software are available on all 64-bit Intel and AMD CPUs, but we target Intel's Nehalem/Westmere CPUs.
Multipliers on Nehalem CPUs.Field multiplications (and squarings) are the main bottlenecks in elliptic-curve performance on most CPUs.The most important tool for fast field multiplication is a fast CPU multiplication instruction.Nehalem CPUs offer three different multiplication instructions that can be used to implement high-speed field arithmetic: -The mulpd instruction can perform two double-precision floating-point multiplications in SIMD fashion every cycle.Newer Sandy Bridge CPUs include a vmulpd instruction that can perform up to 4 double-precision floating-point multiplications per cycle, but this instruction is not available on our target CPUs.-Themul instruction can multiply two 64-bit unsigned integers, producing a 128-bit result, every two cycles.-The pmuldq/pmuludq instructions can perform two multiplications of 32-bit integers, producing 64-bit results, every cycle.The pmuldq instruction performs signed multiplication; the pmuludq instruction performs unsigned multiplication.
Multiplication and Edwards-curve arithmetic involve datalevel parallelism that we could exploit with mulpd and pmuldq, but this approach would incur a serious overhead of shuffle instructions needed to arrange data in registers as described in, e.g., [26] and [60].This overhead is eliminated when several independent computations are run in parallel, but two 64-bit results every cycle are not fundamentally better than one 128-bit result every two cycles.We therefore decompose field multiplication into multiplications of 64-bit unsigned integers.
Radix-2 64 representation.The way to split 255-bit values into 64-bit limbs is a 4-limb, radix-2 64 representation.Each element x of the field is represented as (x 0 , x 1 , x 2 , x 3 ) with x = 3 i=0 x i 2 64i .The multiplication of two elements x and y is decomposed into 16 multiplications of 64-bit unsigned integers; the 128-bit results are added up to produce the result in 8 limbs r 0 , . . ., r 7 .Reduction modulo 2 255 − 19 exploits the fact that 2 256 ≡ 38, so 38 • r 4 is added to r 0 , 38 • r 5 to r 1 and so on.
A detail worth noting of this representation is that it uses 256 bits to represent 255-bit field elements.We use this one extra bit and do not always reduce modulo 2 255 − 19 but modulo 2 256 − 38.For a similar representation this has been shown to be useful for example in [17].
Our implementation of the signature scheme based on this representation of field elements yields high performance on many microprocessors such as AMD K10 or 65-nm Intel Core 2 processors.However, on our target platform, the Intel Nehalem/Westmere CPUs, this representation triggers a serious bottleneck.Every 128-bit result of the mul instruction is produced in two 64-bit registers.Adding two of these results requires two addition instructions.In the field multiplication most of these additions produce carries; the carry bits need to be handled by subsequent additions.The Intel Nehalem and Westmere CPUs can perform three additions per cycle, but only if these additions do not have to handle a carry bit from a previous addition (add instruction).An add with carry (adc instruction) can only be done once every two cycles; i.e., carry bits decrease addition throughput by a factor of 6.This bottleneck is triggered not only inside field multiplication and squaring but also inside additions.
Radix-2 51 representation.To reduce the number of expensive adc/subc instructions, we instead represent an element x of F 2 255 −19 as (x 0 , x 1 , x 2 , x 3 , x 4 ) with x = 4 i=0 x i 2 51i .The 5 limbs are unsigned integers.We can represent each element of the field F 2 255 −19 with each x i ∈ [0, . . ., 2 51 − 1].In fact our implementation does not enforce these bounds except for comparisons.Multiplication accepts inputs with each limb having up to 54 bits and produces results of which each limb can be only slightly larger than 2 51 .
Multiplication and squaring.Schoolbook multiplication of two field elements x and y, each represented in 5 unsigned integers, takes 25 mul instructions.The results are again produced in two 64-bit integer registers, but as both inputs have only up to 54 bits, the value in the upper result register has only up to 44 bits.Adding two multiplication results now takes only one adc and one add instruction.Furthermore reduction can be carried out simultaneously to multiplication.For example, we do not compute a coefficient r 5 .Whenever the result of a mul instruction belongs to r 5 , for example in the multiplication of x 2 • y 3 , we multiply one of the inputs by 19 and add the result to r 0 .Similarly we do not compute r 6 , r 7 , r 8 and r 9 but directly add into r 1 , . . ., r 4 .Multiplying one input by 19 yields a result with less than 64 bits so we can use the faster imul instruction for these multiplications.The 5 result coefficients require 10 64-bit registers; the AMD64 architecture has 15 such registers, so we can keep the result coefficients inside registers throughout the computation.
After the multiplication we need to reduce (carry) the 5 coefficients to obtain a result with coefficients that are at most slightly larger than 2 51 .Denote the two registers holding coefficient r 0 as r 00 and r 01 with r 0 = 2 64 r 01 + r 00 .Similarly denote the two registers holding coefficient r 1 as r 10 and r 11 .We first shift r 01 left by 13, while shifting in the most significant bits of r 00 (shld instruction) and then compute the logical and of r 00 with 2 51 − 1.We do the same with r 10 and r 11 and add r 01 into r 10 after the logical and with 2 51 − 1.We proceed this way for coefficients r 2 , . . ., r 4 ; register r 41 is multiplied by 19 before adding it to r 00 .Now all 5 coefficients fit into 64-bit registers but are still too large to be used as input to another multiplication.We therefore carry from r 0 to r 1 , from r 1 to r 2 , from r 2 to r 3 , from r 3 to r 4 , and finally from r 4 to r 0 .Each of these carries is done as one copy, one right shift by 51, one logical and with 2 51 − 1, and one addition.
Squaring needs only 15 mul instructions.Some inputs are multiplied by 2; this is combined with multiplication by 19 where possible.The coefficient reduction after squaring is the same as for multiplication.
Multiplication and squaring are implemented as separate functions, but calls to these functions are used only for inversion (see below).Edwards-curve arithmetic uses inlined functions for point addition and doubling.
Addition, subtraction, and inversion.The results of additions do not have to be reduced if they are used as input to a multiplication.Long sequences of additions that let coefficients grow larger than 54 bits would be a problem but we do not have such sequences of additions.Field addition is therefore nothing but 5 integer additions without carries (add instruction).Subtraction is slightly more expensive because we use unsigned coefficients.Therefore we first add a multiple of q and then perform subtraction.This costs 5 add and 5 sub instructions.
Inversion is implemented as exponentiation with exponent q − 2. It uses the same sequence of 255 squarings and 11 multiplications as [12].

Signing messages
Signature generation has three steps: (1) computing r = H (h b , . . ., Our primary concern is with short messages M, obviously the top concern for a server trying to keep up with a given 123 volume of data; longer messages take more per signature but far fewer cycles per byte.The computations of H take negligible time for short messages.The reduction modulo also takes negligible time with standard branchless techniques.For the rest of this section we focus on the main signing bottleneck, namely computing r B given r .
For each i we look up 16 i |r i |B in a precomputed table, and then conditionally negate 16 i |r i |B to obtain 16 i r i B. Finally we compute r B as i 16 i r i B.
There is nothing new in our computation at this level.Computing r B as a sum of precomputed pieces is a special case of a standard scalar-multiplication algorithm published by Pippenger in [65] (subsequently reinvented in [19] and [50]); allowing negative coefficients is a standard tweak.The devil lies in the lower-level details -choosing the optimal radix 16, and computing 16 i r i B and i 16 i r i B as efficiently as possible.These details are discussed below.

Low level, part 1: table lookups.
Recall that, as a side-channel defense, we prohibit secret array indices.In particular, we cannot use |r i | as an array index.We instead load all table entries 0B, 16 i B, 2 We actually store table entries only for i ∈ {0, 2, 4, . . ., 62}, at the expense of 4 elliptic-curve doublings.The table then contains 8 • 32 = 256 curve points (aside from 0B, which is not stored).Each point is represented as three integers (see below) modulo 2 255 −19.Each integer in turn is represented as five 8-byte words.Overall the table consumes 30 kilobytes of RAM.
We could instead use radix 32 or larger.Radix 32 would involve twice as many table loads (since we load all table entries), and twice as much arithmetic to combine table entries, but these costs would be outweighed by the benefit of fewer elliptic-curve additions.A more serious concern is that the table would be twice as large, consuming 60KB instead of 30KB.This is only a minor issue for a typical cryptographic speed test on our target CPUs (each Nehalem/Westmere core has its own fast 256KB L2 cache efficiently handling our sequential loads), but 30KB is clearly more attractive inside a larger application that needs to fit several different subroutines into L2 cache.
In the opposite direction, we could chop the table in half again at the expense of 8 more doublings; we could also switch to radix 8, 4, or 2. These changes would also allow reasonably fast signing on much smaller CPUs.
Low level, part 2: elliptic-curve addition.We use extended coordinates for the twisted Edwards curve −x 2 + y 2 = 1 + dx 2 y 2 , as proposed by Hisil, Wong, Carter, and Dawson in [41].These coordinates are (X : Y : Z : T ) with XY = Z T representing x = X/Z and y = Y/Z .The addition formulas from [41, Section 3.1] are complete for our curve and use just 9 field multiplications to add a table entry (x 0 , y 0 ) into (X : Y : Z : T ).Note that these formulas rely on the −1 in −x 2 ; this is why EdDSA uses the −1 twist.
One of the field multiplications is a multiplication by d = −121665/121666.We could replace this with a small number of multiplications by 121665 and 121666, as in [13,Section 6], but our current software treats d as a generic field element to save code size.We considered switching to a new curve using a small integer d (such as 646, which has a nearprime group order; note that we do not need the twist security of Curve25519), but decided that the resulting speedup was too small to justify departing from an established curve.
A different way to save a multiplication is to use the dual addition formulas from [41,Section 3.2].However, those formulas are not complete; they would require a detailed analysis of intermediate results in our computation to see whether any of the intermediate additions could trigger any of the exceptional cases in the formulas.
Instead we represent a precomputed point (x 0 , y 0 ) as (y 0 − x 0 , y 0 + x 0 , 2dx 0 y 0 ).These values depend only on x 0 and y 0 and are usually computed in the first part of addition in extended coordinates; providing them as part of the precomputation saves the multiplication by d, the multiplication x 0 y 0 , and 2 field additions, at the expense of increasing the storage requirements by a factor of 1.5.

Template attacks.
We comment that for hardware implementations this type of precomputation reduces the information exposed to template attacks trying to link multiple uses of the same precomputed point.
Consider, for example, an attacker monitoring the power consumption of a device with very limited memory.Assume that the device designer has reduced the table described above to just B, 2B, . . ., 8B at the expense of many doublings, and has saved more memory by storing a table entry as simply (x 0 , y 0 ).The addition formulas then begin by computing y 0 − x 0 , y 0 + x 0 , etc.If the same table entry is used again later then the same subtraction, addition, etc. will be performed again, resulting in exactly the same power trace.The attacker can therefore partition the loaded points into (at most) 16 different groups, obtaining 55 bits of information on average, as discussed in [31,Section 5.1.2].
Precomputing y 0 − x 0 , y 0 + x 0 , etc. guarantees (for these addition formulas) that all operations involving the precomputed point also involve the intermediate point, which varies unpredictably between different of the same table entry.A closer look at field arithmetic sometimes reveals lowerlevel operations that depend on only one input, such as the preliminary additions in Karatsuba's method; the results of those operations can be similarly precomputed.
Of course, there is much more to say about countermeasures to hardware side-channel attacks; we do not claim that any single countermeasure is adequate by itself.The software situation is simpler, since the side channels exposed to an attacker are much more limited.
Results.Overall we spend a bit less than 1000 cycles for each iteration of our main signing loop, i.e., for one table lookup and one elliptic-curve mixed addition.We also spend about 21000 cycles to invert Z at the end of the computation.The complete signing procedure for a short message takes 87548 cycles.

Verifying signatures
Fast signature verification seems considerably more difficult than fast signature generation, for two reasons.First, the verifier has to recover the elliptic-curve points A and R from the compressed points A and R. Second, checking S B = R+H (R, A, M)A seems to require not merely a fixedbase scalar multiplication S B but also a much more expensive variable-base scalar multiplication H (R, A, M)A.This section explains several techniques that we use to address these problems.

Fast decompression.
Recall that the encoding R of a point R = (x, y) contains a straightforward encoding of y but contains only a sign bit for x.One must therefore recover x via the equation x = ± (y 2 − 1)/(dy 2 + 1); note that dy 2 +1 = 0 since −d is not a square.The division and square root here seem to involve two exponentiations, about twice as expensive as the usual Weierstrass-curve decompression.
Of course, we could use Montgomery's trick to merge the two divisions involved in decompressing two points, but two square roots and a division are still more expensive than two Weierstrass-curve decompressions.We could also skip the compression and decompression for applications willing to use 64-byte keys and 96-byte signatures; but we think that 32-byte keys and 64-byte signatures are considerably more attractive.
Fast single-signature verification.To verify a single signature we use standard techniques for double-scalar multiplication to compute S B − H (R, A, M)A, and we then check whether the result is the same as R. (We actually check whether the encoding of the result is the same as the encoding of R, so that we can skip decompression of R.) The speed of Edwards-curve addition, especially with the −1 twist, makes these techniques particularly efficient; using the tables discussed in Section 4 does not seem to offer any advantage.This computation fits in very little space.
We have also considered the verification method suggested by Antipa, Brown, Gallant, Lambert, Struik, and Vanstone in [7], but our very efficient elliptic-curve arithmetic makes the overheads in this method -extra decompression and a Euclidean computation -much more troublesome.In the batch context discussed below, the only extra overhead of the method of [7] would be the Euclidean computation, but the benefit would also be much smaller.
Fast batch verification.For any system bottlenecked by signature verification, the problem is not to verify one signature at a time, but to verify many signatures as quickly as possible.
Naccache, M'Raïhi, Vaudenay, and Raphaeli in [59, Section 2.2] proposed verifying a batch of linear signature equations by verifying a random linear combination of the equations.This proposal is not directly applicable to ElGamal, DSA, Schnorr, ECDSA, etc., because all of those systems require computing linear functions (to compute R) rather than merely verifying linear functions; but if R is transmitted instead of H (• • • ), as suggested in [59], then this problem disappears.
Unfortunately, the verification algorithm in [59] was quite slow: [59, Table 1] reported "29n" multiplications to verify n signatures from the same signer at a highly questionable 2 20 security level.If the same technique were adapted to ECDSA and increased to a 2 128 security level then it would require nearly 200 elliptic-curve additions for each signature from the same signer-somewhat faster than verifying each signature separately, but not much.
The followup paper [10] by Bellare, Garay, and Rabin proposed a more complicated verification technique using, e.g., 3200 multiplications to verify 100 exponentiations, or 6480 multiplications to verify 100 DSA signatures, both cases at a substandard 2 60 security level.See [10,Appendix A.1].The number of multiplications per signature begins to drop as the batch size grows towards 1000 -see [10, Figure 3] -but such large batches do not fit into cache on typical CPUs.
The unimpressive theoretical performance of these batchverification techniques can be traced directly to the naive exponentiation algorithms used in [59] and [10].We do much better by using random linear combinations, as in [59], together with state-of-the-art scalar-multiplication techniques.
Specifically, we start from a batch of (M i , A i , R i , S i ) where (R i , S i ) is an alleged signature of M i under key A i .We choose independent uniform random 128-bit integers z i , compute H i = H (R i , A i , M i ), and verify the equation by a multi-scalar multiplication.It is important to choose new independent integers z i uniformly at random in each batch verification.There are two reasonable choices of scalar-multiplication methods here, namely Pippenger's method in [65] and the Bos-Coster method reported in [27, Section 4].We use the Bos-Coster method because it fits into less storage; see below for details.Note that z i is not secret, so side-channel protection is not required.The number of scalars here is 2n+1.Half of the scalars are 253-bit and half are 128-bit.If public keys appear repeatedly, the situation considered in [59] and [10], then we could save some time by merging the 253-bit scalars; this merging also explains why we do not use the similar signature equation S B = A + H (R, A, M)R, which would allow only merging 128-bit scalars.Our software focuses on general-purpose verification with arbitrary keys.
If verification succeeds then we are confident that 8S i B = 8R i + 8H i A i for each i, i.e., that each signature is valid.The logic is simple: the differences P i = 8R i + 8H i A i − 8S i B are elements of a cyclic group of prime order , and have been verified to satisfy i z i P i = 0; but this equation cannot hold with probability more than 2 −128 unless all P i = 0.For example, if P 4 is nonzero then the choices of z 1 , z 2 , z 3 , z 5 , z 6 , . . .determine exactly one choice of z 4 satisfying i z i P i = 0, and z 4 has chance at most 2 −128 of matching that choice.
If verification fails then there must be at least one invalid signature.We then fall back to verifying each signature separately.There are several techniques to identify a small number of invalid signatures in a batch, but all known techniques become slower than separate verification as the number of invalid signatures increases; separate verification provides the best defense against denial-of-service attacks.
We keep the scalars n i in a heap so that identifying the two largest scalars is easy.The usual method to replace the root of a heap is top-down, starting at the root and swapping down for a variable number of steps.We instead use Floyd's 1964 bottom-up algorithm discussed in [48, (often miscredited to [25] and [79]): start at the root, swap down to the bottom, and then swap up for a variable number of steps.This has the advantage of somewhat reducing the number of comparisons, and the not-so-well-known advantage of drastically reducing the number of branches, especially for balanced heaps.
Results.The complete verification procedure takes under 134000 cycles per signature for batch size 64.Our batchverification software is included in, although not yet benchmarked by, the public eBATS benchmarking framework.
Doubling the batch size to 128 no longer fits into L1 cache but still improves performance on our target CPU, taking under 125000 cycles per signature.Larger batches take under 114000 cycles per signature while still fitting into L2 cache.Our software spends about 44000 cycles on decompression, so verification of uncompressed signatures (32 extra bytes) using uncompressed public keys (another 32 extra bytes) would take only about 81000 cycles for batch size 128, even faster than signing.However, in this paper we have emphasized the performance that we obtain without using so much space.
Open Access This article is distributed under the terms of the Creative Commons Attribution License which permits any use, distribution, and reproduction in any medium, provided the original author(s) and the source are credited.
8 • 16 i B and use arithmetic operations, without branching, to combine the table entries into 16 i |r i |B.We similarly use arithmetic operations to compute 16 i r i B from 16 i |r i |B and −16 i |r i |B.