Subject: ssh-ed25519 implementations

From: "Mark D. Baushke" <[email-masked]>
Date: Wed, 10 May 2017 18:39:19 -0700

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

Hi,

Eric Rescorla <[email-masked]> 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-masked], 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-masked] with your opinions.

        Thank you,
        -- Mark

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Wed, 10 May 2017 21:53:01 -0600

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-masked] 
Subject: ssh-ed25519 implementations

Hi,

        Thank you,
        -- Mark