|
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
[Second attempt. my first attempt got bounced by fraud detection checks for some unknown reason. -- mdb] Hi, Eric Rescorla <ekr%rtfm.com@localhost> 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 curve25519-sha256%libssh.org@localhost, 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 curdle%ietf.org@localhost with your opinions. Thank you, -- Mark |