[Curdle] AD Review of: draft-ietf-curdle-ssh-curves-04.txt

[Eric Rescorla <[e-mail]>]

Document: draft-ietf-curdle-ssh-curves-04.txt

TECHNICAL
S 2.

   The methods are based on Curve25519 and Curve448 scalar
   multiplication, as described in [RFC7748].  Private and public keys
   are generated as described therein.  Public keys are defined as
   strings of 32 bytes for Curve25519 and 56 bytes for Curve448.
   Clients and servers MUST fail the key exchange if the length of the
   received public keys are not the expected lengths, or if the derived
   shared secret only consists of zero bits.  No further validation is
   required beyond what is discussed in [RFC7748].

Is any other validation specified? Maybe I'm missing it, but I don't
see any.


S 2.1. IMPORTANT:
   other side’s public key and the local private key scalar.  The 32 or
   56 bytes of X are converted into K by interpreting the bytes as an
   unsigned fixed-length integer encoded in network byte order.  This
   conversion follows the normal "mpint" process as described in section
   5 of [RFC4251].

It appears you are specifying the opposite encoding from RFC 7748 which
says:

   or GF(2^448 - 2^224 - 1) and are encoded as an array of bytes, u, in
   little-endian order such that u[0] + 256*u[1] + 256^2*u[2] + ... +

First, I want to confirm that this is in fact true and that I'm not
missing something. Second, if it's not true, this needs to be called out
in big letters.


EDITORIAL
   Curve25519 provide strong security and is efficient on a wide range
   of architectures, and has properties that allows better
   implementation properties compared to traditional elliptic curves.
   Curve448 with SHA-512 is similar, but have not received the same

has not received

-Ekr