Re: Curve25519/448 key agreement for SSH

[Damien Miller <djm%mindrot.org@localhost>]

On Mon, 9 Nov 2015, Simon Josefsson wrote:

> Aris and me have prepared a document describing key agreement using the
> CFRG curves for Secure Shell.  As you know, curve25519-sha256%libssh.org@localhost
> is already implemented by libssh, OpenSSH, Dropbear, and some others.
> This is about putting the description of that into IETF format, and to
> add the Curve448 hedge variant chosen by CFRG.  It might not be detailed
> enough for independent implementation, but we hope to get there.  Any
> review and feedback is welcome.
> 
> https://tools.ietf.org/html/draft-josefsson-ssh-curves

Thanks for writing this up. Some feedback:

> 2.  Key Exchange Methods
> 
>    The key exchange procedure is identical to the one described RFC 5656
>    chapter 4 of [RFC5656].  Public ephemeral keys are transmitted over
>    SSH encapsulated into standard SSH strings.

RFC5656 describes multiple key exchange procedures (ECDH and ECMQV),
so s/the one described RFC 5656/the ECDH method described in RFC 5656/

The procedure isn't completely identical, since different encodings are
used for the wire values and the shared secret. IMO it's worth
foreshadowing this here. Perhaps something like:

   The key exchange procedure is similar to the ECDH method described in
   chapter 4 of [RFC5656], though with a different wire encoding used for
   public values and the final shared secret.  Public ephemeral keys are
   transmitted over SSH encapsulated into standard SSH strings.

I think it is also worth mentioning that 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 between this and
RFC5656 chapter 4.

>    The whole method is based on the Curve25519 and Curve448 scalar
>    multiplication, as described in [I-D.irtf-cfrg-curves].  Private and
>    public keys are generated as described therein, and no special
>    validation is required beyond what is discussed there.  Public keys
>    are defined as strings of 32 bytes for Curve25519 and 56 bytes for
>    Curve448.  The derived shared secret is is 32 bytes when Curve25519
>    is used and 56 bytes when Curve448 is used.

I think that it's worth mentioning here that it's [I-D.irtf-cfrg-curves]
that specifies encodings for the public values.

>    The shared secret, k, is defined in SSH specifications to be a big
>    integer.  This number is calculated as follows.  X is the 32 bytes
>    point obtained by the scalar multiplication of the other side's
>    public key and the local private key scalar.  The whole 32 bytes of

s/32 bytes/32 or 56 bytes/ here.

Maybe mention that X is encoded the same as the public values (AFAIK
I-D.irtf-cfrg-curves doesn't explicitly specify an encoding for the
shared secret - maybe it should?)

>    the number X are then converted into a big integer k.  This
>    conversion follows the network byte order.  This step differs from
>    [RFC5656].

Maybe "converted into a big integer k by treating the value X as an
unsigned, network-byte order integer".

-d