[openpgp] Fw: Re: PQC encryption algorithm selection

[Aron Wussler <[e-mail]>]

Hi Simon,

> +1 for reducing redundancy.


Understandable

> Based on earlier discussion, it was suggested that performance of
> ML-KEM-1024+X448 was a challenge, suggesting ML-KEM-768+X25519 is
> better.


I'd like to see some pointers to this discussion: in the previous thread I didn't really see such a consensus.
On the other hand, I've done research on this, and presented the results at both IETF 118 and the OpenPGP Summit, and it seems pretty clear that ML-KEM-1024+X448 is not problematic in terms of speed or artifact size [1].

> Thus my suggestion is to keep MUST on ML-KEM-768+X25519 and, for
> crypto-agility reasons, add MUST on sntrup761+x25519 together with
> SHOULD on mceliece6688128f+x448, and to drop the NIST/BSI EC curves.


While mirroring curves does not require redundant code (as they are already in the OpenPGP suite) these other algorithms you mentioned are not standardized, and will require additional dependencies for implementations (that won't be easy to find in standard libraries).
Furthermore, as an individual and implementer, I also see no point in having 2 lattice-based algorithms as MUST.


Cheers,
Aron


[1] https://www.wussler.it/NIST5thPQC.pdf


--
Aron Wussler
Sent with ProtonMail, OpenPGP key 0x7E6761563EFE3930



On Wednesday, 7 February 2024 at 17:46, Simon Josefsson simon=[e-mail] wrote:

> +1 for reducing redundancy.
> 

> If brainpool/NIST P256/P384 is for NIST/BSI compliance, could thet be
> moved to a separate document?
> 

> Based on earlier discussion, it was suggested that performance of
> ML-KEM-1024+X448 was a challenge, suggesting ML-KEM-768+X25519 is
> better.
> 

> Thus my suggestion is to keep MUST on ML-KEM-768+X25519 and, for
> crypto-agility reasons, add MUST on sntrup761+x25519 together with
> SHOULD on mceliece6688128f+x448, and to drop the NIST/BSI EC curves.
> 

> /Simon
> 

> Bart Butler bart=2Bietf=[e-mail] writes:
> 

> > I think everyone would love to just do 25519 and 448. The others (MAY)
> > are there for compliance (NIST/BSI) if I'm not mistaken.
> > 

> > On Wednesday, February 7th, 2024 at 3:03 PM, Simo Sorce [e-mail] wrote:
> > 

> > > Hi Aron,
> > > Why so much redundancy in EC curves?
> > 

> > > This is basically the same thing 3 times over, wouldn't it be more
> > > appropriate to just allow a singe EC curve family so there is no risk
> > > of interoperability issues between implementations ?
> > 

> > > Simo.
> > 

> > > On Wed, 2024-02-07 at 11:39 +0000, Aron Wussler wrote:
> > 

> > > > Hi everyone,
> > 

> > > > In the next weeks, before IETF 119, we'd like to collect feedback
> > > > about the algorithm selection implemented in the draft [1]. We're
> > > > interested in presenting some vectors for the next meeting. It
> > > > would be great if you could provide feedback by March 1st.
> > 

> > > > To keep the discussion focused we're going to start from the
> > > > encryption algorithm selection, KEM combiners will follow (since
> > > > it may also depend on the algorithm selection). Digital signatures
> > > > will also follow in another thread.
> > 

> > > > Right now, we have the following list of algorithms (in table 1)
> > > > +====+===============================+=============+=============+
> > > > | ID | Algorithm | Requirement | Definition |
> > > > +====+===============================+=============+=============+
> > > > | 29 | ML-KEM-768 + X25519 | MUST | Section 5.2 |
> > > > +----+-------------------------------+-------------+-------------+
> > > > | 30 | ML-KEM-1024 + X448 | SHOULD | Section 5.2 |
> > > > +----+-------------------------------+-------------+-------------+
> > > > | 31 | ML-KEM-768 + ECDH-NIST-P-256 | MAY | Section 5.2 |
> > > > +----+-------------------------------+-------------+-------------+
> > > > | 32 | ML-KEM-1024 + ECDH-NIST-P-384 | MAY | Section 5.2 |
> > > > +----+-------------------------------+-------------+-------------+
> > > > | 33 | ML-KEM-768 + ECDH- | MAY | Section 5.2 |
> > > > | | brainpoolP256r1 | | |
> > > > +----+-------------------------------+-------------+-------------+
> > > > | 34 | ML-KEM-1024 + ECDH- | MAY | Section 5.2 |
> > > > | | brainpoolP384r1 | | |
> > > > +----+-------------------------------+-------------+-------------+
> > 

> > > > Please provide feedback on the algorithms, and if you think they
> > > > should be "MUST", "SHOULD", or "MAY". The proposed list is derived
> > > > from the results of the NIST standardization process, hybrid with
> > > > the curves already supported from OpenPGP for compliance purposes.
> > 

> > > > Finally, please note that this is not the sole opportunity to
> > > > standardize PQC algorithms: as of the crypto-refresh, new
> > > > algorithms will need a specification and designated expert review,
> > > > and not an RFC.
> > 

> > > > Cheers and thanks,
> > > > Aron
> > 

> > > > [1] https://www.ietf.org/archive/id/draft-ietf-openpgp-pqc-00.html#name-algorithm-specifications
> > 

> > > > --
> > > > Aron Wussler
> > > > Sent with ProtonMail, OpenPGP key 0x7E6761563EFE3930
> > > > _______________________________________________
> > > > openpgp mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/openpgp
> > 

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

> > > _______________________________________________
> > > openpgp mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/openpgp
> > 

> > _______________________________________________
> > openpgp mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/openpgp
> 

> _______________________________________________
> openpgp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/openpgp