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]
