Skip to main content

4. Content Encryption Algorithms

  1. Content Encryption Algorithms

Section 8.3 of [RFC9052] contains a generic description of content encryption algorithms. This document defines the identifier and usages for three content encryption algorithms.

4.1. AES-GCM

The Galois/Counter Mode (GCM) mode is a generic AEAD block cipher mode defined in [AES-GCM]. The GCM mode is combined with the AES block encryption algorithm to define an AEAD cipher.

The GCM mode is parameterized by the size of the authentication tag and the size of the nonce. This document fixes the size of the nonce at 96 bits. The size of the authentication tag is limited to a small set of values. For this document, however, the size of the authentication tag is fixed at 128 bits.

The set of algorithms defined in this document is in Table 5.

  +=========+=======+==========================================+
  | Name    | Value | Description                              |
  +=========+=======+==========================================+
  | A128GCM |   1   | AES-GCM mode w/ 128-bit key, 128-bit tag |
  +---------+-------+------------------------------------------+
  | A192GCM |   2   | AES-GCM mode w/ 192-bit key, 128-bit tag |
  +---------+-------+------------------------------------------+
  | A256GCM |   3   | AES-GCM mode w/ 256-bit key, 128-bit tag |
  +---------+-------+------------------------------------------+

              Table 5: Algorithm Values for AES-GCM

Keys may be obtained from either a key structure or a recipient structure. Implementations that are encrypting or decrypting MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved.

When using a COSE key for this algorithm, the following checks are made:

  • The "kty" field MUST be present, and it MUST be "Symmetric".

  • If the "alg" field is present, it MUST match the AES-GCM algorithm being used.

  • If the "key_ops" field is present, it MUST include "encrypt" or "wrap key" when encrypting.

  • If the "key_ops" field is present, it MUST include "decrypt" or "unwrap key" when decrypting.

4.1.1. Security Considerations for AES-GCM

When using AES-GCM, the following restrictions MUST be enforced:

  • The key and nonce pair MUST be unique for every message encrypted.

  • The total number of messages encrypted for a single key MUST NOT exceed 2^32 [SP800-38D]. An explicit check is required only in environments where it is expected that this limit might be exceeded.

  • [RFC8446] contains an analysis on the use of AES-CGM for its environment. Based on that recommendation, one should restrict the number of messages encrypted to 2^24.5.

  • A more recent analysis in [ROBUST] indicates that the number of failed decryptions needs to be taken into account as part of determining when a key rollover is to be done. Following the recommendation in DTLS (Section 4.5.3 of [RFC9147]), the number of failed message decryptions should be limited to 2^36.

Consideration was given to supporting smaller tag values; the constrained community would desire tag sizes in the 64-bit range. Such use drastically changes both the maximum message size (generally not an issue) and the number of times that a key can be used. Given that Counter with CBC-MAC (CCM) is the usual mode for constrained environments, restricted modes are not supported.

4.2. AES-CCM

CCM is a generic authentication encryption block cipher mode defined in [RFC3610]. The CCM mode is combined with the AES block encryption algorithm to define an AEAD cipher that is commonly used in constrained devices.

The CCM mode has two parameter choices. The first choice is M, the size of the authentication field. The choice of the value for M involves a trade-off between message growth (from the tag) and the probability that an attacker can undetectably modify a message. The second choice is L, the size of the length field. This value requires a trade-off between the maximum message size and the size of the nonce.

It is unfortunate that the specification for CCM specified L and M as a count of bytes rather than a count of bits. This leads to possible misunderstandings where AES-CCM-8 is frequently used to refer to a version of CCM mode where the size of the authentication is 64 bits and not 8 bits. In most cryptographic algorithm specifications, these values have traditionally been specified as bit counts rather than byte counts. This document will follow the convention of using bit counts so that it is easier to compare the different algorithms presented in this document.

We define a matrix of algorithms in this document over the values of L and M. Constrained devices are usually operating in situations where they use short messages and want to avoid doing recipient- specific cryptographic operations. This favors smaller values of both L and M. Less-constrained devices will want to be able to use larger messages and are more willing to generate new keys for every operation. This favors larger values of L and M.

The following values are used for L:

16 bits (2): This limits messages to 2^16 bytes (64 KiB) in length. This is sufficiently long for messages in the constrained world. The nonce length is 13 bytes allowing for 2^104 possible values of the nonce without repeating.

64 bits (8): This limits messages to 2^64 bytes in length. The nonce length is 7 bytes, allowing for 2^56 possible values of the nonce without repeating.

The following values are used for M:

64 bits (8): This produces a 64-bit authentication tag. This implies that there is a 1 in 2^64 chance that a modified message will authenticate.

128 bits (16): This produces a 128-bit authentication tag. This implies that there is a 1 in 2^128 chance that a modified message will authenticate.

