]> IMT Atlantique

dmytro.ochkas@imt-atlantique.fr

IMT Atlantique

helene.le-bouder@imt-atlantique.fr

IMT Atlantique

alexander.pelov@imt-atlantique.fr

General COSE Working Group Internet-Draft This document describes CBOR Object Signing and Encryption (COSE) serialization with Ascon, a NIST standard for lightweight cryptography. In 2019, as a part of CAESAR competition, Ascon-128 and Ascon-128a were selected as the first choice for the lightweight authenticated encryption. After, in 2023, National Institute of Standards and Technology (NIST) selected Ascon family of cryptographic algorithms to be the standard for lightweight cryptography. In August 2025, NIST Special Publication 800-232 was released, defining Ascon-based lightweight cryptography standards for constrained devices. This recognition makes it particularly interesting to enable using Ascon with COSE structures.

Introduction Constrained networks such as Internet of Things (IoT) networks most of the time are characterized by the limited computational power and energy. In this context, the choice of suitable cryptographic suites that provide reliable security without consuming large amount of resources is essential. As a winner of the lightweight cryptography standardization process conducted by NIST, Ascon algorithms are the perfect candidates to fit into the described use case. The Ascon family offers a low computational cost that translates into lower latency, reduced energy consumption, and higher throughput compared to traditional crypto algorithms. Moreover, all Ascon algorithms share a single permutation function allowing for a drastic reduction of memory footprint. Ascon-Based Lightweight Cryptography Standards for Constrained Devices introduces a suite of algorithms consisting of Ascon-AEAD128, an authenticated encryption with associated data (AEAD) algorithm; Ascon-Hash256, a hash function; and two eXtendable Output Functions (XOFs). As, in COSE, only AEAD and hash functions of Ascon family are relevant, this document focuses on the usage of Ascon-AEAD128 for COSE content encryption, and Ascon-Hash256 for KDF and MAC procedures. This document does not define any new cryptography, only serializations of existing cryptographic systems described in .

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Ascon algorithms for COSE

Ascon-AEAD128 This document introduces Ascon-AEAD128 for COSE content encryption. Ascon AEAD algorithm is parametrized by the key size k, the nonce size n, the tag size t, the rate r, and the number of outer permutation rounds a and the number of inner permutation rounds b. specifies the Ascon-AEAD128 parameters with the following numerical values. Key size, k Nonce size, n Tag size, t Rate, r Outer permutation rounds, a Inner permutation rounds, b 128 bits 128 bits 32-128 bits 128 bits 12 8 Note that the standard permits tag sizes t between 32 and 128 bits. Tags of less than 64 bits SHALL only be selected after a careful risk analysis. Since COSE can be used in a variety of scenarios, this document requests to register three configurations of Ascon-AEAD128 in with tag sizes of 32, 64, and 128 bits (see ). Using the 32-bit variation is discouraged for typical scenarios and SHOULD be introduced only in extremely constrained use cases with justified security. Name alg Description Ascon-AEAD128 TBD (requested assignment 35) Ascon-AEAD128 with 128-bit tag as the CBOR Object Encryption Algorithm Ascon-AEAD128/64 TBD (requested assignment 36) Ascon-AEAD128 with 64-bit tag as the CBOR Object Encryption Algorithm Ascon-AEAD128/32 TBD (requested assignment 37) Ascon-AEAD128 with 32-bit tag as the CBOR Object Encryption Algorithm In COSE, keys may be obtained from either a key structure or a recipient structure . 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 variation of Ascon-AEAD128 algorithm being used. If the "key_ops" field is present, it MUST include "encrypt" when encrypting. If the "key_ops" field is present, it MUST include "decrypt" when decrypting. COSE encryption and decryption with Ascon-AEAD128 MUST be done in accordance with Section 5.3 of .

Ascon-Hash256 This document introduces Ascon-Hash256 for Key Derivation Function (KDF) and Message Authentication Code (MAC) COSE operations. Ascon hash algorithm is parametrized by the rate r, the number of permutation rounds a, and the length of output l. specifies the Ascon-Hash256 parameters with the following numerical values. Rate, r Permutation rounds, a Output length, l 64 bits 12 256 bits

