# RFC Errata

Found 9 records.

## Status: Verified (3)

### RFC 8032, "Edwards-Curve Digital Signature Algorithm (EdDSA)", January 2017

Source of RFC: IRTF
Errata ID: 5930

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

Reported By: Daniel Bleichenbacher

Date Reported: 2019-12-06

Verifier Name: Colin Perkins

Date Verified: 2021-05-24

Section 6 says:

def verify(public, msg, signature): if len(public) != 32: raise Exception("Bad public key length") if len(signature) != 64: Exception("Bad signature length")

It should say:

def verify(public, msg, signature): if len(public) != 32: raise Exception("Bad public key length") if len(signature) != 64: raise Exception("Bad signature length")

Notes:

Missing raise before Exception

Errata ID: 5519

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

Reported By: Susumu Endoh

Date Reported: 2018-10-10

Verifier Name: Colin Perkins

Date Verified: 2019-04-09

Section 5.1.7 says:

Decode the first half as a point R, and the second half as an integer S, in the range 0 <= s < L.

It should say:

Decode the first half as a point R, and the second half as an integer S, in the range 0 <= S < L.

Notes:

original document expression is ' 0 <= s < L', but it must be '0 <= S < L'. upper/lower case problem.

Errata ID: 6851

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

Reported By: Martin Thomson

Date Reported: 2022-02-15

Verifier Name: RFC Editor

Section 8.7 says:

As an API consideration, this means that any Initialize Update Finalize (IFU) verification interface is prone to misuse.

It should say:

As an API consideration, this means that any Initialize Update Finalize (IUF) verification interface is prone to misuse.

Notes:

Typo in acronym.

## Status: Reported (3)

### RFC 8032, "Edwards-Curve Digital Signature Algorithm (EdDSA)", January 2017

Source of RFC: IRTF
Errata ID: 5968

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

Reported By: Valeria Nikolaenko

Date Reported: 2020-01-28

Section 3.1 says:

3.1. Encoding An integer 0 < S < L - 1 is encoded in little-endian form as a b-bit string ENC(S).

It should say:

3.1. Encoding An integer 0 <= S <= L - 1 is encoded in little-endian form as a b-bit string ENC(S).

Notes:

The range of the scalar should include the end-points: 0 and L-1.

Errata ID: 6306

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

Reported By: Dmitry Khovratovich

Date Reported: 2020-10-15

Section 5.1.7 says:

Decode the first half as a point R, and the second half as an integer S, in the range 0 <= s < L. Decode the public key A as point A'. If any of the decodings fail (including S being out of range), the signature is invalid. 2. Compute SHA512(dom2(F, C) || R || A || PH(M)), and interpret the 64-octet digest as a little-endian integer k. 3. Check the group equation [8][S]B = [8]R + [8][k]A'. It's sufficient, but not required, to instead check [S]B = R + [k]A'.

It should say:

Decode the first half R as a point R', and the second half as an integer S, in the range 0 <= S < L. Decode the public key A as point A'. If any of the decodings fail (including S being out of range), the signature is invalid. 2. Compute SHA512(dom2(F, C) || R || A || PH(M)), and interpret the 64-octet digest as a little-endian integer k. 3. Check the group equation [8][S]B = [8]R' + [8][k]A'. It's sufficient, but not required, to instead check [S]B = R' + [k]A'.

Notes:

1) public key R' and its encoding R are confused

2) s changed to S (this errata has been reported already)

Errata ID: 6348

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

Reported By: David Benjamin

Date Reported: 2020-12-02

Section 3.4 says:

Compute h = H(ENC(R) || ENC(A) || M), and check the group equation [2^c * S] B = 2^c * R + [2^c * h] A in E.

It should say:

Compute h = H(ENC(R) || ENC(A) || M), and check the group equation [2^c * S] B = [2^c] R + [2^c * h] A in E.

Notes:

Section 2 uses a separate notation, [n]X, for point multiplication, so this operation should use the brackets.

## Status: Held for Document Update (2)

### RFC 8032, "Edwards-Curve Digital Signature Algorithm (EdDSA)", January 2017

Source of RFC: IRTF
Errata ID: 5758

**Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT**

Reported By: Franck Rondepierre

Date Reported: 2019-06-21

Held for Document Update by: Stanislav Smyshlyaev

Date Held: 2022-02-15

Section 5.1. says:

(p+3)/8 3 (p-5)/8 x = (u/v) = u v (u v^7) (mod p)

It should say:

(p+3)/8 (p-5)/8 x = (u/v) = u (u v) (mod p)

Notes:

--VERIFIER NOTES--

The original text was correct (verified by Nick Sullivan).

01/28/2022: RFC Editor changed status to Reported per discussion with Stanislav V. Smyshlyaev.

02/15/2022: The status is changed to "Held for Document Update" by Stanislav Smyshlyaev. The proposed formulas are correct as well (for the specific case of the EdDSA parameters) and provide a slight efficiency gain.

Errata ID: 5759

**Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT**

Reported By: Franck Rondepierre

Date Reported: 2019-06-21

Held for Document Update by: Stanislav Smyshlyaev

Date Held: 2022-02-15

Section 5.2. says:

(p+1)/4 3 (p-3)/4 x = (u/v) = u v (u^5 v^3) (mod p)

It should say:

(p+1)/4 (p-3)/4 x = (u/v) = u (u v) (mod p)

Notes:

--VERIFIER NOTES--

The original text was correct (verified by Nick Sullivan).

01/28/2022: RFC Editor changed status to Reported per discussion with Stanislav V. Smyshlyaev.

02/15/2022: The status is changed to "Held for Document Update" by Stanislav Smyshlyaev. The proposed formulas are correct as well (for the specific case of the EdDSA parameters) and provide a slight efficiency gain.

## Status: Rejected (1)

### RFC 8032, "Edwards-Curve Digital Signature Algorithm (EdDSA)", January 2017

Source of RFC: IRTF
Errata ID: 5757

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

Reported By: Franck Rondepierre

Date Reported: 2019-06-21

Rejected by: Stanislav Smyshlyaev

Date Rejected: 2021-10-26

Section .1 says:

An element (x,y) of E is encoded as a b-bit string called ENC(x,y), which is the (b-1)-bit encoding of y concatenated with one bit that is 1 if x is negative and 0 if x is not negative.

It should say:

An element (x,y) of E is encoded as a b-bit string called ENC(x,y), which is the (b-1)-bit encoding of y concatenated with the least significant bit of x.

Notes:

Section 3.1 is not coherent with encodings described for Ed25519 (5.1.2) and Ed448 (5.2.2)

--VERIFIER NOTES--

The original text was correct (verified by Nick Sullivan).