[openpgp] Re: I-D Action: draft-ietf-openpgp-nist-bp-comp- 00.txt

On Fri, 2025-10-10 at 12:12 -0400, Quynh Dang wrote:
> Hi Simo, 
> 
> On Fri, Oct 10, 2025 at 10:05 AM Simo Sorce
> <[email protected]> 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
> > 
> > > 5 for encryption:
> > > 
> > > 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
> > 
> > Any reason why ML-KEM-768 is paired with a 384 bit curve for NIST
> > curves, but a 256bit curve for Brainpool?
> > It seem inconsistent.
> > 
> 
> 
> I can speak for the NIST algorithms only. ML-KEM-512+ECDH-NIST-P-256
> is for level 1 security. ML-KEM-768+ECDH-NIST-P-384 is for level 3
> security (not getting into the details of classical and pq security
> here). The reason for having P-384 instead of P521 in ML-KEM-
> 1024+ECDH-NIST-P-384 is that P-521 is rarely supported as I have seen
> in various presentations and I prefer ML-KEM-1024 over ML-KEM-768 and
> ML-KEM-512. 

When you say "rarely supported" do you have a specific field of use in
mind?

As far as I know most common crypto libraries either support all or
none of the NIST Elliptic Curves, and in fact for a long time P-384 was
less well supported than either P-256 or P-521 in at least a few well
know libraries (no optimizations and/or side-channel issues).

Eitherway unless there is a reall issue with Hardware Tokens this
choice remains bizarre to me. And if HW tokens are the issue I am still
confused given no HW token I know of supports ML-KEM-1024 anyway.

HTH,
Simo.

-- 
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]