RFC 7748, "Elliptic Curves for Security", January 2016Source of RFC: IRTF
Errata ID: 5568
Publication Format(s) : TEXT
Reported By: Juan Alcasabas
Date Reported: 2018-12-07
Rejected by: Stanislav Smyshlyaev
Date Rejected: 2020-12-15
Section 5.2 says:
Input u-coordinate: e5210f12786811d3f4b7959d0538ae2c31dbe7106fc03c3efc4cd549c715a493
It should say:
Input u-coordinate: e5210f12786811d3f4b7959d0538ae2c31dbe7106fc03c3efc4cd549c715a413
In the X25519 2nd test vector the last byte of input u-coordinate should be 13 instead of 93. This will fix inconsistency between u-coordinate, its base10 representation and the output u-coordinate.
A change of one bit of the input u-coordinate in the hexadecimal representation is proposed (to make it "consistent" with the base 10 representation). However, implementations of x25519 should "mask" that bit after taking a u-coordinate as an input - therefore, the existing text of RFC does not have any errors there.