Hybrid ECDHE-SIDH Key Exchange for TLSMozillafranziskuskiefer@gmail.comCloudflarekris@cloudflare.com
IRTF
Internet-DraftThis draft specifies a TLS key exchange that combines the post-quantum key
exchange, Supersingular elliptic curve isogenie diffie-hellman (SIDH), with
elliptic curve Diffie-Hellman (ECDHE) key exchange.Supersingular elliptic curve isogenie diffie-hellman (SIDH) has been proposed
as a diffie-hellman like key-exchange protocol secure against quantum
computers.
Because there’s not enough confidence in the security of SIDH yet it should only
be used in combination with a classical key-exchange scheme.This document defines a way to combine with the ECDHE key exchanges
defined in for the TLS 1.3
key-exchange.x25519 is combined with sidh503 and x448 is combined with sidh751.Both handshake partners have to compute the SIDH values in addition to the ECDHE
values, which requires additional time for computation.
The handshake messages also get larger because the SIDH values are added (see for details).x25519 and x448 denote the ECDHE algorithms defined over the respective curve
from .
sidh503 and sidh751 denote the SIDH algorithms defined using a prime of bit-length
503 and 751 respectively.The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,
“SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this
document are to be interpreted as described in BCP 14
when, and only when, they appear in all capitals, as shown here.A hybrid key exchange takes the output of two separate key exchanges and mixes
the results in a secure way.The ECDHE and SIDH shared secrets are calculated independently. The shared
secret for ECDHE-SIDH is then the concatenation of the ECDHE and the SIDH shared
secrets. For x25519sidh503 for example this isThe HKDF-Extract step used by TLS is relied on to combine entropy from both
secrets.The ECDHE shared secret calculation is performed as described in Section 7.4.2 of .This document uses primes p503 and p751 defined in and for
sidh503 and sidh751. See for details on how to compute key-exchange
messages and the shared secret.
Optimised versions of the algorithms mentioned here might be used.Each element (c=a+b*i) of the underlying quadratic field GF(p^2) is encoded as
an array of bytes in little-endian order, i.e., the least significant octet
appears first, where each element a,b from GF(p) is encoded using itoos from
Section 1.2.6.
In particular, an element of GF(p) is converted towith n 63 for p503 and 94 for p751. The octet representation of each element
is then the concatenation of e_i in little endian, i.e. e_0||...||e_(n-1),
and the octet representation of element c is the concatenation of a and b,
a||b.See fp2toos Section 1.2.6 to 1.2.8 for details.After choosing a private key each party computes its public key (P, Q, R) using
isogen_l from Section 1.3.5 and converts each element into octets (cf. ).See pktoos from Section 1.2.9 for details on converting the public
key to octets.The SIDH shared secret is calculated as described in Section 1.3.6 of
using isoex_l.Calculating SIDH shared secret requires each side to use isogenies of different
degree. This document assumes parameterizations as described in , which
is based on 4- and 3-power degree isogenies.
In order to calculate the shared secret, the client always generates an ephemeral
key pair based on 4-power degree isogenies. Accordingly, the server always
generates an ephemeral key pair based on 3-power degree isogenies.The shared secret is a j-invariant and therefore an element of GF(p^2).
It is converted to octets as described in .See fp2toos Section 1.2.6 to 1.2.8 for details.
All values are encoded without length prefixes or separators.This document extends the enum of NamedGroups to use in the supported_groups
extension from TLS 1.3 Section 4.2.7.
The new codepoint for the “Supported Groups Registry” is:This document defines ECDHE-SIDH parameters to use in the key_share extension
from TLS 1.3 (see Section 4.2.8 of ).ECDHE parameters for both clients and servers are encoded in the key_exchange
field of a KeyShareEntry as described in Section 4.2.8 of and
. SIDH parameters are appended to this value.In particular, the contents are the serialised value of the following struct:X is the public point from x25519 or x448 as described in .P, Q, and R are the binary representations of three field elements over
GF(p503^2) and GF(p751^2) respectively from the public SIDH key values as
described in .
All values in the struct are encoded without length prefixes or separators.Implementers MUST perform the checks to verify the SIDH public key as
specified in Section 9 of .Security of SIDH is based on the isogeny walk problem, assuming elliptic
curves between isogenies are supersingular (see chapter 4.1).
Algorithms solving this problem as well as usage of isogenies as drop-in
replacement for Diffie-Hellman are relatively young area of research.
Therefore the security behind the ECDHE-SIDH handshake does not rely on the
security of SIDH exclusively.Idea behind ECDHE-SIDH hybrid scheme is to combine an existing key-agreement
algorithm with what’s believed to be a quantum-resistant one. When large
quantum computers are available they will be able to break both x25519 and
x448. In this case the ECDHE-SIDH scheme is still safe assuming SIDH is secure.
On the other hand, if SIDH is found to be flawed, the hybrid scheme is still
secure against classical attacks assuming security of x25519/x448. Security
estimates for classical and quantum computers are provided in table below
based on and . Chapter 1 provides introduction
to quantum resource estimates.SchemeClassicalQuantumNIST PQ categoryx25519sidh503128-bit64-qubit1x448sidh751224-bit96-qubit3As described in it is possible to perform active attacks on
static-static or non-interactive variants of the SIDH scheme. The
countermeasure for this attack was described in . Research proposes
so-called “indirect key validation”, using Fujisaki-Okamoto type transform.
However, using this transform is impractical and thus SIDH can be
considered secure only if used for ephemeral keys. A more detailed
discussion can be found in .Security against side-channel attacks is described in . Implementers
are encouraged to use a constant-time implementation.The security of the described key exchange relies on the security, in
particular the collision resistance, of the used key-derivation function.
TLS 1.3 uses HKDF as its key-derivation function.
It is therefore important that the hash function used in HKDF is
collision-resistant.This section gives a test vectors for x25519sidh503.Client SIDH-ECDHE public key:Client SIDH-ECDHE private key:Client Hello:Server selected KE = (EC)DHE. Group = 261.Server SIDH-ECDHE public key:Server SIDH-ECDHE private key:Handshake secrets tls13 s hs traffic:Handshake secrets tls13 c hs traffic:Server Handshake:Client finished handshake:Shared secret (server & client):TODO: register the codepointsElliptic 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.HMAC-based Extract-and-Expand Key Derivation Function (HKDF)This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes.The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.Towards quantum-resistant cryptosystems from supersingular elliptic curve isogenieSupersingular Isogeny Key EncapsulationKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Efficient algorithms for supersingular isogeny Diffie-HellmanOn the security of supersingular isogeny cryptosystemsFailure is not an Option: Standardization Issues for Post-Quantum Key AgreementSoK: The Problem Landscape of SIDHQuantum Resource Estimates for Computing Elliptic Curve Discrete LogarithmsMartin Thomson
Mozilla
mt@mozilla.com