Thanks Filip, (again, chair hat off)
I very much agree with your principle of keeping this as simple as we can – seeking to reduce the number of options is the right thing to do and I like your approach of starting with a minimal set and building from there if there are strong reasons to do so. 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). That is also the approach taken in draft-ietf-hpke-pq too with the test vectors provided being a good example of this. So from my point of view, the minimal set would be: * ML-KEM-768 + AES-128-GCM * ML-KEM-768+P256 + AES-128-GCM * ML-KEM-768+x25519 + AES-128-GCM * ML-KEM-1024 + AES-256-GCM * ML-KEM-1024+P384 + AES-256-GCM (acknowledging Orie’s point on this one that there may be lower demand) As I say, we are aiming for the same thing, just approaching it from different angles. Personally, I’d start with this list but if requests with good justifications come in for different combinations then that’s fine by me. Simo – the point in my previous email is that it is there is now detailed analysis that shows that security impact of Grover’s algorithm on AES is limited, so AES-128 remains secure. ETSI Standard TR 103 967 and CHES 2024’s “"Quantum Attacks on AES" independently came to this conclusion. With regards to NIST – are you referring to the work to specify Wider Variants of AES? The motivation for that was about processing large amounts of data so looking for 256-block size, nothing to do with Grover’s or the threat of CRQC. Thanks, Michael From: Filip Skokan <[email protected]> Sent: 10 February 2026 17:51 To: Orie <[email protected]>; Michael P1 <[email protected]> Cc: [email protected] Subject: Re: [jose] Re: New I-D: draft-skokan-jose-hpke-pq-pqt (JOSE HPKE PQ On a second thought, matching the relative strength of the PQ component seems more appropriate. So I believe the current I-D version to be in order, the additional strength relative to the traditional component doesn't hurt. - Filip 10. 2. 2026 v 16:03, Filip Skokan <[email protected]>: 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]<mailto:[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]<mailto:[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 <[email protected]<mailto:[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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> _______________________________________________ jose mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
