Quantum Safe & Crypto Agility for 5.0

[danielcuthbert]

As the Quantum Cryptography train moves at a faster pace, I think it prudent we rethink https://github.com/OWASP/ASVS/blob/master/5.0/en/0x14-V6-Cryptography.md to include Post Quantum Cryptography, the use of new algorithms such as CRYSTALS-Dilithium , FALCON and SPHINCS+ and how one might adopt better crypto agility.

I'm self-assigning this as this is something I'm actively involved in and will rope in Dr. Mark Carney too

[tkisason]

Under 0x10-V1-Architecture under V1.6 Cryptographic Architecture i considered adding something like:

"Verify that all selected cryptographic systems, protocols, algorithms or modes of operation are appropriate for the application's threat model and defined security requirements"

What i most commonly see is that there is no real reasoning why an algorithm, mode of operation or system was used. Someone considered "AES256-CBC" a great choice since it's the biggest keysize. This would try and at least document some of those choices in the architecture documentation and get some assessment to the architecture choices.

[tghosth]

@set-reminder 2 weeks @danielcuthbert to check status on this

[octo-reminder[bot]]

⏰ Reminder Wednesday, December 21, 2022 12:00 AM (GMT+01:00)

@danielcuthbert to check status on this

[octo-reminder[bot]]

🔔 @tghosth

@danielcuthbert to check status on this

[danielcuthbert]

1: We plan to make this very much a usable section on how one does cryptography in applications that sets a bare minimum baseline. For example with ciphers

• We want you to use ChaCha20-Poly1305*
• We are ok with you using AES-128
• We don't want you using 3TDEA/RC4 etc

2: Bits and bobs

• We want you to use 256 bit length
• We are ok with you using 112 bit length for legacy
• We don't want you using <112 bit length

You get the drift hopefully, but what would be super helpful for us is to understand what you, yes you looking at the screen oddly, uhu yup you, would like to see in a modern cryptography standard that is Post-quantum cryptography (PQC) secure and ready and usable.

Would love it if you commented, shared this widely and gave us as much feedback as possible to make this a solid cryptography section for V5.

[unprovable]

Getting away from inexact "bits and bobs" (much as I love our English colloquialisms :-P) Let's be a bit more formal: We need the standard to have at least two main parts - the cryptography part in ASVS that can change "as slowly as possible" and a supplementary document that carries the 'state of the art' for what is good/bad/ugly cryptography.

To this end, we should get rid of the cryptography section as it is - just completely rewrite it. @tkisason - I like your suggestion.

The way I have written standards before is to split out the 'algorithms' from the 'implementations'. This means having the ASVS standard itself say things like:

• L1 - we just want 128bit security minimum. Stop using 112bit stuff please. Also, you should have a CBOM/cryptographic asset list somewhere. Use AES128, but in any mode.
• L2 - We need you to be AES128-AES256 with AEAD implementations of modes or EtH/EtM variants as a rule, with a CBOM/Crypto asset list AND a plan to migrate to PQC.
• L3 - AES256-GCM or AES256-GCM-SIV as a minimum. Full CBOM and PQC implementation testing.

The baseline for security levels that I've used the most is NIST SP-800-57-Pt1, especially the table on page 71. I've also always preferred RFC2119 language of 'MUST', 'MAY', 'SHOULD', etc. as it makes things VERY clear.

So, once you have determined the approved algos, these items then influence what we do for, say, SSH bulk cipher parameters:

• L3 - AEAD_AES256_GCM, aes256-gcm@openssh.com, or chacha20-poly1305@openssh.com
• L2 - Anything at L3 PLUS: AEAD_AES128_GCM, aes128-gcm@openssh.com
• L1 - Anything at L3 or L2 PLUS: aes128-cbc, aes192-cbc, aes256-cbc, aes128-ctr, aes192-ctr, aes256-ctr

Comments?

[tkisason]

Thanks for the feedback!

I would suggest that we don't specify algorithms or modes, but focus on the result we want to achieve. And the only way for anyone who is developing an application to select good algorithms and protocols is to develop a threat model and write down some potential security requirements. Even a simple (dare I say, bad) threat model will help anyone reviewing the application to see if the selected algorithms are appropriate. If someone is developing an application whose data storage lifetime is 20 years, they must consider PQ. For example, we can do something like this:

"Verify that the selected cryptographic systems, protocols, algorithms, key length and modes of operation are selected in accordance to the current best practices for the application's threat model and security requirements. For instance consider using the Commercial National Security Algorithm Suite or other relevant regional/country-specific alternatives as guidance."

First off, a threat model and security requirements document must exist. After this, the document gives a reference to a larger governance document covering a large number of cases (web services, firmware signing, etc.) with correct answers that includes the good stuff like XMSS, LMS and ML-KEM. For folks averse to this governance document, they can select their national / regional algorithm selection document if they want to use something like GOST, SM4 or Camellia.

If this is not enough, we could add the "correct answers section" to the "Appendix X: Recommendations" chapter, or simply state the requirements in the crypto chapter with correct answers. I'm fine with either and I'm willing to write the requirements for review.

[jmanico]

I agree with @tkisason—several of the early supposed "post-quantum algorithms" have already determined to be crackable. This space is stil emerging.