Introduction of Annex X to address CRY-SOTA

.DS_Store

::include{file=clauses/S.Secure-Update.md}

# Annex X: Product specific state of the art cryptography (Normative)

::include{file=clauses/X.Vertical-Specific-SOTA.md}

# History

The following table will automatically be filled in by the ETSI Secretariat.

The VPN shall use strong cryptography.

#### 5.2.14.2 MI-CRYPT-1: Pre-shared key mixing for post-quantum security

#### 5.2.14.3 MI-CRYPT-1: Use conformant cryptography

The VPN shall support mixing a preshared key (PSK) into the key derivation process to mitigate the risk of quantum-enabled decryption.

* Applicability: (optional, for requirements that depend on a feature)

* Reference: TR-CRYPT

* Objective: Confidentiality

* Preparation: Attach a debugger to the VPN client binding to cryptographic functions or capture traffic on all interfaces

* Activities: Create protocol trace when setting up a post-quantum safe tunnel or capture packet showing the encryption headers

* Verdict: Protocol trace or packet capture demonstrating that the PSK is incorporated into key derivation during tunnel establishment => PASS, otherwise FAIL

* Evidence: The protocol trace or packet capture demonstrating the mixing a preshared key into the key derivation process

#### 5.2.14.3 MI-CRYPT-2: Use conformant encryption

VPN encryption shall use cryptographic algorithms, keys, and parameters as described in EUCC Guidelines Cryptography v2 [\[3\]](#_ref_3) or demonstrably equivalent state-of-the-art mechanisms.

The product shall use cryptographic primitives and parameters as defined in Annex K.  

* Reference: TR-CRYPT

* Objective: Confidentiality

* Preparation: Perform a factory reset or new installation of the VPN client.

* Activities: Start the VPN connection using the default configuration. Capture traffic on all interfaces.

* Verdict: The traffic pertaining to the VPN connection uses the algorithms, keys and parameters as described in EUCC guidelines or demonstrably equivalent state-of-the-art mechanisms.

* Verdict: The traffic pertaining to the VPN connection uses the primitives and parameters as described in Annex K.

* Evidence: Packet capture showing the encryption headers.

### 5.2.15 TR-LOGG: Logging and monitoring

  1. CONF-3

  1. CONF-4

  1. CONF-5

  1. CRYPT-2

  1. DNSL-1

  1. DNSL-2

  1. DNSL-7

  1. CONF-4

  1. CONF-5

  1. CRYPT-1

  1. CRYPT-2

  1. DNSL-1

  1. DNSL-2

  1. DNSL-3

  1. CONF-4

  1. CONF-5

  1. CRYPT-1

  1. CRYPT-2

  1. DNSL-1

  1. DNSL-2

  1. DNSL-3

  1. CONF-4

  1. CONF-5

  1. CRYPT-1

  1. CRYPT-2

  1. DNSL-1

  1. DNSL-2

  1. DNSL-3

  1. CONF-2

  1. CONF-3

  1. CONF-4

  1. CRYPT-2

  1. DNSL-7 *

  1. IPv6-1

  1. LOGG-1

1. CONF-4

1. CONF-5

1. CRYPT-1

1. CRYPT-2

1. DNSL-1

1. DNSL-2

1. DNSL-3

## K.1.1 Requirement 

The default configuration for each security mechanism supported by the

product shall use (*one or more*) public available cryptographic

algorithm, which are:

i\) listed in the ECCG Agreed Cryptographic Mechanism (ACM) catalogue

\[1\] classified as \[CRY-SOTA-listed\] or

ii\) suitable for the corresponding use case, classified as

\[CRY-SOTA-unlisted\] in Annex X

\[1\] ENISA European Cybersecurity Certification Group: "Agreed

Cryptographic Mechanisms, vers 2.0" (ACM)

**NOTE 1:** The use of security mechanism as for example.

*integrity, authentication, access control, secure communication, secure

storage and secure update are described in the main text of this

standard.*

# K.2 Crypto agility

## K.2.1 Requirement 

Where a security mechanism supported by the product uses

<span class="mark">in its</span> the default configuration

<span class="mark">a cryptographic algorithm that is</span>:

