Re: ssh-ed25519 implementations

Hey Mark!

For curve448-sha512, I have no objections for either choice of encoding. What’s more important than the choice of encoding is that there isn’t doubt about the choice of encoding.

That being said, I agree it may be slightly preferable to use signed mpint, given that this would be consistent with all other SSH key exchange methods, including Curve25519, and it would be weird for Curve448 to depart from this.

denis


From: Mark D. Baushke 
Sent: Wednesday, May 10, 2017 19:39
To: [email protected] 
Subject: ssh-ed25519 implementations


[Second attempt. my first attempt got bounced by fraud detection checks
for some unknown reason. -- mdb]

Hi,

Eric Rescorla <[email protected]> has brought to my attention that in
https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04 it is
currently specifying the SSH encoding of secrets on the wire using the
mpint process as described in section 5 of [RFC4251] while RFC 7748
describes using a little-endian format:

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

This seems to be what is being implemeneted for
[email protected], so I should make
an explicit note of this in the draft.

However, I am unaware of any curve448-sha512 implementations at
present and would like consensus that it should also follow the mpint
method rather than the RFC 7748 method.

Please reply to [email protected] with your opinions.

        Thank you,
        -- Mark