Re: [openpgp] PQC encryption algorithm selection

["Kousidis, Stavros" <[e-mail]>]

Hi,

during the crypto-refresh work I pointed out that the Brainpool curves are the inerop parameters of the German Administration (see https://mailarchive.ietf.org/arch/msg/openpgp/A5CnJONK5syoKdR0JXBAMUmFXGI/) and as such are needed in OpenPGP implementations that are deployed there.

What we (Aron, Falko and I) did so far is to take the elliptic curve requirements from the crypto-refresh as granted and to combine them with ML-KEM, i.e.

- Concerning X25519 and X448 see the crypto-refresh for "Implementations MUST implement Ed25519 (27) for signatures, and X25519 (25) for encryption. Implementations SHOULD implement Ed448 (28) and X448 (26).". I am not sure if we should break with the already exisiting MUST/SHOULD when it comes to X25519 and X448, respectively. Personally, I think we should have a SHOULD on at least one paranoia-friendly set. Put differently, emphasize (via SHOULD) a set with a higher security guarantee in case future cryptanalysis cuts off some bits there.

- Concerning NIST and Brainpool curves: we opted for the 256 and 384 bit curves, dropping the 521 and 512 bit ones (to reduce the amount of the hybrid combinations), since the 384 bit curves are recommended for all classification levels (see e.g. CNSA 1.0) as well as listing them as MAY which I guess matches the approach of the crypto-refresh that does not state a requirement on these curves explicitely (if I'm not mistaken).

Punchline: (At least) one ML-KEM + Brainpool item would ease adoption of PQC-enhanced OpenPGP in the German Administration considerably. Selecting also (at least) one ML-KEM + NIST would achieve balance between X-stuff / Germany-Europe / US.

Best
Stavros


-----Ursprüngliche Nachricht-----
Von: Paul Wouters <[e-mail]> 
Gesendet: Mittwoch, 7. Februar 2024 17:45
An: Aron Wussler <[e-mail]>
Cc: [e-mail]
Betreff: Re: [openpgp] PQC encryption algorithm selection

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