i\) listed in the CRY-SOTA catalogue; or

ii\) referenced in a crypto catalogue within the context of K.1.1.(ii)

in accordance to the Cyber Resilience Act (CRA).

<span class="mark">and that algorithm</span> is expected to be

deprecated within the intended lifetime of the product, the product

shall provide a mechanism for updating the cryptographic algorithm or

deprecating its usage.

EXAMPLE 1 : <span class="mark">Hybridization</span>

<span class="mark">serves as a strategy</span>

<span class="mark">to</span> <span class="mark">mitigate</span>

<span class="mark">the case of deprecation, For instance , if within a

secure storage mechanism, it</span> <span class="mark">can involve

combination</span> <span class="mark">classical</span>

<span class="mark">asymmetric cryptographic algorithms with</span>

<span class="mark">quantum.resistant</span>

<span class="mark">algorithm</span> <span class="mark">through dual

encapsulation. This approach ensures</span> <span class="mark">data

confidentiality data over a</span> <span class="mark">specific</span>

<span class="mark">future time</span> <span class="mark">horizon

,</span> <span class="mark">assuming</span> <span class="mark">that at

least one</span> <span class="mark">of the employed algorithm</span>

<span class="mark">remains</span> <span class="mark">uncompromised

during this</span> <span class="mark">period</span>

NOTE 1: To maintain SOTA for cryptographic algorithm within the intended

lifetime of the product concepts to consider are crypto agility

additional to the capability of updating cryptographic algorithms on the

product in accordance to Secure Update and Secure Communication

mechanism.

NOTE 2: The \[ACM\] listing consist of wo classes of SOTA algorithms;

Legacy mechanisms with an expiry date as defined in ACM, and Recommended

mechanisms with no set expiry date.

NOTE 3: For products that cannot have their cryptographic algorithms

updated for example if the implementation or part uses a hardware-based

root of trust, it is important to check if the intended lifetime of the

equipment does not exceed the recommended usage lifetime of their

cryptographic algorithms. Thereby the implementation of an algorithm can

include the specific implementation of their parameters e.g. their key

length.

NOTE 4: If a component storing the algorithm or corresponding parameters

of a main product is replaced by a new component, the product is

considered as a new product according to the New Legislative Framework

Blue Guide, if the replacement provides a substantial modification to

the main product.

*Last update on 2026‑04-15*

[1] e.g. BSI – BSI TR-02102-1, Cryptographic Mechanisms: Recommendations

and Key Lengths , Vers. 2026-01, January 31, 2026

[2] <span class="mark"> </span>e.g. EPC342-08 /Version 15.0 /Guidelines

on cryptographic algorithms usage and key management - PPSSG / 7 March

2025

In addition to general cryptographic catalogues, certain industry

sectors maintain their own specialized algorithm catalogues optimized

for specific threat models, hardware and/or software architectures or

performance constraints. These vertical use-case specific cryptographic

algorithm catalogues may serve as supporting evidence when they

explicitly recognize algorithms as suitable for the intended use case,

*e.g. the ARM Confidential Compute Architecture (CCA) Security Model,

Section 12.3.3 (“Memory Encryption”), recommends specific algorithms for

memory protection in dedicated hardware environments, including:

QARMA‑128 with a 256‑bit key and AES‑128‑XEX with two independent

128‑bit keys* <span class="mark"></span>

[3] European Vulnerability Database established pursuant

to Article 12(2) of Directive (EU) 2022/2555,

https://euvd.enisa.europa.eu/ENISA

[4] SRP = , Single Reporting Platform CRA

https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp

[5] NCCA =

