Please, for the love of all that is good and beautiful in the world,
can we work together to implement algorithm 35 from
draft-ietf-openpgp-pqc in GnuPG, so that we can at least have one

If that is code point for Kyber+ECC: The LibrePGP specification for this
has been in deployed in beta versions for a long time and is since
January part of the most widely used *PGP implementation, namely
Gpg4win.


I’m a complete outsider here. The only reason I’m subscribed is because I once had to ask a question, which uncovered a rift that, from the outside, looked thus: an entire community on the one hand (OpenPGP), and on the other hand the 800 pound gorilla (GnuPG). Unlike any other implementation, we can’t ignore what GnuPG outputs by default, and we can’t output anything it cannot decode. Which gives you, Mr Koch, a rather unique ability: bending the world to your will.

Using that ability tends to breed resentment though: every time you diverge from the rest of the world, every time they change something *and you don’t*, more people will wish they could break free from GnuPG’s hold. (For full disclosure, I already do.)

And today I learn that on the upcoming post quantum support, there will be *another* divergence between OpenPGP and LibrePGP? Unless you can argue urgency, and everyone believes you, this will breed more resentment.


For signatures I see no immediate need, thus better let the
algorithms settle 2 or 3 years before they get specified in *PGP.

Good.  Avoiding a third rift sounds reasonable.

Loup.


_______________________________________________
Gnupg-users mailing list
[email protected]
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Reply via email to