+====================+=======+====+=====+========+===============+
| Name               | Value | L  | M   |  Key   | Description   |
|                    |       |    |     | Length |               |
+====================+=======+====+=====+========+===============+
| AES-CCM-16-64-128  |   10  | 16 | 64  |  128   | AES-CCM mode  |
|                    |       |    |     |        | 128-bit key,  |
|                    |       |    |     |        | 64-bit tag,   |
|                    |       |    |     |        | 13-byte nonce |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-16-64-256  |   11  | 16 | 64  |  256   | AES-CCM mode  |
|                    |       |    |     |        | 256-bit key,  |
|                    |       |    |     |        | 64-bit tag,   |
|                    |       |    |     |        | 13-byte nonce |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-64-64-128  |   12  | 64 | 64  |  128   | AES-CCM mode  |
|                    |       |    |     |        | 128-bit key,  |
|                    |       |    |     |        | 64-bit tag,   |
|                    |       |    |     |        | 7-byte nonce  |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-64-64-256  |   13  | 64 | 64  |  256   | AES-CCM mode  |
|                    |       |    |     |        | 256-bit key,  |
|                    |       |    |     |        | 64-bit tag,   |
|                    |       |    |     |        | 7-byte nonce  |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-16-128-128 |   30  | 16 | 128 |  128   | AES-CCM mode  |
|                    |       |    |     |        | 128-bit key,  |
|                    |       |    |     |        | 128-bit tag,  |
|                    |       |    |     |        | 13-byte nonce |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-16-128-256 |   31  | 16 | 128 |  256   | AES-CCM mode  |
|                    |       |    |     |        | 256-bit key,  |
|                    |       |    |     |        | 128-bit tag,  |
|                    |       |    |     |        | 13-byte nonce |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-64-128-128 |   32  | 64 | 128 |  128   | AES-CCM mode  |
|                    |       |    |     |        | 128-bit key,  |
|                    |       |    |     |        | 128-bit tag,  |
|                    |       |    |     |        | 7-byte nonce  |
+--------------------+-------+----+-----+--------+---------------+
| AES-CCM-64-128-256 |   33  | 64 | 128 |  256   | AES-CCM mode  |
|                    |       |    |     |        | 256-bit key,  |
|                    |       |    |     |        | 128-bit tag,  |
|                    |       |    |     |        | 7-byte nonce  |
+--------------------+-------+----+-----+--------+---------------+

              Table 6: Algorithm Values for AES-CCM

Keys may be obtained from either a key structure or a recipient structure. Implementations that are encrypting or decrypting MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved.

When using a COSE key for this algorithm, the following checks are made:

  • The "kty" field MUST be present, and it MUST be "Symmetric".

  • If the "alg" field is present, it MUST match the AES-CCM algorithm being used.

  • If the "key_ops" field is present, it MUST include "encrypt" or "wrap key" when encrypting.

  • If the "key_ops" field is present, it MUST include "decrypt" or "unwrap key" when decrypting.

4.2.1. Security Considerations for AES-CCM

When using AES-CCM, the following restrictions MUST be enforced:

  • The key and nonce pair MUST be unique for every message encrypted. Note that the value of L influences the number of unique nonces.

  • The total number of times the AES block cipher is used MUST NOT exceed 2^61 operations. This limit is the sum of times the block cipher is used in computing the MAC value and performing stream encryption operations. An explicit check is required only in environments where it is expected that this limit might be exceeded.

  • [RFC9147] contains an analysis on the use of AES-CCM for its environment. Based on that recommendation, one should restrict the number of messages encrypted to 2^23.

  • In addition to the number of messages successfully decrypted, the number of failed decryptions needs to be tracked as well. Following the recommendation in DTLS (Section 4.5.3 of [RFC9147]), the number of failed message decryptions should be limited to 2^23.5. If one is using the 64-bit tag, then the limits are significantly smaller if one wants to keep the same integrity limits. A protocol recommending this needs to analyze what level of integrity is acceptable for the smaller tag size. It may be that, to keep the desired level of integrity, one needs to rekey as often as every 2^7 messages.

[RFC3610] additionally calls out one other consideration of note. It is possible to do a precomputation attack against the algorithm in cases where portions of the plaintext are highly predictable. This reduces the security of the key size by half. Ways to deal with this attack include adding a random portion to the nonce value and/or increasing the key size used. Using a portion of the nonce for a random value will decrease the number of messages that a single key can be used for. Increasing the key size may require more resources in the constrained device. See Sections 5 and 10 of [RFC3610] for more information.

4.3. ChaCha20 and Poly1305

ChaCha20 and Poly1305 combined together is an AEAD mode that is defined in [RFC8439]. This is an algorithm defined using a cipher that is not AES and thus would not suffer from any future weaknesses found in AES. These cryptographic functions are designed to be fast in software-only implementations.

The ChaCha20/Poly1305 AEAD construction defined in [RFC8439] has no parameterization. It takes as inputs a 256-bit key and a 96-bit nonce, as well as the plaintext and additional data, and produces the ciphertext as an output. We define one algorithm identifier for this algorithm in Table 7.

     +===================+=======+==========================+
     | Name              | Value | Description              |
     +===================+=======+==========================+
     | ChaCha20/Poly1305 |   24  | ChaCha20/Poly1305 w/     |
     |                   |       | 256-bit key, 128-bit tag |
     +-------------------+-------+--------------------------+

          Table 7: Algorithm Value for ChaCha20/Poly1305

Keys may be obtained from either a key structure or a recipient structure. Implementations that are encrypting or decrypting MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved.

When using a COSE key for this algorithm, the following checks are made:

  • The "kty" field MUST be present, and it MUST be "Symmetric".

  • If the "alg" field is present, it MUST match the ChaCha20/Poly1305 algorithm being used.

  • If the "key_ops" field is present, it MUST include "encrypt" or "wrap key" when encrypting.

  • If the "key_ops" field is present, it MUST include "decrypt" or "unwrap key" when decrypting.

4.3.1. Security Considerations for ChaCha20/Poly1305

The key and nonce values MUST be a unique pair for every invocation of the algorithm. Nonce counters are considered to be an acceptable way of ensuring that they are unique.

A more recent analysis in [ROBUST] indicates that the number of failed decryptions needs to be taken into account as part of determining when a key rollover is to be done. Following the recommendation in DTLS (Section 4.5.3 of [RFC9147]), the number of failed message decryptions should be limited to 2^36.

[RFC8446] notes that the (64-bit) record sequence number would wrap before the safety limit is reached for ChaCha20/Poly1305. COSE implementations should not send more than 2^64 messages encrypted using a single ChaCha20/Poly1305 key.

Last updated on