Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer
Extracted elements (32)
ECMQV uses a single ephemeral key pair for both of the client's required keys (rather than two different ephemeral keys) because the SSH client has no long-term key to authenticate. This is more efficient and does not adversely affect security, being analogous to the one-pass protocol of Law et al. (1998).
SHA2 was chosen over SHA-1 for all hash operations in this document because weaknesses have been discovered in SHA-1. The SHA2 family variant is selected based on curve size to maintain consistent security levels across the handshake.
Implementations that do not support the ECC algorithms defined in this document will ignore them during SSH algorithm negotiation and use the next mutually supported algorithm, causing no backward compatibility impact with existing SSH implementations.
All elliptic curve public keys MUST be validated after they are received. If a key fails validation, the key exchange MUST fail.
Every compliant SSH ECC implementation MUST implement ECDH key exchange.
Every compliant SSH ECC implementation MUST implement the 'ecdsa-sha2-*' public key format and corresponding signature algorithm.
Every SSH ECC implementation MUST support the named curves nistp256 (secp256r1), nistp384 (secp384r1), and nistp521 (secp521r1). These curves SHOULD always be enabled unless specifically disabled by local security policy.
If ECMQV key exchange is chosen, the public key algorithm supporting ECC host keys MUST also be chosen, due to the use of implicit server authentication.
Implementations MUST use the string identifiers 'nistp256', 'nistp384', and 'nistp521' for the three REQUIRED NIST curves, even when an OID exists for that curve.
Implementations SHOULD NOT use curves smaller than 160 bits, as fewer than 2^80 operations are considered within feasible attack range.
Implementers SHOULD allow system administrators to disable some curves, including REQUIRED or RECOMMENDED curves, to meet local security policy.
Implementers SHOULD ensure that ephemeral private keys and random values (including k in ECDSA and ephemeral keys in ECDH/ECMQV) are generated from a proper RNG, protected from leakage, not reused outside the protocol context, and erased from memory when no longer needed.
It is RECOMMENDED that SSH ECC implementations support the additional named curves: nistk163, nistp192, nistp224, nistk233, nistb233, nistk283, nistk409, nistb409, and nistt571.
It is RECOMMENDED that the client verify that the host key sent is the server's host key (e.g., via a local database). The client MAY accept the host key without verification, but doing so renders the protocol insecure against active attacks.
The message hashing algorithm used in ECDSA MUST be from the SHA2 family of hash functions and is chosen according to the curve size as specified in Section 6.2.1.
ECDH key exchange method names follow the pattern 'ecdh-sha2-[identifier]'; any OID-derived identifier concatenated with 'ecdh-sha2-' is implicitly registered. Public key algorithm names follow 'ecdsa-sha2-[identifier]'.
ECDH key exchange uses ECDH with cofactor multiplication (SEC1 Section 3.3.2) to generate a shared secret from ephemeral local and remote elliptic curve key pairs. It provides explicit server authentication via a signature on the exchange hash.
ECMQV key exchange is OPTIONAL and provides implicit server authentication via an HMAC over the exchange hash using the shared secret, eliminating the need for a separate signature. It requires all keys to be on the same elliptic curve domain parameters as the host key.
Elliptic curve domain parameter identifiers: the three REQUIRED curves use NIST name strings ('nistp256', 'nistp384', 'nistp521'); all other curves use the ASCII decimal OID representation. Identifiers causing method names exceeding 64 characters are undefined and unsupported.
SHA2 hash algorithm selection is determined by curve size: curves with b <= 256 bits use SHA-256, 256 < b <= 384 use SHA-384, and b > 384 use SHA-512. This applies to both ECDSA and ECDH/ECMQV method names.
The ECMQV method name 'ecmqv-sha2' uses a single fixed name (not a family) because curve information is obtained from the chosen ECC host key public key algorithm rather than encoded in the method name.
The Key Exchange Method Names registry is updated with the method name 'ecmqv-sha2', naming the ECMQV key exchange method defined in Section 5. This document creates no new registries.
The Public Key Algorithm Names registry is updated with the family of SSH public key algorithm names beginning with 'ecdsa-sha2-' and not containing '@', naming the ECDSA public key algorithms defined in Section 3.
Curves over GF(2^m) where m is composite may be susceptible to an attack based on Weil descent. System administrators should be cautious when enabling curves not specified in Section 10 and should investigate their security thoroughly.
The elliptic curve size must be chosen to match the security strength of other SSH handshake elements (host key sizes, hash algorithms, bulk encryption algorithms). Using ECDSA and ECDH with different curve sizes can result in two different SHA2 variants being used simultaneously.
The primary security threat to all three ECC algorithms (ECDSA, ECDH, ECMQV) is solving the elliptic curve discrete logarithm problem (ECDLP). The difficulty depends on the size and quality of the elliptic curve parameters.
ECDSA signatures are encoded as: string 'ecdsa-sha2-[identifier]', string ecdsa_signature_blob containing mpint r and mpint s (the ECDSA output integers, modulo the subgroup order).
SSH_MSG_ECMQV_INIT carries: byte SSH_MSG_ECMQV_INIT (30), string Q_C (client's ephemeral public key). SSH_MSG_ECMQV_REPLY carries: byte SSH_MSG_ECMQV_REPLY (31), string K_S, string Q_S, string HMAC tag computed on H using the shared secret.
SSH_MSG_KEX_ECDH_INIT carries: byte SSH_MSG_KEX_ECDH_INIT (30), string Q_C (client's ephemeral public key octet string). SSH_MSG_KEX_ECDH_REPLY carries: byte SSH_MSG_KEX_ECDH_REPLY (31), string K_S (server's public host key), string Q_S (server's ephemeral public key), string signature on exchange hash.
The ECDH exchange hash H is the hash of the concatenation: string V_C, string V_S, string I_C, string I_S, string K_S, string Q_C, string Q_S, mpint K (shared secret).
The 'ecdsa-sha2-*' key format encodes as: string 'ecdsa-sha2-[identifier]', then ecc_key_blob containing string [identifier] and string Q (the public key point encoded per SEC1 Section 2.3.3; point compression MAY be used).
The ECMQV exchange hash H is the hash of: string V_C, string V_S, string I_C, string I_S, string K_S, string Q_C, string Q_S, mpint K. The HMAC over this hash authenticates the server implicitly.