]>
Elliptic Curve Cryptography (ECC) Nothing Up My Sleeve (NUMS) Curves and Curve GenerationMicrosoftOne Microsoft WayRedmondWA98115USbenblack@microsoft.comNXP SemiconductorsInterleuvenlaan 803001 LeuvenBelgiumjoppe.bos@nxp.comMicrosoft ResearchOne Microsoft WayRedmondWA98115UScraigco@microsoft.comMicrosoft ResearchOne Microsoft WayRedmondWA98115USplonga@microsoft.comMicrosoft ResearchOne Microsoft WayRedmondWA98115USmnaehrig@microsoft.com
General
Network Working Groupelliptic curvecryptographyecctlsnumsThis memo describes a family of deterministically generated Nothing Up My Sleeve (NUMS) elliptic curves over prime fields offering high practical security in cryptographic applications, including Transport Layer Security (TLS) and X.509 certificates. The domain parameters are defined for both classical Weierstrass curves, for compatibility with existing applications, and modern twisted Edwards curves, allowing further efficiency improvements for a given security level.Since the initial standardization of elliptic curve cryptography (ECC) in there has been significant progress related to both efficiency and security of curves and implementations. Notable examples are algorithms protected against certain side-channel attacks, different 'special' prime shapes which allow faster modular arithmetic, and a larger set of curve models from which to choose. There is also concern in the community regarding the generation and potential weaknesses of the curves defined in .This memo describes a set of elliptic curves for cryptography, defined in which have been specifically chosen to achieve extremely high performance, security, and attack resistance. These curves are deterministically generated based on algorithms defined in this document and without any hidden parameters or reliance on randomness, hence they are called Nothing Up My Sleeve (NUMS) curves. The domain parameters are defined for both classical Weierstrass curves, for compatibility with existing applications while delivering better performance and stronger security, and modern twisted Edwards curves, allowing even further efficiency improvements for a given security level.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.This RFC specifies elliptic curve domain parameters over prime fields GF(p) with p having a length of 256, 384, and 512 bits, in both Weierstrass and twisted Edwards form. These parameters were generated in a transparent and deterministic way and have been shown to resist current cryptanalytic approaches. Furthermore, this document identifies the security and implementation requirements for the parameters, and describes the methods used for the deterministic generation of the parameters.This document addresses neither the cryptographic algorithms to be used with the specified parameters nor their application in other standards. However, it is consistent with the following RFCs that specify the usage of ECC in protocols and applications: for X.509 certificates for XML signatures for TLS for IKE for CRLs for cryptographic message syntax (CMS)Applicability to multiple cryptographic algorithms without transformation, in particular key exchange (e.g. ECDHE) and digital signature algorithms (e.g., ECDSA, Schnorr).Multiple security levels using the same curve generation algorithm with only a security parameter change. The curve generation algorithm must be extensible to any security level.Ability to use pre-computation for increased performance. In particular, speed-up in key generation is important when a curve is used with ephemeral key exchange algorithm, such as ECDHE.The bit length of prime and order of curves for a given security level MUST be divisible by 8. Specifically, constructions such as NIST P-521 are to be avoided as they introduce interoperability and implementation problems.For each curve type (twisted Edwards or Weierstrass) at a specific specific security level:The domain parameters SHALL be generated in a simple, deterministic manner, without any secret or random inputs. The derivation of the curve parameters is defined in .The curve SHALL NOT restrict the scalars to a small subset. Using full-set scalars prevents implementation pitfalls that might otherwise go unnoticed.The curve selection SHALL include prime order curves with cofactor 1 only. Composite order curves require changes in protocols and in implementations. Additionally, implementations for composite order curves must thwart subgroup attacks.The trace of Frobenius MUST NOT be in {0, 1} in order to rule out the attacks described in , , and , as in .MOV Degree: the embedding degree k MUST be greater than (r - 1) / 100, as in .CM Discriminant: discriminant D MUST be greater than 2^100, as in .Throughout this document, the following notation is used:In addition to the discussion in the requirements, , , and the other reference documents on EC security, users SHOULD match curves with cryptographic functions of similar strength.The authors have no knowledge about any intellectual property rights that cover the usage of the domain parameters defined herein. However, readers should be aware that implementations based on these domain parameters may require use of inventions covered by patent rights.This memo includes no request to IANA.
&RFC2119;
&RFC2629;
&RFC3279;
&RFC3552;
&RFC4050;
&RFC4492;
&RFC4754;
&RFC5226;
&RFC5480;
&RFC5753;
Selecting Elliptic Curves for Cryptography: An Efficiency and Security AnalysisMicrosoft ResearchMicrosoft ResearchMicrosoft ResearchMicrosoft ResearchElliptic Curve Cryptography in PracticeThe discrete logarithm problem on elliptic curves of trace oneFermat quotients and the polynomial time discrete log algorithm for anomalous elliptic curvesEvaluation of discrete logarithms on some elliptic curvesECC Brainpool Standard Curves and Curve GenerationECC BrainpoolSafeCurves: choosing safe curves for elliptic-curve cryptographyRecommended Elliptic Curves for Federal Government UseNational Institute of StandardsSEC 1: Elliptic Curve CryptographyCerticom ResearchThis section describes the generation of the curve parameters, namely the base
field prime p, the curve parameters b and d for the Weierstrass and twisted
Edwards curves, respectively, and a generator point P of the prime order
subgroup of the elliptic curve.For a given bitlength s in {256, 384, 512}, a prime p is selected
as a pseudo-Mersenne prime of the form p = 2^s - c for a positive integer
c. Each prime is determined by the smallest positive integer c such that
p = 2^s - c is prime and p = 3 mod 4.For a given bitlength s in {256, 384, 512} and a corresponding prime p = 2^s -
c selected according to Section A.1, the elliptic curve Eb in short Weierstrass
form is determined by the element b from GF(p), different from -2,2 with
smallest absolute value (when represented as an integer in the interval
[-(p - 1) / 2, (p - 1) / 2]) such that both group orders rb and rb' are prime,
and the group order rb < p, i.e. tb > 1. In addition, care must be taken to ensure the MOV degree and CM discriminant requirements from are met.For a given bitlength s in {256, 384, 512} and a corresponding prime p = 2^s -
c selected according to Section A.1, the elliptic curve Ed in twisted Edwards
form is determined by the element d from GF(p), different from -1,0 with
smallest value (when represented as a positive integer) such that both
subgroup orders rd and rd' are prime, and the group order 4 * rd < p, i.e. td > 1. In addition, care must be taken to ensure the MOV degree and CM discriminant requirements from are met.The generator points on all six curves are selected as the points of order rb
and rd, respectively, with the smallest value for x(P) when represented as a
positive integer.