RFC 5656
Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer
Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer 🦋
Network Working Group · Request for Comments: 5656 · Category: Standards Track 📜
Authors: D. Stebila (Queensland University of Technology) and J. Green (Queen's University) 🎀
Date: December 2009 📅
Obsoletes/Updates: This header doesn't list anything it obsoletes or updates. 🌸
Abstract ✨
okay so this doc adds elliptic curve crypto to SSH's transport layer 🔐 it specs ECDH key agreement, ECMQV key agreement, and ECDSA signatures. no cap, that's the whole pitch 💖
Status of This Memo 💅
this is an Internet standards track protocol for the Internet community, and it's open for discussion and suggestions for improvements 🫶 if you want the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). distribution of this memo is unlimited, so share it with your friends 🌈
Copyright Notice 🔖
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved 🎀
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were on the day it was published. pls read those carefully bc they spell out your rights and restrictions for this doc 😭 any Code Components pulled from this doc have to include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the BSD License says 🧚
some of this doc might include material from IETF Documents or IETF Contributions that were published or publicly available before November 10, 2008. the people who control the copyright on some of that stuff may not have given the IETF Trust permission to let it be modified outside the IETF Standards Process. so unless you've got an adequate license from them, this doc can't be modified outside the IETF Standards Process, and you can't make derivative works of it outside that process either. the one exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌍
Table of Contents 📚
1. Introduction ....................................................3
2. Notation ........................................................4
3. SSH ECC Public Key Algorithm ....................................4
3.1. Key Format .................................................4
3.1.1. Signature Algorithm .................................5
3.1.2. Signature Encoding ..................................5
4. ECDH Key Exchange ...............................................5
5. ECMQV Key Exchange ..............................................8
6. Method Names ...................................................10
6.1. Elliptic Curve Domain Parameter Identifiers ...............10
6.2. ECC Public Key Algorithm (ecdsa-sha2-*) ...................11
6.2.1. Elliptic Curve Digital Signature Algorithm .........11
6.3. ECDH Key Exchange Method Names (ecdh-sha2-*) ..............12
6.4. ECMQV Key Exchange and Verification Method Name
(ecmqv-sha2) ..............................................12
7. Key Exchange Messages ..........................................13
7.1. ECDH Message Numbers ......................................13
7.2. ECMQV Message Numbers .....................................13
8. Manageability Considerations ...................................13
8.1. Control of Function through Configuration and Policy ......13
8.2. Impact on Network Operation ...............................14
9. Security Considerations ........................................14
10. Named Elliptic Curve Domain Parameters ........................16
10.1. Required Curves ..........................................16
10.2. Recommended Curves .......................................17
11. IANA Considerations ...........................................17
12. References ....................................................18
12.1. Normative References .....................................18
12.2. Informative References ...................................19
Appendix A. Acknowledgements .....................................201. Introduction 🧚♀️
this doc adds some elliptic curve cryptography algorithms to the Secure Shell arsenal: Elliptic Curve Diffie-Hellman (ECDH) and Elliptic Curve Digital Signature Algorithm (ECDSA), plus it uses the SHA2 family of secure hash algorithms 🔥 it also brings in support for Elliptic Curve Menezes-Qu-Vanstone (ECMQV) 💜
ECC is blowing up 💥 it has small key sizes and it's in the National Security Agency's Suite B, so it's basically everywhere now 😭 compared to RSA, the Digital Signature Algorithm (DSA), and Diffie-Hellman (DH) key exchange, the ECC versions of these schemes give you equivalent security with smaller keys ✨ the table below shows that. it's based on Section 5.6.1 of NIST 800-57 [NIST-800-57], which lists approximate comparable key sizes for symmetric and asymmetric cryptosystems, based on the best known attacks against them. L is the field size and N is the sub-field size 🍓
+-----------+------------------------------+-------+---------+
| Symmetric | Discrete Log (e.g., DSA, DH) | RSA | ECC |
+-----------+------------------------------+-------+---------+
| 80 | L = 1024, N = 160 | 1024 | 160-223 |
| | | | |
| 112 | L = 2048, N = 256 | 2048 | 224-255 |
| | | | |
| 128 | L = 3072, N = 256 | 3072 | 256-383 |
| | | | |
| 192 | L = 7680, N = 384 | 7680 | 384-511 |
| | | | |
| 256 | L = 15360, N = 512 | 15360 | 512+ |
+-----------+------------------------------+-------+---------+using this spec means you need to know both SSH [RFC4251] [RFC4253] [RFC4250] and ECC [SEC1] 🎀 extra info on ECC lives in [HMV04], [ANSI-X9.62], and [ANSI-X9.63] 📖
this doc is all about the SSH implementation details. the underlying crypto algorithms are specified in other standards docs, so we're not going there 🙈
2. Notation 💅
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read as described in [RFC2119] 👑
the data types boolean, byte, uint32, uint64, string, and mpint are read the way [RFC4251] describes them 🫶
the size of a set of elliptic curve domain parameters on a prime curve is the number of bits in the binary representation of the field order, usually written as p. on a characteristic-2 curve, the size is the number of bits in the binary representation of the field, usually written as m. a set of elliptic curve domain parameters defines a group of order n, generated by a base point P 🌈
3. SSH ECC Public Key Algorithm 🔑
the SSH ECC public key algorithm is defined by its key format, its corresponding signature algorithm ECDSA, its signature encoding, and its algorithm identifiers ✨
this section defines the family of "ecdsa-sha2-*" public key formats and their matching signature formats. every compliant SSH ECC implementation MUST implement this public key format 💖
3.1. Key Format 🗝️
the "ecdsa-sha2-*" key formats all use this encoding:
string "ecdsa-sha2-[identifier]"
byte[n] ecc_key_blobthe ecc_key_blob value has this specific encoding:
string [identifier]
string Qthe string [identifier] is the identifier of the elliptic curve domain parameters. its format is specified in Section 6.1. info on the REQUIRED and RECOMMENDED sets of elliptic curve domain parameters for this algorithm is in Section 10 🌸
Q is the public key, encoded from an elliptic curve point into an octet string as defined in Section 2.3.3 of [SEC1]. point compression MAY be used 🧚
the algorithm for ECC key generation is in Section 3.2 of [SEC1]. given some elliptic curve domain parameters, you can generate an ECC key pair with a private key (an integer d) and a public key (an elliptic curve point Q) 🔐
3.1.1. Signature Algorithm ✍️
signing and verifying use the Elliptic Curve Digital Signature Algorithm (ECDSA), which is specified in [SEC1] 💅 the message hashing algorithm MUST come from the SHA2 family of hash functions [FIPS-180-3], and it's chosen according to the curve size, as specified in Section 6.2.1 🔥
3.1.2. Signature Encoding 🎀
signatures are encoded like this:
string "ecdsa-sha2-[identifier]"
string ecdsa_signature_blobthe string [identifier] is the identifier of the elliptic curve domain parameters. its format is specified in Section 6.1. info on the REQUIRED and RECOMMENDED sets of elliptic curve domain parameters for this algorithm is in Section 10 💜
the ecdsa_signature_blob value has this specific encoding:
mpint r
mpint sr and s are the outputs of the ECDSA algorithm 🦋
the width of the integer fields is set by the curve being used. note that r and s are integers modulo the order of the cryptographic subgroup, which can be larger than the size of the finite field 🌈
4. ECDH Key Exchange ✨
Okay bestie, so ECDH key exchange is the one where you cook up a shared secret from an ephemeral local elliptic curve private key and an ephemeral remote elliptic curve public key 🔑. It gives you explicit server authentication as defined in [RFC4253], using a signature on the exchange hash. Every compliant SSH ECC implementation MUST implement ECDH key exchange, no cap 💅.
The primitive for shared key generation is ECDH with cofactor multiplication 🧮. You can find the full spec in Section 3.3.2 of [SEC1], and the key pair generation algorithm is in Section 3.2.1 of [SEC1].
The family of key exchange method names for this one lives in Section 6.3. Algorithm negotiation picks the public key algorithm used for signing AND the key exchange method name ✨. Whatever method name gets chosen decides the elliptic curve domain parameters and the hash function we use for the rest of this section, so it's giving main character energy 👑.
For the REQUIRED and RECOMMENDED elliptic curve domain parameters, check out Section 10 🎀.
All elliptic curve public keys MUST be validated after they're received 🫶. There's an example validation algorithm in Section 3.2.2 of [SEC1]. If a key fails validation, the key exchange MUST fail 😭.
The elliptic curve public keys (points) that need to be sent get encoded into octet strings first 🌸. The transformation between points and octet strings is specified in Sections 2.3.3 and 2.3.4 of [SEC1], and point compression MAY be used 🦋. The output of shared key generation is a field element xp. SSH wants the shared key to be an integer, so the conversion between a field element and an integer is in Section 2.3.9 of [SEC1] 🧚.
The message numbers SSH_MSG_KEX_ECDH_INIT and SSH_MSG_KEX_ECDH_REPLY are specified in Section 7 💜.
Here's the overview of the whole key exchange process:
Client Server
------ ------
Generate ephemeral key pair.
SSH_MSG_KEX_ECDH_INIT -------------->
Verify received key is valid.
Generate ephemeral key pair.
Compute shared secret.
Generate and sign exchange hash.
<------------- SSH_MSG_KEX_ECDH_REPLY
Verify received key is valid.
*Verify host key belongs to server.
Compute shared secret.
Generate exchange hash.
Verify server's signature.*It is RECOMMENDED that the client verify that the host key sent is the server's host key (for example, using a local database). The client MAY accept the host key without verification, but doing so will render the protocol insecure against active attacks; see the discussion in Section 4.1 of [RFC4251].
⚠️ Skipping the host key check makes the protocol insecure against active attacks. Don't skip it bestie 😭.
This is implemented using the following messages 💅.
The client sends:
byte SSH_MSG_KEX_ECDH_INIT
string Q_C, client's ephemeral public key octet stringThe server responds with:
byte SSH_MSG_KEX_ECDH_REPLY
string K_S, server's public host key
string Q_S, server's ephemeral public key octet string
string the signature on the exchange hashThe exchange hash H is computed as the hash of the concatenation of the following:
string V_C, client's identification string (CR and LF excluded)
string V_S, server's identification string (CR and LF excluded)
string I_C, payload of the client's SSH_MSG_KEXINIT
string I_S, payload of the server's SSH_MSG_KEXINIT
string K_S, server's public host key
string Q_C, client's ephemeral public key octet string
string Q_S, server's ephemeral public key octet string
mpint K, shared secret5. ECMQV Key Exchange ✨
The Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key exchange algorithm generates a shared secret from two local elliptic curve key pairs and two remote public keys 🔥. This method gives you implicit server authentication as defined in [RFC4253]. ECMQV key exchange is OPTIONAL, so you get to decide if you want it 💖.
The key exchange method name for this one is "ecmqv-sha2" 🌈. That name tells you which hashing algorithm to use for the Hashed Message Authentication Code (HMAC) below. Future RFCs may define new method names with new hash algorithms for ECMQV, and you can read more about the method name and HMAC in Section 6.4.
In general, ECMQV key exchange uses the ephemeral and long-term key pairs of both the client and the server, which is 4 keys total 🫠. But within SSH, the client doesn't have a long-term key pair that needs authenticating. So we generate an ephemeral key and use that as both of the client's keys 🧠. This is more efficient than using two different ephemeral keys, and it doesn't hurt security at all (it's analogous to the one-pass protocol in Section 6.1 of [LMQSV98]) ✨.
A full description of the ECMQV primitive is in Section 3.4 of [SEC1], and the key pair generation algorithm is in Section 3.2.1 of [SEC1] 🧮.
During algorithm negotiation with the SSH_MSG_KEXINIT messages, the ECMQV key exchange method can ONLY be chosen if a public key algorithm supporting ECC host keys can also be chosen. Why? Because this method uses implicit server authentication 🙈. This case is handled the same way that key exchange methods needing encryption or signature capable public key algorithms are handled in Section 7.1 of [RFC4253]. If ECMQV key exchange is chosen, then the public key algorithm supporting ECC host keys MUST also be chosen 💅.
ECMQV needs all of the keys used to generate a shared secret to be generated over the same elliptic curve domain parameters 🎀. Since the host key gets used in generating the shared secret (that's how implicit server authentication works), the domain parameters associated with the host key are the ones used throughout this section 👑.
All elliptic curve public keys MUST be validated after they're received 🫶. An example validation algorithm is in Section 3.2.2 of [SEC1]. If a key fails validation, the key exchange MUST fail 😭.
The elliptic curve ephemeral public keys (points) that need to be transmitted get encoded into octet strings before they're sent 🌸. The transformation between points and octet strings is specified in Sections 2.3.3 and 2.3.4 of [SEC1], and point compression MAY be used 🦋. The output of shared key generation is a field element xp. SSH needs the shared key to be an integer, and the conversion between a field element and an integer is in Section 2.3.9 of [SEC1] 🧚.
Here's the overview of the key exchange process:
Client Server
------ ------
Generate ephemeral key pair.
SSH_MSG_KEX_ECMQV_INIT ------------->
Verify received key is valid.
Generate ephemeral key pair.
Compute shared secret.
Generate exchange hash and compute
HMAC over it using the shared secret.
<------------- SSH_MSG_KEX_ECMQV_REPLY
Verify received keys are valid.
*Verify host key belongs to server.
Compute shared secret.
Verify HMAC.*It is RECOMMENDED that the client verify that the host key sent is the server's host key (for example, using a local database). The client MAY accept the host key without verification, but doing so will render the protocol insecure against active attacks.
⚠️ Same rule as ECDH: skipping the host key check makes you vulnerable to active attacks. Verify it, babe 💀.
The specification of the message numbers SSH_MSG_ECMQV_INIT and SSH_MSG_ECMQV_REPLY can be found in Section 7 🦋.
This key exchange algorithm is implemented with the following messages 🌈.
The client sends:
byte SSH_MSG_ECMQV_INIT
string Q_C, client's ephemeral public key octet stringThe server sends:
byte SSH_MSG_ECMQV_REPLY
string K_S, server's public host key
string Q_S, server's ephemeral public key octet string
string HMAC tag computed on H using the shared secretThe hash H is formed by applying the algorithm HASH to a concatenation of the following:
string V_C, client's identification string (CR and LF excluded)
string V_S, server's identification string (CR and LF excluded)
string I_C, payload of the client's SSH_MSG_KEXINIT
string I_S, payload of the server's SSH_MSG_KEXINIT
string K_S, server's public host key
string Q_C, client's ephemeral public key octet string
string Q_S, server's ephemeral public key octet string
mpint K, shared secret6. Method Names ✨
This document defines a new family of key exchange method names, a new key exchange method name, and a new family of public key algorithm names in the SSH name registry 📝.
6.1. Elliptic Curve Domain Parameter Identifiers 🎀
This section specifies identifiers that encode named elliptic curve domain parameters 🧚. This document uses these identifiers to name the curve used in the SSH ECC public key format, the ECDSA signature blob, and the ECDH method name.
For the REQUIRED elliptic curves nistp256, nistp384, and nistp521, the elliptic curve domain parameter identifiers are the strings "nistp256", "nistp384", and "nistp521" 💖.
For all other elliptic curves, including all other NIST curves and all other RECOMMENDED curves, the elliptic curve domain parameter identifier is the ASCII period-separated decimal representation of the Abstract Syntax Notation One (ASN.1) [ASN1] Object Identifier (OID) of the named curve domain parameters associated with the server's ECC host keys 🔢. This identifier is only defined provided that the concatenation of the public key format identifier and the elliptic curve domain parameter identifier (or the method name and the elliptic curve domain parameter identifier) does not exceed the maximum specified by the SSH protocol architecture [RFC4251], namely 64 characters. Otherwise, the identifier for that curve is undefined, and the curve is not supported by this specification 🙅♀️.
A list of the REQUIRED and RECOMMENDED curves and their OIDs can be found in Section 10 🌸.
Note that implementations MUST use the string identifiers for the three REQUIRED NIST curves, even when an OID exists for that curve 🫶.
6.2. ECC Public Key Algorithm (ecdsa-sha2-*) 🦋
The SSH ECC public key algorithm is specified by a family of public key format identifiers 🌈. Each identifier is the concatenation of the string "ecdsa-sha2-" with the elliptic curve domain parameter identifier defined in Section 6.1. A list of the required and recommended curves and their OIDs can be found in Section 10 ✨.
For example, the method name for ECDH key exchange with ephemeral keys generated on the nistp256 curve is "ecdsa-sha2-nistp256" 💅.
6.2.1. Elliptic Curve Digital Signature Algorithm ✨
okay so ECDSA (Elliptic Curve Digital Signature Algorithm) is the one specified for use with the SSH ECC public key algorithm 💅
the hashing algorithm for this family of method names is the SHA2 family [FIPS-180-3] 🦋 and which SHA2 hash you get depends on the size of the named curve in the public key, so check the table:
+----------------+----------------+
| Curve Size | Hash Algorithm |
+----------------+----------------+
| b <= 256 | SHA-256 |
| | |
| 256 < b <= 384 | SHA-384 |
| | |
| 384 < b | SHA-512 |
+----------------+----------------+6.3. ECDH Key Exchange Method Names (ecdh-sha2-*) 🌸
the Elliptic Curve Diffie-Hellman (ECDH) key exchange is defined by a family of method names 🧚 each one is the string ecdh-sha2- glued onto the elliptic curve domain parameter identifier from Section 6.1. a list of the required and recommended curves and their OIDs is in Section 10, so go look there 🎀
for example, the method name for ECDH key exchange with ephemeral keys made on the sect409k1 curve is ecdh-sha2-1.3.132.0.36 💜
the hashing algorithm for this family is also the SHA2 family [FIPS-180-3] 🔥 it's written into the method name so there's room for other algorithms in future documents. which SHA2 hash gets used is picked from the curve size, following the table in Section 6.2.1 🫶
any ASN.1 OID that specifies a set of elliptic curve domain parameters, encoded that way and prefixed with ecdh-sha2-, is implicitly registered under this specification ✨
6.4. ECMQV Key Exchange and Verification Method Name (ecmqv-sha2) 👑
the Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key exchange is defined by the single method name ecmqv-sha2 💖 unlike ECDH, ECMQV relies on a public key algorithm that uses ECC keys, so it doesn't need a family of method names. the curve info comes from the public key algorithm instead 🦋
the hashing and message authentication code algorithms are baked into the method name, which leaves room for other algorithms in future documents for use with ECMQV 🌈
the hashing algorithm for this method name is the SHA2 family [FIPS-180-3] 💅 the SHA2 hash that gets used is chosen from the size of the named curve, which the chosen public key algorithm specifies for ECMQV, following the table in Section 6.2.1 🎀
the keyed-hash message authentication code used to identify the server and verify communications is based on the hash picked above. info on implementing the HMAC with that hash is in [RFC2104] 🧚
7. Key Exchange Messages 🦋
the message numbers 30-49 are key-exchange-specific and live in a private namespace defined in [RFC4250]. any key exchange method can redefine them [RFC4253] without needing an IANA registration process, which is so convenient 🫶
these message numbers are defined in this document:
7.1. ECDH Message Numbers 💜
#define SSH_MSG_KEX_ECDH_INIT 30
#define SSH_MSG_KEX_ECDH_REPLY 317.2. ECMQV Message Numbers 🌸
#define SSH_MSG_ECMQV_INIT 30
#define SSH_MSG_ECMQV_REPLY 318. Manageability Considerations 🍓
ngl this part is pretty chill. this document only adds new public key algorithms and key exchange methods inside the existing Secure Shell protocol architecture, so there aren't many manageability considerations beyond the ones that already apply to existing Secure Shell implementations 💅 the extra ones are listed below ✨
8.1. Control of Function through Configuration and Policy 🎀
Section 10 specifies REQUIRED and RECOMMENDED elliptic curve domain parameters to be used with the public key algorithms and key exchange methods defined in this document. Implementers SHOULD allow system administrators to disable some curves, including REQUIRED or RECOMMENDED curves, to meet local security policy 🔐
8.2. Impact on Network Operation 🌈
this document adds new functionality inside the Secure Shell protocol architecture, so the only network impact is the one on existing Secure Shell implementations 🧚 the protocol has negotiation mechanisms for public key algorithms and key exchange methods. any implementation that doesn't recognize the algorithms and methods defined here will just ignore them during negotiation and use the next mutually supported algorithm or method, so there's no negative impact on backward compatibility 🫶
the use of elliptic curve cryptography should not place a significant computational burden on an implementing server 💖 fun fact (well, the spec says so): due to its smaller key sizes, elliptic curve cryptography can be implemented more efficiently for the same security level than RSA, finite field Diffie-Hellman, or DSA ⭐
9. Security Considerations 💀
okay this is the serious section, bestie, so pay attention 🙈 this document adds new public key algorithms and new key agreement methods for the Secure Shell protocol. for the most part, the security considerations of using the Secure Shell protocol apply. on top of that, implementers should be aware of the security considerations specific to elliptic curve cryptography 🔥
for all three classes of functionality this document adds (the public key algorithms involving ECDSA, key exchange involving ECDH, and authenticated key exchange involving ECMQV), the current best known technique for breaking the cryptosystems is solving the elliptic curve discrete logarithm problem (ECDLP) 💀
the difficulty of breaking the ECDLP depends on the size and quality of the elliptic curve parameters. some curve types are more susceptible to known attacks than others. for example, curves over finite fields GF(2^m), where m is composite, may be susceptible to an attack based on the Weil descent. All of the RECOMMENDED curves in Section 10 do not have this problem. system administrators should be cautious when enabling curves other than the ones specified in Section 10, and should do a more detailed investigation into the security of the curve in question ⚠️
it is believed (see, for example, Section B.2.1 of [SEC1]) that when curve parameters are generated at random, the curves will be resistant to special attacks, and must rely on the most general attacks. The REQUIRED curves in Section 10 were all generated verifiably pseudorandomly 🧚 the runtime of general attacks depends on the algorithm used. right now, the best known algorithm is the Pollard-rho method. (Shor's algorithm for quantum computers can solve the ECDLP in polynomial time, but at present large-scale quantum computers have not been constructed, and significant experimental physics and engineering work needs to be done before they can be. there is no solid estimate as to when this may occur, but it is widely believed to be at least 20 years from the present.) 🌌
based on projections of computation power, it is possible to estimate the running time of the best known attacks based on the size of the finite field. the table in Section 1 gives an estimate of the equivalence between elliptic curve field size and symmetric key size. roughly speaking, an N-bit elliptic curve offers the same security as an N/2-bit symmetric cipher, so a 256-bit elliptic curve (such as the REQUIRED nistp256 curve) is suitable for use with 128-bit AES, for example 🍓
many estimates consider 2^80-2^90 operations to be beyond feasible, which would suggest using elliptic curves of at least 160-180 bits. The REQUIRED curves in this document are 256-, 384-, and 521-bit curves; implementations SHOULD NOT use curves smaller than 160 bits 🛡️
a detailed discussion of the security considerations of elliptic curve domain parameters and the ECDH, ECDSA, and ECMQV algorithms can be found in Appendix B of [SEC1] 📖
additionally, the key exchange methods defined here rely on the SHA2 family of hash functions, defined in [FIPS-180-3]. the appropriate security considerations of that document apply. although some weaknesses have been discovered in the predecessor, SHA-1, no weaknesses in the SHA2 family are known at present. the SHA2 family has four variants -- SHA-224, SHA-256, SHA-384, and SHA-521 -- named after their digest lengths. without special purpose attacks that exploit the specific structure of the hash function, the difficulty of finding collisions, preimages, and second preimages is related to the digest length. this document specifies in Section 6.2.1 which SHA2 variant should be used with which elliptic curve size, based on this guidance 🌈
since ECDH and ECMQV allow elliptic curves of arbitrary sizes, and thus arbitrary security strength, it is important that the size of the elliptic curve be chosen to match the security strength of the other elements of the SSH handshake. in particular, host key sizes, hashing algorithms, and bulk encryption algorithms must be chosen appropriately. info on the estimated equivalence of key sizes is in [NIST-800-57], and the discussion in [RFC3766] is also relevant. we note in particular that when ECDSA is the signature algorithm and ECDH is the key exchange method, if curves of different sizes are used, different hash functions from the SHA2 family could be used 🔥
the REQUIRED and RECOMMENDED curves in this document are believed to offer security at the levels indicated in this section and in the table in Section 1 ✨
system administrators and implementers should think carefully about the security issues before enabling curves other than the REQUIRED or RECOMMENDED curves in this document. not all elliptic curves are secure, even ones over a large field 🙈
implementers SHOULD ensure that any ephemeral private keys or random values -- including the value k used in ECDSA signature generation and the ephemeral private key values in ECDH and ECMQV -- are generated from a random number generator or a properly seeded pseudorandom number generator, are protected from leakage, are not reused outside of the context of the protocol in this document, and are erased from memory when no longer needed 🔐
10. Named Elliptic Curve Domain Parameters 👑
implementations MAY support any ASN.1 object identifier (OID) in the ASN.1 object tree that defines a set of elliptic curve domain parameters [ASN1] 🧚
10.1. Required Curves 💖
Okay bestie, this is the list of curves every SSH ECC implementation MUST support, no cap 🫶 These curves are defined in [SEC2], and the NIST curves were originally defined in [NIST-CURVES]. They SHOULD always stay enabled unless your local security policy specifically turns them off 🔒
+----------+-----------+---------------------+
| NIST* | SEC | OID |
+----------+-----------+---------------------+
| nistp256 | secp256r1 | 1.2.840.10045.3.1.7 |
| | | |
| nistp384 | secp384r1 | 1.3.132.0.34 |
| | | |
| nistp521 | secp521r1 | 1.3.132.0.35 |
+----------+-----------+---------------------+* For these three REQUIRED curves, the elliptic curve domain parameter identifier is the string in the first column of the table, the NIST name of the curve. (See Section 6.1.) ✨
10.2. Recommended Curves 🦋
It is RECOMMENDED that SSH ECC implementations also support the curves below, and they're all defined in [SEC2] 💅
+----------+-----------+---------------------+
| NIST | SEC | OID* |
+----------+-----------+---------------------+
| nistk163 | sect163k1 | 1.3.132.0.1 |
| | | |
| nistp192 | secp192r1 | 1.2.840.10045.3.1.1 |
| | | |
| nistp224 | secp224r1 | 1.3.132.0.33 |
| | | |
| nistk233 | sect233k1 | 1.3.132.0.26 |
| | | |
| nistb233 | sect233r1 | 1.3.132.0.27 |
| | | |
| nistk283 | sect283k1 | 1.3.132.0.16 |
| | | |
| nistk409 | sect409k1 | 1.3.132.0.36 |
| | | |
| nistb409 | sect409r1 | 1.3.132.0.37 |
| | | |
| nistt571 | sect571k1 | 1.3.132.0.38 |
+----------+-----------+---------------------+* For these RECOMMENDED curves, the elliptic curve domain parameter identifier is the string in the third column of the table, the ASCII representation of the OID of the curve. (See Section 6.1.) 🌈
11. IANA Considerations 🌸
Consistent with Section 8 of [RFC4251] and Section 4.6 of [RFC4250], this document makes the following registrations 📝
In the Public Key Algorithm Names registry: the family of SSH public key algorithm names beginning with ecdsa-sha2- and not containing the at-sign (@), to name the public key algorithms defined in Section 3. 🔑
In the Key Exchange Method Names registry: the family of SSH key exchange method names beginning with ecdh-sha2- and not containing the at-sign (@), to name the key exchange methods defined in Section 4. 🤝
In the Key Exchange Method Names registry: the SSH key exchange method name ecmqv-sha2 to name the key exchange method defined in Section 5. ✨
This document creates no new registries. Main character restraint 💅
12. References 📚
12.1. Normative References
- [ASN1] International Telecommunications Union, "Abstract Syntax Notation One (ASN.1): Specification of basic notation", X.680, July 2002. 🧾
- [FIPS-180-3] National Institute of Standards and Technology, "Secure Hash Standard", FIPS 180-3, October 2008.
- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
- [RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006.
- [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
- [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
- [SEC1] Standards for Efficient Cryptography Group, "Elliptic Curve Cryptography", SEC 1, May 2009,
<http://www.secg.org/download/aid-780/sec1-v2.pdf>. - [SEC2] Standards for Efficient Cryptography Group, "Recommended Elliptic Curve Domain Parameters", SEC 2, September 2000,
<http://www.secg.org/download/aid-386/sec2_final.pdf>.
12.2. Informative References
- [ANSI-X9.62] American National Standards Institute, "Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI X9.62, 1998. 🧠
- [ANSI-X9.63] American National Standards Institute, "Public Key Cryptography For The Financial Services Industry: Key Agreement and Key Transport Using Elliptic Curve Cryptography", ANSI X9.63, January 1999.
- [HMV04] Hankerson, D., Menezes, A., and S. Vanstone, "Guide to Elliptic Curve Cryptography", Springer ISBN 038795273X, 2004.
- [LMQSV98] Law, L., Menezes, A., Qu, M., Solinas, J., and S. Vanstone, "An Efficient Protocol for Authenticated Key Agreement", University of Waterloo Technical Report CORR 98-05, August 1998,
<http://www.cacr.math.uwaterloo.ca/techreports/1998/corr98-05.pdf>. - [NIST-800-57] National Institute of Standards and Technology, "Recommendation for Key Management - Part 1: General (Revised)", NIST Special Publication 800-57, March 2007.
- [NIST-CURVES] National Institute of Standards and Technology, "Recommended Elliptic Curves for Federal Government Use", July 1999.
Appendix A. Acknowledgements 🫶
The authors acknowledge helpful comments from James Blaisdell, David Harrington, Alfred Hoenes, Russ Housley, Jeffrey Hutzelman, Kevin Igoe, Rob Lambert, Jan Pechanek, Tim Polk, Sean Turner, Nicolas Williams, and members of the ietf-ssh@netbsd.org mailing list. Thank you all, you're literally the reason this spec slaps 💖
Authors' Addresses 💌
Douglas Stebila
Queensland University of Technology
Information Security Institute
Level 7, 126 Margaret St
Brisbane, Queensland 4000
Australia
EMail: douglas@stebila.ca
Jon Green
Queen's University
Parallel Processing Research Laboratory
Department of Electrical and Computer Engineering
Room 614, Walter Light Hall
Kingston, Ontario K7L 3N6
Canada
EMail: jonathan.green@queensu.ca📦 where this page comes from
- ietf: rfc5656 2009-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms