RFC Errata
Found 7 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: 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**.