Ascon-Hash256 for KDF operations In COSE, integration Ascon-Hash256 for KDF operations SHALL be done via HMAC-based Extract-and-Expand KDF (HKDF) defined in . HKDF leverages HMAC mechanism described in . HMAC is an algorithm allowing usage of arbirtary cryptographic hash functions for message authentication. This KDF is described in . Name PRF Description HKDF Ascon-Hash256 HMAC with Ascon-Hash256 HKDF using HMAC with Ascon-Hash256 COSE leverages KDF algorithms to perform direct encryption. Thus, this documents requests the registration of a new direct key with KDF algorithm using HKDF and Ascon-Hash256. The algorithm is defined in . Name Value KDF Description direct+HKDF-Ascon-Hash256 TBD (requested assigment -20) HKDF Ascon-Hash256 Shared secret w/ HKDF Ascon-Hash256 The algorithm from MUST be used as described in Section 6.1.2 of .

Ascon-Hash256 for MAC operations In COSE, integration Ascon-Hash256 for MAC operations SHALL be implemented via HMAC algorithm . This algorithm is described in . Name Value Hash Tag Length Description HMAC Ascon-Hash256 TBD (requested assigment 8) Ascon-Hash256 256 bits HMAC w/ Ascon-Hash256 HMAC Ascon-Hash256/64 TBD (requested assigment 9) Ascon-Hash256 64 bits HMAC w/ Ascon-Hash256 truncated to 64 bits The process of creation and verification of COSE MAC using the algorithms from MUST follow Section 6.3 of .

IV Header Parameter Unlike some common AEAD algorithms, Ascon distinguishes between the notion of initialization vector (IV) and nonce (N). While N is the input argument for the Ascon-AEAD128 encryption/decryption functions, IV is the constant defined for each Ascon algorithm used as part of state initialization. However, does not define a separate header parameter to specify Nonce. Thus, in COSE, whenever Full Initialization Vector Header Parameter (Name: IV, Label: 5) or Partial Initialization Vector Header Parameter (Name: Partial IV, Label: 6) is specified it SHALL refer to the N argument of the corresponding Ascon function.

Security Considerations The security considerations for , , and apply to this specification as well. According to the most recent security analysis publications, Ascon did not show any security vulnerabilities so far and the best attacks target the initialization of Ascon reduced to 7 (out of 12) rounds, concluding that Ascon has a security margin of 5 rounds (42 % of the 12 rounds). More details are available at List of Published Analysis section of .

IANA Considerations

Additions to COSE Algorithms Registry IANA is requested to add the following entries to the COSE Algorithms Registry. The following completed registration templates are provided as described in . The "Recommended" fields for Ascon-AEAD128/32 and HMAC Ascon-Hash256/64 are set to "Filter Only" to discourage unreflected usage.

Ascon-AEAD128 for COSE Name: Ascon-AEAD128 Value: TBD (requested assignment 35) Description: Ascon-AEAD128 with 128-bit tag Capabilities: [kty] Reference: NIST SP 800-232 Recommended: Yes

Ascon-AEAD128/64 for COSE Name: Ascon-AEAD128/64 Value: TBD (requested assignment 36) Description: Ascon-AEAD128 with 64-bit tag Capabilities: [kty] Reference: NIST SP 800-232 Recommended: Yes

Ascon-AEAD128/32 for COSE Name: Ascon-AEAD128/32 Value: TBD (requested assignment 37) Description: Ascon-AEAD128 with 32-bit tag Capabilities: [kty] Reference: NIST SP 800-232 Recommended: Filter Only

direct+HKDF-Ascon-Hash256 for COSE Name: direct+HKDF-Ascon-Hash256 Value: TBD (requested assignment -20) Description: Shared secret w/ HKDF Ascon-Hash256 Capabilities: [kty] Reference: NIST SP 800-232 Recommended: Yes

HMAC Ascon-Hash256 for COSE Name: HMAC Ascon-Hash256 Value: TBD (requested assignment 8) Description: HMAC w/ Ascon-Hash256 Capabilities: [kty] Reference: NIST SP 800-232 Recommended: Yes

HMAC Ascon-Hash256/64 for COSE Name: HMAC Ascon-Hash256/64 Value: TBD (requested assignment 9) Description: HMAC w/ Ascon-Hash256 truncated to 64 bits Capabilities: [kty] Reference: NIST SP 800-232 Recommended: Filter Only

This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. IANA

Examples This appendix provides some examples of various Ascon-AEAD128 encryptions with COSE.

COSE Content Encryption

Simple Ascon-AEAD128 encryption

Direct Ascon-AEAD128 encryption with recipient

Direct Ascon-AEAD128 encryption with HKDF-SHA-256