Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Curve25519->X25519 (and same for 448) plus add zero check #16

Merged
merged 2 commits into from
Nov 14, 2015
Merged

Curve25519->X25519 (and same for 448) plus add zero check #16

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
ad1cc78
Curve25519->X25519 (and same for 448) plus add zero check
ilaril Nov 4, 2015
6d74917
Rename the curves to be consistent with TLS 1.3
ilaril Nov 7, 2015
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
46 changes: 25 additions & 21 deletions draft-ietf-tls-rfc4492bis.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -304,8 +304,8 @@
enum {
deprecated(1..22),
secp256r1 (23), secp384r1 (24), secp521r1 (25),
Curve25519(TBD1),
Curve448(TBD2),
X25519(TBD1),
X448(TBD2),
Ed25519(TBD3),
Ed448(TBD4),
reserved (0xFE00..0xFEFF),
Expand All @@ -317,7 +317,7 @@
<t> secp256r1, etc: Indicates support of the corresponding named curve or class of explicitly defined
curves. The named curves secp256r1, secp384r1, and secp521r1 are specified in SEC 2
<xref target="SECG-SEC2"/>. These curves are also recommended in ANSI X9.62
<xref target="ANSI.X9-62.2005"/> and FIPS 186-4 <xref target="FIPS.186-4"/>. Curve25519 and Curve448
<xref target="ANSI.X9-62.2005"/> and FIPS 186-4 <xref target="FIPS.186-4"/>. X25519 and X448
are defined in <xref target="CFRG-Curves"/>. Ed25519 and Ed448 are signature-only curves defined in
<xref target="CFRG-EdDSA"/>. Values 0xFE00 through 0xFEFF are reserved for private use.</t>
<t> The NamedCurve name space is maintained by IANA. See <xref target="iana"/> for information on how new
Expand Down Expand Up @@ -446,7 +446,7 @@
conversion routine in Section 4.3.6 of <xref target="ANSI.X9-62.2005"/>. This byte string may
represent an elliptic curve point in uncompressed or compressed format; it MUST conform to what the
client has requested through a Supported Point Formats Extension if this extension was used. For the
Curve25519 and Curve448 curves, the only valid representation is the one specified in
X25519 and X448 curves, the only valid representation is the one specified in
<xref target="CFRG-Curves"/> - a 32- or 56-octet representation of the u value of the point. This structure
MUST NOT be used with Ed25519 and Ed448 public keys.</t>
<t> <figure><artwork><![CDATA[
Expand Down Expand Up @@ -671,7 +671,7 @@
elliptic curve domain parameters recommended in ANSI X9.62, FIPS 186-4, and SEC 2
<xref target="SECG-SEC2"/> or in <xref target="CFRG-EdDSA"/>.</t>
<t>EdDSA keys using Ed25519 and Ed25519ph algorithms MUST use the Ed25519 curve, and Ed448 and Ed448ph keys
MUST use the Ed448 curve. Curves Curve25519, Curve448, Ed25519 and Ed448 MUST NOT be used for ECDSA.</t>
MUST use the Ed448 curve. Curves X25519, X448, Ed25519 and Ed448 MUST NOT be used for ECDSA.</t>
</section>
<section anchor="alg_computes" title="ECDH, ECDSA, and RSA Computations">
<t> All ECDH calculations for the NIST curves (including parameter and key generation as well as the shared
Expand All @@ -685,11 +685,12 @@
than for computing the master secret. In TLS 1.0 and 1.1, this means that the MD5- and SHA-1-based TLS
PRF serves as a KDF; in TLS 1.2 the KDF is determined by ciphersuite; it is conceivable that future TLS
versions or new TLS extensions introduced in the future may vary this computation.)</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
and compute a shared secret as x_S = Curve25519(d, x_peer). ECDHE for Curve448 works similarily, replacing
Curve25519 with Curve448. The derived shared secret is used directly as the premaster secret, which is
always exactly 32 bytes when ECDHE with Curve25519 is used and 56 bytes when ECDHE with Curve448 is used.</t>
<t> An ECDHE key exchange using X25519 goes as follows. Each party picks a secret key d uniformly at
random and computes the corresponding public key x = X25519(d, G). Parties exchange their public keys
and compute a shared secret as x_S = X25519(d, x_peer). If either party obtains all-zeroes x_S, it
MUST abort the handshake (as required by definition of X25519 and X448). ECDHE for X448 works similarily,
replacing X25519 with X448. The derived shared secret is used directly as the premaster secret, which is
always exactly 32 bytes when ECDHE with X25519 is used and 56 bytes when ECDHE with X448 is used.</t>
<t> All ECDSA computations MUST be performed according to ANSI X9.62 or its successors. Data to be
signed/verified is hashed, and the result run directly through the ECDSA algorithm with no additional
hashing. The default hash function is SHA-1 <xref target="FIPS.180-2"/>, and sha_size (see
Expand All @@ -710,19 +711,22 @@
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 it was chosen as prescribed, for any value of x (the same holds true for Curve448).</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 (for Ed448, any bit
<t> X25519 was designed in a way that the result of X25519(x, d) will never reveal information about
d, provided it was chosen as prescribed, for any value of x (the same holds true for X448).</t>
<t> All-zeroes output from X25519 or X448 MUST NOT be used for premaster secret (as required by definition
of X25519 and X448). If the premaster secret would be all zeroes, the handshake MUST be aborted (most
probably by sending a fatal alert).</t>
<t> Let's define legitimate values of x as the values that can be obtained as x = X25519(G, d') for some
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is d' supposed to be just d?

d, and call the other values illegitimate. The definition of the X25519 function shows that legitimate
values all share the following property: the high-order bit of the last byte is not set (for X448, any bit
can be 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
<t> Since there are some implementation of the X25519 function that impose this restriction on their input
and others that don't, implementations of X25519 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>Ed25519 and Ed448 internally do public key validation as part of signature verification.</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>
are legitimate: this is not necessary for security with X25519.</t>
</section>
</section>
<section anchor="suites" title="Cipher Suites">
Expand Down Expand Up @@ -792,8 +796,8 @@
<t> NOTE: IANA, please update the registries to reflect the new policy name.</t>
<t> NOTE: RFC editor please delete these two notes prior to publication.</t>
<t> IANA, please update these two registries to refer to this document.</t>
<t> IANA is requested to assign four values from the NamedCurve registry with names Curve25519(TBD1),
Curve448(TBD2), Ed25519(TBD3) and Ed448(TBD4) with this document as reference.</t>
<t> IANA is requested to assign four values from the NamedCurve registry with names X25519(TBD1),
X448(TBD2), Ed25519(TBD3) and Ed448(TBD4) with this document as reference.</t>
<t> IANA is requested to assign one value from SignatureAlgorithm Registry with name eddsa(TBD5) with this
document as reference.</t>
</section>
Expand Down Expand Up @@ -1118,7 +1122,7 @@
<t>All the other RC4 ciphersuites</t></list></t>
</list></t>
<t> Removed unused curves and all but the uncompressed point format.</t>
<t> Added Curve25519 and Curve448.</t>
<t> Added X25519 and X448.</t>
<t> Deprecated explicit curves.</t>
<t> Removed restriction on signature algorithm in certificate.</t>
</section>
Expand Down