Subject: Re: Curve25519/448 key agreement for SSH

From: "Mark D. Baushke" <[email-masked]>
Date: Sun, 21 Feb 2016 08:22:48 -0800

Hi Simon,

Regarding

  https://datatracker.ietf.org/doc/draft-josefsson-ssh-curves/

could advise on the the following?

|   The protocol flow, the SSH_MSG_KEX_ECDH_INIT and
|   SSH_MSG_KEX_ECDH_REPLY messages, and the structure of the exchange
|   hash are identical to chapter 4 of [RFC5656].
|
|   The method names registered by this document are "curve25519-sha256"
|   and "curve448-sha256".

The RFC5656 "4. ECDH Key Exchange" also says

|    The Elliptic Curve Diffie-Hellman (ECDH) key exchange method
|    generates a shared secret from an ephemeral local elliptic curve
|    private key and ephemeral remote elliptic curve public key.  This key
|    exchange method provides explicit server authentication as defined in
|    [RFC4253] using a signature on the exchange hash.  Every compliant
|    SSH ECC implementation MUST implement ECDH key exchange.

which would seem to also implicitly reference RFC5656 3.1.1:

| 3.1.1.  Signature Algorithm
| 
|    Signing and verifying is done using the Elliptic Curve Digital
|    Signature Algorithm (ECDSA).  ECDSA is specified in [SEC1].  The
|    message hashing algorithm MUST be from the SHA2 family of hash
|    functions [FIPS-180-3] and is chosen according to the curve size as
|    specified in Section 6.2.1.

and if so, looking at 6.2.1:

| 6.2.1.  Elliptic Curve Digital Signature Algorithm
|
|   The hashing algorithm defined by this family of method names is the
|   SHA2 family of hashing algorithms [FIPS-180-3].  The algorithm from
|   the SHA2 family that will be used is chosen based on the size of the
|   named curve specified in the public key:
|
|                     +----------------+----------------+
|                     |   Curve Size   | Hash Algorithm |
|                     +----------------+----------------+
|                     |    b <= 256    |     SHA-256    |
|                     |                |                |
|                     | 256 < b <= 384 |     SHA-384    |
|                     |                |                |
|                     |     384 < b    |     SHA-512    |
|                     +----------------+----------------+

Is the hash to use driven by the table in RFC5656 as seen in 6.2.1 such
that curve448 should use SHA-512?

If so, why is the Key Exchange Method name "curve448-sha256" rather than
"curve488-sha512" ?

Also, should the current draft be updated to change references of
[I-D.irtf-cfrg-curves] to [RFC7748] ?

	Thank you,
	-- Mark

---

From: [email-masked] (Niels Möller)
Date: Mon, 22 Feb 2016 10:08:32 +0100

> If so, why is the Key Exchange Method name "curve448-sha256" rather than

I think Damien Miller's argument for using sha512 here makes sense:
"curve448 is a backup against as-yet-unknown attacks on curve25519.
Since we're not likely to need it, we might as well pair it with SHA512
as a backup against as-yet-unknown attacks on SHA256."

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 25 Feb 2016 12:52:35 +0100

Den Mon, 22 Feb 2016 10:08:32 +0100
skrev Re: Curve25519/448 key agreement for SSH:

> > If so, why is the Key Exchange Method name "curve448-sha256" rather
> > than "curve488-sha512" ?
> 
> Since we're not likely to need it, we might as well pair it with
> SHA512 as a backup against as-yet-unknown attacks on SHA256."

Hello Mark and Niels.  Indeed there appears to be strong support from
several people to couple Curve448 with SHA-512 instead of SHA-256.  We
are making this change and there will be a -04 out shortly.  Mark's
RFC quoting is a strong reason to make this change, but I believe there
were sufficient motivation to do it anyway because of the hedge aspect.

/Simon