Cryptography tweak wording related to "authenticated encryption", "MAC algorithm"

[randomstuff]

We have received this feedback from Bart Preneel.

Current:

Applications need to be designed with strong cryptographic architecture to protect data assets as per their classification. Encrypting everything is wasteful, not encrypting anything is legally negligent. A balance must be struck, usually during architectural or high-level design, design sprints or architectural spikes. Designing cryptography as you go or retrofitting it will inevitably cost much more to implement securely than simply building it in from the start.

Proposed:

Applications need to be designed with strong cryptographic architecture to protect data assets as per their classification. Applying authenticated encryption to everything is wasteful, not applying authenticated encryption to anything is legally negligent. A balance must be struck, usually during architectural or high-level design, design sprints or architectural spikes. Designing cryptography as you go or retrofitting it will inevitably cost much more to implement securely than simply building it in from the start.

---

Current:

1.6.5 [ADDED] Verify that cryptographic discovery mechanisms are employed to identify all instances of cryptography in the system, including encryption, hashing, and signing operations.

Proposed:

1.6.5 [ADDED] Verify that cryptographic discovery mechanisms are employed to identify all instances of cryptography in the system, including authenticated encryption, hashing, and signing operations.

---

Current:

6.2.4 [MODIFIED, MERGED FROM 1.6.3] 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.

Proposed:

6.2.4 [MODIFIED, MERGED FROM 1.6.3] Verify that the application is designed with crypto agility such that random number, authenticated encryption, MAC algorithms 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.

---

Current:

V6.5 Cipher Algorithms

Cipher algorithms such as AES and CHACHA20 form the backbone of modern cryptographic practice.

Proposed:

V6.5 Authenticated Encryption Algorithms

Authenticated encryption algorithms built on AES and CHACHA20 form the backbone of modern cryptographic practice.

[randomstuff]

My suggestions and comments:

Applications need to be designed with strong cryptographic architecture to protect data assets as per their classification. Applying authenticated encryption to everything is wasteful, not applying authenticated encryption to anything is legally negligent. A balance must be struck, usually during architectural or high-level design, design sprints or architectural spikes. Designing cryptography as you go or retrofitting it will inevitably cost much more to implement securely than simply building it in from the start.

OK. It feels somewhat weird to explicitly state "authenticated encryption" at this point but I guess it works.

---

1.6.5 [ADDED] Verify that cryptographic discovery mechanisms are employed to identify all instances of cryptography in the system, including authenticated encryption, hashing, and signing operations.

I would not include "authenticated" here because we want to identify all instances of cryptography, even if they are not authenticated encryption :)

---

6.2.4 [MODIFIED, MERGED FROM 1.6.3] Verify that the application is designed with crypto agility such that random number, authenticated encryption, MAC algorithms 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.

OK.

---

V6.5 Authenticated Encryption Algorithms

I would suggest "V6.5 Encryption" instead. The requirements in this section apply everytime you want to use encryption and one of these requirements should be to use authenticated encryption.

Authenticated encryption algorithms built on AES and CHACHA20 form the backbone of modern cryptographic practice.

OK.

[jmanico]

I am extremely grateful that Bart is providing this feedback. Any chance we can get these into 5.0?

CC @danielcuthbert

[tghosth]

OK. It feels somewhat weird to explicitly state "authenticated encryption" at this point but I guess it works.

I think it is unnecessary, we are talking conceptually here.

I would not include "authenticated" here because we want to identify all instances of cryptography, even if they are not authenticated encryption :)

Agree

I would suggest "V6.5 Encryption" instead. The requirements in this section apply everytime you want to use encryption and one of these requirements should be to use authenticated encryption.

I propose Encryption at Rest as later on we talk about "In-Use Data Cryptography"

I agree with the other changes.

[randomstuff]

I propose Encryption at Rest as later on we talk about "In-Use Data Cryptography"

Why "at rest"? This applies equally to in transit encryption (TLS, DTLS, etc.).

[tghosth]

because we talk about encryption in transit in V9

[randomstuff]

Yes, however these requirements (V6.5) could (should ?) apply equally to encryption in transit (and are not "duplicated" in V9). I understood that these requirements (in V6.5) were intended to apply to in-transit encryption (TLS) as well. Do you think these requirements should not apply to TLS and such?

[randomstuff]

For reference, here is the feedback from Bart Preneel on this topic (to clarify, this was a comment which we have received previously, not related to this specific exchange):

I am not sure that it is a good idea to separate encryption from data authentication. I would thus call this section Authenticated Encryption algorithms and say that for the encryption component you only allow AES and Chacha-20 (I would not add Salsa20).

I would add a separate section: Disk Encryption algorithms and there list the XEX, XTS and LRW. That may reduce the risk that developers will use these algorithms in other settings.

This implies immediately that all traditional modes are banned (ECB, CBC, CFB, OFB, CTR) as they are not authenticated encryption modes and they shall not be used for disk encryption.

I was intending to file a separate issue but this is related to this one so maybe we can discuss all these points here?

[tghosth]

So maybe just change the heading to "Encryption Algorithms" ? Would that be sufficient?

[randomstuff]

Yes that, looks good to me.

[tghosth]

Ok thanks, I opened #2527 to handle this