RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 6 records.

Status: Verified (2)

RFC 5116, "An Interface and Algorithms for Authenticated Encryption", January 2008

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 4008
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Tapio Sokura
Date Reported: 2014-06-08
Verifier Name: Kathleen Moriarty
Date Verified: 2015-03-31

Section 2.2 says:

   The
   authenticated decrypt operation will, with high probability, return
   FAIL whenever the inputs N, P, and A were crafted by a nonce-
   respecting adversary that does not know the secret key (assuming that
   the AEAD algorithm is secure).

It should say:

   The
   authenticated decrypt operation will, with high probability, return
   FAIL whenever the inputs N, C, and A were crafted by a nonce-
   respecting adversary that does not know the secret key (assuming that
   the AEAD algorithm is secure).

Notes:

Inputs to the authenticated decrypt operation do not include plaintext P, but instead includes ciphertext C.

Thanks for the correction, since this is descriptive text, it will be marked as editorial.

Errata ID: 4268
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Martin Thomson
Date Reported: 2015-02-09
Verifier Name: Kathleen Moriarty
Date Verified: 2015-03-31

Section 3.1 says:

As an example, the nonce 100 could be stored, after which the nonces
1 through 99 could be used for encryption.  The nonce value 200 could
be stored at the same time that nonces 1 through 99 are being used,
and so on.

It should say:

As an example, the nonce 100 could be stored, after which the nonces
1 through 99 could be used for encryption.  Then, nonces 101 to 199
could be used after the nonce 200 was saved.

Notes:

This might be confusing in its original form, maybe even suggesting an interpretation where nonces are reused.

Status: Reported (4)

RFC 5116, "An Interface and Algorithms for Authenticated Encryption", January 2008

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 4338
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Maarten Bodewes
Date Reported: 2015-04-19

Section 3.2.1 says:

      +-------------------+--------------------+---------------+
      |    Fixed-Common   |   Fixed-Distinct   |    Counter    |
      +-------------------+--------------------+---------------+
       <---- implicit ---> <------------ explicit ------------>

                 Figure 2: Partially implicit nonce format

      The rationale for the partially implicit nonce format is as
      follows.  This method of nonce construction incorporates the best
      known practice; it is used by both GCM Encapuslating Security
      Payload (ESP) [RFC4106] and CCM ESP [RFC4309], in which the Fixed
      field contains the Salt value and the lowest eight octets of the
      nonce are explicitly carried in the ESP packet.  In GCM ESP, the
      Fixed field must be at least four octets long, so that it can
      contain the Salt value.  In CCM ESP, the Fixed field must be at
      least three octets long for the same reason.  This nonce
      generation method is also used by several counter mode variants
      including CTR ESP.

It should say:

      +-------------------+------------------------------------+
      |    Fixed-Common   |           Fixed-Distinct           |
      +-------------------+------------------------------------+
       <---- implicit ---> <------------ explicit ------------->

                 Figure 2: Partially implicit nonce format

      The rationale for the partially implicit nonce format is as
      follows.  This method of nonce construction incorporates the best
      known practice; it is used by both GCM Encapuslating Security
      Payload (ESP) [RFC4106] and CCM ESP [RFC4309], in which the
      Fixed-Common field contains the Salt value and the lowest eight
      octets of the nonce are explicitly carried in the ESP packet. In
      GCM ESP, the Fixed-Common field must be at least four octets
      long, so that it can contain the Salt value.  In CCM ESP, the
      Fixed-Common field must be at least three octets long for the
      same reason.  This nonce generation method is also used by
      several counter mode variants including CTR ESP.

Notes:

The counter is generally not considered part of the nonce.

The counter itself is not /send/ as part of the nonce, so the figure doesn't comply with the sentence in the text above: "We call the portion of the nonce that is stored or sent with the ciphertext the explicit part." Furthermore the text above also reads: "lowest eight octets of the nonce are explicitly carried in the ESP packet"

The referred to documents (e.g. RFC 4106) also explicitly specify a 12 byte nonce.

The GCM documentation recommends using a nonce of 96 bits (12 bytes) and then proceeds to build a counter (specified as J0) out of that. If the nonce is considered 128 bits instead then J0 is created using a GMAC invocation, which is probably not what was meant by this specification.

Finally, the text about GCM ESP and CCM ESP didn't distinguish between Fixed-Common and Fixed Distinct. It seems clear to me that Fixed-Common was meant the text below Figure 2. (If this should be in a separate Report, please let me know - the text between these parentheses may be removed of course)

Errata ID: 5219
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Brian Smith
Date Reported: 2017-12-28

Section 5.1, 5.2 says:

P_MAX is 2^36 - 31 octets

It should say:

P_MAX is 2^36 - 32 octets

Notes:

There is an off-by-one error in the specification of the maximum input size for AES-GCM.

NIST SP-800-38D [1] Section 5.2.1.1 says:

len(P) ≤ 2^39-256


(2^39-256) / 8 = 2^36 - 32

See also RFC 7539 Errata 4858.

[1] http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf

Errata ID: 6415
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Jordan Smith
Date Reported: 2021-01-29

Section 3.2 says:

  Implementations
   SHOULD support 12-octet nonces in which the Counter field is four
   octets long.

It should say:

  Implementations
   SHOULD support 12-octet nonces in which the Fixed field is four
   octets long.

Notes:

The ascii diagram given shows the Fixed portion being smaller and the examples given in https://tools.ietf.org/id/draft-mcgrew-iv-gen-01.html also show that the Fixed portion is 4 bytes.

Also an 8 byte counter gives 2^64, where a 4 byte counter would only give 2^32

Errata ID: 5233
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Lars Maier
Date Reported: 2018-01-10

Section 5.3 says:

An AEAD_AES_128_CCM ciphertext is exactly 16 octets longer than its
 corresponding plaintext.

It should say:

An AEAD_AES_128_CCM ciphertext is exactly 2 octets longer than its
 corresponding plaintext.

Notes:

As described in NIST SP 800-38c the length of the MAC is given in bits. The algorithm specified therein at 6.2 returns a string of PLen + TLen bits.

Report New Errata



Advanced Search