Re: [openpgp] PQC encryption algorithm selection

[Aron Wussler <[e-mail]>]

Hi Paul,

Thanks for your feedback!

> If we pick 29, I think we should make 30 a MAY.
> We should pick at least one SHOULD/MUST that complies with FIPS
> We should pick at least one SHOULD/MUST that complies with BSI/Europe

The current logic we used to pick MAY / SHOULD / MUST is based off the crypto-refresh requirements.

Re. FIPS compliance, once FIPS 203 is a standard, all of the hybrids will be de facto FIPS compliant, as long as we use an SP800-56C compliant KDF (to my understanding).


> Right, but I think going that route would mean your algorithm really can
> only be a MAY. Standards track action should be needed for a SHOULD or
> MUST.

I sorta agree with you, even though in general an implementation can choose not to follow a standard :)

Cheers,
Aron

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



On Wednesday, 7 February 2024 at 17:45, Paul Wouters <[e-mail]> wrote:

> On Wed, 7 Feb 2024, Aron Wussler wrote:
> 

> Speaking as an individual only.
> 

> > 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 | | |
> > +----+-------------------------------+-------------+-------------+
> 

> 

> If we pick 29, I think we should make 30 a MAY.
> We should pick at least one SHOULD/MUST that complies with FIPS
> We should pick at least one SHOULD/MUST that complies with BSI/Europe
> 

> I would argue that perhaps it is a bit too soon to make these decisions
> now, and that it would be good to look at other WGs such as TLS and
> IPsec before making a choice for OpenPGP.
> 

> > 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.
> 

> 

> Right, but I think going that route would mean your algorithm really can
> only be a MAY. Standards track action should be needed for a SHOULD or
> MUST.
> 

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

> 

> Note this draft is using the "old" names for the registry that the
> crypto-refresh document updates (eg PGP -> OpenPGP).