cv25519 scalar byte order

[NIIBE Yutaka]

Vincent Breitmoser <look at my.amazin.horse> wrote:
> MPIs are specified as big-endian, but this doesn't really have meaning
> if they aren't actually interpreted as numbers.  RFC7748 specifically
> defines EdDSA and X25519 over octet-strings:

That would be an interesting claim.

Please note that our adoption of ECDH using Curve25519 was done before
X25519.  In the context of RFC 6637, which defines 18 for ECDH public
key algorithm, it is a valid interpretation to handle the secret key
field in a way described in the section 9. Encoding of Public and
Private Keys.

It seems for me that you are implementing OpenPGP ECDH of Curve25519 on
top of X25519 function.  That's different path.  If so, I could
understand your claim, but... if it is the case, from my viewpoint, it's
more relevant to have new algorithm ID of twenty-something.

> My expectation was that skey[3] would be passed to the functions as-is,
> which was matched by GnuPG for EdDSA, but not X25519.

Since EdDSA has its own algorithm ID, the definition of the field is up
to EdDSA.

> As for where to go from here, I don't know. Most importantly, we should
> make sure the spec can be independently implemented in an interoperable
> way. :)

Perhaps, refering RFC7749 for Curve25519 is not good if it can result
such a confusion?  While I don't know how to improve the spec, but
it is needed to clarify.
--