RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 7 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 (2)

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

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.

Report New Errata



Advanced Search