Ilari, JWE "enc" may not have ChaCha but HPKE AEAD does, so we *can* include ChaCha in our HPKE algs if we wanted to (and in fact the I-D *does*). Maybe only in the IE algs so there's no awkward pairing of HPKE KE AEAD and JWE "enc". I agree with the rest and it matches what the I-D has at the moment.
I'm not hearing anything against SHAKE256 KDF so I'll proceed with an assumption that that's alright with everyone so far. S pozdravem, *Filip Skokan* On Wed, 11 Feb 2026 at 14:38, Ilari Liusvaara <[email protected]> wrote: > 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]
