Thank you Orie, to clarify - "The choices look reasonable to me" refers to the ones in the draft or the inline table ones from the response you replied to?
S pozdravem, *Filip Skokan* On Tue, 10 Feb 2026 at 15:44, Orie <[email protected]> wrote: > 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]
