One document matched: draft-josefsson-tls-curve25519-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY rfc2863 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2863.xml">
<!ENTITY rfc3418 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3418.xml">
<!ENTITY rfc4181 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4181.xml">
<!ENTITY rfc2578 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2578.xml">
<!ENTITY rfc2579 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2579.xml">
<!ENTITY rfc2580 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2580.xml">
<!ENTITY rfc3410 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3410.xml">
<!ENTITY rfc4492 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4492.xml">
<!ENTITY rfc5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY rfc6347 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6347.xml">
<!ENTITY rfc7027 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7027.xml">
]>
<?rfc symrefs="yes"?>
<rfc category="info"
updates="4492, 5246"
ipr="trust200902"
docName="draft-josefsson-tls-curve25519-05" >
<front>
<title abbrev="Curve25519 for TLS">
Curve25519 for ephemeral key exchange
in Transport Layer Security (TLS)
</title>
<author fullname="Simon Josefsson" initials="S." surname="Josefsson">
<organization>SJD AB</organization>
<address>
<email>simon@josefsson.org</email>
</address>
</author>
<author fullname="Manuel Pegourie-Gonnard"
initials="M." surname="Pegourie-Gonnard">
<organization>Independent / PolarSSL</organization>
<address>
<email>mpg@elzevir.fr</email>
</address>
</author>
<date year="2014" />
<keyword>TLS, Elliptic Curve Cryptography, Diffie-Hellman,
Curve25519</keyword>
<abstract>
<t>This document specifies the use of Curve25519 for ephemeral key
exchange in the Transport Layer Security (TLS) protocol, as well
as its DTLS variant. It updates RFC 5246 (TLS 1.2) and RFC 4492
(Elliptic Curve Cryptography for TLS).</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>In <xref target="Curve25519" />, a new elliptic curve
function for use in cryptographic applications was specified.
Curve25519 is a Diffie-Hellman function designed with
performance and security in mind.</t>
<t><xref target="RFC4492" /> defines the usage of elliptic
curves for authentication and key agreement in TLS 1.0 and TLS
1.1, and these mechanisms are also applicable to TLS 1.2 <xref
target='RFC5246' />. The use of ECC curves for key exchange
requires the definition and assignment of additional NamedCurve
IDs. This document specify that value for Curve25519, as well
as the minor changes in key selection and representation that
are required to accommodate for Curve25519's slightly different
nature.</t>
<t>This document only describes usage of Curve25519 for ephemeral
key exchange (ECDHE). It does not define its use for signature,
since the primitive considered here is a Diffie-Hellman
function; the related signature scheme, Ed25519, is outside the
scope of this document. The use of Curve25519 with long-term
keys embedded in X.509 certificates is also out of scope
here.</t>
<section title="Requirements Terminology">
<t>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 <xref target="RFC2119" />.</t>
</section>
</section>
<section title="Data Structures and Computations">
<section anchor="crypto" title="Cryptographic computations">
<t>All cryptographic computations are done using the Curve25519
function defined in <xref target="Curve25519" />. In this memo,
this function is considered as a black box that takes as input
a (secret key, public key) pair and outputs a public key.
Public keys are defined as strings of 32 bytes. Secret keys are
defined as 255 bits numbers such as the high-order bit (bit
254) is set, and the three lowest-order bits are unset. In
addition, a common public key, denoted by G, is shared by
all users.</t>
<t>An ECDHE key exchange using Curve25519 goes as follows. Each
party picks a secret key d uniformly at random and computes the
corresponding public key x = Curve25519(d, G). Parties exchange
their public keys (see <xref target="ECPointFormat" />) and
compute a shared secret as x_S = Curve25519(d, x_peer). This
shared secret is used directly as the premaster secret, which
is always exactly 32 bytes when ECDHE with Curve25519 is
used.</t>
<t>A complete description of the Curve25519 function, as well as
a few implementation notes, are provided in <xref
target="curve25519func" />.</t>
</section>
<section title="Curve negotiation and new NamedCurve value"
anchor="NamedCurve" >
<t>Curve negotiation uses the mechanisms introduced by <xref
target="RFC4492" />, without modification except the
following restriction: in the ECParameters structure, only
the named_curve case can be used with Curve25519.
Accordingly, arbitrary_explicit_prime_curves in the Supported
Curves extension does not imply support for Curve25519, even
though the Curve25519 function happens to be defined using
an elliptic curve over a prime field.</t>
<t>The reason for this restriction is that explicit_prime is
only suited to the so-called Short Weierstrass representation
of elliptic curves, while Curve25519 uses a different
representation for performance and security reasons.</t>
<t>This document adds a new NamedCurve value for Curve25519 as
follows.</t>
<figure>
<artwork><![CDATA[
enum {
Curve25519(TBD1),
} NamedCurve;
]]></artwork>
</figure>
<t>Curve25519 is suitable for use with DTLS <xref
target='RFC6347'/>.</t>
<t>Since Curve25519 is not designed to be used in signatures,
clients who offer ECDHE_ECDSA ciphersuites and advertise
support for Curve25519 in the elliptic_curves ClientHello
extension SHOULD also advertise support for at least one
curve suitable for ECDSA. Servers MUST NOT select an
ECDHE_ECDSA ciphersuite if there are no common curves
suitable for ECDSA.</t>
</section>
<section
title="Public Key representation and new ECPointFormat value"
anchor="ECPointFormat">
<t>This section defines a new point format suitable to
encode Curve25519 public keys, as well as an identifier to
negotiate this new format in TLS, and includes guidance on
their use.</t>
<t>The curves defined in <xref target="RFC4492" /> define a
public key as a point on the curve. In order to exchange
public keys, the points are serialized as a string of bytes
using one of the formats defined in <xref target="SEC1"/>.
These encodings begin with a leading byte identifying the
format, followed by a string of bytes, whose length is
uniquely determined by the leading byte and curve used.</t>
<t>Since Curve25519 public keys already are string of bytes,
no serialization is needed. However, a leading byte with value
0x41 is prepended to the public key to identify the format.
The goal, besides consistency with the SEC1 formats, is to
allow using other formats with Curve25519 in the future if
needed.</t>
<t>In order to negotiate this format in TLS, a new ECPointFormat
is defined as follows.</t>
<figure>
<artwork><![CDATA[
enum {
montgomery_x_le(TBD2),
} ECPointFormat;
]]></artwork>
</figure>
<t>This format is currently the only format defined for use with
Curve25519. Clients offering Curve25519 in the Supported
Elliptic Curves extension MUST also offer montgomery_x_le in
the Supported Point Format extension. Servers selecting
Curve25519 for key exchange MUST include montgomery_x_le in
their Supported Point Format extension. Servers willing to use
Curve25519 MUST NOT assume that the client supports the
montgomery_x_le format if the client did not advertise it
explicitly.</t>
<t>When included in a ServerKeyExchange or ClientKeyExchange
message, the public key is wrapped in an ECPoint structure as
defined in <xref target="RFC4492" />, whose payload is as
described above. For example, a public key with value 2A ...
2A appears on the wire as follows (including the length byte
of ECPoint.point).</t>
<figure>
<artwork><![CDATA[
21 41 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A
2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A
]]></artwork>
</figure>
</section>
<section title="Public key validation">
<t>With the curves defined by <xref target="RFC4492" />, each
party must validate the public key sent by its peer before
performing cryptographic computations with it. Failing to do
so allows attackers to gain information about the private key,
to the point that they may recover the entire private key in a
few requests, if that key is not really ephemeral.</t>
<t>Curve25519 was designed in a way that the result of
Curve25519(x, d) will never reveal information about d,
provided is was chosen as prescribed, for any value of x.</t>
<t>Let's define legitimate values of x as the values that can be
obtained as x = Curve25519(G, d') for some d, and call the
other values illegitimate. The definition of the Curve25519
function shows that legitimate values all share the following
property: the high-order bit of the last byte is not set.</t>
<t>Since there are some implementation of the Curve25519
function that impose this restriction on their input and
others that don't, implementations of Curve25519 in TLS SHOULD
reject public keys when the high-order bit of the last byte is
set (in other words, when the value of the leftmost byte is
greater than 0x7F) in order to prevent implementation
fingerprinting.</t>
<t>Other than this recommended check, implementations do not
need to ensure that the public keys they receive are
legitimate: this is not necessary for security with
Curve25519.</t>
</section>
</section>
<section title="IANA Considerations">
<t>IANA is requested to assign numbers for Curve25519 listed in
<xref target='NamedCurve' /> to the Transport Layer Security
(TLS) Parameters registry EC Named Curve <xref target='IANA-TLS'
/> as follows. </t>
<texttable>
<preamble></preamble>
<ttcol align='center'>Value</ttcol>
<ttcol align='center'>Description</ttcol>
<ttcol align='center'>DTLS-OK</ttcol>
<ttcol align='center'>Reference</ttcol>
<c>TBD1</c>
<c>Curve25519</c>
<c>Y</c>
<c>This doc</c>
<postamble></postamble>
</texttable>
<t>IANA is also requested to assign numbers for Curve25519 listed in
<xref target='ECPointFormat' /> to the Transport Layer Security
(TLS) Parameters registry EC Point Format <xref target='IANA-TLS'
/> as follows. </t>
<texttable>
<preamble></preamble>
<ttcol align='center'>Value</ttcol>
<ttcol align='center'>Description</ttcol>
<ttcol align='center'>DTLS-OK</ttcol>
<ttcol align='center'>Reference</ttcol>
<c>TBD2</c>
<c>montgomery_x_le</c>
<c>Y</c>
<c>This doc</c>
<postamble></postamble>
</texttable>
</section>
<section title="Security Considerations">
<t>The security considerations of <xref target="RFC5246" /> and
most of the security considerations of <xref target="RFC4492" />
apply accordingly.</t>
<t>Curve25519 is designed to facilitate the production of
high-performance constant-time implementations of the Curve25519
function. Implementors are encouraged to use a constant-time
implementation of the Curve25519 function. This point is of
crucial importance if the implementation chooses to reuse its
supposedly ephemeral key pair for many key exchanges, which some
implementations do in order to improve performance.</t>
<t>Curve25519 is believed to be at least as secure as
the secp256r1 curve defined in <xref
target="RFC4492" />, also know as NIST P-256. While the NIST
curves are advertised as being chosen verifiably at random, there
is no explanation for the seeds used to generate them. In
contrast, the process used to pick Curve25519 is fully documented
and rigid enough so that independent verification has been done.
This is widely seen as a security advantage for Curve25519, since
it prevents the generating party from maliciously manipulating
the parameters.</t>
<t>Another family of curves available in TLS, generated in a fully
verifiable way, is the Brainpool curves <xref target="RFC7027"
/>. Specifically, brainpoolP256 is expected to provide a level
of security comparable to Curve25519 and NIST P-256. However,
due to the use of pseudo-random prime, it is significantly
slower than NIST P-256, which is itself slower than Curve25519.</t>
<t>See <xref target="SafeCurves" /> for more comparisons between
curves.</t>
</section>
<section title="Acknowledgements">
<t>Several people provided comments and suggestions that helped
improve this document: Kurt Roeckx, Andrey Jivsov, Robert
Ransom, Rich Salz, David McGrew.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="Curve25519"
target="http://dx.doi.org/10.1007/11745853_14">
<front>
<title>
Curve25519: New Diffie-Hellman Speed Records
</title>
<author surname="Bernstein" initials="J."
fullname="Daniel J. Bernstein">
<organization></organization>
</author>
<date month="February" year="2006"/>
</front>
<seriesInfo name="LNCS" value="3958, pp. 207-228" />
</reference>
&rfc2119;
&rfc4492;
&rfc5246;
&rfc6347;
</references>
<references title="Informative References">
<reference anchor="IANA-TLS" target="http://www.iana.org/assignments/tls-parameters/tls-parameters.xml">
<front>
<title>Transport Layer Security (TLS) Parameters</title>
<author>
<organization>Internet Assigned Numbers Authority</organization>
</author>
<date month="" year=""/>
</front>
</reference>
<reference anchor="SafeCurves" target="http://safecurves.cr.yp.to/">
<front>
<title>SafeCurves: choosing safe curves for elliptic-curve
cryptography.</title>
<author initials="D.J." surname="Bernstein"
fullname="Daniel J. bernstein">
<organization />
</author>
<author initials="T." surname="Lange" fullname="Tanja Lange">
<organization />
</author>
<date month="January" year="2014"/>
</front>
</reference>
&rfc7027;
<reference anchor="SEC1">
<front>
<title>Standards for Efficient Cryptography (SEC) 1</title>
<author initials="" surname="Certicom Research"
fullname="Certicom Research">
<organization />
</author>
<date month="September" year="2000"/>
</front>
</reference>
<reference anchor="EFD"
target="http://www.hyperelliptic.org/EFD/g1p/auto-montgom-xz.html">
<front>
<title>Explicit-Formulas Database: XZ coordinates for
Montgomery curves</title>
<author initials="D.J." surname="Bernstein"
fullname="Daniel J. bernstein">
<organization />
</author>
<author initials="T." surname="Lange" fullname="Tanja Lange">
<organization />
</author>
<date month="January" year="2014"/>
</front>
</reference>
<reference anchor="NaCl"
target="http://cr.yp.to/highspeed/naclcrypto-20090310.pdf">
<front>
<title>Cryptography in NaCL</title>
<author initials="D.J." surname="Bernstein"
fullname="Daniel J. bernstein">
<organization />
</author>
<date month="March" year="2013"/>
</front>
</reference>
</references>
<section anchor="curve25519func" title="The curve25519 function">
<section title="Formulas">
<t>This section completes <xref target="crypto" /> by defining
the Curve25519 function and the common public key G.
It is meant as an alternative, self-contained specification
for the Curve25519 function, possibly easier to follow than
the original paper for most implementors.</t>
<section anchor="field" title="Field Arithmetic">
<t>Throughout this section, P denotes the integer 2^255-19 =
0x7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFED.
The letters X and Z, and their numbered variants such as x1,
z2, etc. denote integers modulo P, that is integers
between 0 and P-1 and every operation between them is
implictly done modulo P. For addition, subtraction and
multiplication this means doing the operation in the usual
way and then replacing the result with the remainder of its
division by P. For division, "X / Z" means mutliplying (mod P) X
by the modular inverse of Z mod P.</t>
<t>A convenient way to define the modular inverse of Z mod P is
as Z^(P-2) mod P, that is Z to the power of 2^255-21 mod P. It
is also a practical way of computing it, using a
square-and-multiply method.</t>
<t>The four operations +, -, *, / modulo P are known as the
field operations. Techniques for efficient implementation
of the field operations are outside the scope of this
document.</t>
</section>
<section title="Conversion to and from internal format">
<t>For the purpose of this section, we will define a
Curve25519 point as a pair (X, Z) were X and Z are integers
mod P (as defined above). Though public keys were defined to
be strings of 32 bytes, internally they are represented as
curve points. This subsection describes the conversion
process as two functions: PubkeyToPoint and PointToPubkey.</t>
<figure>
<artwork><![CDATA[
PubkeyToPoint:
Input: a public key b_0, ..., b_31
Output: a Curve25519 point (X, Z)
1. Set X = b_0 + 256 * b_1 + ... + 256^31 * b_31 mod P
2. Set Z = 1
3. Output (X, Z)
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
PointToPubkey:
Input: a Curve25519 point (X, Z)
Output: a public key b_0, ..., b_31
1. Set x1 = X / Z mod P
2. Set b_0, ... b_31 such that
x1 = b_0 + 256 * b_1 + ... + 256^31 * b_31 mod P
3. Output b_0, ..., b_31
]]></artwork>
</figure>
</section>
<section title="Scalar Multiplication">
<t>We first introduce the DoubleAndAdd function, defined as
follows (formulas taken from <xref target="EFD" />).</t>
<figure>
<artwork><![CDATA[
DoubleAndAdd:
Input: two points (X2, Z2), (X3, Z3), and an integer mod P: X1
Output: two points (X4, Z4), (X5, Z5)
Constant: the integer mod P: a24 = 121666 = 0x01DB42
Variables: A, AA, B, BB, E, C, D, DA, CB are integers mod P
1. Do the following computations mod P:
A = X2 + Z2
AA = A2
B = X2 - Z2
BB = B2
E = AA - BB
C = X3 + Z3
D = X3 - Z3
DA = D * A
CB = C * B
X5 = (DA + CB)^2
Z5 = X1 * (DA - CB)^2
X4 = AA * BB
Z4 = E * (BB + a24 * E)
2. Output (X4, Z4) and (X5, Z5)
]]></artwork>
</figure>
<t>This may be taken as the abstract definition of an
arbitrary-looking function. However, let's mention "the true
meaning" of this function, without justification, in order
to help the reader make more sense of it. It is possible to
define operations "+" and "-" between Curve25519 points.
Then, assuming (X2, Z2) - (X3, Z3) = (X1, 1), the
DoubleAndAdd function returns points such that (X4, Z4) =
(X2, Z2) + (X2, Z2) and (X5, Z5) = (X2, Z2) + (X3, Z3).</t>
<t>Taking the "+" operation as granted, we can define
multiplication of a Curve25519 point by a positive integer
as N * (X, Z) = (X, Z) + ... + (X, Z), with N point
additions. It is possible to compute this operation, known
as scalar multiplication, using an algorithm called the
Montgomery ladder, as follows.</t>
<figure>
<artwork><![CDATA[
ScalarMult:
Input: a Curve25519 point: (X, 1) and a 255-bits integer: N
Output: a point (X1, Z1)
Variable: a point (X2, Z2)
0. View N as a sequence of bits b_254, ..., b_0,
with b_254 the most significant bit
and b_0 the least significant bit.
1. Set X1 = 1 and Z1 = 0
2. Set X2 = X and Z2 = 1
3. For i from 254 downwards to 0, do:
If b_i == 0, then:
Set (X2, Z2) and (X1, Z1) to the output of
DoubleAndAdd((X2, Z2), (X1, Z1), X)
else:
Set (X1, Z1) and (X2, Z2) to the output of
DoubleAndAdd((X1, Z1), (X2, Z2), X)
4. Output (X1, Z1)
]]></artwork>
</figure>
</section>
<section title="Conclusion">
<t>We are now ready to define the Curve25519 function
itself.</t>
<figure>
<artwork><![CDATA[
Curve25519:
Input: a public key P and a secret key S
Output: a public key Q
Variables: two Curve25519 points (X, Z) and (X1, Z1)
1. Set (X, Z) = PubkeyToPoint(P)
2. Set (X1, Z1) = ScalarMult((X, Z), S)
3. Set Q = PointToPubkey((X1, Z1))
4. Output Q
]]></artwork>
</figure>
<t>The common public key G mentioned in the first paragraph of
<xref target="crypto" /> is defined as G = PointToPubkey((9,
1).</t>
</section>
</section>
<section title="Test vectors">
<t>The following test vectors are taken from <xref target="NaCl"
/>. Compared to this reference, the private key strings
have been applied the ClampC function of the reference and
converted to integers in order to fit the description given in
<xref target="Curve25519" /> and the present memo.</t>
<t>The secret key of party A is denoted by S_a, it public key by
P_a, and similarly for party B. The shared secret is SS.</t>
<figure>
<artwork><![CDATA[
S_a = 0x6A2CB91DA5FB77B12A99C0EB872F4CDF
4566B25172C1163C7DA518730A6D0770
P_a = 85 20 F0 09 89 30 A7 54 74 8B 7D DC B4 3E F7 5A
0D BF 3A 0D 26 38 1A F4 EB A4 A9 8E AA 9B 4E 6A
S_b = 0x6BE088FF278B2F1CFDB6182629B13B6F
E60E80838B7FE1794B8A4A627E08AB58
P_b = DE 9E DB 7D 7B 7D C1 B4 D3 5B 61 C2 EC E4 35 37
3F 83 43 C8 5B 78 67 4D AD FC 7E 14 6F 88 2B 4F
SS = 4A 5D 9D 5B A4 CE 2D E1 72 8E 3B F4 80 35 0F 25
E0 7E 21 C9 47 D1 9E 33 76 F0 9B 3C 1E 16 17 42
]]></artwork>
</figure>
</section>
<section title="Side-channel considerations">
<t>Curve25519 was specifically designed so that correct, fast,
constant-time implementations are easier to produce. In
particular, using a Montgomery ladder as described in the
previous section ensures that, for any valid value of the
secret key, the same sequence of field operations are
performed, which eliminates a major source of side-channel
leakage.</t>
<t>However, merely using Curve25519 with a Montgomery ladder does
not prevent all side-channels by itself, and some point are the
responsibility of implementors:
<list style="numbers">
<t>In step 3 of SclarMult, avoid branches depending on
b_i, as well as memory access patterns depending on b_i,
for example by using safe conditional swaps on the inputs
and outputs of DoubleAndAdd.</t>
<t>Avoid data-dependant branches and memory access patterns
in the implementation of field operations.</t>
</list>
</t>
<t>Techniques for implementing the field operations in constant
time and with high performance are out of scope of this
document. Let's mention however that, provided constant-time
multiplication is available, division can be computed in
constant time using exponentiation as described in <xref
target="field" />.</t>
<t>If using constant-time implementations of the field
operations is not convenient, an option to reduce the
information leaked this way is to replace step 2 of the
SclarMult function with:</t>
<figure>
<artwork><![CDATA[
2a. Pick Z uniformly randomly between 1 and P-1 included
2b. Set X2 = X * Z and Z2 = Z
]]></artwork>
</figure>
<t>This method is known as randomizing projective coordinates.
However, it is no guaranteed to avoid all side-channel leaks
related to field operations.</t>
<t>Side-channel attacks are an active reseach domain that still
sees new significant results, so implementors of the
Curve25519 function are advised to follow recent security
research closely.</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 18:39:00 |