Dc v6 patch3 #2371
Dc v6 patch3 #2371
Conversation
| | **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 | |
There was a problem hiding this comment.
"HMAC" → This should be "or a MAC"?
There was a problem hiding this comment.
Is there any need to talk about encrypt-then-mac vs mac-then-encrypt vs mac-and-encrypt?
There was a problem hiding this comment.
To answer your questions:
- HMAC can become MAC, but HMAC is usually preferred.
- Yes, there is a need to talk about this - since RFC7366 and with developments in ISO19772 and its revisions, it has been common practice to promote Authenticated Encryption with Associated Data (AEAD). EtH (Encrypt then Hash) or EtM (Encrypt then MAC) are common ways to achieve AEAD. However, in systems like SSH they have the choice between ciphers with and without
etmin the name, hence it MUST be explicitly stated.
5.0/en/0x14-V6-Cryptography.md
Outdated
|
|
||
| ## V6.7 Key Exchange Mechanisms | ||
|
|
||
| There exists a need for approved key exchange mechanisms, such as Diffie-Hellman and Elliptic Curve Diffie-Hellman (ECDH) to ensure that the cryptosystem remains secure against modern threats. | ||
|
|
||
| | # | 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 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. | | ✓ | ✓ | | |
There was a problem hiding this comment.
"cryptographic algorithms, such as Diffie-Hellman groups" → I think it should read "cryptographic algorithms, such as Diffie-Hellman" because a DH group is not really an algorithm but only a group (i.e. a mathematical construct).
May we reword as
Verify that industry-proven cryptographic key exchanges, such as Diffie-Hellman, are used in order to prevent attacks on the key establishment process. The key exchange mechanisms must use secure parameters to prevent man-in-the-middle attacks or cryptographic breaks.
There was a problem hiding this comment.
to prevent man-in-the-middle attacks or cryptographic breaks.
Should we mention the notion of "authenticated key exchange" (i.e. anonymous Diffie-Hellman is usually not so great).
There was a problem hiding this comment.
Yes we can reword it like that, and yes, we can mention it for the same reasons we should mention AEAD/EtM above. :)
There was a problem hiding this comment.
how does this resonate?
| 6.7.1 | [ADDED] Verify that industry-proven cryptographic algorithms are used for key exchanges with secure parameters to prevent man-in-the-middle attacks or cryptographic breaks. Ensure that key exchange mechanisms employ authenticated key exchange protocols to verify the identities of communicating parties and mitigate attacks on the key establishment process. | | ✓ | ✓ | |
There was a problem hiding this comment.
"… and provides forward secrecy" 😉 #2215
(Actually I think it would be better to include forward secrecy as a separate requirement … ?)
| | **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 hash functions used in HMAC, KDF, and random bit generation are derived from those with proper entropy seeding for random bit generation. | | ✓ | ✓ | | |
There was a problem hiding this comment.
I don't really understand (can't parse the meaning) of this one.
There was a problem hiding this comment.
Verify that hash functions used in HMAC, KDF, and random bit generation are derived from those with proper entropy seeding for random bit generation.
I find it difficult to understand the last part ("are derived from those with proper entropy seeding for random bit generation") but after checking the appendix I understand that the correct column from the appendix must be checked :)
Can we reword it somehow like:
Verify that all hash function used in HMAC, KDF, and random bit generation are suitable for these usages.
Relating to #2315, #2314