Re: ssh-ed25519 implementations

[Ron Frederick <ronf%timeheart.net@localhost>]

On May 10, 2017, at 9:18 AM, Mark Baushke <mdb%juniper.net@localhost> wrote:

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.

I have implemented for ssh-ed25519 public keys and certificates in AsyncSSH, and my implementation currently uses opaque byte strings taken from the implementation of curve25519 in libsodium when encoding public and private keys. These byte strings are encoded as SSH ‘string’ values (4-byte big-endian string length followed by an array of bytes of that length). The public key is a single string value and the private key is the concatenation of two string values (public key followed by private key, each with its own preceding 4-byte length value). This implementation interoperates with OpenSSH.

More details can be found in the Internet Draft at:

https://tools.ietf.org/html/draft-bjh21-ssh-ed25519-00

This refers to:

https://tools.ietf.org/html/draft-josefsson-eddsa-ed25519-03

I have also implemented curve25519-sha256%libssh.org@localhost key exchange as documented at:

https://git.libssh.org/projects/libssh.git/plain/doc/curve25519-sha256%libssh.org.txt@localhost

OpenSSH also implements this, and makes it available under both this name and more recently as just “curve25519-sha256”.

Here, the public key values exchanged in messages like KEX_ECDH_INIT and KEX_ECDH_REPLY are opaque byte strings similar to the above. As discussed in https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04, the final computed shared secret value is converted to an integer by taking the 32-byte point obtained by scalar multiplication and treating the bytes as a bigendian (network byte order) value, but this value is never directly sent on the wire, so I’m not sure the “mpint" encoding ever applies to it. The only values on the wire are the public keys and signature values, all of which are encoded as strings.

-- 
Ron Frederick
ronf%timeheart.net@localhost