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