cv25519 scalar byte order
look at my.amazin.horse
Thu Feb 15 10:54:39 CET 2018
> 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:
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
> 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!
More information about the Gnupg-devel