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 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?
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.PDFIf 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
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?
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]
|
