`94105`

`94105`

`22031`

```
```Scalars are assumed to be randomly generated bytes. For X25519, in order to decode 32 random bytes as an integer scalar, set the three least significant bits of the first byte and the most significant bit of the last to zero, set the second most significant bit of the last byte to 1 and, finally, decode as little-endian. This means that resulting integer is of the form 2^254 plus eight times a value between 0 and (2^251)-1 (inclusive). Likewise, for X448, set the two least significant bits of the first byte to 0, and the most significant bit of the last byte to 1. This means that the resulting integer is of the form 2^447 plus four times a value between 0 and (2^445)-1 (inclusive).
```
```To implement the X25519(k, u) and X448(k, u) functions (where k is the scalar and u is the u-coordinate) first decode k and u and then perform the following procedure, which is taken from and based on formulas from . All calculations are performed in GF(p), i.e., they are performed modulo p. The constant a24 is (486662 - 2) / 4 = 121665 for curve25519/X25519 and (156326 - 2) / 4 = 39081 for curve448/X448.
(Note that these formulas are slightly different from Montgomery's original paper. Implementations are free to use any correct formulas.)
Finally, encode the resulting value as 32 or 56 bytes in little-endian order. For X25519, the unused, most-significant bit MUST be zero.
The cswap function SHOULD be implemented in constant time (i.e. independent of the swap argument). For example, this can be done as follows:
Where mask(swap) is the all-1 or all-0 word of the same length as x_2 and x_3, computed, e.g., as mask(swap) = 0 - swap.
X25519 and X448 are designed so that fast, constant-time implementations are easier to produce. The procedure above ensures that the same sequence of field operations is performed for all values of the secret key, thus eliminating a common source of side-channel leakage. However, this alone does not prevent all side-channels by itself. It is important that the pattern of memory accesses and jumps not depend on the values of any of the bits of k. It is also important that the arithmetic used not leak information about the integers modulo p, for example by having b*c be distinguishable from c*c. On some architectures, even primitive machine instructions, such as single-word division, can have variable timing based on their inputs.
Side-channel attacks are an active research area that still sees significant, new results. Implementors are advised to follow this research closely.
Two types of tests are provided. The first is a pair of test vectors for each function that consist of expected outputs for the given inputs. The inputs are generally given as 64 or 112 hexadecimal digits that need to be decoded as 32 or 56 binary bytes before processing.
The second type of test vector consists of the result of calling the function in question a specified number of times. Initially, set k and u to be the following values:
For each iteration, set k to be the result of calling the function and u to be the old value of k. The final result is the value left in k.

```
```
The X25519 function can be used in an elliptic-curve Diffie-Hellman (ECDH) protocol as follows:
Alice generates 32 random bytes in f[0] to f[31] and transmits K_A = X25519(f, 9) to Bob, where 9 is the u-coordinate of the base point and is encoded as a byte with value 9, followed by 31 zero bytes.
Bob similarly generates 32 random bytes in g[0] to g[31] and computes K_B = X25519(g, 9) and transmits it to Alice.
Using their generated values and the received input, Alice computes X25519(f, K_B) and Bob computes X25519(g, K_A).
Both now share K = X25519(f, X25519(g, 9)) = X25519(g, X25519(f, 9)) as a shared secret. Both MUST check, without leaking extra information about the value of K, whether K is the all-zero value and abort if so (see below). Alice and Bob can then use a key-derivation function that includes K, K_A and K_B to derive a key.
The check for the all-zero value results from the fact that the X25519 function produces that value if it operates on an input corresponding to a point with order dividing the co-factor, h, of the curve. This check is cheap and so MUST always be carried out. The check may be performed by ORing all the bytes together and checking whether the result is zero as this eliminates standard side-channels in software implementations.
Test vector:
The X448 function can be used in an ECDH protocol very much like the X25519 function.
If X448 is to be used, the only differences are that Alice and Bob generate 56 random bytes (not 32) and calculate K_A = X448(f, 5) or K_B = X448(g, 5) where 5 is the u-coordinate of the base point and is encoded as a byte with value 5, followed by 55 zero bytes.
As with X25519, both sides MUST check, without leaking extra information about the value of K, whether the resulting shared K is the all-zero value and abort if so.
Test vector:
The security level (i.e. the number of "operations" needed for a brute-force attack on a primitive) of curve25519 is slightly under the standard 128-bit level. This is acceptable because the standard security levels are primarily driven by much simplier, symmetric primitives where the security level naturally falls on a power of two. For asymmetric primitives, rigidly adhering to a power-of-two security level would require compromises in other parts of the design, which we reject. Additionally, comparing security levels between types of primitives can be misleading under common threat models where multiple targets can be attacked concurrently .
The ~224-bit security level of curve448 is a trade-off between performance and paranoia. Large quantum computers, if ever created, will break both curve25519 and curve448, and reasonable projections of the abilities of classical computers conclude that curve25519 is perfectly safe. However, some designs have relaxed performance requirements and wish to hedge against some amount of analytical advance against elliptic curves and thus curve448 is also provided.
This document has no actions for IANA.
This document merges draft-black-rpgecc-01 and draft-turner-thecurve25519function-01. The following authors of those documents wrote much of the text and figures but are not listed as authors on this document: Benjamin Black, Joppe W. Bos, Craig Costello, Patrick Longa, Michael Naehrig and Watson Ladd.
The authors would also like to thank Tanja Lange, Rene Struik, Rich Salz, Ilari Liusvaara, Deirdre Connolly, Simon Josefsson, Stephen Farrell and Georg Nestmann for their reviews and contributions.
The X25519 function was developed by Daniel J. Bernstein in .

```
```
&RFC2119;
&RFC6090;
Understanding brute force
The discrete logarithm problem on elliptic curves of trace one
Fermat quotients and the polynomial time discrete log algorithm for anomalous elliptic curves
Evaluation of discrete logarithms on some elliptic curves
Reducing elliptic curve logarithms to logarithms in a finite field
ECC Brainpool Standard Curves and Curve Generation
ECC Brainpool
SafeCurves: choosing safe curves for elliptic-curve cryptography
Recommended Elliptic Curves for Federal Government Use
National Institute of Standards
SEC 1: Elliptic Curve Cryptography
Certicom Research
Curve25519 -- new Diffie-Hellman speed records
Speeding the Pollard and elliptic curve methods of factorization
High-speed high-security signatures
Ed448-Goldilocks, a new elliptic curve
This section specifies the procedure that was used to generate the above curves; specifically it defines how to generate the parameter A of the Montgomery curve y^2 = x^3 + A*x^2 + x. This procedure is intended to be as objective as can reasonably be achieved so that it's clear that no untoward considerations influenced the choice of curve. The input to this process is p, the prime that defines the underlying field. The size of p determines the amount of work needed to compute a discrete logarithm in the elliptic curve group and choosing a precise p depends on many implementation concerns. The performance of the curve will be dominated by operations in GF(p) so carefully choosing a value that allows for easy reductions on the intended architecture is critical. This document does not attempt to articulate all these considerations.
The value (A-2)/4 is used in several of the elliptic curve point arithmetic formulas. For simplicity and performance reasons, it is beneficial to make this constant small, i.e. to choose A so that (A-2) is a small integer which is divisible by four.
For each curve at a specific security level:
The trace of Frobenius MUST NOT be in {0, 1} in order to rule out the attacks described in , , and , as in and .
MOV Degree : the embedding degree k MUST be greater than (r - 1) / 100, as in and .
CM Discriminant: discriminant D MUST be greater than 2^100, as in .

For primes congruent to 1 mod 4, the minimal cofactors of the curve and its twist are either {4, 8} or {8, 4}. We choose a curve with the latter cofactors so that any algorithms that take the cofactor into account don't have to worry about checking for points on the twist, because the twist cofactor will be the smaller of the two.
To generate the Montgomery curve we find the minimal, positive A value, such that A > 2 and (A-2) is divisible by four and where the cofactors are as desired. The find1Mod4 function in the following Sage script returns this value given p:
```
```

```
```
For a prime congruent to 3 mod 4, both the curve and twist cofactors can be 4 and this is minimal. Thus we choose the curve with these cofactors and minimal, positive A such that A > 2 and (A-2) is divisible by four. The find3Mod4 function in the following Sage script returns this value given p:
```
```

```
```
The base point for a curve is the point with minimal, positive u value that is in the correct subgroup. The findBasepoint function in the following Sage script returns this value given p and A:
```
```

```
```

```
```

```
```

```
```