@@ -114,7 +114,27 @@ The following referenced documents are necessary for the application of the pres
<spanid="_ref_1"></span><aname="_ref_1">[1]</a> [ENISA Report 1747792503](https://certification.enisa.europa.eu/document/download/a845662b-aee0-484e-9191-890c4cfa7aaa_en?filename=ECCG%20Agreed%20Cryptographic%20Mechanisms%20version%202.pdf)(version 2 - April 2025) "European Cybersecurity Certification Group Sub-group on Cryptography Agreed Cryptographic Mechanisms"
<spanid="_ref_2"></span><aname="_ref_2">[2]</a> prEN 40000-1-3: "Cybersecurity requirements for products with digital elements - Vulnerability Handling"
<spanid="_ref_2"></span><aname="_ref_2">[2]</a> CEN-CENELEC prEN 40000-1-3: "Cybersecurity requirements for products with digital elements - Vulnerability Handling"
<spanid="_ref_3"></span><aname="_ref_3">[3]</a> IETF [RFC 7488](https://datatracker.ietf.org/doc/html/rfc7748): "Elliptic Curves for Security"
<spanid="_ref_4"></span><aname="_ref_4">[4]</a> IETF [RFC 8032](https://datatracker.ietf.org/doc/html/rfc8032): "Edwards-Curve Digital Signature Algorithm (EdDSA)"
<spanid="_ref_5"></span><aname="_ref_5">[5]</a> NIST [FIPS 186-5](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf): "Digital Signature Standard (DSS)"
<spanid="_ref_6"></span><aname="_ref_6">[6]</a> IETF [RFC 9106](https://datatracker.ietf.org/doc/html/rfc9106): "Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications"
<spanid="_ref_7"></span><aname="_ref_7">[7]</a> BSI [TR-02102-1](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.html)(2026-01): "Cryptographic Mechanisms: Recommendations and Key Lengths"
<spanid="_ref_8"></span><aname="_ref_8">[8]</a> IETF [RFC 7914](https://datatracker.ietf.org/doc/html/rfc7914): "The scrypt Password-Based Key Derivation Function"
<spanid="_ref_9"></span><aname="_ref_9">[9]</a> IETF [RFC 8439](https://datatracker.ietf.org/doc/html/rfc8439): "ChaCha20 and Poly1305 for IETF Protocols"
<spanid="_ref_10"></span><aname="_ref_10">[10]</a> IETF [RFC 7693](https://datatracker.ietf.org/doc/html/rfc7693): "The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC)"
<spanid="_ref_12"></span><aname="_ref_12">[12]</a> C2SP [BLAKE3](https://c2sp.org/BLAKE3): "The BLAKE3 Hashing Framework"
## 2.2 Informative references
@@ -184,6 +204,20 @@ For the purposes of the present document, the terms given in Regulation (EU) 202
> NOTE: This includes cases where that product provides access from a restricted-use logical computer network to the public internet.
**cryptographic mechanism**: security-related procedure using cryptography
> NOTE 1: The term “cryptographic mechanism” is used as an umbrella term covering the categories used in the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue [1](#_ref_1), including cryptographic algorithms, primitives, schemes, protocols, protocol profiles, cipher suites, modes of operation, constructions and parameter sets.
> NOTE 2: The terms “cryptographic primitive”, “cryptographic construction”, “cryptographic scheme” and “cryptographic protocol” are used consistently with the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue [1](#_ref_1).
> NOTE 3: A cryptographic mechanism can be specified at different levels of abstraction. For example, AES is a cryptographic primitive, AES-GCM is a mode of operation / authenticated encryption construction, TLS 1.3 is a protocol, a TLS 1.3 restricted cipher-suite profile is a protocol profile, and TLS\_AES\_128\_GCM\_SHA256 is a cipher suite.
**cryptographic property**: property provided or supported by a cryptographic mechanism
> NOTE 1: Cryptographic properties include, for example, confidentiality, integrity, authenticity, entity authentication, message authentication, key establishment, key confirmation, replay protection, collision resistance, second-preimage resistance, pre-image resistance, signature unforgeability, non-repudiation, forward secrecy and password-verifier protection. Where relevant, a cryptographic property can be expressed using a formal cryptographic notion, for example IND-CPA, IND-CCA, IND-CCA2, EUF-CMA, SUF-CMA or authenticated key exchange security.
> NOTE 2: A cryptographic property is distinct from a product-level technical requirement, although it can support such a requirement. For example, a secure communication requirement can rely on cryptographic properties such as confidentiality, integrity and authentication.
## 3.2 Symbols
There are no symbols requiring definition used in the present document.
Editor’s note: Clause K.0 provides general context, terms and application guidance for vertical standards. Guidance and editorial instructions in this clause shall be removed or adapted when Annex K is integrated into a vertical standard. Terms and definitions in clause K.0.2 shall be moved to the terms and definitions clause of the vertical standard or retained in Annex K, as appropriate.
The requirements and assessment provisions provided by this annex are intended to be used as a common framework for vertical CRA standards concerning the use of cryptography, including state-of-the-art cryptographic mechanisms and controlled interoperability-based exceptions, with the aim to:
* provide a path towards presumption of conformity;
* enable cross-vertical alignment; and
* reflect interoperability needs.
Vertical standards may adapt the framework, and in particular specify additional or more specific requirements, assessment activities, assessment evidence or assessment criteria where needed for the relevant product category, product function, use case or risk profile.
Clause K.1.1 defines the product-facing requirement for the cryptographic mechanisms used in the product’s default configuration. It distinguishes ACM-listed cryptographic mechanisms defined in [1](#_ref_1), ACM-extended cryptographic mechanisms, and interoperability-based cryptographic mechanisms listed in clause K.4.2. ACM-extended cryptographic mechanisms are either listed in clause K.3.2 or fulfil the criteria specified in clause K.1.1 item 2.b.
Vertical standards can instantiate clause K.3.2 where ACM-extended cryptographic mechanisms are specified by the vertical standard. Mechanisms listed or referenced in clause K.3.2 shall be identified with sufficient precision to support assessment under clause K.1.2. For interoperability-based cryptographic mechanisms, vertical standards shall instantiate clause K.4.2 and identify the mechanisms with sufficient precision to support assessment under clause K.1.2.
### K.0.2 Terms and definitions
**Cryptographic mechanism**: security-related procedure using cryptography.
> NOTE 1: The term “cryptographic mechanism” is used in this annex as an umbrella term covering the categories used in the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue [1](#_ref_1), including cryptographic algorithms, primitives, schemes, protocols, protocol profiles, cipher suites, modes of operation, constructions and parameter sets.
> NOTE 2: The terms “cryptographic primitive”, “cryptographic construction”, “cryptographic scheme” and “cryptographic protocol” are used consistently with the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue [1](#_ref_1).
> NOTE 3: A cryptographic mechanism can be specified at different levels of abstraction. For example, AES is a cryptographic primitive, AES-GCM is a mode of operation / authenticated encryption construction, TLS 1.3 is a protocol, a TLS 1.3 restricted cipher-suite profile is a protocol profile, and TLS\_AES\_128\_GCM\_SHA256 is a cipher suite.
**Cryptographic property**: property provided or supported by a cryptographic mechanism.
> NOTE 4: Cryptographic properties include, for example, confidentiality, integrity, authenticity, entity authentication, message authentication, key establishment, key confirmation, replay protection, collision resistance, second-preimage resistance, pre-image resistance, signature unforgeability, non-repudiation, forward secrecy and password-verifier protection. Where relevant, a cryptographic property can be expressed using a formal cryptographic notion, for example IND-CPA, IND-CCA, IND-CCA2, EUF-CMA, SUF-CMA or authenticated key exchange security.
> NOTE 5: A cryptographic property is distinct from a product-level technical requirement, although it can support such a requirement. For example, a secure communication requirement can rely on cryptographic properties such as confidentiality, integrity and authentication.
### K.0.3 Application Guidance for vertical standards
Vertical standards should use the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue [1](#_ref_1) as the primary reference for cryptographic mechanisms, as defined in clause K.1.1 item 1.
@@ -297,30 +266,25 @@ Table K.3.2 lists the ACM-extended cryptographic mechanisms specified by the pre
| ACM-extended cryptographic mechanism | Type of cryptographic mechanism | Characteristics / parameters | Related product function(s) / use case(s), where applicable | Cryptographic properties | Specification / reference | Conditions or limitations, where applicable |
| UMAC | Algorithm | 128 bit | MAC | Authentication, Integrity | RFC 4418 | |
> NOTE: The combination of the mechanism mentioned in Table K.3.2: ACM-extended cryptographic mechanisms together with the mechanisms in ACM that is appropriate for the cryptographic use-case to form a cryptographic protocol are allowed. For example ChaCha20-Poly1305, HMAC-blake2s or X25519ML-KEM768.
> NOTE: The use-case defined in K.3.2 marked in “Related product function(s) / use case(s), where applicable” is a non-exhaustive list and listed algorithm can be used for other appropriate use-cases as well.
| UMAC | Algorithm | 128 bit | MAC | Authentication, Integrity | RFC 4418 [\[11\]](#_ref_11) | |
Editor’s note for rapporteurs: Where no ACM-extended cryptographic mechanisms are specified by the vertical standard, this clause is to state: “No ACM-extended cryptographic mechanisms are specified.” This editor’s note shall be removed before publication.
> NOTE 1: The combination of the mechanism mentioned in Table K.3.2: ACM-extended cryptographic mechanisms together with the mechanisms in ACM that is appropriate for the cryptographic use-case to form a cryptographic protocol are allowed. For example ChaCha20-Poly1305, HMAC-blake2s or X25519ML-KEM768.
Editor’s note for rapporteurs: Table K.3.2 is an example template and can be adapted where needed for the relevant vertical standard.
> NOTE 2: The use-case defined in K.3.2 marked in “Related product function(s) / use case(s), where applicable” is a non-exhaustive list and listed algorithm can be used for other appropriate use-cases as well.
