cv25519 scalar byte order

[Vincent Breitmoser]

Hey gniibe,

> 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.

That actually explains a lot, haha!

I was following the reference to RFC7748 from rfc4880bis:
https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-04#section-13.1

And given that the public point is encoded with a 0x40 prefix, I assumed
that X25519 was used the same way as EdDSA as a type of ECDH. What else
would define the "custom point compression" format that is used here, if
not X25519?

> it's more relevant to have new algorithm ID of twenty-something.

That would be a lot simpler both in terms of specification and
implementation - just put byte arrays into a well-defined,
well-specified and widely used method. Compared to actually dealing with
points on curves and their different representations etc.

Alas, it's probably too late for that idea to be useful.

> 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.

I'm not sure. If it's valid to "just X25519, then KDF" (and that worked
at least for me, modulo reversing the byte array) then I would
definitely point that out specifically in the spec, as it greatly
simplifies implementation. I had failed implementing cv25519 support
using bouncycastle's plain Curve25519 primitives before.

Thanks for your input so far, much appreciated!

 - V