# RFC Errata

Found 5 records.

## Status: Verified (3)

#### 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.

## Status: Reported (2)

#### RFC 7748, "Elliptic Curves for Security", January 2016

Source of RFC: IRTF
Errata ID: 7096

**Status: Reported
Type: Technical
Publication Format(s) : TEXT**

Reported By: James Muir

Date Reported: 2022-08-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.

Errata ID: 7095

**Status: Reported
Type: Editorial
Publication Format(s) : TEXT**

Reported By: James Muir

Date Reported: 2022-08-18

Section 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.