On Wed, 6 Mar 2024 at 15:22, Neil Madden <[email protected]> wrote:
> On 6 Mar 2024, at 09:46, tirumal reddy <[email protected]> wrote: > > > On Wed, 6 Mar 2024 at 14:13, Ilari Liusvaara <[email protected]> > wrote: > >> On Wed, Mar 06, 2024 at 11:50:04AM +0530, tirumal reddy wrote: >> > On Tue, 5 Mar 2024 at 20:48, Neil Madden <[email protected]> >> wrote: >> > > >> > > Regarding this specific draft under discussion, I'm confused why >> everyone >> > > keeps wanting to cram things into the "enc" header? JWE is quite >> clear that >> > > this header "MUST be an AEAD algorithm"[2]. KEMs are not AEADs. If we >> are >> > > going to add ML-KEM as an encryption algorithm then we should have >> > > something like "alg":"ML-KEM-768","enc":"A256GCM" or >> > > "alg":"ML-KEM-768+A256KW" etc. (or "alg":"XWingXYZ+A256KW" or >> whatever we >> > > choose). >> > > >> > >> > The use of a fully-specified algorithm aims to permit a limited set of >> > 'known good' PQ-KEM ciphersuites rather than allowing arbitrary >> > combinations of PQC algorithms, HKDF, and AEAD algorithms. For instance, >> > ML-KEM-768, with a PQ security level of 3, must not be used with >> A128GCM. >> >> It is should not be used, not must not be used. Strength-matching is >> about performance: It does not make sense to pay significant extra cost >> to make another component more secure than another component which >> limits security (without other good reasons). However, strength- >> matching is no excuse to weaken algorithms without performance benefit >> (unfortunately I have heard of that happening). >> > > The PQ security levels are defined to necessitate computational resources > comparable to or greater than those required for an attack on AES (128, > 192, and 256) and SHA-2/SHA-3 algorithms. This includes exhaustive key > recovery for AES and optimal collision search for SHA-2/SHA-3. I don't see > a reason why a draft should allow ML-KEM-768 (PQ Security Level 3) with > A128GCM (PQ Security Level 1) as an exception, and allowing such arbitrary > combinations would significantly increase the number of configurations. > > > This is already the case in JOSE - e.g. you can use ECDH-ES with P-521 and > then specify A128GCM. You may not like that, but trying to change it > retrospectively is a massive breaking change. > HPKE already specifies the combination of KEM, KDF, and AEAD. The need for specifying the AEAD is two-fold: to restrict the number of combinations and to address the threat to symmetric cryptography from quantum computers (see https://www.ietf.org/archive/id/draft-ietf-pquip-pqc-engineers-03.html#section-7.1 for details). NIST suggests that both AES-192 and AES-256 will remain secure for a very long time but allows applications to continue using AES with a key size of 128 (see https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs). -Tiru > > -- Neil > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
