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.