Damien Miller <djm%mindrot.org@localhost> 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
Attachment:
signature.asc
Description: PGP signature