openpgp-pqc / draft-openpgp-pqc

Repository of the WIP draft-ietf-openpgp-pqc
Other
8 stars 2 forks source link

Please add sntrup761 and mceliece6688128 #76

Closed jas4711 closed 2 weeks ago

jas4711 commented 7 months ago

I suggest to add sntrup761 and mceliece6688128 to the document.

Including some rationale also posted to the mailing list:

The argument would be that sntrup761 is a reasonable alternative for lattice-based kyber, and mceliece is a conservative fallback if lattices fails.

I believe that for some deployments, the currently chosen algorithms won't be relevant, in the same way that NIST would consider some algorithms not relevant for their deployment. Fortunately NIST reconsider, so we now have Curve25519 in NIST too, and having others lead the way may have helped that happen.

Plenty of arguments can be made comparing any two crypto algorithms. While it is easy today to see what went wrong in the design of MD4, RC4, DES; I don't believe we yet can easily tell what the bad parts of current PQ algorithms are (except for the recently broken ones, but that doesn't give us enough of patterns to look for) including the mentioned algorithms. Classic McEliece is the only one with longer track record, but even that has not been widely deployed on the Internet.

Hard coding deployments of protocols to one mandatory crypto algorithm makes the ecosystem vulnerable if a weakness if found in that algorithm. Compare how long it took to migrate from RC4 in TLS. I believe the modern design approach is to not have crypto negotiation built into protocols but rather roll protocol version to upgrade all protocol semantics, and have one hard coded crypto algorithm and no in-protocol negotiation. That's not feasible for legacy PGP as far as I can tell.

This all leads me to believe that it is better to mandate at least two different PQ-safe algorithms so that we get two variants deployed and get better testing of algorithm negotiation. The algorithms to select is a subjective choice, and I suggest we pick variants that cater to different communities.

wussler commented 3 months ago

Hi @jas4711, as discussed at IETF 119, we are trying to reduce the number of algorithms, and split off variants to separate drafts to ensure a less controversial draft and an easier document for the WG. We just removed most of the codepoints included in the document.

falko-strenzke commented 2 weeks ago

I am closing this issue now since like Aron wrote, further crypto algorithms are out-of-scope of this draft.