# RFC Errata

Found 8 records.

## Status: Verified (4)

#### RFC 8439, "ChaCha20 and Poly1305 for IETF Protocols", June 2018

Source of RFC: IRTF
Errata ID: 5689

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

Reported By: Stefan Heiss

Date Reported: 2019-04-11

Verifier Name: Colin Perkins

Date Verified: 2019-04-15

Section 2.5.1 says:

for i=1 upto ceil(msg length in bytes / 16) n = le_bytes_to_num(msg[((i-1)*16)..(i*16)] | [0x01]) a += n a = (r * a) % p end

It should say:

for i=1 upto ceil(msg length in bytes / 16) j = min(i*16-1, msg length in bytes - 1) n = le_bytes_to_num(msg[((i-1)*16)..j] | [0x01]) a += n a = (r * a) % p end

Notes:

Correction of Errata 5675

Errata ID: 5989

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

Reported By: Lê Minh Đăng

Date Reported: 2020-02-26

Verifier Name: Stanislav Smyshlyaev

Date Verified: 2021-04-28

Section 2.4.1 says:

encrypted_message += block ^ key_stream ... encrypted_message += (block^key_stream)[0..len(plaintext)%64]

It should say:

encrypted_message |= block ^ key_stream ... encrypted_message |= (block^key_stream)[0..len(plaintext)%64]

Notes:

The encrypted_message is the result of concatenation of blocks.

"|" and "|=" are used for concatenation elsewhere in the document, changing "+=" to "|=" will reduce ambiguity.

Errata ID: 6025

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

Reported By: James Muir

Date Reported: 2020-03-21

Verifier Name: Stanislav Smyshlyaev

Date Verified: 2021-11-17

Section 3 says:

A constant-time but not optimal approach would be to naively implement the arithmetic operations for 288-bit integers, because even a naive implementation will not exceed 2^288 in the multiplication of (acc+block) and r.

It should say:

It is possible to create a constant-time, but not optimal, implementation by implementing arithmetic operations for 256-bit integers, because even a naive implementation will not exceed 2^256 in the multiplication of (acc+block) and r (note that we have r < 2^124 because r is "clamped").

Notes:

There are two issues 1) 288 bits is too big, and 2) a naive implementation of 288 bit integer arithmetic isn't necessarily constant time.

#1: 288 seems to be tied to the machine int size and assumes 32-bit integers (288 is nine 32-bit integers). It is probably better to give a number independent of the machine int size. It is possible to compute Poly1305 using 255 bit arithmetic. Padded blocks of the message are in the range 2^8, 2^8 +1,..., 2^129 -1. Assuming that the partial reduction step always reduces the accumulator to 130 bits, we have acc < 2^130, so acc+block < 2^131. r is a 16 byte value, but some of its bits are "clampled", so we have r < 2^124. Thus (acc+block)*r < 2^255; so we can get by with 255 bit big-integer arithmetic (probably 256 bits is more convenient to work with).

#2: big-integer arithmetic can be implemented in constant time, but perhaps not in a obvious or naive way. Keeping things constant time seems to depend on the characteristics of the underlying processor.

Errata ID: 6257

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

Reported By: Alan Presser

Date Reported: 2020-08-18

Verifier Name: Stanislav Smyshlyaev

Date Verified: 2021-04-13

Section 2.5.2 says:

Adding s, we get this number, and serialize if to get the tag:

It should say:

Adding s, we get this number, and serialize it to get the tag:

Notes:

It's a trivial typo. Change "if" to "it".

## Status: Reported (3)

#### RFC 8439, "ChaCha20 and Poly1305 for IETF Protocols", June 2018

Source of RFC: IRTF
Errata ID: 6569

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

Reported By: David Reed

Date Reported: 2021-05-03

Section 2.3 says:

o A 32-bit block count parameter, treated as a 32-bit little-endian integer.

It should say:

o A 32-bit block count parameter, treated as a 32-bit integer.

Notes:

The block count is not used as a little-endian integer. An example of this can be seen in the example test vector in section 2.3.2, where Block Count = 1, but the block count word of the initial state is 00000001.

Errata ID: 6989

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

Reported By: Mike Markowitz

Date Reported: 2022-06-10

Section 2.8.2 says:

Poly1305 r = 455e9a4057ab6080f47b42c052bac7b

It should say:

Poly1305 r = 8455e9a4057ab6080f47b42c052bac7b

Notes:

fist nibble of r appears to be missing

Errata ID: 7880

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

Reported By: Volker Diels-Grabsch

Date Reported: 2024-04-03

Section 2.4.1 says:

encrypted_message |= (block^key_stream)[0..len(plaintext)%64]

It should say:

encrypted_message |= (block^key_stream)[0..(len(plaintext)%64)-1]

Notes:

If the plaintext size is not a multiple of 64 bytes, there is an off-by-one error in appending the final block of the encrypted message. In the original version, the encrypted message would always be one byte larger than the plaintext.

The corrected version ensures that the encrypted message size is always equal to the plaintext size.

For completeness: If the plaintext size is a multiple of 64 bytes, the second part of the code is skipped. Hence, this off-by-one error is not triggered in that specific case.

(Non-)relation to correction 5989: The "original text", as quoted here, assumes that correction 5989 has already been applied. Correction 5989 deals with a different issue of this line of code, namely, the replacement of "+=" by "|=". This is completely orthogonal to the off-by-one error described here.

## Status: Rejected (1)

#### RFC 8439, "ChaCha20 and Poly1305 for IETF Protocols", June 2018

Source of RFC: IRTF
Errata ID: 5675

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

Reported By: Stefan Heiss

Date Reported: 2019-03-25

Rejected by: Colin Perkins

Date Rejected: 2019-04-15

Section 2.5.1 says:

for i=1 upto ceil(msg length in bytes / 16) n = le_bytes_to_num(msg[((i-1)*16)..(i*16)] | [0x01]) a += n a = (r * a) % p end

It should say:

for i=1 upto floor(msg length in bytes / 16) j = min(i*16-1, msg length in bytes - 1) n = le_bytes_to_num(msg[((i-1)*16)..j] | [0x01]) a += n a = (r * a) % p end

Notes:

Corection for lengths of msg blocks (full blocks are of size 16, NOT 17 and last blocks of size != 16 have to be treated separately).

--VERIFIER NOTES--

Rejected in favour of errata 5689.