errata logo graphic

Found 3 records.

Status: Verified (2)

RFC5116, "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

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

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 (1)

RFC5116, "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

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)


Report New Errata