diff --git a/5.0/en/0x14-V6-Cryptography.md b/5.0/en/0x14-V6-Cryptography.md
index d9f13b26fc..4ae9957ca7 100644
--- a/5.0/en/0x14-V6-Cryptography.md
+++ b/5.0/en/0x14-V6-Cryptography.md
@@ -1,4 +1,4 @@
-# V6 Stored Cryptography
+# V6 Cryptography
## Control Objective
@@ -48,7 +48,7 @@ Although this section is not easily penetration tested, developers should consid
| **6.2.1** | [MODIFIED] Verify that all cryptographic modules fail securely, and errors are handled in a way that does not enable vulnerabilities, such as Padding Oracle attacks. | ✓ | ✓ | ✓ | 310 |
| **6.2.2** | Verify that industry proven or government approved cryptographic algorithms, modes, and libraries are used, instead of custom coded cryptography. | | ✓ | ✓ | 327 |
| **6.2.3** | [DELETED, DUPLICATE OF 6.2.5] | | | | |
-| **6.2.4** | Verify that the application is designed with crypto agility such that random number, encryption or hashing algorithms, key lengths, rounds, ciphers or modes can be reconfigured, upgraded, or swapped at any time, to protect against cryptographic breaks. Similarly, it must also be possible to replace keys and passwords and re-encrypt data. This should allow for seamless upgrades to post-quantum cryptography (PQC), once PQC standards are fully established. | | ✓ | ✓ | 320 |
+| **6.2.4** | [MODIFIED] Verify that the application is designed with crypto agility such that random number, encryption or hashing algorithms, key lengths, rounds, ciphers or modes can be reconfigured, upgraded, or swapped at any time, to protect against cryptographic breaks. Similarly, it must also be possible to replace keys and passwords and re-encrypt data. This should allow for seamless upgrades to post-quantum cryptography (PQC), once PQC standards are fully established. | | ✓ | ✓ | 320 |
| **6.2.5** | [SPLIT TO 6.5.1, 6.5.2, 6.6.3] | | | | |
| **6.2.6** | [MOVED TO 6.5.3] | | | | |
| **6.2.7** | [MOVED TO 6.5.4] | | | | |
@@ -84,8 +84,8 @@ Cipher algorithms such as AES and CHACHA20 form the backbone of modern cryptogra
| :---: | :--- | :---: | :---: | :---: | :---: |
| **6.5.1** | [ADDED, SPLIT FROM 6.2.5] Verify that insecure block modes (e.g., ECB) and weak padding schemes (e.g., PKCS#1 v1.5) are not used. | | ✓ | ✓ | 326 |
| **6.5.2** | [ADDED, SPLIT FROM 6.2.5, LEVEL L2 > L1] Verify that insecure ciphers, including Triple-DES and Blowfish, are not used but secure ciphers and modes** such as AES with GCM are. | ✓ | ✓ | ✓ | 326 |
-| **6.5.3** | [MOVED FROM 6.2.6, LEVEL L2 > L3] Verify that nonces, initialization vectors, and other single-use numbers are not used for more than one encryption key/data-element pair. The method of generation must be appropriate for the algorithm being used. | | | ✓ | 326 |
-| **6.5.4** | [MOVED FROM 6.2.7] Verify that encrypted data is authenticated via signatures, including unencrypted tokens being used for secure access control, as well as through authenticated cipher modes or HMAC for protection against unauthorized modification. | | | ✓ | 326 |
+| **6.5.3** | [MODIFIED, MOVED FROM 6.2.6, LEVEL L2 > L3] Verify that nonces, initialization vectors, and other single-use numbers are not used for more than one encryption key/data-element pair. The method of generation must be appropriate for the algorithm being used. | | | ✓ | 326 |
+| **6.5.4** | [MODIFIED, MOVED FROM 6.2.7] Verify that encrypted data is authenticated via signatures, including unencrypted tokens being used for secure access control, as well as through authenticated cipher modes or HMAC for protection against unauthorized modification. | | | ✓ | 326 |
| **6.5.5** | [ADDED] Verify that any authenticated signatures are operating in encrypt-then-MAC or encrypt-then-hash modes as required. | | | ✓ | 326 |
## V6.6 Hashing and Hash-based Functions
@@ -94,11 +94,11 @@ Cryptographic hashes are used in a wide variety of cryptographic protocols, such
| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---: | :---: | :---: |
-| **6.6.1** | [ADDED] Verify that only approved hash functions are used for general cryptographic use cases, including digital signatures, HMAC, KDF, and random bit generation. | | ✓ | ✓ | 916 |
-| **6.6.2** | [MODIFIED, MOVED FROM 2.4.1, MERGED FROM 2.4.3, 2.4.4] Verify that passwords are stored using an approved, computationally intensive, hashing algorithm with parameter settings configured based on current guidance. The settings should balance security and performance to make brute-force attacks more challenging. | | ✓ | ✓ | 916 |
-| **6.6.3** | [ADDED, SPLIT FROM 6.2.5] Verify that cryptographic systems avoid the use of disallowed hash functions, such as MD5, SHA-1, or any other insecure hash functions, for any cryptographic purpose. | ✓ | ✓ | ✓ | 327 |
-| **6.6.4** | [ADDED] Verify that hash functions used in digital signatures are collision resistant and have appropriate bit-lengths to avoid attacks, such as collision or pre-image attacks. | ✓ | ✓ | ✓ | 916 |
-| **6.6.5** | [ADDED] Verify that hash functions used in HMAC, KDF, and random bit generation are derived from those with proper entropy seeding for random bit generation. | | ✓ | ✓ | 916 |
+| **6.6.1** | [ADDED] Verify that only approved hash functions are used for general cryptographic use cases, including digital signatures, HMAC, KDF, and random bit generation. | | ✓ | ✓ | |
+| **6.6.2** | [MODIFIED, MOVED FROM 2.4.1, MERGED FROM 2.4.3, 2.4.4] Verify that passwords are stored using an approved, computationally intensive, hashing algorithm with parameter settings configured based on current guidance. The settings should balance security and performance to make brute-force attacks more challenging. | | ✓ | ✓ | |
+| **6.6.3** | [ADDED, SPLIT FROM 6.2.5] Verify that cryptographic systems avoid the use of disallowed hash functions, such as MD5, SHA-1, or any other insecure hash functions, for any cryptographic purpose. | ✓ | ✓ | ✓ | |
+| **6.6.4** | [ADDED] Verify that hash functions used in digital signatures are collision resistant and have appropriate bit-lengths to avoid attacks, such as collision or pre-image attacks. | ✓ | ✓ | ✓ | |
+| **6.6.5** | [ADDED] Verify that all hash functions used in HMAC, KDF, and random bit generation are suitable for these usages. | | ✓ | ✓ | |
## V6.7 Key Exchange Mechanisms
@@ -106,7 +106,7 @@ There exists a need for approved key exchange mechanisms, such as Diffie-Hellman
| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---: | :---: | :---: |
-| **6.7.1** | [ADDED] Verify that industry-proven cryptographic algorithms, such as Diffie-Hellman groups, with a focus on ensuring that key exchange mechanisms use secure parameters to prevent man-in-the-middle attacks or cryptographic breaks, are used for key exchanges to prevent attacks on the key establishment process. | | ✓ | ✓ | 798 |
+| **6.7.1** | [ADDED] Verify that industry-proven cryptographic algorithms, such as Diffie-Hellman, with a focus on ensuring that key exchange mechanisms use secure parameters to prevent man-in-the-middle attacks or cryptographic breaks, are used for key exchanges to prevent attacks on the key establishment process. | | ✓ | ✓ | |
## V6.8 In-Use Data Cryptography
@@ -114,8 +114,8 @@ Protecting data while it is being processed is paramount. Techniques such as ful
| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---: | :---: | :---: |
-| **6.8.1** | [ADDED] Verify that full memory encryption is in use that protects sensitive data while it is in use, preventing access by unauthorized users or processes. | | | ✓ | 798 |
-| **6.8.2** | [ADDED] Verify that data minimization ensures the minimal amount of data is exposed during processing, and ensure that data is encrypted immediately after use or as soon as feasible. | | ✓ | ✓ | 798 |
+| **6.8.1** | [ADDED] Verify that full memory encryption is in use that protects sensitive data while it is in use, preventing access by unauthorized users or processes. | | | ✓ | |
+| **6.8.2** | [ADDED] Verify that data minimization ensures the minimal amount of data is exposed during processing, and ensure that data is encrypted immediately after use or as soon as feasible. | | ✓ | ✓ | |
## V6.9 Post-Quantum Cryptography (PQC)
@@ -123,8 +123,8 @@ The need to future-proof cryptographic systems in preparation for the eventual r
| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---: | :---: | :---: |
-| **6.9.1** | [ADDED] Verify, if the application needs to support post-quantum cryptography, that quantum-safe algorithms, or quantum-resistant algorithms, such as lattice-based (ML-KEM), hash-based, code-based, or multivariate cryptographic schemes, are used as replacements for vulnerable classical algorithms like RSA and ECC. | | ✓ | ✓ | 798 |
-| **6.9.2** | [ADDED] Verify that advancements in the field of post-quantum cryptography are being monitored in order to ensure that the application is aligned with emerging industry standards, and remains prepared for quantum threats. | | ✓ | ✓ | 798 |
+| 6.9.1 | [ADDED] Verify that a cryptographic inventory is maintained and includes a documented transformation plan or mapping that outlines the migration path from current cryptographic algorithms and systems to those that are post-quantum cryptography/quantum-safe.| | ✓ | ✓ | |
+| **6.9.2** | [ADDED] Verify that advancements in the field of post-quantum cryptography are being monitored in order to ensure that the application is aligned with emerging industry standards, and remains prepared for quantum threats. | | ✓ | ✓ | |
## References
diff --git a/5.0/en/0x97-Appendix-V_Cryptography.md b/5.0/en/0x97-Appendix-V_Cryptography.md
index 2c653dad70..2cdb968da8 100644
--- a/5.0/en/0x97-Appendix-V_Cryptography.md
+++ b/5.0/en/0x97-Appendix-V_Cryptography.md
@@ -86,8 +86,6 @@ Implementations MUST choose from the following block modes, in order of preferen
* All encrypted messages must be authenticated. Given this, for ANY use of CBC mode there MUST be an associated hashing function or MAC to validate the message. This MUST be applied in the 'Encrypt-Then-Hash' or 'ETH' method. If this cannot be guaranteed, then CBC MUST NOT be used.
-\*\*CCM-8 is included in regard to TLS cipher suites (see [TLS](https://github.com/santander-group-cyber-cto/CryptographyStandard/blob/main/Implementations/TLS/README.md) section).
-
#### Recommendations for Approved Cipher Modes for General Use Cases
Out of the given approved block modes, implementations SHOULD use the ciphers in this list, in order of preference:
@@ -120,6 +118,11 @@ The following cipher modes MUST NOT be used for any use case:
### Key Wrapping
+Cryptographic key wrap (and corresponding key unwrap) is a method of protecting an existing key by encapsulating (i.e. wrapping) it by employing an additional encryption mechanism so that the original key is not obviously exposed, e.g. during a transfer. This additional key used to protect the original key is referred to as the the wrap key.
+
+This operation may be performed when it is desirable to protect keys in places deemed untrustworthy, or to send sensitive keys over untrusted networks or within applications.
+However, serious consideration should be given to understanding the nature (e.g. the identity and the purpose) of the original key prior to committing to a wrap/unwrap procedure as this may have repercussions for both source and target systems/applications in terms of security and especially compliance which may include audit trails of a key's function (e.g. signing) as well as appropriate key storage.
+
ONLY AES-256 MUST be used for key wrapping, following [NIST SP 800-38F](https://csrc.nist.gov/pubs/sp/800/38/f/final) and considering forward-looking provisions against the quantum threat. Cipher modes using AES are the following, in order of preference:
| Key Wrapping | Reference | L1 | L2 | L3 |
@@ -135,7 +138,7 @@ AES-192 and AES-128 MAY be used if the use case demands it, but its motivation M
The following hash functions are approved for use in general cryptographic use cases such as digital signatures, HMAC, key derivation functions (KDF), and random bit generation (RBG). These functions provide strong collision resistance and are suitable for high-security applications. Some of these algorithms offer strong resistance to attacks when used with proper cryptographic key management, and so are additionally approved for HMAC, KDF, and RBG functions.
-| Hash functions | Suitable for
HMAC/KDF/RBG? |Reference | L1 | L2 | L3 |
+| Hash functions | Suitable for HMAC/KDF/RBG? | Reference | L1 | L2 | L3 |
| -------------- | ----------------------------- |-------------------------------------------------------------- |--|--|--|
| SHA3-512 | Y |[FIPS 202](https://csrc.nist.gov/pubs/fips/202/final) | | ✓ | ✓ |
| SHA-512 | Y |[FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final) | | ✓ | ✓ |
@@ -190,8 +193,8 @@ A security strength of 112 bits or above MUST be ensured for all Key Exchange sc
| Scheme | Domain Parameters |
|--|--|
| RSA | k >= 2048 |
-| Diffie-Hellman (DH) | (L, N) parameters:
L >= 2048 & N >= 224 |
-| Elliptic Curve
Diffie-Hellman (ECDH) | f >= 224 |
+| Diffie-Hellman (DH) | L >= 2048 & N >= 224 |
+| Elliptic Curve Diffie-Hellman (ECDH) | f >= 224 |
Where the following parameters are:
@@ -216,10 +219,80 @@ The following groups are approved and MUST be used for implementations of Diffie
| 15 | MODP | 3072-bit MODP Group | 128 | ✓ | ✓ | ✓ |
| 14 | MODP | 2048-bit MODP Group | 112 | ✓ | ✓ | ✓ |
-A complete list of IKE Groups is available by [IANA](https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml) under "Transform Type 4 - Key Exchange Method Transform IDs". Further recommendations on IKE specifically can be found on the [IPSec](https://github.com/santander-group-cyber-cto/CryptographyStandard/blob/main/Implementations/IPSec/README.md) section.
-
### Disallowed KEX Schemes
Any new implementation MUST NOT use any scheme that is NOT compliant with [NIST SP 800-56A](https://csrc.nist.gov/pubs/sp/800/56/a/r3/final) & [B](https://csrc.nist.gov/pubs/sp/800/56/b/r2/final) and [NIST SP 800-77](https://csrc.nist.gov/pubs/sp/800/77/r1/final).
Specifically, IKEv1 MUST NOT be used in production.
+
+## Message Authentication Codes (MAC)
+
+Message Authentication Codes (MACs) are cryptographic constructs used to verify the integrity and authenticity of a message. A MAC takes a message and a secret key as inputs and produces a fixed-size tag (the MAC value). MACs are widely used in secure communication protocols (e.g., TLS/SSL) to ensure that messages exchanged between parties are authentic and intact.
+
+### Approved MAC Algorithms
+
+The following MAC algorithms are approved for use in securing messages by providing integrity and authenticity guarantees. Implementations MUST use only authenticated encryption modes or separately applied HMAC to ensure the security of messages:
+
+| MAC Algorithm | Reference | Suitable for General Use? | L1 | L2 | L3 |
+| ----------------- | ----------------------------------------------------------------------------------------- | ------------------------- |----|----|----|
+| HMAC-SHA-256 | [RFC 2104](https://www.rfc-editor.org/info/rfc2104) & [FIPS 198-1](https://csrc.nist.gov/pubs/fips/198-1/final) | ✓ | ✓ | ✓ | ✓ |
+| HMAC-SHA-384 | [RFC 2104](https://www.rfc-editor.org/info/rfc2104) & [FIPS 198-1](https://csrc.nist.gov/pubs/fips/198-1/final) | ✓ | | ✓ | ✓ |
+| HMAC-SHA-512 | [RFC 2104](https://www.rfc-editor.org/info/rfc2104) & [FIPS 198-1](https://csrc.nist.gov/pubs/fips/198-1/final) | ✓ | | ✓ | ✓ |
+| KMAC128 | [NIST SP 800-185](https://csrc.nist.gov/pubs/sp/800/185/final) | ✓ | ✓ | ✓ | ✓ |
+| KMAC256 | [NIST SP 800-185](https://csrc.nist.gov/pubs/sp/800/185/final) | ✓ | ✓ | ✓ | ✓ |
+
+### Disallowed MAC Algorithms
+
+The following algorithms are explicitly banned and MUST NOT be used due to known vulnerabilities or insufficient security strength:
+
+| MAC Algorithm | Reference |
+| ---------------- | ---------------------------------------------------------------------------------- |
+| MD5-based HMAC | [RFC 1321](https://www.rfc-editor.org/info/rfc1321) |
+| SHA-1-based HMAC | [RFC 3174](https://www.rfc-editor.org/info/rfc3174) & [RFC 6194](https://www.rfc-editor.org/info/rfc6194) |
+
+## Digital Signatures
+
+### Approved Digital Signature Algorithms
+
+The following digital signature algorithms are approved for use in ensuring data authenticity and integrity. Signature schemes MUST use approved key sizes and parameters per [NIST SP 800-57 Part 1](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final):
+
+| Signature Algorithm | Reference | Suitable for General Use? | L1 | L2 | L3 |
+| -------------------------- | ---------------------------------------------------------------------------------- | ------------------------- |----|----|----|
+| EdDSA (Ed25519, Ed448) | [RFC 8032](https://www.rfc-editor.org/info/rfc8032) | ✓ | ✓ | ✓ | ✓ |
+| ECDSA (P-256, P-384, P-521)| [FIPS 186-4](https://csrc.nist.gov/pubs/fips/186-5/final) | ✓ | ✓ | ✓ | ✓ |
+| RSA-PSS | [RFC 8017](https://www.rfc-editor.org/info/rfc8017) | ✓ | ✓ | ✓ | ✓ |
+
+### Disallowed Digital Signature Algorithms
+
+The following digital signature algorithms MUST NOT be used due to known weaknesses or insufficient security strength:
+
+| Signature Algorithm | Reference |
+| ------------------- | ---------------------------------------------------------------------------------- |
+| RSA PKCS#1 v1.5 | [RFC 8017](https://www.rfc-editor.org/info/rfc8017) |
+| DSA (any key size) | [FIPS 186-4](https://csrc.nist.gov/pubs/fips/186-4/final) |
+
+## Key Derivation Functions (KDFs)
+
+### Approved KDFs
+
+Key derivation functions transform a keying material into keys suitable for specific cryptographic operations. The following KDFs are approved and MUST be used based on the application’s needs and security context:
+
+| KDF | Reference | Suitable for General Use? | L1 | L2 | L3 |
+| ----------- | --------------------------------------------------------------------------------------------- | ------------------------- |----|----|----|
+| argon2id | [RFC 9106](https://www.rfc-editor.org/info/rfc9106) | ✓ | | ✓ | ✓ |
+| scrypt | [RFC 7914](https://www.rfc-editor.org/info/rfc7914) | ✓ | | ✓ | ✓ |
+| PBKDF2 | [RFC 8018](https://www.rfc-editor.org/info/rfc8018) & [NIST SP 800-132](https://csrc.nist.gov/pubs/sp/800/132/final) | ✓ | ✓ | ✓ | ✓ |
+| HKDF | [RFC 5869](https://www.rfc-editor.org/info/rfc5869) | ✓ | ✓ | ✓ | ✓ |
+
+### Disallowed KDFs
+
+The following KDFs are explicitly banned and MUST NOT be used due to insufficient security properties or known weaknesses:
+
+| KDF | Reference |
+| -------------- | ---------------------------------------------------------------------------------- |
+| MD5-based KDFs | [RFC 1321](https://www.rfc-editor.org/info/rfc1321) |
+| SHA-1-based KDFs | [RFC 3174](https://www.rfc-editor.org/info/rfc3174) & [RFC 6194](https://www.rfc-editor.org/info/rfc6194) |
+
+### Post-Quantum Encryption Standards
+
+PQC implementations must be inline with [FIPS-203](https://csrc.nist.gov/pubs/fips/203/ipd)/[204](https://csrc.nist.gov/pubs/fips/204/ipd)/[205](https://csrc.nist.gov/pubs/fips/205/ipd) as there isn't any hardened code nor implementation reference yet. https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards