Secure elliptic curves: security engineering perspective – Elliptic Curves
8.4.5 Secure elliptic curves: security engineering perspective
As illustrated by the Dual_EC_DRBG example, the mathematical perspective on the security of elliptic curves is not sufficient. As cryptographers Dan Bernstein and Tanja Lange explain in their SafeCurves initiative [22], preventing backdoors in cryptographic mechanisms based on elliptic curves requires rigidity.
Rigidity refers to a curve generation process where the number of curves that can be generated is limited or, to put it in the words of Bernstein and Lange, where the ECC security story is as simple as possible.
With rigidity, Eve can only succeed if some curve in that limited set is vulnerable to a secret attack known only to Eve. In contrast, without rigidity, Eve can simply generate curves until she finds one that is vulnerable to her secret attack.
A fully rigid curve generation process must be therefore completely explainable. An example given in [22] is a curve generation process where the following applies:
- Only prime numbers larger than 2224 are used for security reasons
- The smallest prime larger than 2224 is chosen for efficiency reasons
- Only curves of the shape y2 = x3 −3x+b are considered for efficiency reasons
- The smallest positive integer b is used that meets the security criteria
Similarly, rigidity must also be used when selecting elliptic curve-based parameters for cryptographic algorithms like points P and Q used in Dual_EC_DRBG. Only then is it possible for parties other than the algorithm designers to arrive at a reasonable degree of confidence that the algorithm has no backdoors. We’ll now take a look at the specific curves defined in TLS 1.3.
8.5 Elliptic curves in TLS 1.3
Elliptic curves provide one option within the TLS handshake protocol for server Alice and client Bob to agree on a shared secret. First of all, Alice and Bob have to negotiate whether they want to use elliptic curves at all, and which curve they are going to use.
The supported˙groups extension that client Bob sends to server Alice in his ClientHello message to negotiate the cryptographic parameters contains a list of groups that Bob wants to use to establish the secret key with Alice via ECDH. The list is ordered according to Bob’s preference in descending order.
Technically, the supported˙groups extension has a field called extension˙data. This field contains a value of the type NamedGroupList, defined as shown in Listing 8.1.
Listing 8.1: NamedGroupList in supported_groups extension
struct {
NamedGroup named_group_list<2..2^16-1>;
} NamedGroupList;
Each entry in NamedGroupList is a named group supported in the TLS 1.3 standard. When elliptic curve cryptography is used, these named groups refer to specific elliptic curves that Alice and Bob can use to establish their secret shared key via ECDH when using TLS 1.3. The valid choices for a NamedGroup – including the supported elliptic curves – are defined as shown in Listing 8.2.
Listing 8.2: Named finite fields and elliptic curves supported in TLS 1.3
enum {
/* Elliptic Curve Groups (ECDHE) */
obsolete_RESERVED(0x0001..0x0016),
secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019),
obsolete_RESERVED(0x001A..0x001C),
x25519(0x001D), x448(0x001E),
/* Finite Field Groups (DHE) */
ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102), ffdhe6144(0x0103), ffdhe8192(0x0104),
/* Reserved Code Points */
ffdhe_private_use(0x01FC..0x01FF),
ecdhe_private_use(0xFE00..0xFEFF),
obsolete_RESERVED(0xFF01..0xFF02),
(0xFFFF)
} NamedGroup;
The values secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019), x25519(0x001D), and x448(0x001E) indicate the named elliptic curves supported by the TLS 1.3 standard. These curves are defined either in the Federal Information Processing Standards (FIPS) publication FIPS 186-4 Digital Signature Standard (DSS) [128] or in Internet Research Task Force (IRTF) RFC 7748 Elliptic Curves for Security [86].
The value range ecdhe˙private˙use(0xFE00..0xFEFF) is reserved for private use as defined in RFC 8126. RFC 8126 outlines the guidelines for writing an IANA considerations section in RFCs. These guidelines ensure that parameter values used for the protocol’s extensibility have no conflicting uses.
For all IETF protocols, the role of a central record keeper that coordinates the allocation of these values and, by doing this, ensures interoperability, is filled by the Internet Assigned Numbers Authority (IANA).
Any parameters or values declared as for private use according to RFC 8126 are for private or local use only, with the type and purpose defined by the local site and IANA makes no attempt to prevent multiple sites from using the same value in different ways. Thus, TLS 1.3 theoretically even allows Alice and Bob to choose their own elliptic curves (which is not advisable from a cryptographic point of view unless Alice and Bob know exactly what they are doing).
The obsolete˙RESERVED value ranges seen in Listing 8.2 exist for legacy reasons. These values refer to groups used in previous TLS versions. However, these groups – mostly specific elliptic curves from previous TLS versions – have various practical or theoretical weaknesses, or have been used very little in the past. As a result, the TLS 1.3 standard considers these curves obsolete. As a result, if Alice and Bob want to use TLS version 1.3, they are not permitted to use the insecure obsolete˙RESERVED curves.