RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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**.

Report New Errata



Advanced Search