[National Cybersecurity Certification

Authorities](https://certification.enisa.europa.eu/take-action/national-cybersecurity-certification-authorities_en)

[  

](https://certification.enisa.europa.eu/take-action/national-cybersecurity-certification-authorities_en)

[6] defined in \[ACM\]

## X.1 State of the Art Cryptography (CRY-SOTA-unlisted)

This annex provides additional generic requirements around the use of state of the art cryptography. Annex K classifies cryptographic algorithm primitives as CRY-SOTA if they are listed in the ENISA ACM [REF] and are suitable for the implementation of supported security mechanisms of the product. This annex lists additional cryptographic algorithm primitives and schemes that are commonly existing on the market for VPNs that are classified as CRY-SOTA.

## X.2 Symmetric atomic primitives

### X.2.1 Block ciphers

No additional primitives.

### X.2.2 Stream ciphers

Block ciphers can be configured to behave like stream ciphers using counter (CTR) mode, as described in [ACM] clause 3.1. In addition, the stream ciphers included in Table X.2.2-1 are agreed as state of the art.

**Table X.2.2-1: State of the art stream ciphers.**

| Primitive            | Parameter's size | Notes             |

|----------------------|------------------|-------------------|

| ChaCha20 (RFC 8439)   | 256 bit (key)    | A modern stream cipher used in VPNs and TLS 1.3. Preferred for devices without AES hardware acceleration. Extending ChaCha20 with a larger 24-byte nonce (XChaCha20) to mitigate nonce collisions is included in this primitive. |

### X.2.3 Hash Functions 

The additional hash functions are included in table X.2.3-1 are agreed as state of the art. 

**Table X.2.3-1: State of the art hash functions.**

| Primitive            | Parameter's size | Notes             |

|----------------------|------------------|-------------------|

| Blake2b (RFC7693, NIST IR 7896)     | 512 bit | A modern cryptographic hash function which targets 64-bit platform (blake2s).  |

| Blake2s (RFC7693, NIST IR 7896)     | 256 bit | A modern cryptographic hash function which targets 64-bit platform. |  

## X.3 Symmetric constructions

### X.3.1 Confidentiality modes of operation: encryption/decryption modes

No additional schemes.

### X.3.2 Specific confidentiality modes: disk encryption

No additional schemes.

### X.3.3 Integrity modes: message authentication codes

The additional message authentication codes included in Table X.3.3-1 are agreed as state of the art.

**Table X.3.3-1: State of the art message authentication codes.**

| Scheme                                           | Parameter's size | Notes             |

|--------------------------------------------------|------------------|-------------------|

| Poly1305 (RFC 8439)                              | 256 bit key      | Paired with ChaCha20 in TLS 1.3. |

| HMAC-blake2s (RFC 2104, RFC 7693)                | 256 bit key      | Used in modern VPN protocols. |

| UMAC (RFC 4418)                                  | 128 bit key      | Used in  SSH configurations for managing VPN servers |

### X.3.4 Symmetric entity authentication schemes

No additional schemes.

### X.3.5 Authenticated encryption

The additional authentication encryption schemes included in Table X.3.5-1 are agreed as state of the art.

**Table X.3.5-1: State of the art authentication encryption schemes.**

| Scheme | Parameter's size | Notes             |

|-----------|------------------|-------------------|

| ChaCha20-Poly1305 (RFC8439) | 256 bit(key)| Standard AEAD for TLS 1.3. Extending ChaCha20 with a larger 24-byte nonce (XChaCha20) to mitigate nonce collisions is included in this primitive. |

### X.3.6 Key protection

No additional schemes.

### X.3.7 Key derivation functions

The additional key derivation functions included in Table X.3.7-1 are agreed as state of the art.

**Table X.3.7-1: State of the art key derivation functions.**

| Scheme                                        | Parameter's size      | Notes             |

|-----------------------------------------------|-----------------------|-----------------------------------------------------|

| Blake2s (RFC 7693)                              | Key: 128 bit        | Blake2s is used in modern VPN protocols. Blake supportes a keyed mode which makes it a suitable key derivation function.  |

| Blake2b (RFC 7693)                              | Key: 256 bit        | Blake2b is used in modern VPN protocols. Blake supportes a keyed mode which makes it a suitable key derivation function.  |

| SipHash24 (https://eprint.iacr.org/2012/351)    | Key: 128 bit        | A pseudorandom random function (PRF) optimized for short inputs. Allowed use-cases for this PRF is limited to non-security critical use-cases, such as, for example, hash table creation and ID generation. For other use-cases, refere to other approved cryptographic functions.   |

### X.3.8 Password protection/password hashing mechanisms

The additional Password protection/password hashing mechanisms are included in table X.3.8-1 are agreed as state of the art. 

Every password based hashing mechansim shall include a unique random salt (at least 16 bytes) per user. 

**Table X.3.8-1: State of the art Password protection/password hashing mechanisms.**

| Primitive            | Parameter's size | Notes             |

|----------------------|------------------|-------------------|

| Argon2id (RFC 9106, BSI-TR-02102-1)    | (Output: 32 bytes, OpsLimit: 2, Memory: 19 MiB, Threats: 1) or higher | A resource intensive hash function to protect passwords. Can also be used as a KDF to derive secret keys from passwords. Generated entropy depends on the entropy of the password.  |

| scrypt (RFC 7914)    | (Cost: 2^17, block size 1024 bytes, parallelization 1) or higher | A resource intensive hash function to protect passwords. Can also be used as a KDF to derive secret keys from passwords. Generated entropy depends on the entropy of the password. | 

### X.3.9 Key combiners

## X.4 Asymmetric atomic primitives

### X.4.1 RSA/Integer factorization

No additional primitives.

### X.4.2 Discrete logarithm in finite fields

No additional primitives.

### X.4.3 Discrete logarithm in elliptic curves

The additional elliptic curve parameters included in Table X.4.3-1 are agreed as state of the art.

> ![Note] 

> It is noted that all mentioned curves in this sections are included in the ECDH umbrella and are thus usable for all applicable ECDH use cases. 

**Table X.4.3-1: Additional elliptic curve parameters agreed as start of the art.**

| Scheme | Curve | Notes             |

|-----------|------------------|-------------------|

| X25519 / Ed25519 (RFC 8410) | Curve25519 | Standard for TLS 1.3, and SSH and various VPN protocols. |

### X.4.4 Learning with errors in (structured) lattices

No additional LWE mechanisms.

### X.4.5 Hash function preimage resistance

No additional schemes.

### X.4.6 Other intractable problems

No additional schemes.

## X.5	Asymmetric constructions

### X.5.1 Asymmetric encryption scheme

No additional schemes.

### X.5.2 Digital signature

The additional digital signature schemes included in Table X.5.2-1 are agreed as state of the art.

**Table X.5.2-1: State of the art digital signature schemes.**

| Scheme | Parameter’s sizes | Notes             |

|-----------|------------------|-------------------|

| Ed25519 (RFC 8032) | 256 bit key | Used for TLS and formally known as EdDSA. | 

### X.5.3	Asymmetric entity authentication schemes

 The additional asymmetric entity authentication schemes included in table X.5.3-1 are agreed as state of the art.

 **Table X.5.3-1: State of the art entity authentication schemes.**

| Scheme | Parameter’s sizes | Notes             |

|-----------|------------------|-------------------|

| Ed25519-256 with Curve25519 (RFC 8420) | 256 bit | Allowing Ed25519 in modern VPN protocols. |

### X.5.4 Key establishment and key encapsulation

No additional primitives.

## X.6	Cryptographic Industry Standards

The following industry standards serve as a baseline for approved cryptographic algorithm and are concidered approved as CRY-SOTA.   

 **Table X.6.1-1: National catalouges defined as CRY-SOTA.**

| Cryptographic Mechanisms                                                                                             | Version | Notes |

|----------------------------------------------------------------------------------------------------------------------|---------|-------|

| BSI TR-02102-1 "Cryptographic Mechanisms: Recommendations and Key Lengths" (https://www.bsi.bund.de/dok/TR-02102-en) | 2026-01 |       |  

| BSI TR-02102-2 "Cryptographic Mechanisms: Recommendations and Key Lengths: Use of Transport Layer Security (TLS)"  (https://www.bsi.bund.de/dok/TR-02102-en) | 2026-01 | TLS is often used as a baseline for common tunneling protocols. |

| BSI TR-02102-3 "Cryptographic Mechanisms: Recommendations and Key Lengths – Use of Internet Protocol Security (IPsec) and Internet Key Exchange (IKEv2)" (https://www.bsi.bund.de/dok/TR-02102-en) | 2026-01 | | 

| BSI TR-02102-4 "Cryptographic Mechanisms: Recommendations and Key Lengths – Use of Secure Shell (SSH)"               | 2026-01 | SSH can act as tunnel, but mainly is used for node maintainance and deployments. |