# RFC Errata

Found 4 records.

## Status: Verified (1)

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

Source of RFC: IRTF
Errata ID: 4730

**Status: Verified
Type: Technical
**

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.

## Status: Reported (3)

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

Source of RFC: IRTF
Errata ID: 5568

**Status: Reported
Type: Technical
**

Reported By: Juan Alcasabas

Date Reported: 2018-12-07

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.

Errata ID: 5651

**Status: Reported
Type: Technical
**

Reported By: Pierre Laurent

Date Reported: 2019-03-11

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)

Errata ID: 5028

**Status: Reported
Type: Editorial
**

Reported By: Adam Langley

Date Reported: 2017-06-02

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.