Re: ssh-ed25519 implementations

["Mark D. Baushke" <mdb%juniper.net@localhost>]

Eric Rescorla <ekr%rtfm.com@localhost> writes:

> On Wed, May 10, 2017 at 9:18 AM, Mark Baushke <mdb%juniper.net@localhost> wrote:
> 
> > 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.
> >
> 
> Thanks. To be clear, I'm not saying this is the wrong thing in the draft
> (though I do think it's kind of an unfortunate outcome). I just think it's
> critically important to be clear.

Thank you for the clarification. I agree it is unfortunate.

> > 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.
> >
> 
> I tend to think the 7748 method, but all the options are pretty terrible
> here

I am agnostic on the best way to deal with curve448 for SSH.
I agree all options are unlpleasant.

RFC 8032 vs implementations for ssh-ed25519 will have the same issue.

So, if https://tools.ietf.org/html/draft-ietf-curdle-ssh-ed25519
is updated to point to RFC 8032, it will likely need to worry about
the mpint vs little-endian encoding issue as well. :-(

	-- Mark