The point of security level matching should be to ensure that all components meet a given *minimum* security level. It should not mean that we arbitrarily reduce the security level of some components just to satisfy some arbitrary notion of equality. Unless there are performance or other reasons to downgrade to AES-128, then we should default to 256. Given that most uses of JOSE are for short messages (<1kB), such performance concerns are often dominated by the key management algorithm.
Besides, if we consider multi-target security models (which should be the default for JOSE), AES-128 doesn’t achieve 128-bit security. Neil > On 11 Feb 2026, at 14:26, Michael P1 > <[email protected]> wrote: > > OFFICIAL > > Hi, > > I agree with you that ML-KEM-768 provides NIST Category III. My point is that > as per the discussion in draft-ietf-hpke-pq, the use of ML-KEM-768 in HPKE is > actually that we are targeting NIST Category I but hedging against future > cryptanalysis of ML-KEM that removes some bits of security from ML-KEM-512. > This targeting of Category I (providing 128-bits of security) is the reason > that P-256 and x25519 are the chosen algorithms in PQ/T hybrid modes and the > reason I suggested AES-128-GCM. > > My preference is to aim for consistency of security level provided across > components, as that makes it clear how much security is provided by the HPKE > algorithm itself. If there is a general feeling that AES-256 is preferable > for simplicity, then I'm not going to push back against that but did want to > highlight that Grover's shouldn’t be the reason for making that choice. > > Following this discussion perhaps it's worth the inclusion of the level of > security that is provided by the HPKE algorithm so that it's clear when > readers are selecting from the options provided? > > Thanks, > Michael > > > OFFICIAL > -----Original Message----- > From: [email protected] <[email protected]> > Sent: 11 February 2026 13:39 > To: [email protected] > Subject: [jose] Re: New I-D: draft-skokan-jose-hpke-pq-pqt (JOSE HPKE PQ > >> On Wed, Feb 11, 2026 at 09:53:35AM +0000, Michael P1 wrote: >> >> My motivation was to do that, though we’ve come at it from different >> angles. Rather than attempting to match components specifically, my >> point was to select a security level that we are trying to provide >> with our HPKE algorithm and select the components that achieve that. >> So in the case of providing 128 bits of security, we would have >> AES-128-GCM + ML-KEM-768 (ML-KEM-512 could be sufficient here but we >> are hedging as discussed in Security Considerations) + P256/x25519 >> (if PQ/T hybrid is required). > > ML-KEM-768 targets NIST Category III, which means its nominal strength is > comparable to AES-192. Since HPKE does not have AES-192, that gets rounded to > AES-256. So ML-KEM-768 should be paired with AES-256. > > For composites, ML-KEM dominates nominal security of KEM, so the same applies > to this case too. > > And JOSE does not have Chacha as cipher, so one gets the following > list: > > * ML-KEM-768 + AES-256-GCM > * ML-KEM-768+P256 + AES-256-GCM > * ML-KEM-768+X25519 + AES-256-GCM > * ML-KEM-1024 + AES-256-GCM > * ML-KEM-1024+P384 + AES-256-GCM > > > > > -Ilari > > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
