Hi All, The choices look reasonable to me, but if I were to pick at one, it would be MLKEM1024-P384.
It's my understanding the P384 would mainly be used by folks transitioning based on: - https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF If I were to guess, P384 ECDH adoption is probably low (HPKE-1 even lower) and folks who are using it will have several options to consider now. They can migrate to ML-KEM-1024 or MLKEM768-P256... It's easy to register MLKEM1024-P384, but I wonder given the other options available, why someone would choose it. Perhaps I have the wrong intuition about it. Regards, OS, no hats On Tue, Feb 10, 2026 at 8:10 AM Filip Skokan <[email protected]> wrote: > Hello Michael, > > On AES-256-GCM: The primary motivation here is uniformity and simplicity > of choice. Within the PQ[/T] algorithm set the goal was to offer a choice > between AES-GCM and ChaCha20Poly1305 but not introduce a further AES-128 > vs. AES-256 decision axis. This keeps the number of algorithms manageable, > each KEM gets exactly two AEAD options rather than three. > > Note that HPKE-7 was added to draft-ietf-jose-hpke-encrypt upon request > from WG members and that one also combines P-256 with AES-256-GCM. > > On SHAKE256: Similarly motivated by uniformity and implementation > dependency reduction. ML-KEM is internally using Keccak/SHAKE, and as > draft-ietf-hpke-pq notes, it can be convenient for HPKE users of these KEMs > to rely solely on SHA-3. By using SHAKE256 uniformly, implementations that > adopt the PQ/PQT algorithms from this draft only need a SHA-3 > implementation for the KDF, rather than needing both SHA-2 and SHA-3. So, > it keeps the number of algorithms and dependencies down. > > Bottom line is that the specific algorithm combinations are very much up > for discussion at this stage and we merely try to keep their count > manageable. The draft and its test vectors can be regenerated with > different KDF and AEAD choices with ease, so if the sentiment would be to > adjust any of these pairings, we're happy to do so. It would be amazing if > we were able to agree on pairing each KEM with exactly one KDF and AEAD. > > Maybe like so (see below), without ChaCha and with P-256 and X25519 paired > with SHAKE128 and AES-128-GCM, but as evident by HPKE-7, requests will come > for pairing 128-bit traditional curves with AES-256-GCM at which point I'd > rather have "no additional security given" than an explosion of the number > algorithm choices. > > +--------------------+----------+-------------------+ > | HPKE KEM | HPKE KDF | HPKE AEAD | > +--------------------+----------+-------------------+ > | MLKEM768-P256 | SHAKE128 | AES-128-GCM | > | (0x0050) | (0x0010) | (0x0001) | > +--------------------+----------+-------------------+ > | MLKEM768-X25519 | SHAKE128 | AES-128-GCM | > | (0x647a) | (0x0010) | (00x0001) | > +--------------------+----------+-------------------+ > | MLKEM1024-P384 | SHAKE256 | AES-256-GCM | > | (0x0051) | (0x0011) | (0x0002) | > +--------------------+----------+-------------------+ > | ML-KEM-768 | SHAKE256 | AES-256-GCM | > | (0x0041) | (0x0011) | (0x0002) | > +--------------------+----------+-------------------+ > | ML-KEM-1024 | SHAKE256 | AES-256-GCM | > | (0x0042) | (0x0011) | (0x0002) | > +--------------------+----------+-------------------+ > > Do you think starting off with these 5 (+ their KE variants) and seeing > what additional discussions arise later is better? > > S pozdravem, > *Filip Skokan* > > > On Tue, 10 Feb 2026 at 13:25, Michael P1 <michael.p1= > [email protected]> wrote: > >> Hi all, >> >> >> >> Posting as an individual, with chair hat off. >> >> >> >> Firstly, thank you Filip and Brian for doing this work and I agree with >> this as a path forward following the previous discussions. >> >> >> >> I did have a question on the algorithm combination choices. At the >> moment, the security levels between KEM, KDF and AEAD are not consistent in >> some of the algorithms. In draft-ietf-jose-hpke-encrypt we match >> P-256/x25519 with AES-128-GCM as they provide the desired security level, >> but that's not the case here at the moment. >> >> >> >> I understand the choice of ML-KEM-768 over ML-KEM-512 as per discussions >> around draft-ietf-hpke-pq and this is documented well in the security >> considerations. >> >> >> >> However, could you outline the reasoning for the choice of AES-256-GCM >> over AES-128-GCM? >> For example, in algorithm HPKE-8, we use P256 in our KEM to give 128 bits >> of traditional security for those who want to use a hybrid approach, and so >> AES-256-GCM provides no additional security over AES-128-GCM in this >> algorithm. >> >> >> >> If it's motivated by discussions of Grover's algorithm, then there has >> been separate analysis from both ETSI and the University of Waterloo to >> show that security impact on symmetric algorithms of quantum computing is >> in-fact limited. >> >> >> >> Similarly, worth discussing the motivation for the choice of SHAKE256 >> throughout. >> >> >> >> Thanks again for your work on this, >> Michael >> >> >> _______________________________________________ >> 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]
