Update for Annex K version 1.2 (302030c6) · Commits · STAN4CRA / EN 304 620 Virtual Private Networks Part 1

EN-304-620.md

+0 −4

Original line number	Diff line number	Diff line
		@@ -1271,10 +1271,6 @@ _This Annex is optional and may be referred to from the Introduction of the docu

		::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._

clauses/5.Requirements.md

+2 −0

Original line number	Diff line number	Diff line
		@@ -1116,6 +1116,8 @@ The VPN shall use strong cryptography.

		* \[REQ-CON-akkis] The product shall use cryptographic primitives and parameters as defined in Annex K.

		> NOTE: VPN protocols such as IPSec, Wireguard, OpenVPN and IKEv2 are approved VPN protocols if they use state of the art cryptogrpahy as defined in Annex K.

		[//]: # (### 6.6.N CON)

		* Reference: TR-CRYPT

clauses/K.Cryptography.md

+377 −101

File changed.

Preview size limit exceeded, changes collapsed.

clauses/X.Vertical-Specific-SOTA.md

deleted100644 → 0

+0 −194

Original line number	Diff line number	Diff line
		## 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.

		Note: The combination of the mechanism mentioned in CRY-SOTA-unlisted 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 X25519ML-KEM768.
		Note: The list of CRY-SOTA-unlisted as well as ACM relates to the default configuration of the product. Additional cryptography may be used when explicitly configured by the user.

		## 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), 20 Rounds \| 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. \|
		\| Salsa20 (SALSA20) \| 256 bit (key), 20 Rounds \| Salsa20 was analyised and approved in the eSTREAM by eCRYPT which was sponsored by the EC. Extending Salsa20 with a larger 25-byte nonce (XSalsa20) to mitigate nonce collisions is included in this primitive. \|
		\| AEGIS (AEGIS, RFC-AEGIS) \| AEGIS-128, AEGIS-256, AEGIS-128L, AEGIS-256X \| A modern AEAD algorithm based on AES. \|

		SALSA20 - https://cr.yp.to/snuffle/spec.pdf
		AEGIS - https://competitions.cr.yp.to/round3/aegisv11.pdf
		RFC-AEGIS - https://datatracker.ietf.org/doc/draft-irtf-cfrg-aegis-aead/

		### 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. \|
		\| Blake3 (C2SP/BLAKE3) \| \| A modern cryptographic hash function that is an evolution from Blake2, but much faster. \|

		BLAKE3 - https://github.com/BLAKE3-team/BLAKE3-specs/blob/master/blake3.pdf
		C2SP - https://github.com/C2SP/C2SP

		## 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), 20 Rounds \| Standard AEAD for TLS 1.3. Extending ChaCha20 with a larger 24-byte nonce (XChaCha20) to mitigate nonce collisions is included in this primitive. \|
		\| Salsa20-Poly1305 \| 256 bit (key), 20 Rounds \| Combination of Salsa20 and Poly1305 to create an AEAD. Extending Salsa20 with a larger 24-byte nonce (XSalsa20) 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 (SIPHASH24) \| 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. \|
		\| Blake3 (C2SP/BLAKE3) \| \| A modern cryptographic hash function that is an evolution from Blake2, but much faster. \|

		BLAKE3 - https://github.com/BLAKE3-team/BLAKE3-specs/blob/master/blake3.pdf
		C2SP - https://github.com/C2SP/C2SP
		SIPHASH24 - https://cr.yp.to/siphash/siphash-20120918.pdf


		### 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 7748) \| Curve25519 \| Standard for TLS, and SSH and various VPN protocols. \|
		\| X448 / Ed448 (RFC 7748) \| Curve448 \| Standard in TLS 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, FIPS 186-5) \| 256 bit \| Used for TLS and formally known as EdDSA. \|
		\| Ed448 (RFC 8032, FIPS 186-5) \| 456 bit \| Used in TLS and various VPN protocols based on TLS. \|

		### 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

		The additional Key establishment and key encapsulation included in table X.5.4-1 are agreed as state of the art.

		Table X.5.4-1: State of the art entity authentication schemes.
		\| Scheme \| Parameter’s sizes \| Notes \|
		\|-----------\|------------------\|-------------------\|
		\| X25519 (RFC 7748) \| 256 bit \| Used in TLS and various VPN protocols. \|
		\| X448 (RFC 7748) \| 448 bit \| Used in TLS and in various VPN protocols based on TLS. \|

		## 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. \|