Re: Curve25519/448 key agreement for SSH

Damien Miller <[email protected]> writes:

>> 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.

Agreed, it now has two paragraphs:

   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.

   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 with chapter 4 of [RFC5656].

>>    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.

I've changed it into:

   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 32 bytes when Curve25519 is
   used and 56 bytes when Curve448 is used.  The encodings of all values
   are defined in [I-D.irtf-cfrg-curves].

>>    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.

Fixed.

> 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 cfrg-curves document should specify encoding for everything, see
section 5.  It has the encodeUCoordinate function and also says:

   Finally, encode the resulting value as 32 or 56 bytes in little-
   endian order.  For X25519, the unused, most-significant bit MUST be
   zero.

So I believe this is covered by the previous changed paragraph which
refers to cfrg-curves for all encodings.

>>    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".

For Curve448, it appears to lead to 56 byte bigint or sometimes (when
msb is 1) a 57 byte bigint with leading zero.  Is this a problem?  If
somebody could observe the size difference, it would leak the MSB.  If
worth resolving, how to resolve it?

/Simon

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJWQb7LAAoJEIYLf7sy+BGd2wAH/jz6mj74w16ygHLH0Y8/ydYM
6tN+6vseYoHJY6t0c1HZJdEur9lM0A3PtfaaDl7xZM8TTd/R19cdooXjEFfNCE6f
ePNSZcszVgUgKb4ZATDf23A4h/RahK9iPZEkMInAeq0A7egH8A80+k2M4AAqJCv8
n/Yx/6fQKxjsA1kNFH0LUfMSF1hQ8PHPCqaqVk55jiZyKHv2+BD9K/tSKbt1ZXMW
QOTD6uc5EFuxAqkJUGIvWmH/cmXxEoINV9Bsow0ou0IRMR7ufOFyG9A5mTZB9I4H
azzrVsVSuG8Lge2oLzRx1WqmUa5IPTgwiz4pggppsb8J0ea5y+T+jqKkWNPwsw4=
=txWr
-----END PGP SIGNATURE-----