cv25519 scalar byte order
Vincent Breitmoser
look at my.amazin.horse
Thu Feb 15 00:24:11 CET 2018
> I wonder if we have difference in the interpretation of secret part
> (skey[3]).
>
> In GnuPG, this part is interpreted as standard MPI representation
> (big-endian).
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:
# Although the functions work internally with integers, the inputs and
# outputs are 32-byte strings (for X25519) or 56-byte strings (for X448)
# and this specification defines their encoding.
My expectation was that skey[3] would be passed to the functions as-is,
which was matched by GnuPG for EdDSA, but not X25519.
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. :)
- V
More information about the Gnupg-devel
mailing list