[openpgp] Re: I-D Action: draft-ietf-openpgp-nist-bp-comp- 00.txt
Quynh Dang <[email protected]> Thu, 16 Oct 2025 06:13:51 -0400
| Newsgroups | gmane.ietf.openpgp |
|---|---|
| Message-ID | <CAE3-qLRtcR9qWuhAALoj7=o5nrR=CBwQ+sXftaQcc8hV-+f6pQ@mail.gmail.com> |
Hi Andrew, If the performance of ML-KEM-1024 is acceptable to a user, the user should use it instead of ML-KEM-768 and ML-KEM-512. If it is not, the user should use ML-KEM-768 if ML-KEM-768's performance is acceptable. If ML-KEM-768's performance is not acceptable, the user should go with ML-KEM-512. I am confident in ML-KEM-512's security. In other words, I support the preference of ML-KEM-1024 and ML-KEM-768 over ML-KEM-512. And, I also support enabling the availability of ML-KEM-512 for the users who would like better performance. Regards, Quynh. On Thu, Oct 16, 2025 at 5:25 AM Andrew Gallagher <andrewg= [email protected]> wrote: > Hi, all. > > On 10/10/2025 15:05, Simo Sorce wrote: > > On Fri, 2025-10-10 at 06:51 +0200, Falko Strenzke wrote: > >> After the adoption of draft-ietf-openpgp-nist-bp-comp, we would like to > initiate the discussion about the code points. The draft currently has > ... > >> ML-KEM-512+ECDH-NIST-P-256 MAY > >> ML-KEM-768+ECDH-NIST-P-384 MAY > >> ML-KEM-1024+ECDH-NIST-P-384 MAY > >> ML-KEM-768+ECDH-brainpoolP256r1 MAY > >> ML-KEM-1024+ECDH-brainpoolP384r1 MAY > ...>> ML-DSA-44+ECDSA-NIST-P-256 MAY > >> ML-DSA-65+ECDSA-NIST-P-384 MAY > >> ML-DSA-87+ECDSA-NIST-P-384 MAY > >> ML-DSA-65+ECDSA-brainpoolP256r1 MAY > >> ML-DSA-87+ECDSA-brainpoolP384r1 MAY > ... > > Is it actually worth supporting the 256 bit curves at all? > > > > If we drop them we can reduce the code points to just 3 + 3 > > (or 4+4 if you want to pair the mid-strenght PQC algorithms with > > brainpool 384) > > I have a similar question, but for the post-quantum components. During > the discussion process for draft-pqc, we dropped ML-KEM-512 and > ML-DSA-44 from consideration. Partly this was due to doubts about the > true cryptographic strength of small lattices (particularly ML-KEM-512), > which I don't believe have ever been resolved. Should the same > precautionary principle not be applied here, even if only for consistency? > > Thanks, > A > > _______________________________________________ > openpgp mailing list -- [email protected] > To unsubscribe send an email to [email protected] > _______________________________________________ openpgp mailing list -- [email protected] To unsubscribe send an email to [email protected]