RFC Errata
Found 9 records.
Status: Verified (4)
RFC 7748, "Elliptic Curves for Security", January 2016
Source of RFC: IRTF
Errata ID: 4730
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Adam Langley
Date Reported: 2016-07-05
Verifier Name: Lars Eggert
Date Verified: 2016-07-05
Section 4.1 says:
V(P) 147816194475895447910205935684099868872646061346164752889648818 37755586237401
It should say:
V(P) 431144251710685529207648989359339670393703861982038067307639101 66200978582548
Notes:
The Montgomery form of the curve is generally used with a ladder, where the v coordinate is unused and unspecified. Thus I picked the smaller of the two possible values for v.
However, the curve is birationally equivalent to edwards25519, where both coordinates of the base point are used and are already in widespread use. Sadly, picking the smaller of the values for v ends up mapping to the negative of the base point on edwards25519.
This change replaces v with -v so that it matches up.
Errata ID: 7625
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tomasz Mioduszewski
Date Reported: 2023-08-31
Verifier Name: Stanislav Smyshlyaev
Date Verified: 2023-09-04
Section 5 says:
swap ^= k_t
It should say:
swap = swap XOR k_t
Notes:
The '^' symbol is used inconsistently. In the line `swap ^= k_t` this symbol means the XOR operation, while later, e.g. in line `x_3 = (DA + CB)^2`, it indicates exponentiation. Pseudocode in this document also denotes the XOR operation in the following way: `x_2 = x_2 XOR dummy`. The inconsistent use of the '^' symbol may cause confusion. If one were to perform the operation `swap = swap (to the power of) k_t` instead of `swap = swap XOR k_t`, they would get incorrect results.
Errata ID: 5028
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adam Langley
Date Reported: 2017-06-02
Verifier Name: Stanislav Smyshlyaev
Date Verified: 2020-12-15
Section 5.2 says:
Input u-coordinate as a number (base 10):
It should say:
Decoded u-coordinate as a number (base 10):
Notes:
It is unclear that the base 10 numbers are the decoded values (i.e. after masking). That should have been made more explicit to reduce confusion.
Errata ID: 7095
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: James Muir
Date Reported: 2022-08-18
Verifier Name: RFC Editor
Date Verified: 2024-01-22
Appendix A says:
This section specifies the procedure that was used to generate the above curves; specifically, it defines how to generate the parameter A of the Montgomery curve y^2 = x^3 + A*x^2 + x.
It should say:
This section specifies the procedure that was used to generate the above curves; specifically, it defines how to generate the parameter A of the Montgomery curve v^2 = u^3 + A*u^2 + u.
Notes:
For consistency with the other parts of the document (e.g. Section 3), use the variables u and v in the Montgomery curve equation.
Status: Reported (1)
RFC 7748, "Elliptic Curves for Security", January 2016
Source of RFC: IRTF
Errata ID: 7824
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Jose Luis Amador Moreno
Date Reported: 2024-02-27
Section 5.2 says:
Input scalar:
203d494428b8399352665ddca42f9de8fef600908e0d461cb021f8c5
38345dd77c3e4806e25f46d3315c44e0a5b4371282dd2c8d5be3095f
Input scalar as a number (base 10):
633254335906970592779259481534862372382525155
252028961056404001332122152890562527156973881
968934311400345568203929409663925541994577184
Input u-coordinate:
0fbcc2f993cd56d3305b0b7d9e55d4c1a8fb5dbb52f8e9a1e9b6201b
165d015894e56c4d3570bee52fe205e28a78b91cdfbde71ce8d157db
Input u-coordinate as a number (base 10):
622761797758325444462922068431234180649590390
024811299761625153767228042600197997696167956
134770744996690267634159427999832340166786063
Output u-coordinate:
884a02576239ff7a2f2f63b2db6a9ff37047ac13568e1e30fe63c4a7
ad1b3ee3a5700df34321d62077e63633c575c1c954514e99da7c179d
It should say:
Input scalar:
203d494428b8399352665ddca42f9de8fef600908e0d461cb021f8c5
38345dd77c3e4806e25f46d3315c44e0a5b4371282dd2c8d5be3095f
Input scalar as a number (base 10):
633254335906970592779259481534862372382525155
252028961056404001332122152890562527156973881
968934311400345568203929409663925541994577184
Input u-coordinate:
1e37b1e6368991ebce5815bf6b567cedfec0d32246815a6707f02c4a
61247656f5df569f02613cc5bcedf7a924424ff063c9c0aff5b395ae
Input u-coordinate as a number (base 10):
495683502945530038677307449626580741146441879
406119444019011021926629134928724388368946852
962833749157931574628774133988199037473470238
Output u-coordinate:
d34142faca68f7a3ddf805fa39cc706d5ab3f5633ceff5e6462b775d
ef45f33083461dcf821cc3f0f74a813277e6895a35d958feef79a5bf
Notes:
Regarding Section 5.2, X448, second vector, the given input u-coordinate is not part of a valid point on the Montgomery form of Curve448.
I suggest replacing the point with a valid one: (2^447 + 100)*G
See the SageMath code (permalink): https://web.archive.org/web/20240227114733/https://pastebin.com/yAuzvEJG
Status: Held for Document Update (1)
RFC 7748, "Elliptic Curves for Security", January 2016
Source of RFC: IRTF
Errata ID: 7096
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: James Muir
Date Reported: 2022-08-18
Held for Document Update by: Nick Sullivan
Date Held: 2025-01-18
Section Appendix A says:
# section A.1 sage code:
for A in xrange(3, int(1e9)):
if (A-2) % 4 != 0:
continue
# section A.3 sage code:
for uInt in range(1, 1e3):
u = F(uInt)
It should say:
# section A.1 sage code:
for A in xsrange(3, int(1e9)):
if (A-2) % 4 != 0:
continue
# section A.3 sage code:
for uInt in xsrange(1, int(1e3)):
u = F(uInt)
Notes:
"xrange" is not recognized by Sage with python 3, so the script from section A.1 fails with a syntax error (using "xrange" likely worked fine for Sage with python 2). The suggested changes in A.3 are just for consistency.
Held for Document Update. Errata 7096 updates Sage code in Appendix A to make it compatible with Python 3 by replacing 'xrange' with 'xsrange'. This change addresses a compatibility issue for modern implementations but does not affect the cryptographic security or functionality of the protocol, making it low-priority and suitable for future document updates. - CFRG co-chair
Status: Rejected (3)
RFC 7748, "Elliptic Curves for Security", January 2016
Source of RFC: IRTF
Errata ID: 5568
Status: Rejected
Type: Technical
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
Notes:
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.
--VERIFIER NOTES--
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.
Errata ID: 5651
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Pierre Laurent
Date Reported: 2019-03-11
Rejected by: Stanislav Smyshlyaev
Date Rejected: 2020-12-15
Section 5 says:
z_2 = E * (AA + a24 * E)
It should say:
z_2 = E * (BB + a24 * E)
Notes:
When BB is used, the point multiplication of the second test vector
P = (0x13a415c749d54cfc3e3cc06f10e7db312cae38059d95b7f4d3116878120f21e5, 0x1)
by scalar k
0x4dba18799e16a42cd401eae021641bc1f56a7d959126d25a3c67b4d1d4e96648
gives the expected point
[k]P = (0x5779ac7a64f7f8e652a19f79685a598bf873b8b45ce4ad7a7d90e87694decb95, 0x1)
The implementation based on AA gives the unexpected point
[k]P = (0x3884d5c22af664f822cb3dd728b03c9fac1e1d78c772a74f05546566bd7bed9c, 1)
--VERIFIER NOTES--
It is proposed to modify the algorithm description for calculation of z_2. However, after checking the original algorithm independently, it was confirmed that the expected numbers are obtained. Therefore, the existing text of RFC does not have any errors here.
Errata ID: 7879
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Nawras Hussein Sabbry
Date Reported: 2024-04-02
Rejected by: Nick Sullivan
Date Rejected: 2025-01-18
Section 5 says:
z_2 = E * (AA + a24 * E)
It should say:
z_2 = E * (BB + a24 * E)
Notes:
In the for loop on page 8, the variable AA should be replaced with BB in Z_2. This modification is necessary because the mathematical formula for point doubling on the Montgomery curve according to (https://en.wikipedia.org/wiki/Montgomery_curve#Montgomery_arithmetic) indicates that Z2n (equivalent to Z_2 in this case) is calculated as follows: Z2n = 4XnZn((Xn-Zn)^2 + ((A+2)/4)(4XnZn)). It is observed in this equation that the operation in the (Xn-Zn)^2 part involves subtraction similar to the variable B, while the operation in the variable A involves addition. Considering this discrepancy, it is suggested to substitute AA with BB for correctness.
--VERIFIER NOTES--
Duplicate of errata report 5651, rejected on CFRG list