RFC Errata
Found 8 records.
Status: Verified (4)
RFC 7539, "ChaCha20 and Poly1305 for IETF Protocols", May 2015
Note: This RFC has been obsoleted by RFC 8439
Source of RFC: IRTF
Errata ID: 4371
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Adam Eijdenberg
Date Reported: 2015-05-21
Verifier Name: Lars Eggert
Date Verified: 2015-06-03
Section 2.8.1 says:
mac_data |= num_to_4_le_bytes(aad.length)
mac_data |= num_to_4_le_bytes(ciphertext.length)
It should say:
mac_data |= num_to_8_le_bytes(aad.length)
mac_data |= num_to_8_le_bytes(ciphertext.length)
Notes:
Per section 2.8 the lengths should be 64-bit (8 bytes), not 4.
After this change the pseudo-code output matches the test vectors shown in 2.8.2.
Errata ID: 4700
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Martin Thomson
Date Reported: 2016-05-24
Verifier Name: Lars Eggert
Date Verified: 2016-06-08
Section 2.8 says:
The output from the AEAD is twofold:
o A ciphertext of the same length as the plaintext.
o A 128-bit tag, which is the output of the Poly1305 function.
It should say:
The output from the AEAD is the concatenation of:
o A ciphertext of the same length as the plaintext.
o A 128-bit tag, which is the output of the Poly1305 function.
Notes:
Section 2.1 of RFC 5116 defines the AEAD interface, and that interface produces a single output, C (or an error).
Errata ID: 4858
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Timm Korte
Date Reported: 2016-11-10
Verifier Name: Lars Eggert
Date Verified: 2016-11-13
Section 2.8. says:
1. The amount of encrypted data possible in a single invocation is
2^32-1 blocks of 64 bytes each, because of the size of the block
counter field in the ChaCha20 block function. This gives a total
of 247,877,906,880 bytes, or nearly 256 GB.
It should say:
1. The amount of encrypted data possible in a single invocation is
2^32-1 blocks of 64 bytes each, because of the size of the block
counter field in the ChaCha20 block function. This gives a total
of 274,877,906,880 bytes, or nearly 256 GB.
Notes:
There is an error in the result of the P_MAX = ((2^32) - 1) * 64 calculation.
The correct value is 2_74_,877,906,880 while the document states 2_47_,877,906,880.
This error has already been adopted by multiple implementations as P_MAX value.
Errata ID: 4861
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Timm Korte
Date Reported: 2016-11-10
Verifier Name: Lars Eggert
Date Verified: 2016-11-13
Section 2.8. says:
o C_MAX = P_MAX + tag length = 247,877,906,896 octets.
It should say:
o C_MAX = P_MAX + tag length = 274,877,906,896 octets.
Notes:
When reviewing errata 4858, Adam Langely and Yoav Nir identified that this text should also be changed.
(This errata was created by duplicating 4858 in the system by Lars Eggert.)
Status: Reported (1)
RFC 7539, "ChaCha20 and Poly1305 for IETF Protocols", May 2015
Note: This RFC has been obsoleted by RFC 8439
Source of RFC: IRTF
Errata ID: 8274
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Alina Obst
Date Reported: 2025-01-30
Edited by: Nick Sullivan
Date Edited: 2025-03-06
Section 2.3.2 says:
ChaCha state with the key setup.
61707865 3320646e 79622d32 6b206574
03020100 07060504 0b0a0908 0f0e0d0c
13121110 17161514 1b1a1918 1f1e1d1c
00000001 09000000 4a000000 00000000
It should say:
ChaCha state with the key setup.
61707865 3320646e 79622d32 6b206574
03020100 07060504 0b0a0908 0f0e0d0c
13121110 17161514 1b1a1918 1f1e1d1c
01000000 09000000 4a000000 00000000
Notes:
Section 2.3 says: "A 32-bit block count parameter, treated as a 32-bit little-endian integer". In Section 2.3.2 the initial block counter is set to 1 which is 00000001 in big-endian hex. So I think, the corresponding entry in the state matrix (index 12) should be 01000000.
Note from CFRG Chair: this change also applies to RFC 8439, which supercedes RFC 7539
Status: Held for Document Update (3)
RFC 7539, "ChaCha20 and Poly1305 for IETF Protocols", May 2015
Note: This RFC has been obsoleted by RFC 8439
Source of RFC: IRTF
Errata ID: 4372
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Adam Eijdenberg
Date Reported: 2015-05-21
Held for Document Update by: Lars Eggert
Date Held: 2015-06-03
Section 2.5.1 says:
accumulator = 0
It should say:
a = 0
Notes:
This variable goes by both "accumulator" and "a" in the pseudo-code. Renaming this line allows the pseudo-code to pseudo-compile.
Errata ID: 4373
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Adam Eijdenberg
Date Reported: 2015-05-21
Held for Document Update by: Lars Eggert
Date Held: 2015-06-03
Section 2.5.1 says:
s = le_num(key[16..31])
It should say:
s = le_bytes_to_num(key[16..31])
Notes:
Other usages in the same pseudo-code example call the function le_bytes_to_num to perform what appears to be the same task.
Errata ID: 4434
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lukasz Stelmach
Date Reported: 2015-08-05
Held for Document Update by: Lars Eggert
Date Held: 2015-08-06
Section 2.6 says:
We take the first 256 bits or the serialized state, and use those as the one- time Poly1305 key: the first 128 bits are clamped and form "r", while the next 128 bits become "s".
It should say:
We take the first 256 bits of the serialized state, and use those as the one- time Poly1305 key: the first 128 bits are clamped and form "r", while the next 128 bits become "s".
Notes:
“We take the first 256 **or** the serialized state”. Should be **of**.