Re: Post-quantum defaults

"Robert J. Hansen via Gnupg-users" <[email protected]> Mon, 27 Apr 2026 12:29:35 -0400
Newsgroups	gmane.comp.encryption.gpg.user
Message-ID	<[email protected]>
A note to the list: from the tenor and tone of this email, it would 
appear Andrew intended it to be an off-list private communication rather 
than a public one. From this we can learn a very important lesson: if 
someone as on-the-ball as Andrew can make human errors that jeopardize 
the privacy of his communications, *so can you*, and your security 
posture needs to take that into account.

I have no authority here: I'm just a user like anyone else. I am 
therefore going to ask everyone, politely, as a favor to me, to not 
respond to either his email or this one.

The Libre/OpenPGP split is painful. We as a community can do very little 
to fix it: that is the task of certain people on both sides of the rift. 
But we as a community can do a lot to prevent it from being fixed, and 
responding to Andrew's email or this one likely will make fixing it harder.

On 4/27/26 11:21 AM, Andrew Gallagher via Gnupg-users wrote:
> On 27/04/2026 11:26, Werner Koch wrote:
>  >
>  > The MTG and BSI folks eventually came up
>  > with a draft and - according to personal communication - on suggestion
>  > from certain attendees at an IETF meeting
> 
> Which particular attendees? You keep blaming things on unnamed people. 
> Maybe you think it's impolite to name names, but it reads like a 
> conspiracy theory. I've been at most of the meetings you mention, and 
> they're not as sinister as you make out.
> 
> The IETF WG is mostly a bunch of goofy nerds. I count many of them as 
> personal friends. They're trying to do the right thing, in the face of 
> the inevitable disagreements and technical challenges and backwards- 
> compatibility nightmares. We don't get everything right, and that's OK. 
> That's why we rely on each other to point out blatant mistakes and 
> missed opportunities, and the ways we can all do better next time. It's 
> difficult, but it's healthy. Nobody can be expected to do critical 
> infosec work by themselves. We need each other, and mostly we enjoy it.
> 
> (It might not seem that way on the mailing list sometimes, but family 
> arguments aren't the end of the world!)
> 
>  > to change from the usual PGP
>  > way to the uncommon thing of assigning a public key algorithm id to
>  > each combination of algorithms and parameters.
> 
> The rough consensus in the WG during the drafting of RFC9580 was that 
> parameterised algorithm code points cause more problems than they solve. 
> The new algorithms in RFC9580 (but not the existing ones!) follow this 
> convention, so it makes sense for the PQC draft to do the same.
> 
> Most implementers agree that the new convention is cleaner. However, 
> this point is obviously not crucial for any security properties. It's 
> surely not necessary for GnuPG to diverge from how the rest of the 
> OpenPGP ecosystem represents PQC keys on the wire, which is largely a 
> minor matter of taste.
> 
> Is this the hill that you're willing to die on? A numbering convention? 
> *Really*?
> 
>  > The WG later changed more
>  > things which I did not follow in particular because the important
>  > Brainpool support was also removed by them.
> 
> There was some initial disagreement about how many curves in total to 
> specify, so the document was split to avoid getting bogged down. The 
> first document specifies curves 25519 and 448, and the second document 
> specifies the NIST and Brainpool curves:
> 
> * https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-pqc
> * https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-nist-bp-comp
> 
> Brainpool support was always a goal of the process. Remember, the BSI 
> are co-authors of both documents. There was surely no need to fork the 
> PQC draft in order to satisfy the additional curve requirements of your 
> client (i.e. the BSI)?
> 
>  > I later had a meeting at the BSI (iirc, due the projects goal of
>  > implementing the algorithms in Libgcrypt).  It was important to them
>  > that their key combiner needs to be used.
> 
> It is also important to remember that BSI have agreed to the updated KEM 
> combiner from draft-ietf-openpgp-pqc, so there is no reason for GnuPG 
> not to implement it. I find it totally bizarre that you are using a 
> private meeting with the BSI as an argument *against* implementing a 
> BSI-instigated and BSI-approved specification.
> 
>  > And that is what Niibe-san
>  > and me implemented in GnuPG and later specified in LibrePGP.
> 
> I can never tell whether your recurring name-dropping of Niibe-san in 
> these arguments is meant to credit him for his achievements, or use him 
> as a scapegoat.
> 
> I have not forgotten how you let him put his name to RFC9580 and then 
> threw him under the bus by condemning the results of his work, after you 
> had quit the design team in a huff because you could no longer work with 
> the WG. It is none of my business whether you have ever apologised to 
> him in private, but your lack of public remorse has not helped the PGP 
> ecosystem shed its toxic public image.
> 
> We need to foster a more inviting community, or it will die with us.
> 
>  > The changes affected only protocol format details and not the actual
>  > crypto.
> 
> I agree the security properties are the same. I just feel it is a 
> disastrous situation to specify two almost-identical KEM combiners for 
> two almost-identical protocols, simply because communication channels 
> have broken down.
> 
> You don't engage with other implementers, you miss meetings, you rely on 
> second-hand information, you implement and ship outdated specs, and then 
> you throw shade at everyone else for making decisions that you don't 
> agree with. Decisions that, when viewed from outside this little bubble, 
> *don't matter*. But this tinpot disagreement is escalating to the point 
> where end users are abandoning the PGP ecosystem entirely. Is that the 
> outcome we want?
> 
> 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 point of commonality between 
> PQC implementations? *I will help you*. I will work for free. I just 
> want this to be over.
> 
> A
> 
> _______________________________________________
> Gnupg-users mailing list
> [email protected]
> https://lists.gnupg.org/mailman/listinfo/gnupg-users

_______________________________________________
Gnupg-users mailing list
[email protected]
https://lists.gnupg.org/mailman/listinfo/gnupg-users
OpenPGP_signature.asc (application/pgp-signature, 236 B)