From jb-gnumlists at wisemo.com  Wed Apr  1 00:58:59 2026
From: jb-gnumlists at wisemo.com (Jakob Bohm)
Date: Wed, 1 Apr 2026 00:58:59 +0200
Subject: Suggestions of standards added to openpgp/Gnupg/LibrePgp
In-Reply-To: <CACnSDUtE6gJ_FjfbUY=FHkEz-5K4dYfKWLJzdNUZCPe4T5WiVw@mail.gmail.com>
References: <CACnSDUtfHY2SRa2XqEXBZD+k+WAG29otEATJVSOKjJQRXahPyQ@mail.gmail.com>
 <d6dfefde-7ed8-4d95-8fe0-8c15420d8e05@sixdemonbag.org>
 <CACnSDUtE6gJ_FjfbUY=FHkEz-5K4dYfKWLJzdNUZCPe4T5WiVw@mail.gmail.com>
Message-ID: <011e1fe0-99bd-ddb0-8705-e472aee3e976@wisemo.com>

On 31/03/2026 17:09, Hakun_the_eril via Gnupg-users wrote:
> Oh? I was not aware of that.
>
> My arguments are:
> Shamirs secret has been around since 1979,- I find it odd that it is 
> not included in Openpgp.
You mean "secret sharing scheme", not any of the other things he made that
deals with secrets?

> It could add things like distributed key custody, hardware enforced 
> split custody. Right now,- if someone with a key leaves or dies 
> important encrypted data gets lost.
> That would cause issues for any organization.? ?It could also fix the 
> plausible "only one person knows the password" to a " K of N can 
> cooperate" situation.
> That would also work for a encrypted file system,- split into parts.
> If a hardware token has , say 256 GB space.. Then it can be a part of 
> a Shamirs secret scheme.? 4 out of 6 keys could be used to recreate 
> the shared encrypted file system on a empty drive.
Copying the deeply protected secret stuff to a plaintext copy on a 
device with
unknown deletion abilities is a clear security risk that should not be 
taken.
Instead create an intermediary layer that extracts the secret key from the
sharing scheme and keeps it in memory just long enough to access the actual
secret data (such as PGP private keys) on the fly.
>
>
> Ephemeral signed elliptic curve diffie hellman is usable, because it 
> will solve a forward security issue.
> If you encrypt say radio transmissions with the same key over long 
> periods anyone who gets hold of that key can decrypt old transmissions.
> TLS 1.3 , the signal protocol and versions of openssh that is never 
> than? 5.7 supports this.
Ephemeral DH (classic or ECC) only works if the recipient can send you
an ephemeral public key, thus not on any one-way channel such as
broadcast radio, e-mail, messages for the future etc. etc.

Signing the keys makes sense only if there is a risk that an attacker
sends you a different key, which there often is, but it is not a given,
since some means will eventually be needed to establish trust in the
party whose key you need to trust.

>
> I have no business relations with Baochip,- I just think its 
> interesting and neat.
>
>
> tir. 31. mars 2026 kl. 16:27 skrev Robert J. Hansen via Gnupg-users 
> <gnupg-users at gnupg.org <mailto:gnupg-users at gnupg.org>>:
>
>     Hakun, this list overwhelmingly prefers plain text, not HTML. Some
>     list
>     members (including Werner!) simply don't read HTML-composed
>     emails. And
>     sometimes, HTML emails render in a format that makes it impossible
>     to read.
>
>     > As the Baochip-x1 has the hardware to do a lot of cryptographic
>     > functions like active zeroisation, Ed25519 signed boot, Glitch
>     sensors,
>     > security mesh, PV sensor, ECC-protected RAM,Algorithm-agnostic
>     engine
>     > etc I think that these could be added to standards.
>
>     Why?
>
>     That's the basic question here. What is the use case for LibrePGP
>     that
>     isn't being adequately addressed by the spec, and how would these
>     changes mitigate that shortcoming?
>
>     If you can give a good and terse answer to that question I'll be
>     happy
>     to consider this proposal.
>
>     > The baochips specs can be found here: https://www.baochip.com/
>
>     Do you have any business relationship to this vendor?
>
Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260401/49a7fa03/attachment.html>

From gnupg-users at city17.xyz  Fri Apr  3 13:04:57 2026
From: gnupg-users at city17.xyz (jman)
Date: Fri, 03 Apr 2026 13:04:57 +0200
Subject: Why Some Criticisms Matters More Than Others
In-Reply-To: <874ilx8wga.fsf@jacob.g10code.de> (Werner Koch via Gnupg-users's
 message of "Mon, 30 Mar 2026 12:04:37 +0200")
References: <874ilx8wga.fsf@jacob.g10code.de>
Message-ID: <878qb4qp7q.fsf@nyarlathotep>

Werner Koch via Gnupg-users <gnupg-users at gnupg.org> writes:

> Robert was kind enough to to turn one of his recent mailing list replies
> into an essay which is now available at
>
>   https://gnupg.org/blog/20260320-some-criticism-matter.html

If the goal of this article is to clarify the story behind RFC9580 and the critics to GnuPG, I think 
the article looks worth a read but without said context, links and sources for those claims, looks a 
bit unsubstantial.
FWIW: I am reading the article from the point of view of someone that has heard about this 
discussion but doesn't have great context.

(Probably a link to the mailing list reply would also help me understading what this article is 
about)

Hope this feedback is useful


From rjh at sixdemonbag.org  Fri Apr  3 18:08:15 2026
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Fri, 3 Apr 2026 12:08:15 -0400
Subject: Why Some Criticisms Matters More Than Others
In-Reply-To: <878qb4qp7q.fsf@nyarlathotep>
References: <874ilx8wga.fsf@jacob.g10code.de> <878qb4qp7q.fsf@nyarlathotep>
Message-ID: <644c4fb3-6388-4e6c-b64c-196b119c6b67@sixdemonbag.org>

> If the goal of this article is to clarify the story behind RFC9580 and 
> the critics to GnuPG?

The goal of this article is stated in clear text right at the beginning: 
to explain, and I quote, "Why Some Criticisms Matters More Than Others".

I cited four basic kinds of criticisms: the Fearmongers, the Half 
Truthers, the Ivory Towerists, and the Honest Brokers.

I also stated in clear text right at the beginning, "[t]he things I'm 
speaking of apply to both LibrePGP and RFC9580 OpenPGP. The criticisms 
made against one usually wind up getting made against the other, whether 
for good or ill. These criticisms fall on a spectrum, from infuriatingly 
dishonest all the way to carefully thought out and researched."

There are absolutely some honest, good-hearted, solid critics of 
LibrePGP on the RFC9580 side of the fence. There are also some people 
operating from less than pure motives. With regard to any particular 
critic, I remain silent.[*] I encourage you to decide for yourself which 
kind of critic it is.

[*] with one exception: there seems to be a persistent myth that Daniel 
Kahn Gillmoor and I don't get along. Quite the opposite. I've met him a 
couple of times and each time we got along well. Don't mistake the two 
of us sometimes arguing heatedly about technical matters with there 
being any level of personal animosity. I can tell you from personal 
experience Daniel doesn't play the game that way, and I hope the same 
can be said about me.

, I think the article looks worth a read but without
> said context, links and sources for those claims, looks a bit 
> unsubstantial.

There is no context.

Ever since PGP was released in 1991, there have been a chorus of voices 
declaring that it, and/or its descendants, have been insecure, 
government plants, that the NSA has a secret Utah data center that can 
break RSA, and so on. This whisper campaign against ClassicPGP, OpenPGP 
2440, OpenPGP RFC 4880, OpenPGP RFC9580, and now LibrePGP, has gone on 
for so many decades that someone on the mailing list asked why there was 
this persistent, decade-long campaign against it.

> FWIW: I am reading the article from the point of view of someone that 
> has heard about this discussion but doesn't have great context.

Good. Please stay that way. Dirty laundry is best when it's not aired in 
public. A lot of people behaved in ways that in hindsight maybe they 
wish they hadn't. At some point in the future, I hope these people will 
have the courage and personal growth to say, "you know, maybe I was the 
bad guy here," and consider the possibility the other side wasn't as bad 
as they thought. When that happens -- and I believe it's a "when," not 
an "if": I'm an optimist who believes in people -- the quieter we are in 
the divorce, the easier it will be to reconcile.

I am not particularly privy to details. (Some people think I am. I'm 
really not.) To the extent I am involved in this at all, I wish I 
wasn't, and to the extent I know anything about this, I wish I didn't.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260403/1c83925c/attachment-0001.sig>

From klaus+gnupg at ethgen.ch  Mon Apr  6 01:35:41 2026
From: klaus+gnupg at ethgen.ch (Klaus Ethgen)
Date: Mon, 6 Apr 2026 00:35:41 +0100
Subject: Different locale for pinentry
Message-ID: <adLxzR3vBMuEpQsT@chil>

Hi,

I always use locale latin1. But when pinentry is in use, it starts some
GUI boxes, which nee UTF-8. The most annoying here is the word "Z?hler"
instead of Z?hler.

Is there any way to start GUI stuff with UTF-8-locale instead of
something else? Alternatively, the whole gpg-agent or any pinentry could
be made started with UTF-8.

Regards
   Klaus
-- 
Klaus Ethgen                                       http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16            Klaus Ethgen <Klaus at Ethgen.ch>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 728 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260406/ed0e2e09/attachment.sig>

From guru at unixarea.de  Mon Apr  6 08:50:36 2026
From: guru at unixarea.de (Matthias Apitz)
Date: Mon, 6 Apr 2026 08:50:36 +0200
Subject: Different locale for pinentry
In-Reply-To: <adLxzR3vBMuEpQsT@chil>
References: <adLxzR3vBMuEpQsT@chil>
Message-ID: <adNXvKxcUXGq-AEK@c720-1400094>

El d?a lunes, abril 06, 2026 a las 12:35:41a. m. +0100, Klaus Ethgen escribi?:

> Hi,
> 
> I always use locale latin1. But when pinentry is in use, it starts some
> GUI boxes, which nee UTF-8. The most annoying here is the word "Z?hler"
> instead of Z?hler.
> 
> Is there any way to start GUI stuff with UTF-8-locale instead of
> something else? Alternatively, the whole gpg-agent or any pinentry could
> be made started with UTF-8.

Hello,

You coul try to configure a shellscript in gpg-agent which sets the
cnvironment and launches the real pinentry command.

HIH

	matthias

-- 
Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

In Cuba bei der Ankunft eines Schiffes mit Roh?l: "Endlich, die Russen sind da!
En Cuba al llegar un barco con crudo: "Por fin, los rusos llegan!"
Wann kommen sie endlich zu uns? ?C?ando llegan por fin para ac??


From klaus+gnupg at ethgen.ch  Mon Apr  6 14:53:31 2026
From: klaus+gnupg at ethgen.ch (Klaus Ethgen)
Date: Mon, 6 Apr 2026 13:53:31 +0100
Subject: Different locale for pinentry
In-Reply-To: <CACOMi+cNwc1po171kdYUczoNHGcjhWTJxCjbXHP=Sv3+4DEAkQ@mail.gmail.com>
References: <adLxzR3vBMuEpQsT@chil>
 <CACOMi+cNwc1po171kdYUczoNHGcjhWTJxCjbXHP=Sv3+4DEAkQ@mail.gmail.com>
Message-ID: <adOsyzDDrRXDxS_0@chil>

Hi,

Am Mo den  6. Apr 2026 um 13:12 schrieb chris at anthum.com:
> > Is there any way to start [pinentry] GUI ... with UTF-8-locale instead of
> > something else?
> 
> #!/bin/bash
> 
> echo "??????  Latin-1 Test  ??????"
> LANG=en_US.ISO8859-1 LC_ALL=en_US.ISO8859-1 pinentry --ttyname /dev/tty <<'EOF'
> SETDESC Latin-1 test: H?llo ??? w?rk? ?????????
> SETPROMPT P?ssw?rd:
> GETPIN
> BYE
> EOF
> 
> echo "??????  UTF-8 Test  ??????"
> LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 pinentry --ttyname /dev/tty <<'EOF'
> OPTION lc-ctype en_US.UTF-8
> SETTTYNAME /dev/tty
> SETTTYTYPE xterm-256color
> SETDESC UTF-8 test: H?llo ??? w?rk? ?????????
> SETPROMPT P?ssw?rd:
> GETPIN
> BYE
> EOF

They give the same result. I tried it once saving the file as latin1
where both versions are identical and the same (but different, correct
output) when I save it as utf8.

So I guess that gpg-agent needs to use different encoding.

Regards
   Klaus
-- 
Klaus Ethgen                                       http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16            Klaus Ethgen <Klaus at Ethgen.ch>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 728 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260406/0793d694/attachment.sig>

From wk at gnupg.org  Mon Apr  6 17:42:22 2026
From: wk at gnupg.org (Werner Koch)
Date: Mon, 06 Apr 2026 17:42:22 +0200
Subject: Different locale for pinentry
In-Reply-To: <adLxzR3vBMuEpQsT@chil> (Klaus Ethgen's message of "Mon, 6 Apr
 2026 00:35:41 +0100")
References: <adLxzR3vBMuEpQsT@chil>
Message-ID: <87wlykrt7l.fsf@jacob.g10code.de>

Hi!

On Mon,  6 Apr 2026 00:35, Klaus Ethgen said:

> Is there any way to start GUI stuff with UTF-8-locale instead of
> something else? Alternatively, the whole gpg-agent or any pinentry could
> be made started with UTF-8.

The static strings presented by Pinentry (like Counter:/Z?hler:) are
provided by gpg-agent.  Thus the gettext used by gpg-agent is
responsible for this.  gpg-agent however switches gettext quite early to
utf-8:

  /* gpg-agent usually does not output any messages because it runs in
     the background.  For log files it is acceptable to have messages
     always encoded in utf-8.  We switch here to utf-8, so that
     commands like --help still give native messages.  It is far
     easier to switch only once instead of for every message and it
     actually helps when more then one thread is active (avoids an
     extra copy step). */
    bind_textdomain_codeset (PACKAGE_GT, "UTF-8");

Thus pinentry sees UTF-8 and depending on the type of pinentry this
should work.  It might be that sme pinentries switch to some native
encoding depending on $TERM.

  gpg-connect-agent 'getinfo std_env_names' /bye

gives a list of envvars passed on to Pinentry and are initially set by
gpg, gpgsm etc.



Shalom-Salam,

   Werner


-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 284 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260406/2ee72e51/attachment.sig>

From klaus+gnupg at ethgen.ch  Mon Apr  6 18:17:01 2026
From: klaus+gnupg at ethgen.ch (Klaus Ethgen)
Date: Mon, 6 Apr 2026 17:17:01 +0100
Subject: Different locale for pinentry
In-Reply-To: <87wlykrt7l.fsf@jacob.g10code.de>
References: <adLxzR3vBMuEpQsT@chil>
 <87wlykrt7l.fsf@jacob.g10code.de>
Message-ID: <adPcfWpRQdBB-omB@chil>

Hi Werner,

Am Mo den  6. Apr 2026 um 16:42 schrieb Werner Koch:
> On Mon,  6 Apr 2026 00:35, Klaus Ethgen said:
> 
> > Is there any way to start GUI stuff with UTF-8-locale instead of
> > something else? Alternatively, the whole gpg-agent or any pinentry could
> > be made started with UTF-8.
> 
> The static strings presented by Pinentry (like Counter:/Z?hler:) are
> provided by gpg-agent.  Thus the gettext used by gpg-agent is
> responsible for this.  gpg-agent however switches gettext quite early to
> utf-8:
> 
>   /* gpg-agent usually does not output any messages because it runs in
>      the background.  For log files it is acceptable to have messages
>      always encoded in utf-8.  We switch here to utf-8, so that
>      commands like --help still give native messages.  It is far
>      easier to switch only once instead of for every message and it
>      actually helps when more then one thread is active (avoids an
>      extra copy step). */
>     bind_textdomain_codeset (PACKAGE_GT, "UTF-8");
> 
> Thus pinentry sees UTF-8 and depending on the type of pinentry this
> should work.

That is strange as it is definitivelly latin1 what reaches pinentry.

When did that come into the source?

I use gpg-agent on gentoo in version 2.5.17-r2 and my use flags are
alternatives, bzip2, nls, readline, smartcard, ssl, tofu and tools.

> It might be that sme pinentries switch to some native
> encoding depending on $TERM.

See my last post, Thanks to chris I checked that and pinentry does not
care about environment settings.

>   gpg-connect-agent 'getinfo std_env_names' /bye
> 
> gives a list of envvars passed on to Pinentry and are initially set by
> gpg, gpgsm etc.

```
~> gpg-connect-agent 'getinfo std_env_names' /bye
D GPG_TTY
D TERM
D DISPLAY
D XAUTHORITY
D XMODIFIERS
D WAYLAND_DISPLAY
D XDG_SESSION_TYPE
D QT_QPA_PLATFORM
D GTK_IM_MODULE
D DBUS_SESSION_BUS_ADDRESS
D QT_IM_MODULE
D INSIDE_EMACS
D PINENTRY_USER_DATA
D PINENTRY_GEOM_HINT
OK

~/.gnupg> cat gpg-agent.conf
default-cache-ttl 34560000
max-cache-ttl 34560000
log-file /home/klaus/.gnupg/gpg-agent.log
no-allow-external-cache
enable-ssh-support
ssh-fingerprint-digest SHA256
allow-preset-passphrase

grab
#debug-pinentry

# Erst ab Agent 2.1.12
enable-extended-key-format
```

I use pinentry-qt6.

So something is definitivelly wrong here.

Regards
   Klaus

Ps. Gru? aus der Schweiz.
-- 
Klaus Ethgen                                       http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16            Klaus Ethgen <Klaus at Ethgen.ch>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 728 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260406/03719f61/attachment.sig>

From klaus+gnupg at ethgen.ch  Mon Apr  6 19:32:51 2026
From: klaus+gnupg at ethgen.ch (Klaus Ethgen)
Date: Mon, 6 Apr 2026 18:32:51 +0100
Subject: Different locale for pinentry
In-Reply-To: <adPcfWpRQdBB-omB@chil>
References: <adLxzR3vBMuEpQsT@chil> <87wlykrt7l.fsf@jacob.g10code.de>
 <adPcfWpRQdBB-omB@chil>
Message-ID: <adPuQ72R2acho9tK@chil>

By the way, I checked the log file that should have utf8 strings but
there is latin1: "command 'PKDECRYPT' failed: Kein geheimer Schl?ssel"
(see the "?").

So for some reasons, that switch to utf8 is not working or reverted.

I do not know the code good enough, but I checked and found some
i18n_switchto_utf8/i18n_switchback somewhere in he gpg-agent dir.
However, that looks quite reasonable for me.

The only difference I find is that all the code uses "utf-8" but
gpg-agent uses "UTF-8". Could it be that this codeset is case sensitive?

You even have the following comment:
      { /* We only switch when we are able to restore the codeset later.
           Note that bind_textdomain_codeset does only return on memory
           errors but not if a codeset is not available.  Thus we don't
           bother printing a diagnostic here. */

So I am afraid that it is just ignoring that UTF-8. But I would not bet
for it.

Would it be possible to check after setting it if the codeset is equal?

Something like:
char *orig_codeset = bind_textdomain_codeset(PACKAGE_GT, NULL);
if (!strcmp(orig_codeset, "UTF-8"))
{
   log_info(_("WARNING: \"%s\" is not equal to UTF-8\n"), orig_codeset);
}

Regards
   Klaus
-- 
Klaus Ethgen                                       http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16            Klaus Ethgen <Klaus at Ethgen.ch>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 728 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260406/595a675f/attachment.sig>

From klaus+gnupg at ethgen.ch  Mon Apr  6 19:36:17 2026
From: klaus+gnupg at ethgen.ch (Klaus Ethgen)
Date: Mon, 6 Apr 2026 18:36:17 +0100
Subject: Different locale for pinentry
In-Reply-To: <adPcfWpRQdBB-omB@chil>
References: <adLxzR3vBMuEpQsT@chil> <87wlykrt7l.fsf@jacob.g10code.de>
 <adPcfWpRQdBB-omB@chil>
Message-ID: <adPvEbkESdAVK6eq@chil>

By the way, the only place I find "Please unlock the card" is
verify_a_chv() in scd/app-openpgp.c.

So maybe that strings comes not from gpg-agent.

Regards
   Klaus
-- 
Klaus Ethgen                                       http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16            Klaus Ethgen <Klaus at Ethgen.ch>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 728 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260406/ac810273/attachment.sig>

From rjh at sixdemonbag.org  Mon Apr  6 21:54:07 2026
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 6 Apr 2026 15:54:07 -0400
Subject: Post-quantum defaults
Message-ID: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org>

As many people on this list know, I have for a very long time been a 
skeptic on the subject of quantum computing advances. I won't go into 
details, but the bottom line is there are three pillars on which I have 
set my projections and this week it looks as if two of them are 
beginning to crack.

It is probably wise to begin deploying post-quantum cryptography. Are 
there any plans in GnuPG to make post-quantum algorithms the default for 
new certificates?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260406/913f0833/attachment-0001.sig>

From johndoe65534 at mail.com  Mon Apr  6 22:22:48 2026
From: johndoe65534 at mail.com (john doe)
Date: Mon, 6 Apr 2026 22:22:48 +0200
Subject: Post-quantum defaults
In-Reply-To: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org>
References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org>
Message-ID: <16f50eb3-d238-4bed-8b11-b5d5e7e72d25@mail.com>

On 4/6/26 9:54 PM, Robert J. Hansen via Gnupg-users wrote:
> details, but the bottom line is there are three pillars on which I have 
> set my projections and this week it looks as if two of them are 
> beginning to crack.
> 
Can you elaborate on why  you think  this is the right time to do so?

-- 
John Doe


From rjh at sixdemonbag.org  Mon Apr  6 22:40:22 2026
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 6 Apr 2026 16:40:22 -0400
Subject: Post-quantum defaults
In-Reply-To: <16f50eb3-d238-4bed-8b11-b5d5e7e72d25@mail.com>
References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org>
 <16f50eb3-d238-4bed-8b11-b5d5e7e72d25@mail.com>
Message-ID: <11f4e41f-bb07-4aae-b92e-660628273c62@sixdemonbag.org>

> Can you elaborate on why? you think? this is the right time to do so?

My three pillars are the difficulty of accumulating a large enough 
ensemble; the difficulty of quantum error correction; and the general 
inefficiency of quantum computers. These are all to some degree 
interconnected.

For instance, there's a theoretical minimum of 5n+1 qubits necessary to 
break RSA-n, but at our current level of engineering it requires orders 
of magnitude more. That's an inefficiency problem that runs into "so, 
how do you plan to get that many qubits anyway?" (large ensemble 
problem) and "how do you plan on doing error correction on that huge 
ensemble?" (error correction).

Well, there's been some news there.

 From Google [1]:

	Specifically, we have compiled two quantum circuits (a
	sequence of quantum gates) that implement Shor's algorithm
	for ECDLP-256: one that uses less than 1,200 logical
	qubits and 90 million Toffoli gates and one that uses less
	than 1,450 logical qubits and 70 million Toffoli gates. We
	estimate that these circuits can be executed on a
	superconducting qubit CRQC with fewer than 500,000
	physical qubits in a few minutes, given standard
	assumptions about hardware capabilities that are
	consistent with some of Google?s flagship quantum
	processors. This is an approximately 20-fold reduction in
	the number of physical qubits required to solve ECDLP-256
	and a continuation of a long history of gradual
	optimization in compiling quantum algorithms to fault-
	tolerant circuits.

Well. That's ? impressive. A twentyfold reduction is scary because it 
says they're on to a good method and this is just the beginning. There 
are some serious cracks showing.

But wait, 500,000 physical qubits? That's ... we can still take some 
reassurance from that, right?

Maybe.[2] Cain, Xu, King, et al., just a few days later showed that 
maybe it can be done in 10,000 physical qubits.

Serious cracks, indeed. It's not worth panicking over: I give a low 
probability these will turn into real attacks any time in the next few 
years. But I do think we'll all be using post-quantum algorithms around 
2030, and for a lot of us, the time to start making that transition is 
today.

[1] 
https://research.google/blog/safeguarding-cryptocurrency-by-disclosing-quantum-vulnerabilities-responsibly/

[2] https://arxiv.org/abs/2603.28627
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260406/2690a502/attachment.sig>

From mark.christian at intel.com  Mon Apr  6 22:33:21 2026
From: mark.christian at intel.com (Christian, Mark)
Date: Mon, 6 Apr 2026 20:33:21 +0000
Subject: Post-quantum defaults
In-Reply-To: <16f50eb3-d238-4bed-8b11-b5d5e7e72d25@mail.com>
References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org>
 <16f50eb3-d238-4bed-8b11-b5d5e7e72d25@mail.com>
Message-ID: <24341bbc1a6f31ad0aa69af1dbabfde624b36509.camel@intel.com>

On Mon, 2026-04-06 at 22:22 +0200, john doe via Gnupg-users wrote:
> On 4/6/26 9:54 PM, Robert J. Hansen via Gnupg-users wrote:
> > details, but the bottom line is there are three pillars on which I
> > have 
> > set my projections and this week it looks as if two of them are 
> > beginning to crack.
> > 
> Can you elaborate on why? you think? this is the right time to do so?

A couple recent papers on the subject:
https://arxiv.org/abs/2603.28846
https://arxiv.org/abs/2603.28627

Some reporting of those papers:
https://arstechnica.com/security/2026/03/new-quantum-computing-advances-heighten-threat-to-elliptic-curve-cryptosystems/

Mark


From bwalzer at 59.ca  Tue Apr  7 00:59:44 2026
From: bwalzer at 59.ca (Bruce Walzer)
Date: Mon, 6 Apr 2026 17:59:44 -0500
Subject: Post-quantum defaults
In-Reply-To: <16f50eb3-d238-4bed-8b11-b5d5e7e72d25@mail.com>
References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org>
 <16f50eb3-d238-4bed-8b11-b5d5e7e72d25@mail.com>
Message-ID: <adQ64GgSH0dXkFmz@watt.59.ca>

On Mon, Apr 06, 2026 at 10:22:48PM +0200, john doe via Gnupg-users wrote:
> On 4/6/26 9:54 PM, Robert J. Hansen via Gnupg-users wrote:
> > details, but the bottom line is there are three pillars on which I have
> > set my projections and this week it looks as if two of them are
> > beginning to crack.
> > 
> Can you elaborate on why  you think  this is the right time to do so?

There seem to be two papers that have sparked the recent excitement. One involves boring old superconducting qubits. AFAIK, it assumes a significant improvement in noise performance to work. So the fact that it uses less qubits isn't very interesting in the absence of increased noise performance. Impossible is still impossible.

The other one involves something called neutral atoms. This technology has better noise performance. But it is a different technology. It appears that we don't know how to run a relevant algorithm on it at this time in a useful way. The paper refers to "engineering challenges". So I think this is the one to pay attention to in the next few months. We need to wait for comments from knowledgeable critics.

Bruce


From rjh at sixdemonbag.org  Tue Apr  7 02:24:29 2026
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 6 Apr 2026 20:24:29 -0400
Subject: Post-quantum defaults
In-Reply-To: <adQ64GgSH0dXkFmz@watt.59.ca>
References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org>
 <16f50eb3-d238-4bed-8b11-b5d5e7e72d25@mail.com> <adQ64GgSH0dXkFmz@watt.59.ca>
Message-ID: <0cb9ffa6-69b3-48bc-8438-b580897bfc10@sixdemonbag.org>

> The other one involves something called neutral atoms. This
> technology has better noise performance. But it is a different
> technology. It appears that we don't know how to run a relevant
> algorithm on it at this time in a useful way. The paper refers to
> "engineering challenges". So I think this is the one to pay
> attention to in the next few months. We need to wait for comments
> from knowledgeable critics.

Yes and no.

Scott Aaronson, a widely respected quantum computational theorist, had 
this to say in December 2025:

	When Frisch and Peierls wrote their now-famous memo
	in March 1940, estimating the mass of Uranium-235
	that would be needed for a fission bomb, they didn't
	publish it in a journal, but communicated the result
	through military channels only. As recently as
	February 1939, Frisch and Meitner had published in
	_Nature_ their theoretical explanation of recent
	experiments, showing that the uranium nucleus could
	fission when bombarded by neutrons. But by 1940,
	Frisch and Peierls realized that the time for open
	publication of these matters had passed.

	Similarly, at some point, the people doing detailed
	estimates of how many physical qubits and gates
	it'll take to break actually deployed cryptosystems
	using Shor's algorithm are going to stop publishing
	those estimates, if for no other reason than the
	risk of giving too much information to adversaries.
	Indeed, for all we know, that point may have been
	passed already. This is the clearest warning that I
	can offer in public right now about the urgency of
	migrating to post-quantum cryptosystems, a process
	that I'm grateful is already underway.

For many years now my own personal, private, rule-of-thumb, educated 
guess, wild hope, semi-informed nonsense, however you want to put it, 
has been "I need to migrate to post-quantum cryptography while the risk 
of breaking RSA-2048 in the next five years feels to be under 1%."

It no longer feels like it's under 1%, and that motivates me to ask when 
GnuPG is going to migrate the standard keypair to PQC.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260406/437b073b/attachment.sig>

From jcb62281 at gmail.com  Tue Apr  7 04:25:02 2026
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Mon, 6 Apr 2026 21:25:02 -0500
Subject: Post-quantum defaults
In-Reply-To: <11f4e41f-bb07-4aae-b92e-660628273c62@sixdemonbag.org>
References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org>
 <16f50eb3-d238-4bed-8b11-b5d5e7e72d25@mail.com>
 <11f4e41f-bb07-4aae-b92e-660628273c62@sixdemonbag.org>
Message-ID: <3fe7c5d5-1e4b-4a80-9b46-42862b43ba5c@gmail.com>

On 4/6/26 15:40, Robert J. Hansen via Gnupg-users wrote:
>> Can you elaborate on why? you think? this is the right time to do so?
>
> My three pillars are the difficulty of accumulating a large enough 
> ensemble; the difficulty of quantum error correction; and the general 
> inefficiency of quantum computers. These are all to some degree 
> interconnected.
>
> For instance, there's a theoretical minimum of 5n+1 qubits necessary 
> to break RSA-n, but at our current level of engineering it requires 
> orders of magnitude more. That's an inefficiency problem that runs 
> into "so, how do you plan to get that many qubits anyway?" (large 
> ensemble problem) and "how do you plan on doing error correction on 
> that huge ensemble?" (error correction).
>
> Well, there's been some news there.
>
> [...]
>
> Maybe.[2] Cain, Xu, King, et al., just a few days later showed that 
> maybe it can be done in 10,000 physical qubits.
>
> Serious cracks, indeed. [...]

The issue I see here is that these seem to be specialized for elliptic 
curve cryptosystems.? In other words, the "free lunch" of shorter keys 
and better performance by using the more-complicated mathematics of 
elliptic curves instead of the general integers is going away.

This is almost *exactly* what I expected and is the concern that I have 
long had with EC cryptosystems:? the shorter ECC keys will fall to 
quantum computing long before the longer RSA keys will.

The theoretical minimum you cite means that 10241 qubits are required to 
break RSA-2048 and 20481 qubits are required to break RSA-4096, for 
example; while resistance to conventional factoring scales 
logarithmically with key length, simply doubling the RSA key length 
doubles the number of qubits needed to attack the key---and this 
relationship is linear /ad infinitum/, while the difficulty of building 
larger ensembles increases exponentially in qubit count.

Further, as you mention, those are the ultimate logical qubits required 
to run Shor's algorithm; actual implementations will require many 
physical qubits to support each of those logical qubits.

Assuming that Shor's algorithm "sees through" the mathematical 
complexity of elliptic curves (i.e. the cost of using Shor's algorithm 
is the same for ECDLP-256 and RSA-256), those 10000 physical qubits 
represent about 39n to break RSA-n.? This is 79872 qubits to break RSA-2048.

Lastly, Bruce Walzer's reply notes that both of these appear to be 
hypothetical and the "10000 qubits to crack ECDLP-256" uses a technology 
that has yet to actually work, while Google's paper apparently assumes a 
significant noise reduction that is also yet to be proven.


-- Jacob



From rjh at sixdemonbag.org  Tue Apr  7 05:47:08 2026
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 6 Apr 2026 23:47:08 -0400
Subject: Post-quantum defaults
In-Reply-To: <3fe7c5d5-1e4b-4a80-9b46-42862b43ba5c@gmail.com>
References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org>
 <16f50eb3-d238-4bed-8b11-b5d5e7e72d25@mail.com>
 <11f4e41f-bb07-4aae-b92e-660628273c62@sixdemonbag.org>
 <3fe7c5d5-1e4b-4a80-9b46-42862b43ba5c@gmail.com>
Message-ID: <725e631f-64bb-4db7-9454-37bad15dc265@sixdemonbag.org>

> The issue I see here is that these seem to be specialized for elliptic 
> curve cryptosystems.? In other words, the "free lunch" of shorter keys 
> and better performance by using the more-complicated mathematics of 
> elliptic curves instead of the general integers is going away.

Yes. But attacks only get better over time: they don't get worse. If the 
current defaults of ECC keypairs are at threat, and our original 
projection for RSA-2048 was it would be safe only until 2030 or so (see 
the GnuPG FAQ, section 11.2), then the solution is not to go back to 
RSA-2048 but to find something with long-term prospects. That would seem 
to be Kyber, not RSA-4096.

> This is almost *exactly* what I expected and is the concern that I have 
> long had with EC cryptosystems:? the shorter ECC keys will fall to 
> quantum computing long before the longer RSA keys will.

Perhaps.

I have to say it all feels so very intensely surreal. As an undergrad in 
1993 I read every crypto paper I could get my hands on, and back then 
the tantalizing hot new thing in crypto was elliptical curves. They were 
conjectured to be strong but they relied on the unproven 
Taniyama-Shimura conjecture, which everyone thought was true but nobody 
knew how to solve.

Then around 1995, Andrew Wiles proved Taniyama-Shimura (and, in the 
course of doing so, Fermat's last theorem). ECC was now on 
mathematically rigorous ground. It was a time of great upheaval and 
everyone was eager to get on the ECC bandwagon and ...

Yow. Heady times. Seriously, you have no idea how big of a thing it was 
unless you were there.

Now, thirty years later and approaching the end of my career, I'm seeing 
the end of ECC. The last time I mentioned Taniyama-Shimura, the younger 
cryptologists I was conversing with looked at each other confused until 
another graybeard explained "it's what we used to call what they now 
call the 'modularity theorem'."

I felt like an idiot. Of course nobody calls it Taniyama-Shimura any 
more. It's no longer a conjecture, after all.

Sigh. Sic transit gloria mundi?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260406/cc505667/attachment.sig>

From jcb62281 at gmail.com  Tue Apr  7 06:36:20 2026
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Mon, 6 Apr 2026 23:36:20 -0500
Subject: Post-quantum defaults
In-Reply-To: <725e631f-64bb-4db7-9454-37bad15dc265@sixdemonbag.org>
References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org>
 <16f50eb3-d238-4bed-8b11-b5d5e7e72d25@mail.com>
 <11f4e41f-bb07-4aae-b92e-660628273c62@sixdemonbag.org>
 <3fe7c5d5-1e4b-4a80-9b46-42862b43ba5c@gmail.com>
 <725e631f-64bb-4db7-9454-37bad15dc265@sixdemonbag.org>
Message-ID: <0b7d2249-0602-40e8-8f64-c8e4136118d4@gmail.com>

On 4/6/26 22:47, Robert J. Hansen wrote:
>> The issue I see here is that these seem to be specialized for 
>> elliptic curve cryptosystems.? In other words, the "free lunch" of 
>> shorter keys and better performance by using the more-complicated 
>> mathematics of elliptic curves instead of the general integers is 
>> going away.
>
> Yes. But attacks only get better over time: they don't get worse.

Yes.? But there are hard physical requirements (like needing enough 
qubits to store the key) that will always be higher for any practical 
RSA than for EC cryptosystems.? (RSA-256 falls easily to conventional 
factoring, while 256-bit ECC keys are common.)

> If the current defaults of ECC keypairs are at threat, and our 
> original projection for RSA-2048 was it would be safe only until 2030 
> or so (see the GnuPG FAQ, section 11.2), then the solution is not to 
> go back to RSA-2048 but to find something with long-term prospects. 
> That would seem to be Kyber, not RSA-4096.

That calculation seems to be based on the projected advance of 
conventional computing.? Quantum computing is different and will break 
ECC keypairs long before it can touch even RSA-1024 or RSA-768 (which 
are already now considered broken by conventional means).

That FAQ also claims that 256-bit ECC is equivalent to RSA-16384.? 
Perhaps we should actually add RSA-16384 (which requires at minimum 
81921 qubits to crack) and take the advances in conventional computing 
as the enabling factor for such (ludicrously) large keys.

(On a side note, how many bits are needed for a Kyber keypair?)

>> This is almost *exactly* what I expected and is the concern that I 
>> have long had with EC cryptosystems: the shorter ECC keys will fall 
>> to quantum computing long before the longer RSA keys will.
>
> Perhaps.

There is no "perhaps" here:? Shor's algorithm apparently solves ECDLP 
with the same difficulty as it solves RSA.? The hard part is getting 
enough qubits to perform the operation for a given key size to actually 
work at once.

That is an engineering problem that will progress from smaller ensembles 
to larger ensembles, possibly hitting a wall along the way, possibly 
not.? Either way, it is certain that quantum computing ensembles 
sufficient for cracking 256-bit keys will exist before larger ensembles 
that can crack 2048-bit keys will.

More entertainingly, we will likely find out that someone has such an 
ensemble when Bitcoins start "disappearing" from wallets...


-- Jacob



From bbenedictg at verizon.net  Tue Apr  7 12:20:20 2026
From: bbenedictg at verizon.net (bbenedictg at verizon.net)
Date: Tue, 7 Apr 2026 10:20:20 +0000 (UTC)
Subject: Post-quantum defaults
In-Reply-To: <adQ64GgSH0dXkFmz@watt.59.ca>
References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org>
 <16f50eb3-d238-4bed-8b11-b5d5e7e72d25@mail.com> <adQ64GgSH0dXkFmz@watt.59.ca>
Message-ID: <1995704755.1252160.1775557220909@mail.yahoo.com>

Please take me off this thread. I do not know why I am on it?


Sent from the all new AOL app for iOS


On Monday, April 6, 2026, 7:00 PM, Bruce Walzer via Gnupg-users <gnupg-users at gnupg.org> wrote:

On Mon, Apr 06, 2026 at 10:22:48PM +0200, john doe via Gnupg-users wrote:
> On 4/6/26 9:54 PM, Robert J. Hansen via Gnupg-users wrote:
> > details, but the bottom line is there are three pillars on which I have
> > set my projections and this week it looks as if two of them are
> > beginning to crack.
> > 
> Can you elaborate on why? you think? this is the right time to do so?

There seem to be two papers that have sparked the recent excitement. One involves boring old superconducting qubits. AFAIK, it assumes a significant improvement in noise performance to work. So the fact that it uses less qubits isn't very interesting in the absence of increased noise performance. Impossible is still impossible.

The other one involves something called neutral atoms. This technology has better noise performance. But it is a different technology. It appears that we don't know how to run a relevant algorithm on it at this time in a useful way. The paper refers to "engineering challenges". So I think this is the one to pay attention to in the next few months. We need to wait for comments from knowledgeable critics.

Bruce

_______________________________________________
Gnupg-users mailing list
Gnupg-users at gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260407/b2f1adcd/attachment-0001.html>

From bbenedictg at verizon.net  Tue Apr  7 12:24:02 2026
From: bbenedictg at verizon.net (bbenedictg at verizon.net)
Date: Tue, 7 Apr 2026 10:24:02 +0000 (UTC)
Subject: Different locale for pinentry
In-Reply-To: <adPcfWpRQdBB-omB@chil>
References: <adLxzR3vBMuEpQsT@chil> <87wlykrt7l.fsf@jacob.g10code.de>
 <adPcfWpRQdBB-omB@chil>
Message-ID: <1582524810.1248376.1775557442802@mail.yahoo.com>

Please remove me from this thread


Sent from the all new AOL app for iOS


On Monday, April 6, 2026, 12:17 PM, Klaus Ethgen <klaus+gnupg at ethgen.ch> wrote:

Hi Werner,

Am Mo den? 6. Apr 2026 um 16:42 schrieb Werner Koch:
> On Mon,? 6 Apr 2026 00:35, Klaus Ethgen said:
> 
> > Is there any way to start GUI stuff with UTF-8-locale instead of
> > something else? Alternatively, the whole gpg-agent or any pinentry could
> > be made started with UTF-8.
> 
> The static strings presented by Pinentry (like Counter:/Z?hler:) are
> provided by gpg-agent.? Thus the gettext used by gpg-agent is
> responsible for this.? gpg-agent however switches gettext quite early to
> utf-8:
> 
>? /* gpg-agent usually does not output any messages because it runs in
>? ? ? the background.? For log files it is acceptable to have messages
>? ? ? always encoded in utf-8.? We switch here to utf-8, so that
>? ? ? commands like --help still give native messages.? It is far
>? ? ? easier to switch only once instead of for every message and it
>? ? ? actually helps when more then one thread is active (avoids an
>? ? ? extra copy step). */
>? ? bind_textdomain_codeset (PACKAGE_GT, "UTF-8");
> 
> Thus pinentry sees UTF-8 and depending on the type of pinentry this
> should work.

That is strange as it is definitivelly latin1 what reaches pinentry.

When did that come into the source?

I use gpg-agent on gentoo in version 2.5.17-r2 and my use flags are
alternatives, bzip2, nls, readline, smartcard, ssl, tofu and tools.

> It might be that sme pinentries switch to some native
> encoding depending on $TERM.

See my last post, Thanks to chris I checked that and pinentry does not
care about environment settings.

>? gpg-connect-agent 'getinfo std_env_names' /bye
> 
> gives a list of envvars passed on to Pinentry and are initially set by
> gpg, gpgsm etc.

```
~> gpg-connect-agent 'getinfo std_env_names' /bye
D GPG_TTY
D TERM
D DISPLAY
D XAUTHORITY
D XMODIFIERS
D WAYLAND_DISPLAY
D XDG_SESSION_TYPE
D QT_QPA_PLATFORM
D GTK_IM_MODULE
D DBUS_SESSION_BUS_ADDRESS
D QT_IM_MODULE
D INSIDE_EMACS
D PINENTRY_USER_DATA
D PINENTRY_GEOM_HINT
OK

~/.gnupg> cat gpg-agent.conf
default-cache-ttl 34560000
max-cache-ttl 34560000
log-file /home/klaus/.gnupg/gpg-agent.log
no-allow-external-cache
enable-ssh-support
ssh-fingerprint-digest SHA256
allow-preset-passphrase

grab
#debug-pinentry

# Erst ab Agent 2.1.12
enable-extended-key-format
```

I use pinentry-qt6.

So something is definitivelly wrong here.

Regards
? Klaus

Ps. Gru? aus der Schweiz.
-- 
Klaus Ethgen? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? http://www.ethgen.ch/
pub? 4096R/4E20AF1C 2011-05-16? ? ? ? ? ? Klaus Ethgen <Klaus at Ethgen.ch>
Fingerprint: 85D4 CA42 952C 949B 1753? 62B3 79D0 B06F 4E20 AF1C
_______________________________________________
Gnupg-users mailing list
Gnupg-users at gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260407/048c405a/attachment.html>

From wk at gnupg.org  Tue Apr  7 16:35:24 2026
From: wk at gnupg.org (Werner Koch)
Date: Tue, 07 Apr 2026 16:35:24 +0200
Subject: Post-quantum defaults
In-Reply-To: <1995704755.1252160.1775557220909@mail.yahoo.com> (bbenedictg's
 message of "Tue, 7 Apr 2026 10:20:20 +0000 (UTC)")
References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org>
 <16f50eb3-d238-4bed-8b11-b5d5e7e72d25@mail.com>
 <adQ64GgSH0dXkFmz@watt.59.ca>
 <1995704755.1252160.1775557220909@mail.yahoo.com>
Message-ID: <87ldeysus3.fsf@jacob.g10code.de>

On Tue,  7 Apr 2026 10:20, bbenedictg--- said:
> Please take me off this thread. I do not know why I am on it?

Becuase you subscribed to this list.  I temporary disabled mail delivery
but you should go to 
https://lists.gnupg.org/mailman/options/gnupg-users/bbenedictg at verizon.net
and unsubscribe.


Salam-Shalom,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 284 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260407/5e90ac3c/attachment.sig>

From jb-gnumlists at wisemo.com  Tue Apr  7 18:34:56 2026
From: jb-gnumlists at wisemo.com (Jakob Bohm)
Date: Tue, 7 Apr 2026 18:34:56 +0200
Subject: Post-quantum defaults
In-Reply-To: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org>
References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org>
Message-ID: <3650e64a-b30c-6c66-97f4-25883152985e@wisemo.com>

Dear GPG/PGP designers.

Note that besides the highly advanced post-quantum algorithms promoted in
recent years, there is also Merkle's hash tree signing algorithm, which
uses solid security arguments from the properties of good hash algorithms.
Two variants of this have been published as RFCs differing mostly in
padding details.

While this is purely a signature algorithm and each signature is several
kilobytes big (hashbits**2 / w / 8 plus the extra hash values for carry
bits, plus the ?? hashbits * log2(sigcount) / 8 path to the tree root),
the public key is just a single hash value and the private key is either
a large one-time-pad or a symmetric key for a strong enough stream
cipher.? Given the theory that quantum attacks halve the strength of
hash functions and other symmetric algorithms, and the theory that hash
algorithms have the equivalent symmetric strength of hashbits / 2,
Merkle-tree algorithms should be hash algorithm agile and use a hash
algorithm with hashbits >= 4 * desired-strength.? Thus 128-bit
equivalent strength would need a 512 bit hash algorithm and a 256 bit
stream cipher; Double for 256-bit strength.

For example an addition to OpenPGP can reference one of the 2 RFCs,
specify w=8 and make the hash algorithm a separate part of the algorithm
indication in public keys, while a corresponding GPG implementation can
then be parameterized by a reference to the entire list of implemented
hash algorithms >= 256 bits (to verify all spec-compliant signatures)
while using one or two very strong stream ciphers for the private key
storage format (making stream and hash algs user choices during key
generation).? Tree height would be dictated by a need to leave one
signing invocation available to sign a new public key, one to sign
self revocation and a few others for similar tasks, then at least 1
usable signing invocation for signing an actual mail or software
release.

On 06/04/2026 21:54, Robert J. Hansen via Gnupg-users wrote:
> As many people on this list know, I have for a very long time been a 
> skeptic on the subject of quantum computing advances. I won't go into 
> details, but the bottom line is there are three pillars on which I 
> have set my projections and this week it looks as if two of them are 
> beginning to crack.
>
> It is probably wise to begin deploying post-quantum cryptography. Are 
> there any plans in GnuPG to make post-quantum algorithms the default 
> for new certificates?
>
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260407/2ec43a16/attachment.html>

From gnupg-users at city17.xyz  Wed Apr  8 12:52:47 2026
From: gnupg-users at city17.xyz (jman)
Date: Wed, 08 Apr 2026 12:52:47 +0200
Subject: Post-quantum defaults
In-Reply-To: <16f50eb3-d238-4bed-8b11-b5d5e7e72d25@mail.com> (john doe via
 Gnupg-users's message of "Mon, 6 Apr 2026 22:22:48 +0200")
References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org>
 <16f50eb3-d238-4bed-8b11-b5d5e7e72d25@mail.com>
Message-ID: <87a4vdk9kw.fsf@nyarlathotep>

john doe via Gnupg-users <gnupg-users at gnupg.org> writes:

> On 4/6/26 9:54 PM, Robert J. Hansen via Gnupg-users wrote:
>> details, but the bottom line is there are three pillars on which I
>> have set my projections and this week it looks as if two of them are
>> beginning to crack.
>> 
> Can you elaborate on why  you think  this is the right time to do so?

I think this article from Valsorda is also getting some attention:

https://words.filippo.io/crqc-timeline/


From wk at gnupg.org  Wed Apr  8 15:21:17 2026
From: wk at gnupg.org (Werner Koch)
Date: Wed, 08 Apr 2026 15:21:17 +0200
Subject: Post-quantum defaults
In-Reply-To: <87a4vdk9kw.fsf@nyarlathotep> (jman via Gnupg-users's message of
 "Wed, 08 Apr 2026 12:52:47 +0200")
References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org>
 <16f50eb3-d238-4bed-8b11-b5d5e7e72d25@mail.com>
 <87a4vdk9kw.fsf@nyarlathotep>
Message-ID: <877bqhsi42.fsf@jacob.g10code.de>

On Wed,  8 Apr 2026 12:52, jman said:

> I think this article from Valsorda is also getting some attention:

I think this article recently posted at Cryptography should get more
attention:

https://www.metzdowd.com/pipermail/cryptography/2026-March/039449.html


Shalom-Salam,

   Werner


-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 284 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260408/27931895/attachment-0001.sig>

From andrewg at andrewg.com  Wed Apr  8 15:33:09 2026
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 8 Apr 2026 14:33:09 +0100
Subject: Post-quantum defaults
In-Reply-To: <3650e64a-b30c-6c66-97f4-25883152985e@wisemo.com>
References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org>
 <3650e64a-b30c-6c66-97f4-25883152985e@wisemo.com>
Message-ID: <a3df81ba-02da-493d-9265-e99a889408a5@andrewg.com>

On 07/04/2026 17:34, Jakob Bohm via Gnupg-users wrote:
> Note that besides the highly advanced post-quantum algorithms promoted in
> recent years, there is also Merkle's hash tree signing algorithm, which
> uses solid security arguments from the properties of good hash algorithms.
> Two variants of this have been published as RFCs differing mostly in
> padding details.

There are two draft RFCs that have done all the spec work required for 
PQC signatures in OpenPGP, using commonly-supported and 
commonly-approved (by BSI, NSA and others) algorithms. They've been in 
progress for over three years; the one using curve25519/448[1] has 
production-ready implementations right now, and the one using 
nistp/brainpool curves[2] is wire-format stable aside from the final 
code points. We should be getting on with implementing these before 
examining novel alternatives.

A

[1] https://www.rfc-editor.org/current_queue.php#draft-ietf-openpgp-pqc
     https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-pqc
[2] https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-nist-bp-comp-03


From andrewg at andrewg.com  Wed Apr  8 15:40:37 2026
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 8 Apr 2026 14:40:37 +0100
Subject: Post-quantum defaults
In-Reply-To: <a3df81ba-02da-493d-9265-e99a889408a5@andrewg.com>
References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org>
 <3650e64a-b30c-6c66-97f4-25883152985e@wisemo.com>
 <a3df81ba-02da-493d-9265-e99a889408a5@andrewg.com>
Message-ID: <2ba997af-bb4f-498f-b9ef-2d1fca253a21@andrewg.com>

On 08/04/2026 14:33, Andrew Gallagher via Gnupg-users wrote:
> by BSI, NSA and others

Argh, I meant NIST of course. :-D

From andrewg at andrewg.com  Wed Apr  8 15:48:00 2026
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 8 Apr 2026 14:48:00 +0100
Subject: Post-quantum defaults
In-Reply-To: <877bqhsi42.fsf@jacob.g10code.de>
References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org>
 <16f50eb3-d238-4bed-8b11-b5d5e7e72d25@mail.com> <87a4vdk9kw.fsf@nyarlathotep>
 <877bqhsi42.fsf@jacob.g10code.de>
Message-ID: <29c3497d-5302-46ca-8897-974034c548fb@andrewg.com>

On 08/04/2026 14:21, Werner Koch via Gnupg-users wrote:
> On Wed,  8 Apr 2026 12:52, jman said:
> 
>> I think this article from Valsorda is also getting some attention:
> 
> I think this article recently posted at Cryptography should get more
> attention:
> 
> https://www.metzdowd.com/pipermail/cryptography/2026-March/039449.html
Sure, the NSA can't be trusted... but in the particular case of ML-KEM 
it seems there's nowhere for them to hide:

https://keymaterial.net/2025/11/27/ml-kem-mythbusting/

There are concerns about the real strength of the smallest ML-KEM keys, 
but the PGP PQC drafts do not permit them, only the two larger key 
sizes. They also only permit them in hybrid PQ/T mode, so if you think 
ECC is still secure, the only thing you've lost is some processor 
cycles. Not great, but not the end of the world either.

tl;dr: nothing to see here.

A


From rjh at sixdemonbag.org  Wed Apr  8 17:05:12 2026
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Wed, 8 Apr 2026 11:05:12 -0400
Subject: Post-quantum defaults
In-Reply-To: <877bqhsi42.fsf@jacob.g10code.de>
References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org>
 <16f50eb3-d238-4bed-8b11-b5d5e7e72d25@mail.com> <87a4vdk9kw.fsf@nyarlathotep>
 <877bqhsi42.fsf@jacob.g10code.de>
Message-ID: <f4b6d24f-1b1e-49ce-94f8-8888047dafdd@sixdemonbag.org>

> I think this article recently posted at Cryptography should get more
> attention:

I don't think Ray is a crackpot, let me start with that. His concern is 
real. If I were in his shoes I'd think the same.

But I'm not.

A little-known fact about the National Security Agency is it's also 
responsible for establishing the US Government's computer security 
policies. When it comes to securing classified information at the Top 
Secret level, NSA has established that government agencies must migrate 
to PQC effective immediately, and they're not especially picky about 
which PQC. The official guidance is worth reading:

https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF

My take is that if RSA-2048 is about to be decertified by the USG for 
securing Top Secret data, in favor of Crystals-Kyber and/or 
Crystals-Dilithium, we should take that as a strong hint NSA genuinely 
believes RSA-2048 may soon be threatened by foreign nation-states.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260408/935cfddb/attachment.sig>

From klaus+gnupg at ethgen.ch  Thu Apr  9 18:14:59 2026
From: klaus+gnupg at ethgen.ch (Klaus Ethgen)
Date: Thu, 9 Apr 2026 17:14:59 +0100
Subject: PKA support
Message-ID: <adfQg8IG6HIf4Nkx@chil>

Hi,

I just realized, as I was searching for Werner's current key, that PKA
was removed from GnuPG in 2021.

Until now that was my preferred way to spread my key.

What was the reason for that?

The problem with WKD is that it relies on https and I refuse to use that
broken CA based system that forces me to renew my certs every month or
even more often. The only halfway trustable CA is Cacert. But it is
nowhere installed anymore.

So PKA was the only alternative to WKD...

Regards
   Klaus
-- 
Klaus Ethgen                                       http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16            Klaus Ethgen <Klaus at Ethgen.ch>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 728 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260409/f8723435/attachment.sig>

From johndoe65534 at mail.com  Thu Apr  9 19:29:40 2026
From: johndoe65534 at mail.com (john doe)
Date: Thu, 9 Apr 2026 19:29:40 +0200
Subject: PKA support
In-Reply-To: <adfQg8IG6HIf4Nkx@chil>
References: <adfQg8IG6HIf4Nkx@chil>
Message-ID: <ac1d6e14-0927-49be-b7f2-c099a3b4f6a7@mail.com>

On 4/9/26 6:14 PM, Klaus Ethgen wrote:
> Hi,
> 
> I just realized, as I was searching for Werner's current key, that PKA
> was removed from GnuPG in 2021.
> 
> Until now that was my preferred way to spread my key.
> 
> What was the reason for that?
> 
> The problem with WKD is that it relies on https and I refuse to use that
> broken CA based system that forces me to renew my certs every month or
> even more often. 

Unless I'm missing something, Letsencrypt is every three months..

-- 
John Doe


From me at chandlerdavis.cc  Thu Apr  9 19:07:17 2026
From: me at chandlerdavis.cc (Chandler Davis)
Date: Thu, 09 Apr 2026 13:07:17 -0400
Subject: PKA support
In-Reply-To: <adfQg8IG6HIf4Nkx@chil>
References: <adfQg8IG6HIf4Nkx@chil>
Message-ID: <c0cca4bf-85a6-467b-84d0-c1d972fbeba1@app.fastmail.com>

Sorry to go off topic, and that I don?t have an answer to the
question, but am curious about:

> broken CA based system

What about it is broken? I understand it has its flaws but
haven?t come across a particularly strong distaste for it
before.

> forces me to renew my certs every month or even more often.

Probably quite annoying if you?re not using ACME, but? why not
use ACME?

Best,
Chandler


From klaus+gnupg at ethgen.ch  Thu Apr  9 21:27:51 2026
From: klaus+gnupg at ethgen.ch (Klaus Ethgen)
Date: Thu, 9 Apr 2026 20:27:51 +0100
Subject: PKA support
In-Reply-To: <c0cca4bf-85a6-467b-84d0-c1d972fbeba1@app.fastmail.com>
References: <adfQg8IG6HIf4Nkx@chil>
 <c0cca4bf-85a6-467b-84d0-c1d972fbeba1@app.fastmail.com>
Message-ID: <adf9t2CACWWQ807O@chil>

Hi,

it will really get out of topic, however, lets summarize it a bit.

Am Do den  9. Apr 2026 um 18:07 schrieb Chandler Davis:
> Sorry to go off topic, and that I don???t have an answer to the
> question, but am curious about:
> 
> > broken CA based system
> 
> What about it is broken? I understand it has its flaws but
> haven???t come across a particularly strong distaste for it
> before.

- The system relies on the weakest point in all CA's. And there are
  really weak in the usual browsers/systems. (Why would you trust any of
  them?)
- The only solution would be DNSSEC + TLSA but even such browsers as
  firefox broke solutions at best and all are working against it as it
  would make all business models of CA's obsolete.
- All "solutions" to fix the issue makes it even worse like CAA or other
  "solutions" from Google.
- Making SSL invisible by allowing transparent to encrypt stuff (As TLS
  is doing but that therm is made weak as it is used for SSL to today).
  This is no problem of the system itself but play in that game. I don't
  want a SSL encrypted connection unable to talk plain text.

> > forces me to renew my certs every month or even more often.
> 
> Probably quite annoying if you???re not using ACME, but??? why not
> use ACME?

Well, I will never allow some crappy cloud service to change my
configuration all the time. I want to have control over it.

5 years for a new cert is good. 2 years are ok(ish) and 1 year is
already a pain but shorter is not bearable!

Regards
   Klaus
-- 
Klaus Ethgen                                       http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16            Klaus Ethgen <Klaus at Ethgen.ch>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 728 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260409/3791ba56/attachment.sig>

From klaus+gnupg at ethgen.ch  Thu Apr  9 21:34:17 2026
From: klaus+gnupg at ethgen.ch (Klaus Ethgen)
Date: Thu, 9 Apr 2026 20:34:17 +0100
Subject: PKA support
In-Reply-To: <adf9t2CACWWQ807O@chil>
References: <adfQg8IG6HIf4Nkx@chil>
 <c0cca4bf-85a6-467b-84d0-c1d972fbeba1@app.fastmail.com>
 <adf9t2CACWWQ807O@chil>
Message-ID: <adf_OWJY8kkbzqD-@chil>

Some typos...

Am Do den  9. Apr 2026 um 20:27 schrieb Klaus Ethgen:
> - Making SSL invisible by allowing transparent to encrypt stuff (As TLS
>   is doing but that therm is made weak as it is used for SSL to today).
... term ...
... too today

>   This is no problem of the system itself but play in that game. I don't
>   want a SSL encrypted connection unable to talk plain text.

wrong double negating. :-)

Regards
   Klaus
-- 
Klaus Ethgen                                       http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16            Klaus Ethgen <Klaus at Ethgen.ch>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 728 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260409/42f101d9/attachment-0001.sig>

From sam at gentoo.org  Thu Apr  9 20:22:11 2026
From: sam at gentoo.org (Sam James)
Date: Thu, 09 Apr 2026 19:22:11 +0100
Subject: PKA support
In-Reply-To: <ac1d6e14-0927-49be-b7f2-c099a3b4f6a7@mail.com>
References: <adfQg8IG6HIf4Nkx@chil>
 <ac1d6e14-0927-49be-b7f2-c099a3b4f6a7@mail.com>
Message-ID: <877bqgxacs.fsf@gentoo.org>

john doe via Gnupg-users <gnupg-users at gnupg.org> writes:

> On 4/9/26 6:14 PM, Klaus Ethgen wrote:
>> Hi,
>> I just realized, as I was searching for Werner's current key, that
>> PKA
>> was removed from GnuPG in 2021.
>> Until now that was my preferred way to spread my key.
>> What was the reason for that?
>> The problem with WKD is that it relies on https and I refuse to use
>> that
>> broken CA based system that forces me to renew my certs every month or
>> even more often. 
>
> Unless I'm missing something, Letsencrypt is every three months..

https://letsencrypt.org/2025/12/02/from-90-to-45
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 418 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260409/73996487/attachment.sig>

From dgouttegattat at incenp.org  Thu Apr  9 22:01:16 2026
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Thu, 09 Apr 2026 21:01:16 +0100
Subject: PKA support
In-Reply-To: <adfQg8IG6HIf4Nkx@chil>
References: <adfQg8IG6HIf4Nkx@chil>
Message-ID: <DHOW42A00YGB.KST6YJAQIGN5@incenp.org>

On Thu Apr 9, 2026 at 5:14 PM BST, Klaus Ethgen wrote:
> I just realized, as I was searching for Werner's current key, that PKA
> was removed from GnuPG in 2021.
>
> Until now that was my preferred way to spread my key.
>
> What was the reason for that?

As far as I know, PKA has always been a GnuPG-specific method. Now we
actually have a standardized way of doing the same thing: DANE, as
specified in RFC 7929 [1] -- which GnuPG has supported since the early
2.1 branch.

Use `gpg --export-options export-dane --export MY_KEY` to get GnuPG to
print a suitable DANE OPENPGPKEY record for your key, that you can then
publish to your DNS zone.

Use `gpg --auto-key-locate dane --locate-key RECIPIENT_ADDRESS` to fetch
a key that is being distributed through DANE.

- Damien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 265 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260409/934c0b92/attachment.sig>

From jb-gnumlists at wisemo.com  Thu Apr  9 22:53:45 2026
From: jb-gnumlists at wisemo.com (Jakob Bohm)
Date: Thu, 9 Apr 2026 22:53:45 +0200
Subject: Post-quantum defaults
In-Reply-To: <a3df81ba-02da-493d-9265-e99a889408a5@andrewg.com>
References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org>
 <3650e64a-b30c-6c66-97f4-25883152985e@wisemo.com>
 <a3df81ba-02da-493d-9265-e99a889408a5@andrewg.com>
Message-ID: <3be60ded-7d9c-ba3c-e2ff-b1ed152a123e@wisemo.com>

On 08/04/2026 15:33, Andrew Gallagher via Gnupg-users wrote:
> On 07/04/2026 17:34, Jakob Bohm via Gnupg-users wrote:
>> Note that besides the highly advanced post-quantum algorithms 
>> promoted in
>> recent years, there is also Merkle's hash tree signing algorithm, which
>> uses solid security arguments from the properties of good hash 
>> algorithms.
>> Two variants of this have been published as RFCs differing mostly in
>> padding details.
>
> There are two draft RFCs that have done all the spec work required for 
> PQC signatures in OpenPGP, using commonly-supported and 
> commonly-approved (by BSI, NSA and others) algorithms. They've been in 
> progress for over three years; the one using curve25519/448[1] has 
> production-ready implementations right now, and the one using 
> nistp/brainpool curves[2] is wire-format stable aside from the final 
> code points. We should be getting on with implementing these before 
> examining novel alternatives.
>

The algorithm I suggested has 9 PUBLISHED RFCs, not just drafts, which
simply omit descriptionsof how to integrate them in PGP. It is not at
all novel, being originally proposed in 1979.? The security properties
it relies on are basic: 1. The hash algorithm cannot be reversed with
available attack resources.? 2. Different inputs create wildly
different outputs.? 0a. It doesn't even require the hash algorithm to
be a good key generator for things like password hashing.? 0b. It
doesn't require the hash to be fully collision-resistant .

http://www.merkle.com/papers/Thesis1979.pdf: Original specification
U.S. Patent 5,432,852: Expired patent on the HSS/LMS variant
RFC8391: The complex formatting named XMSS
RFC8554: The simplified formatting named HSS/LMS
RFC8708: PKCS.7 Integration for the HSS/LMS format (obsoleted by RFC9708)
RFC8778: CBOR-COSE integration for the HSS/LMS format
RFC9708: PKCS.7 Integration for the HSS/LMS format
RFC9802: X.509 integration for both formats
RFC9814: PKCS.7 Integration for the HSS/LMS format
RFC9858: Additional standard parameter sets for the HSS/LMS format
RFC9909: X.509 Integration for the HSS/LMS format

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded



From andrewg at andrewg.com  Fri Apr 10 02:24:57 2026
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Fri, 10 Apr 2026 01:24:57 +0100
Subject: Post-quantum defaults
In-Reply-To: <3be60ded-7d9c-ba3c-e2ff-b1ed152a123e@wisemo.com>
References: <3be60ded-7d9c-ba3c-e2ff-b1ed152a123e@wisemo.com>
Message-ID: <483B09E7-2A1B-499A-865A-F7029F1F730B@andrewg.com>

On 9 Apr 2026, at 21:54, Jakob Bohm via Gnupg-users <gnupg-users at gnupg.org> wrote:
> 
> The algorithm I suggested has 9 PUBLISHED RFCs, not just drafts, which
> simply omit descriptionsof how to integrate them in PGP.

The openpgp pqc draft does not specify algorithms, it references algorithms with published specs (ml-kem, ml-dsa and slh-dsa) and adds the critical ?descriptions of how to integrate them in pgp?, including hybrid constructions where appropriate. It has multiple implementations fully interop tested and available as public betas. Other algorithms can be added in the future, but the current draft spec is ready to go *now*.

A

From wk at gnupg.org  Fri Apr 10 09:28:29 2026
From: wk at gnupg.org (Werner Koch)
Date: Fri, 10 Apr 2026 09:28:29 +0200
Subject: PKA support
In-Reply-To: <adfQg8IG6HIf4Nkx@chil> (Klaus Ethgen's message of "Thu, 9 Apr
 2026 17:14:59 +0100")
References: <adfQg8IG6HIf4Nkx@chil>
Message-ID: <87ecknnujm.fsf@jacob.g10code.de>

Hi!

> I just realized, as I was searching for Werner's current key, that PKA
> was removed from GnuPG in 2021.

Right.  The practial problem with PKA is that the majority of mail users
have no way to easily add records to their zone.  With WKD you only need
a web server and a way to upload things.

Except for the huge mail providers it is easy to setup a way to install
keys on the webserver.  mailbox.org, posteo, kernel.org, protonmail and
more allow this and that covers a lot of mail addresses.

Google and Microsoft have no interest in helping here because it might
damage their business model.  The German Telekom (t-online) could do
this and I even had meetings with them and adjusted the protocol for
their requirements.  But it seems they don't care about security and
prefer to direct their customes to their ads ridden portal.

Bit we want to decentralize mail again, don't we?

> The problem with WKD is that it relies on https and I refuse to use that
> broken CA based system that forces me to renew my certs every month or

The security of TLS is not as good as it could be but at least it is
good enough to do all the commerce.  Thus it is better than nothing.
And: DNS is not more secure given all the problems and the move from DNS
to HTTPS based DNS lookup in the browsers.

In any case the idea of WKD is an easy way to retrieve keys; whether you
put some intial trust into it (Kleopatra and GpgOL do that) is up to
you.  It is not intended to replace classic PGP key validation.


Shalom-Salam,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 284 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260410/bf27bf42/attachment.sig>

From klaus+gnupg at ethgen.ch  Fri Apr 10 09:41:08 2026
From: klaus+gnupg at ethgen.ch (Klaus Ethgen)
Date: Fri, 10 Apr 2026 08:41:08 +0100
Subject: PKA support
In-Reply-To: <87ecknnujm.fsf@jacob.g10code.de>
References: <adfQg8IG6HIf4Nkx@chil>
 <87ecknnujm.fsf@jacob.g10code.de>
Message-ID: <adiplMXPIPDbHhSq@ikki.ket>

Hi,

Am Fr den 10. Apr 2026 um  8:28 schrieb Werner Koch:
> And: DNS is not more secure given all the problems and the move from DNS
> to HTTPS based DNS lookup in the browsers.

Well, if you do DNSSEC, it is much more secure than HTTPS. However, the
problem is, that major players do not care about implementing it. For
example, Hetzner does still not allow to add DNSSEC glue to the
registration. There was a solution for this but isc closed it down as
"all country toplevel domains support DNSSEC", fully ignoring that the
registrars don't.

Another problem are such players as big tech making it hard to have use
of DNSSEC.

Regards
   Klaus
-- 
Klaus Ethgen                                       http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16            Klaus Ethgen <Klaus at Ethgen.ch>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 728 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260410/158cc6c0/attachment.sig>

From jb-gnumlists at wisemo.com  Fri Apr 10 16:23:40 2026
From: jb-gnumlists at wisemo.com (Jakob Bohm)
Date: Fri, 10 Apr 2026 16:23:40 +0200
Subject: PKA support
In-Reply-To: <adiplMXPIPDbHhSq@ikki.ket>
References: <adfQg8IG6HIf4Nkx@chil> <87ecknnujm.fsf@jacob.g10code.de>
 <adiplMXPIPDbHhSq@ikki.ket>
Message-ID: <3502d4b1-98f8-8fcc-bc33-696715e36d31@wisemo.com>

On 10/04/2026 09:41, Klaus Ethgen wrote:
> Hi,
>
> Am Fr den 10. Apr 2026 um  8:28 schrieb Werner Koch:
>> And: DNS is not more secure given all the problems and the move from DNS
>> to HTTPS based DNS lookup in the browsers.
> Well, if you do DNSSEC, it is much more secure than HTTPS. However, the
> problem is, that major players do not care about implementing it. For
> example, Hetzner does still not allow to add DNSSEC glue to the
> registration. There was a solution for this but isc closed it down as
> "all country toplevel domains support DNSSEC", fully ignoring that the
> registrars don't.
>
> Another problem are such players as big tech making it hard to have use
> of DNSSEC.
Plus the major design flaw that DNSSEC is an automatic footgun. Any
failure to regularly apply your signature refresh scripts with access
to your secret keys causes the signed domain/zone to become unreadable.
That scenario may be triggered by loss of the private key (think lost
equipment) and/or any unfortunately timed interruption in ability to
run the scripts.
 ?This is in contrast to GPG and S/MIME where the same scenario just
results in a warning that the data was signed with an expired key.

As a result, I have had to abandon DNSSEC for domains I manage
despite the registrar supporting it.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded



From klaus+gnupg at ethgen.ch  Fri Apr 10 17:20:39 2026
From: klaus+gnupg at ethgen.ch (Klaus Ethgen)
Date: Fri, 10 Apr 2026 16:20:39 +0100
Subject: PKA support
In-Reply-To: <3502d4b1-98f8-8fcc-bc33-696715e36d31@wisemo.com>
References: <adfQg8IG6HIf4Nkx@chil> <87ecknnujm.fsf@jacob.g10code.de>
 <adiplMXPIPDbHhSq@ikki.ket>
 <3502d4b1-98f8-8fcc-bc33-696715e36d31@wisemo.com>
Message-ID: <adkVR0H800ZlaUB9@ikki.ket>

Am Fr den 10. Apr 2026 um 15:23 schrieb Jakob Bohm via Gnupg-users:
> On 10/04/2026 09:41, Klaus Ethgen wrote:
> > Hi,
> >
> > Am Fr den 10. Apr 2026 um  8:28 schrieb Werner Koch:
> >> And: DNS is not more secure given all the problems and the move from DNS
> >> to HTTPS based DNS lookup in the browsers.
> > Well, if you do DNSSEC, it is much more secure than HTTPS. However, the
> > problem is, that major players do not care about implementing it. For
> > example, Hetzner does still not allow to add DNSSEC glue to the
> > registration. There was a solution for this but isc closed it down as
> > "all country toplevel domains support DNSSEC", fully ignoring that the
> > registrars don't.
> >
> > Another problem are such players as big tech making it hard to have use
> > of DNSSEC.
> Plus the major design flaw that DNSSEC is an automatic footgun. Any
> failure to regularly apply your signature refresh scripts with access
> to your secret keys causes the signed domain/zone to become unreadable.
> That scenario may be triggered by loss of the private key (think lost
> equipment) and/or any unfortunately timed interruption in ability to
> run the scripts.

Well, either you see the security important or you don't. If you fail,
learn and try again.

I don't think, that any noob should do their security. This should be
done by experts. And they need to be paid fair for that.

Gru?
   Klaus
-- 
Klaus Ethgen                                       http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16            Klaus Ethgen <Klaus at Ethgen.ch>
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 728 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260410/e01f63cc/attachment-0001.sig>

From me at jfr.im  Thu Apr  9 19:39:03 2026
From: me at jfr.im (John Runyon)
Date: Thu, 9 Apr 2026 11:39:03 -0600
Subject: PKA support
In-Reply-To: <adfQg8IG6HIf4Nkx@chil>
References: <adfQg8IG6HIf4Nkx@chil>
Message-ID: <CAN4EqKWb=fEGn3tsBd7zC+9twSHCm9tFcNFxp6A1szg5e+f7MA@mail.gmail.com>

       --auto-key-locate mechanisms
       --no-auto-key-locate
              GnuPG can automatically locate and retrieve keys as
needed using this option.  This happens when encrypting to an email
address (in the "user at example.com" form), and there are no
"user at example.com" keys on the local keyring.  This option takes any
number of the mech?
              anisms listed below, in the order they are to be tried.
Instead of listing the mechanisms as comma delimited arguments, the
option may also be given several times to add more mechanism.  The
option --no-auto-key-locate or the mechanism "clear" resets the list.
 The
              default is "local,wkd".

              cert   Locate a key using DNS CERT, as specified in RFC-4398.

              dane   Locate a key using DANE, as specified in
draft-ietf-dane-openpgpkey-05.txt.

Thanks,
John Runyon


On Thu, Apr 9, 2026 at 10:19?AM Klaus Ethgen <klaus+gnupg at ethgen.ch> wrote:
>
> Hi,
>
> I just realized, as I was searching for Werner's current key, that PKA
> was removed from GnuPG in 2021.
>
> Until now that was my preferred way to spread my key.
>
> What was the reason for that?
>
> The problem with WKD is that it relies on https and I refuse to use that
> broken CA based system that forces me to renew my certs every month or
> even more often. The only halfway trustable CA is Cacert. But it is
> nowhere installed anymore.
>
> So PKA was the only alternative to WKD...
>
> Regards
>    Klaus
> --
> Klaus Ethgen                                       http://www.ethgen.ch/
> pub  4096R/4E20AF1C 2011-05-16            Klaus Ethgen <Klaus at Ethgen.ch>
> Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users


From asher.mullaney at gmail.com  Sat Apr 11 22:24:19 2026
From: asher.mullaney at gmail.com (Asher Mullaney)
Date: Sat, 11 Apr 2026 20:24:19 +0000
Subject: Plans for Post-Quantum Cryptography in GnuPG
Message-ID: <CALVR1Mfd6037snU8Z=0FBacs3btMddYNswAz2CQLa4Czsy7yvQ@mail.gmail.com>

Hi!

I would like to know if there are any plans for GnuPG to support
post-quantum cryptography schemes, specifically ML-KEM (Kyber) and
ML-DSA (Dilithium) as these will be crucial in cryptography that is
resistant to quantum computer attacks (a fast-growing threat). If such
plans exist, when can we expect to see the aforementioned support in
GnuPG?

Thanks,

--
ajmull

My OpenPGP public key is available on keys.openpgp.org under the email
addresses "corvuscorone at duck.com" and "asher.mullaney at gmail.com."


From collin.funk1 at gmail.com  Sun Apr 12 20:44:34 2026
From: collin.funk1 at gmail.com (Collin Funk)
Date: Sun, 12 Apr 2026 11:44:34 -0700
Subject: Plans for Post-Quantum Cryptography in GnuPG
In-Reply-To: <CALVR1Mfd6037snU8Z=0FBacs3btMddYNswAz2CQLa4Czsy7yvQ@mail.gmail.com>
References: <CALVR1Mfd6037snU8Z=0FBacs3btMddYNswAz2CQLa4Czsy7yvQ@mail.gmail.com>
Message-ID: <874ilgqar1.fsf@gmail.com>

Asher Mullaney via Gnupg-users <gnupg-users at gnupg.org> writes:

> I would like to know if there are any plans for GnuPG to support
> post-quantum cryptography schemes, specifically ML-KEM (Kyber) and
> ML-DSA (Dilithium) as these will be crucial in cryptography that is
> resistant to quantum computer attacks (a fast-growing threat). If such
> plans exist, when can we expect to see the aforementioned support in
> GnuPG?

You can use Kyber in GnuPG 2.5, e.g., from the gnupg.org repositories
[1]. See:

    $ gpg --version
    gpg (GnuPG) 2.5.18
    libgcrypt 1.12.1
    Copyright (C) 2025 g10 Code GmbH
    License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.
    
    Home: /root/.gnupg
    Supported algorithms:
    Pubkey: RSA, Kyber, ELG, DSA, ECDH, ECDSA, EDDSA
    Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
            CAMELLIA128, CAMELLIA192, CAMELLIA256
    Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
    Compression: Uncompressed, ZIP, ZLIB, BZIP2

Collin

[1] https://gnupg.org/blog/20250827-new-repository.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260412/aed3ba3e/attachment.sig>

From rjh at sixdemonbag.org  Mon Apr 13 04:37:16 2026
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Sun, 12 Apr 2026 22:37:16 -0400
Subject: Plans for Post-Quantum Cryptography in GnuPG
In-Reply-To: <CALVR1Mfd6037snU8Z=0FBacs3btMddYNswAz2CQLa4Czsy7yvQ@mail.gmail.com>
References: <CALVR1Mfd6037snU8Z=0FBacs3btMddYNswAz2CQLa4Czsy7yvQ@mail.gmail.com>
Message-ID: <fc8a27bd-36bf-4d06-a05d-da212f2d77a0@sixdemonbag.org>

> I would like to know if there are any plans for GnuPG to support
> post-quantum cryptography schemes, specifically ML-KEM (Kyber) and
> ML-DSA (Dilithium) as these will be crucial in cryptography that is
> resistant to quantum computer attacks (a fast-growing threat).

Kyber is already present in the latest 2.5 series, which is (despite its 
developmental version number) a GA release intended for all users.

There is no support at present for PQC in signing/certifying algorithms, 
as the demand there seems slightly less. (And before anyone screams "how 
can it be less?!", this is less in terms of user demand, and your voice 
is in the minority.)

IMO, the necessary algorithms for PQC signing/certifying are not yet 
ready for primetime. Dilithium is obviously the biggest component of a 
signing/certifying system, but there are others, and things are still 
evolving on the cryptography front. I'm sure that once things stabilize 
LibrePGP will start supporting it quickly enough.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260412/e63c4173/attachment.sig>

From jcb62281 at gmail.com  Mon Apr 13 05:36:44 2026
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Sun, 12 Apr 2026 22:36:44 -0500
Subject: Plans for Post-Quantum Cryptography in GnuPG
In-Reply-To: <fc8a27bd-36bf-4d06-a05d-da212f2d77a0@sixdemonbag.org>
References: <CALVR1Mfd6037snU8Z=0FBacs3btMddYNswAz2CQLa4Czsy7yvQ@mail.gmail.com>
 <fc8a27bd-36bf-4d06-a05d-da212f2d77a0@sixdemonbag.org>
Message-ID: <dcddd516-6e60-474b-971d-c02d32945f61@gmail.com>

On 4/12/26 21:37, Robert J. Hansen via Gnupg-users wrote:
>> I would like to know if there are any plans for GnuPG to support
>> post-quantum cryptography schemes, specifically ML-KEM (Kyber) and
>> ML-DSA (Dilithium) as these will be crucial in cryptography that is
>> resistant to quantum computer attacks (a fast-growing threat).
>
> Kyber is already present in the latest 2.5 series, which is (despite 
> its developmental version number) a GA release intended for all users.
>
> There is no support at present for PQC in signing/certifying 
> algorithms, as the demand there seems slightly less. (And before 
> anyone screams "how can it be less?!", this is less in terms of user 
> demand, and your voice is in the minority.)
>
> IMO, the necessary algorithms for PQC signing/certifying are not yet 
> ready for primetime. Dilithium is obviously the biggest component of a 
> signing/certifying system, but there are others, and things are still 
> evolving on the cryptography front. I'm sure that once things 
> stabilize LibrePGP will start supporting it quickly enough.

This is a serious problem:? recent developments suggest that 256-bit EC 
cryptosystems might not last much longer and here we find that PQC 
signature algorithms are not ready yet.

... That leaves RSA, which even at RSA-4096 may be within the reach of 
very large clusters in the near future.

Perhaps we should just bite the proverbial bullet and roll out RSA-16384 
signatures as an interim measure?? Possibly as a RSA-16384/PQC hybrid 
cryptosystem?

Would a better approach be to generalize hybrid signature systems, 
allowing users to specify combinations when generating keys?? For a 
valid signature under such a key, *all* (per-algorithm) sub-signatures 
must be valid.


-- Jacob




From rjh at sixdemonbag.org  Mon Apr 13 10:13:51 2026
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 13 Apr 2026 04:13:51 -0400
Subject: Plans for Post-Quantum Cryptography in GnuPG
In-Reply-To: <dcddd516-6e60-474b-971d-c02d32945f61@gmail.com>
References: <CALVR1Mfd6037snU8Z=0FBacs3btMddYNswAz2CQLa4Czsy7yvQ@mail.gmail.com>
 <fc8a27bd-36bf-4d06-a05d-da212f2d77a0@sixdemonbag.org>
 <dcddd516-6e60-474b-971d-c02d32945f61@gmail.com>
Message-ID: <f4a35154-07ce-4a41-97f6-c750318382e1@sixdemonbag.org>

> This is a serious problem:? recent developments suggest that 256-bit EC 
> cryptosystems might not last much longer

"Might" and "much not" are vague things. Better to say something 
concrete, like "the US government has informed its suppliers and 
contractors they must use PQC signatures for firmware and software 
starting in 2030. Communications can be secured via ECC until 2033."

We have between four and seven years to transition. Let's talk calmly 
about our smooth, responsible migrations, not scare people into doing it 
quickly with vague talk about how ECC might not be around much longer.

Smooth is slow. Slow is fast.

> and here we find that PQC signature algorithms are not ready yet.

NIST FIPS 204 specifying CRYSTALS was published in 2024, so *a* 
specification exists: but as with all specs, the first release had 
errors. NIST is tracking these errors in a publicly viewable 
spreadsheet. They're emphatic that "[p]otential corrections DO NOT 
introduce new technical requirements", but it's pretty clear that soon a 
new draft of FIPS 204 will be released incorporating this errata.

All the correct information exists: it's just not yet all in one master 
document.

> Perhaps we should just bite the proverbial bullet and roll out RSA-16384 
> signatures as an interim measure?? Possibly as a RSA-16384/PQC hybrid 
> cryptosystem?

Hard no. This is a terrible idea. You can have Werner and g10 Code 
working on implementing FIPS 204, or you can have them working on this. 
Delaying Dilithium to get this out as a six-month stopgap which we'd 
then have to support for 30 years is unwise.

> Would a better approach be to generalize hybrid signature systems, 
> allowing users to specify combinations when generating keys?? For a 
> valid signature under such a key, *all* (per-algorithm) sub-signatures 
> must be valid.

No.

The advice in the GnuPG FAQ still holds true, even today: "unless you 
know what you're doing and why you're doing it, stick with the defaults."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260413/e56e1513/attachment-0001.sig>

From wk at gnupg.org  Mon Apr 13 11:20:19 2026
From: wk at gnupg.org (Werner Koch)
Date: Mon, 13 Apr 2026 11:20:19 +0200
Subject: Plans for Post-Quantum Cryptography in GnuPG
In-Reply-To: <fc8a27bd-36bf-4d06-a05d-da212f2d77a0@sixdemonbag.org> (Robert
 J. Hansen via Gnupg-users's message of "Sun, 12 Apr 2026 22:37:16
 -0400")
References: <CALVR1Mfd6037snU8Z=0FBacs3btMddYNswAz2CQLa4Czsy7yvQ@mail.gmail.com>
 <fc8a27bd-36bf-4d06-a05d-da212f2d77a0@sixdemonbag.org>
Message-ID: <87zf37kyi4.fsf@jacob.g10code.de>

On Sun, 12 Apr 2026 22:37, Robert J. Hansen said:

> IMO, the necessary algorithms for PQC signing/certifying are not yet
> ready for primetime. Dilithium is obviously the biggest component of a

Right.  Experience from 30 years showed that deploying a stable and
secure signing system is much more challenging than an encryption
system.  Given that the claimed threat is store-now-maybe-decrypt-later
the deployment of signatures is not yet not needed.

Further, a new signing algorithm must we widely deployed before it can
be used.  The migration path for encryption is much easier: Add a Kyber
Subkey and implementations supporting this will encrypt using Kyber.
That is actually how we migrated to cv25519.


Shalom-Salam,

   Werner



#include <standard.pqc.disclamer.h>
/* https://www.cs.auckland.ac.nz/~pgut001/pubs/bollocks.pdf
 * https://media.gnupg.org/misc/Peter_Gutmann-Why_Quantum_Cryptanalysis_is_Bollocks-2025-11.mp4  */

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein


-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 284 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260413/41c06d62/attachment.sig>

From rjh at sixdemonbag.org  Mon Apr 13 18:47:47 2026
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 13 Apr 2026 12:47:47 -0400
Subject: Thoughts on PQC
Message-ID: <7cd19ad7-62c7-4ebc-8faf-de67ae8036f8@sixdemonbag.org>

(Ethan Siegel, a Ph.D in astrophysics and science communicator who does 
a lot of explanations of quantum computing, is included here on the bcc 
list so as to not reveal his email address. If he has any thoughts to 
contribute to the discussion, I'll relay them on to the list.)

Some disconnected thoughts on post-quantum cryptography. For some reason 
many people on this list seem to think I have an opinion worth listening 
to on the subject: I really don't. Don't confuse someone who is 
significantly less lost than you are with someone who knows how to get 
home. I am, at best, the helpful stranger at the bus terminal warning 
you you're getting on the wrong bus.


1. MOST OF THE DISCUSSION IS IN DEEPLY BAD FAITH

Professionally speaking, I have a reputation as being a little bit of a 
cold bastard. I genuinely try to be supportive of my co-workers and 
encourage them to try things and make mistakes, but when outside vendors 
come in and use all kinds of jargon and newfangled words to describe 
things, I have been known to be, well...

	"I have a Master's in computer science, decades of work
	experience, I've spoken at DEF CON and Black Hat, I
	invented language-theoretic security. I am not an idiot.
	I have absolutely no idea what you're talking about here.
	I don't think anyone else in the room does, either.
	Please explain that again."

I have to break that out for the good of my engineering team about, oh, 
one time in twenty vendor show-and-tells. When it comes to anything 
involving the word 'quantum', it's closer to half the time.

Last year I was asked to weigh in on the claims of a quantum 
cryptography startup that had a stock price of $970/share. The CEO went 
on the record saying he expected RSA-2048 to fall to quantum 
cryptanalysis within two years. When I saw this YouTube clip I did some 
back of the envelope math and pointed out to everyone within earshot 
that under optimistic assumptions about ensemble size and error 
correction, we'd need to see doublings of quantum computational 
capability every 38 days from here on out for the next two years. I then 
wondered aloud what it was he knew that made him so optimistic 38-day 
doublings would happen for two years. Extraordinary claims require 
extraordinary evidence, and all that.

Their stock price is now $12.66/share. The market got wise to them.

2. MOST OF THE DISCUSSION IGNORES HOW SCIENCE ACTUALLY WORKS.

During the Cold War there was a rush to develop high-yield nuclear 
weapons ("H-bombs": contrary to popular opinion, the "H-bomb" 
designation was never meant to apply to fusion weapons, but any 
high-yield nuclear device).

There were several different competing ideas for how to get there. The 
Russians pursued an architecture called sloika; we pursued a couple of 
different routes before settling on staged detonation. It was a fairly 
straightforward piece of engineering, complicated by the fact we needed 
some parameters we just didn't have and didn't yet have the computing 
power (or the quantum theory!) to compute.

So, the United States government went off to the South Pacific and built 
the world's largest, most expensive science experiment up to that date. 
It was called IVY MIKE. It was not, as some people think, the first 
H-bomb. It wasn't a bomb because it was about the same size as a fairly 
large industrial plant. The Soviets mocked it as a "thermonuclear 
installation".

IVY MIKE went boom. We collected the necessary data. We very quickly 
used the experimental results to start building staged detonation bombs 
small enough to fit onto ICBMs.

A lot of people like to tell you that's what's happening here: yes, the 
existing quantum computers are IVY MIKE-like monstrosities completely 
unsuited for real work, but the real devices are just around the corner...

... and it's all complete hokum. Each new quantum computer is its own 
IVY MIKE installation. We are not at the stage where we know how to make 
quantum computers, we just need a couple of data points to finalize our 
design. We are at the stage where we're struggling just to do things 
that aren't trivial.

Scott Aaronson, a quantum computational nerd of immense nerditude -- mad 
respect to him -- says that the proper analogy is someone in 1943 
saying, "wow, those guys are close to a nuclear chain reaction." Okay, 
great, big deal, what does that get you? -- well, if Scott is to be 
believed, it gets you a Trinity test two years later in the summer of 1945.

No. That's not how it works.

Trinity depended on massive advances in plutonium breeding and 
enrichment. We had to invent new electrical switches (krytrons) to very 
precisely send electrical signals to entirely new explosive detonators 
(exploding bridgewires) embedded in entirely new explosives (castables) 
that formed complex geometries never before done in explosives 
(explosive lenses) that required entirely new branches of mathematics to 
be invented (hydrodynamics). The engineering infrastructure to support 
the Bomb was *huge*.

For right now, we're building that infrastructure once per quantum 
experiment. It's ... expensive, to say the least. It does not scale. 
Some ideas may carry over from one installation to the next, but *how 
those ideas are executed* are essentially reinvented de novo.

Everyone remembers how awesome it was when astronomers released the 
first visible-light images of a black hole, right? As difficult as it 
was to gain the raw data -- a heroic work of astronomy if ever there was 
one -- just as difficult, if not moreso, was assembling the teams of 
software engineers needed to tease information out of these petabytes of 
collected data.

That's where we are with quantum computing right now. For every new 
installation it's a massive investment of time and money, with very 
little carrying over. We build one, we say we learned something, we move 
on, reinventing and reimplementing all over again.

Sooner or later the economics are going to catch up. This is not 
sustainable unless an actual economic case can be made, unless real 
return-on-investment can be demonstrated.

3. THERE IS THOROUGHLY TOO MUCH SPECIAL PLEADING GOING ON.

Asking an undergraduate computer science student to enumerate the 
characteristics of an algorithm is a quick way to discover what textbook 
they learned algorithms from. Maybe they used CLRS or maybe Knuth's 
TAOCP or ... whatever. It's like identifying Christians by asking them 
to enumerate the Ten Commandments; by listening carefully to how they're 
enumerated you can guess at the denomination.

But, like the Ten Commandments, the good textbooks all agree on the 
important bits. One of the defining rules of an algorithm is IT MUST BE 
EFFECTIVE -- put in screaming caps because this must never be forgotten. 
If you forget that requirement, well, hey, I have an algorithm that 
breaks RSA-4096 keys in seconds. It always gives you the wrong answer, 
but why should that be an obstacle?

That's why we require effectiveness in algorithms. If a process is not 
effective at its task, it is not an algorithm. With me?

Last year (or maybe in 2024) Google made this massive hue and cry over 
how they had finally proved quantum supremacy -- or maybe it was quantum 
advantage -- their press releases seemed a bit ambivalent before 
settling on quantum supremacy. (Probably because it sounds cooler.) But 
when I dove into exactly what algorithm they'd demonstrated quantum 
supremacy for, I was underwhelmed.

They proved they could wire up random quantum circuits.

That's it. That's analogous to me saying I can get random values in 
memory by reading them on right after power-on. Okay, great, but *why*? 
Why would anyone be interested in that? How is this in any way a 
breakthrough?

When I realized they were saying "we can't wire up a circuit of our own 
specification, but we can wire up a completely random one faster than a 
classical computer can!", wow. I remember the moment vividly, because I 
threw the paper across my cubicle and bitterly quoted the television 
show _Firefly_:

"Well, Google, my days of not taking you seriously are certainly coming 
to a middle."

If you dig deep into a lot of these papers showing quantum supremacy, 
you'll quickly discover you're not entirely sure whether the thing 
they're doing is even an algorithm. And if it's not an algorithm, wow, 
doesn't that just put their wild claims in a new light?

4. PRESS RELEASES AREN'T PEER REVIEW, DAMN IT.

This one should be self-explanatory.

Nobody at the Trinity test site had to go find reporters and persuade 
them they'd done something amazing. Yet, these people pushing quantum 
computing have astonishingly well-funded press offices and they're very 
effective at convincing journalists to pay attention.

I am sick and tired of people saying "... but the paper's on arXiv!". 
That's the science way of saying you self-published your fanfic on 
Archive Of Our Own. arXiv is AO3 for science. I'm very happy there's a 
preprint of a paper on arXiv: now let me know as soon as Peter Deutsch 
or Scott Aaronson or Lee Smolin notices it and comments.

5. WHAT DOES THIS FEEL LIKE?

It feels like string theory all over again.

I realized string theory was an unscientific bunch of hokum back in 
2005, when I realized string theory could not tell us which possible 
universe we were in. It predicted a landscape of some 10^500 universes, 
ours was in there somewhere, they were just sure of it.

I thought about it some and decided I put the likelihood of the 
Judeo-Christian concept of God being accurate at about 10^-20. But 
believing God said "deus vult!" is unscientific, but waxing ecstatic 
about an accuracy of 10^-500 was somehow the cutting edge of science?

It was then I knew string theory was an interesting idea wrapped up in a 
spectacular PR campaign in pursuit of all the grant money everywhere in 
the world. Wasn't for me, and I looked skeptically on it afterwards.

I get the same feeling from quantum computation. It's not hokum: it's 
based on some really interesting physical possibilities wrapped up in 
engineering problems we have no idea how to solve yet. It's like if 
someone gave Napoleon the plutonium pit from the Trinity bomb: cool 
beans, dude, but he's got a lot of catching up to do before anything 
useful can be done with it. He would find more utility from its fifteen 
watts of waste heat than from anything else.

6. THE BOTTOM LINE

Quantum computing is not a fraud on the public, but there are a lot of 
businesses using quantum computing claims to perpetuate frauds on the 
public. The infrastructure is simply *not there* and *we have no idea 
how to make it there*.

My own personal guess -- and it's a wild guess, please don't mistake 
this for a scientific estimate -- is there's a 1% chance of a really 
major advance in real-world quantum computing by 2035.

That's still an uncomfortable number. It's worth some long, calm, sober 
deliberation.

But don't forget there's a 99% chance this current hype train isn't 
going to pan out. That, too, should enter your deliberations.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260413/234b1b76/attachment.sig>

From johndoe65534 at mail.com  Mon Apr 13 19:19:45 2026
From: johndoe65534 at mail.com (john doe)
Date: Mon, 13 Apr 2026 19:19:45 +0200
Subject: Thoughts on PQC
In-Reply-To: <7cd19ad7-62c7-4ebc-8faf-de67ae8036f8@sixdemonbag.org>
References: <7cd19ad7-62c7-4ebc-8faf-de67ae8036f8@sixdemonbag.org>
Message-ID: <377e96cf-8734-401f-a8ba-58527d9b32c5@mail.com>

On 4/13/26 6:47 PM, Robert J. Hansen via Gnupg-users wrote:
> (Ethan Siegel, a Ph.D in astrophysics and science communicator who does 
> a lot of explanations of quantum computing, is included here on the bcc 
> list so as to not reveal his email address. If he has any thoughts to 
> contribute to the discussion, I'll relay them on to the list.)
> 
> Some disconnected thoughts on post-quantum cryptography. For some reason 
> many people on this list seem to think I have an opinion worth listening 
> to on the subject: I really don't. Don't confuse someone who is 
> significantly less lost than you are with someone who knows how to get 
> home. I am, at best, the helpful stranger at the bus terminal warning 
> you you're getting on the wrong bus.
> 
> <snip>
 >

I have a lot of things to learn from you, having your thoughts diluted 
in hyperbole does not do you justice.
Granted, English is not my mother tong and is likely why it's hard for 
me to really understand you and also some  cultural differences are 
likely not helping.

-- 
John Doe


From rjh at sixdemonbag.org  Mon Apr 13 19:54:19 2026
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 13 Apr 2026 13:54:19 -0400
Subject: Thoughts on PQC
In-Reply-To: <377e96cf-8734-401f-a8ba-58527d9b32c5@mail.com>
References: <7cd19ad7-62c7-4ebc-8faf-de67ae8036f8@sixdemonbag.org>
 <377e96cf-8734-401f-a8ba-58527d9b32c5@mail.com>
Message-ID: <8701e900-66dc-4939-8be9-c18b55d3052d@sixdemonbag.org>

> I have a lot of things to learn from you, having your thoughts diluted 
> in hyperbole does not do you justice.

You're kind. Thank you.

I don't like to talk about my health troubles, but I live with major 
depressive disorder and social anxiety disorder. One of the quickest 
ways to trigger my social anxiety disorder is to treat me like I'm an 
authority.

It is genuinely a kindness to me to treat me like I'm just a guy with 
some good ideas. That's all I want to be. Thank you for understanding. :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260413/9bde9364/attachment.sig>

From avi.wiki at gmail.com  Mon Apr 13 19:41:44 2026
From: avi.wiki at gmail.com (Avi)
Date: Mon, 13 Apr 2026 13:41:44 -0400
Subject: Thoughts on PQC
In-Reply-To: <377e96cf-8734-401f-a8ba-58527d9b32c5@mail.com>
References: <7cd19ad7-62c7-4ebc-8faf-de67ae8036f8@sixdemonbag.org>
 <377e96cf-8734-401f-a8ba-58527d9b32c5@mail.com>
Message-ID: <CAF5O_jzJkP6UnuSCDpf=e7ca-7vBZV84a_aZo6HSQZ8aMjRL6Q@mail.gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

As a very-long-time (multiple decades) lurker on this list, and
follower of Werner and Robert since the late 1900s [8-)], I feel
obligated to implement MeatBallWiki's DefendEachOther and say that I
have never found Robert to be guilty of hyperbole when he is being
serious. Besides being one of the best expositors I have ever had the
privilege of reading, he is also extremely diligent about providing
the math or science behind his claims. His old FAQ on sixdemonbag was
a complete eye-opener for anyone who understood basic physics and
algebra. If you find his claims fantastical, I respectfully suggest
that you verify the analysis for yourself. If he is wrong, he will be
the first to admit it.
Thank you,
Avi
-----BEGIN PGP SIGNATURE-----

iJEEAREIADkWIQQWfAY/eYGh9nHsq6oNYrAZ+A4p+QUCad0qihsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMiwyLDEACgkQDWKwGfgOKflAGQD/YWsV7TwQhCDbi+xqRrdl
n4SjRBBBT7zMQdRFutx6JEcA/1IOjZ7+HfELORSAFhY71bLx7W+zExvTypN9Q50r
FpTj
=XU4Y
-----END PGP SIGNATURE-----

----
Avraham

pub 3072D/F80E29F9 1/30/2009 Avi (Wikimedia-related key) <avi.wiki at gmail.com>
   Primary key fingerprint: 167C 063F 7981 A1F6 71EC ABAA 0D62 B019 F80E 29F9

On Mon, Apr 13, 2026 at 1:20?PM john doe via Gnupg-users
<gnupg-users at gnupg.org> wrote:
>
> On 4/13/26 6:47 PM, Robert J. Hansen via Gnupg-users wrote:
> > (Ethan Siegel, a Ph.D in astrophysics and science communicator who does
> > a lot of explanations of quantum computing, is included here on the bcc
> > list so as to not reveal his email address. If he has any thoughts to
> > contribute to the discussion, I'll relay them on to the list.)
> >
> > Some disconnected thoughts on post-quantum cryptography. For some reason
> > many people on this list seem to think I have an opinion worth listening
> > to on the subject: I really don't. Don't confuse someone who is
> > significantly less lost than you are with someone who knows how to get
> > home. I am, at best, the helpful stranger at the bus terminal warning
> > you you're getting on the wrong bus.
> >
> > <snip>
>  >
>
> I have a lot of things to learn from you, having your thoughts diluted
> in hyperbole does not do you justice.
> Granted, English is not my mother tong and is likely why it's hard for
> me to really understand you and also some  cultural differences are
> likely not helping.
>
> --
> John Doe
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users


From johndoe65534 at mail.com  Mon Apr 13 21:47:04 2026
From: johndoe65534 at mail.com (john doe)
Date: Mon, 13 Apr 2026 21:47:04 +0200
Subject: Thoughts on PQC
In-Reply-To: <8701e900-66dc-4939-8be9-c18b55d3052d@sixdemonbag.org>
References: <7cd19ad7-62c7-4ebc-8faf-de67ae8036f8@sixdemonbag.org>
 <377e96cf-8734-401f-a8ba-58527d9b32c5@mail.com>
 <8701e900-66dc-4939-8be9-c18b55d3052d@sixdemonbag.org>
Message-ID: <b1e3df98-941a-488f-8f2b-13c5da7284ca@mail.com>

On 4/13/26 7:54 PM, Robert J. Hansen via Gnupg-users wrote:
>> I have a lot of things to learn from you, having your thoughts diluted 
>> in hyperbole does not do you justice.
> 

Hyperbole, was not the word I should have used/included, sorry about that.
The point I was trying to make was that in your original e-mail at [1], 
your second point  and other parts are not helping me understanding your 
thoughts on PQC.

> You're kind. Thank you.
> 
> I don't like to talk about my health troubles, but I live with major 
> depressive disorder and social anxiety disorder. One of the quickest 
> ways to trigger my social anxiety disorder is to treat me like I'm an 
> authority.
> 

For better or for worse, I use John Doe because I do not want to have my 
real name publicly associated with who I am.


[1] https://lists.gnupg.org/pipermail/gnupg-users/2026-April/068253.html

-- 
John Doe


From rjh at sixdemonbag.org  Mon Apr 13 23:07:27 2026
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 13 Apr 2026 17:07:27 -0400
Subject: Thoughts on PQC
In-Reply-To: <b1e3df98-941a-488f-8f2b-13c5da7284ca@mail.com>
References: <7cd19ad7-62c7-4ebc-8faf-de67ae8036f8@sixdemonbag.org>
 <377e96cf-8734-401f-a8ba-58527d9b32c5@mail.com>
 <8701e900-66dc-4939-8be9-c18b55d3052d@sixdemonbag.org>
 <b1e3df98-941a-488f-8f2b-13c5da7284ca@mail.com>
Message-ID: <360b1c88-896e-483f-a50b-6e571d0169fa@sixdemonbag.org>

> The point I was trying to make was that in your original e-mail at [1], 
> your second point? and other parts are not helping me understanding your 
> thoughts on PQC.

1. An awful lot of the people talking about PQC are doing so for 
self-serving reasons. Some of these people are committing outright 
fraud. They think that if they can use enough science gibberish they can 
fool people into giving them money. I used as an example a company that 
once traded for $970/share, where their CEO made extraordinary claims 
about how quantum computing capability would double every 38 days for 
the next two years. This man had a Ph.D in physics. Was he just an 
incompetent physicist, to make such an outrageous claim? Or was he a 
fraud looking to sell stock to people who were easily impressed?

Hard to say. I don't know.

So that's my first thought on PQC: a lot of the people talking about it 
are swindlers, scoundrels, rogues, grifters, and flimflam artists. You 
should always remember that when hearing someone talk about PQC. "Is 
this person a fraud, or are they being honest?"

2. Of the honest ones, few of them understand how science works.

Let's say that you traveled back to Napoleon at the Battle of Waterloo, 
and you gave him a carefully machined sphere of plutonium. How would 
this change the Battle of Waterloo?

Some people say, "introducing atomic weapons to the Battle of Waterloo 
would change everything!"

But it wouldn't. The best thing Napoleon could do with a carefully 
machined sphere of plutonium would be to silverplate it (for health: 
plutonium's incredibly toxic) and then keep it around as a fifteen-watt 
space heater.

To successfully use cutting-edge technology normally requires massive 
investments in other cutting-edge technologies just to support the 
operation of the thing you're interested in. In the case of a nuclear 
bomb, you need new kinds of physics, new kinds of mathematics, new kinds 
of metallurgy, new kinds of nitrochemistry, new kinds of electronics... 
and if you don't have them, well, enjoy your fifteen-watt space heater.

Today's quantum computation, quantum cryptanalysis, and post-quantum
cryptography press releases are meant to make you focus on the nuclear 
pit. They're also meant to distract you from the fact that, like 
Napoleon, we really have no idea how to use it. That distraction game is 
another reason I'm very careful about how much stock I put in it.

3. There is thoroughly too much special pleading going on.

The sine qua non of computer science ("without this, there is nothing") 
is effectiveness. If something isn't effective, it's not an algorithm. 
If it's not an algorithm, it's ... well, very probably boring.

The quantum computation and quantum cryptanalysis crowd tends to be 
guilty of this. A few years ago Google invented a "problem" that existed 
to ... to what? They created a random quantum circuit (which is a little 
weird, but not totally weird: random matrix theory is well-known in 
computer science, RQC is sort of its quantum analogue) that did nothing, 
could do nothing, except ... set itself up faster than a classical 
algorithm could.

Where's the effectiveness? What problem was it solving?

"Special pleading" means "I know the law, but this time it's not going 
to apply to me." The law says, if your procedure is not effective at 
doing something, it's not an algorithm and is of far less interest. This 
crowd likes to say, "sure, it's not effective at doing anything, but do 
you see how FAST it is at not being effective at doing anything?"

4. Press releases are not peer review.

The fact a paper is published on arXiv means exactly as much as if was 
mimeographed and distributed via newsletter. arXiv is not a 
peer-reviewed forum. All kinds of crap gets published there.

When the quantum crowd says "read this paper on arXiv, you'll see I'm 
right!", you may safely wait. If the paper is as groundbreaking as the 
speaker claims, luminaries will weigh in on it.

5. What does this feel like?

String theory in the '90s. That's not a very promising feeling.

6. The bottom line

It's something to keep an eye on, but remember the odds are 
overwhelmingly good you won't need PQC in the next five years.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4583 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260413/749487e1/attachment-0001.bin>

From jcb62281 at gmail.com  Tue Apr 14 06:12:37 2026
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Mon, 13 Apr 2026 23:12:37 -0500
Subject: Thoughts on PQC
In-Reply-To: <360b1c88-896e-483f-a50b-6e571d0169fa@sixdemonbag.org>
References: <7cd19ad7-62c7-4ebc-8faf-de67ae8036f8@sixdemonbag.org>
 <377e96cf-8734-401f-a8ba-58527d9b32c5@mail.com>
 <8701e900-66dc-4939-8be9-c18b55d3052d@sixdemonbag.org>
 <b1e3df98-941a-488f-8f2b-13c5da7284ca@mail.com>
 <360b1c88-896e-483f-a50b-6e571d0169fa@sixdemonbag.org>
Message-ID: <dfe3f744-45b7-4763-b0bc-76cccc5a29b2@gmail.com>

On 4/13/26 16:07, Robert J. Hansen via Gnupg-users wrote:
>> The point I was trying to make was that in your original e-mail at 
>> [1], your second point? and other parts are not helping me 
>> understanding your thoughts on PQC.
>
> 1. An awful lot of the people talking about PQC are doing so for 
> self-serving reasons. Some of these people are committing outright 
> fraud. They think that if they can use enough science gibberish they 
> can fool people into giving them money. I used as an example a company 
> that once traded for $970/share, where their CEO made extraordinary 
> claims about how quantum computing capability would double every 38 
> days for the next two years. This man had a Ph.D in physics. Was he 
> just an incompetent physicist, to make such an outrageous claim? Or 
> was he a fraud looking to sell stock to people who were easily impressed?

Well, if the stock traded at $970/share, I would say that he succeeded 
in getting people to give him money, at least for a while.? *That* part 
worked, even if the qubits did not.? :-)

>
> [...]
>
> So that's my first thought on PQC: a lot of the people talking about 
> it are swindlers, scoundrels, rogues, grifters, and flimflam artists. 
> You should always remember that when hearing someone talk about PQC. 
> "Is this person a fraud, or are they being honest?"

My understanding (based on the "heffalumps" paper) is that past PQC 
systems have had nasty tendencies to unravel under conventional 
computing.? You have looked at this much more than I have.? Have we 
finally found problems that are reliably hard for both quantum and 
conventional computing?

>
> [...]
>
> 3. There is thoroughly too much special pleading going on.
>
> The sine qua non of computer science ("without this, there is 
> nothing") is effectiveness. If something isn't effective, it's not an 
> algorithm. If it's not an algorithm, it's ... well, very probably boring.
>
> The quantum computation and quantum cryptanalysis crowd tends to be 
> guilty of this. A few years ago Google invented a "problem" that 
> existed to ... to what? They created a random quantum circuit (which 
> is a little weird, but not totally weird: random matrix theory is 
> well-known in computer science, RQC is sort of its quantum analogue) 
> that did nothing, could do nothing, except ... set itself up faster 
> than a classical algorithm could.
>
> Where's the effectiveness? What problem was it solving?

How does its performance compare to existing TRNGs?? (Presumably a 
random quantum circuit would produce random output... or is my ignorance 
showing and most of them just produce zero or some constant not 
characteristic of the circuit?)

(It could be "return 4;" in quantum form.)? :-)

> [...]
>
>
> 6. The bottom line
>
> It's something to keep an eye on, but remember the odds are 
> overwhelmingly good you won't need PQC in the next five years.

As another guy with a bunch of ideas, I expect RSA-2048 to eventually 
fall to ever-larger clusters if Moore's law does not completely break 
down.? (We are also very close, if not already at, a point where Moore's 
law collides with hard physical limits, like the inability to make 
transistors smaller than the atoms of which they are comprised.)

Looking at it another way, I expect conventional computing to solve 
RSA-2048 before qubit ensembles capable of solving even RSA-1024 are built.

On the other hand, reports seem to suggest that the mathematical 
advantage that makes 256-bit ECRSA viable despite RSA-256 being easily 
solved does not apply to Shor's algorithm.? If *that* is correct, EC 
cryptosystems will fall to quantum computing long before RSA does, and 
*possibly* [*] even before conventional clusters are able to solve RSA-2048.

[*] The "possibly" here carries quite a bit of weight:? the required 
advances in *both* conventional and quantum computing are uncertain.


-- Jacob




From jcb62281 at gmail.com  Tue Apr 14 06:13:10 2026
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Mon, 13 Apr 2026 23:13:10 -0500
Subject: Plans for Post-Quantum Cryptography in GnuPG
In-Reply-To: <f4a35154-07ce-4a41-97f6-c750318382e1@sixdemonbag.org>
References: <CALVR1Mfd6037snU8Z=0FBacs3btMddYNswAz2CQLa4Czsy7yvQ@mail.gmail.com>
 <fc8a27bd-36bf-4d06-a05d-da212f2d77a0@sixdemonbag.org>
 <dcddd516-6e60-474b-971d-c02d32945f61@gmail.com>
 <f4a35154-07ce-4a41-97f6-c750318382e1@sixdemonbag.org>
Message-ID: <bdbd2be2-a54a-45a7-a913-967941fc9a3c@gmail.com>

On 4/13/26 03:13, Robert J. Hansen wrote:
>> This is a serious problem:? recent developments suggest that 256-bit 
>> EC cryptosystems might not last much longer
>
> "Might" and "much not" are vague things. Better to say something 
> concrete, like "the US government has informed its suppliers and 
> contractors they must use PQC signatures for firmware and software 
> starting in 2030. Communications can be secured via ECC until 2033."
>
> We have between four and seven years to transition. Let's talk calmly 
> about our smooth, responsible migrations, not scare people into doing 
> it quickly with vague talk about how ECC might not be around much longer.
>
> Smooth is slow. Slow is fast.

Agreed.

>> and here we find that PQC signature algorithms are not ready yet.
>
> NIST FIPS 204 specifying CRYSTALS was published in 2024, so *a* 
> specification exists: but as with all specs, the first release had 
> errors. NIST is tracking these errors in a publicly viewable 
> spreadsheet. They're emphatic that "[p]otential corrections DO NOT 
> introduce new technical requirements", but it's pretty clear that soon 
> a new draft of FIPS 204 will be released incorporating this errata.
>
> All the correct information exists: it's just not yet all in one 
> master document.

This is good news, at least.

>> Perhaps we should just bite the proverbial bullet and roll out 
>> RSA-16384 signatures as an interim measure? Possibly as a 
>> RSA-16384/PQC hybrid cryptosystem?
>
> Hard no. This is a terrible idea. You can have Werner and g10 Code 
> working on implementing FIPS 204, or you can have them working on 
> this. Delaying Dilithium to get this out as a six-month stopgap which 
> we'd then have to support for 30 years is unwise.

Since we already *have* RSA, I would expect expanding the supported key 
size to be trivial, but Werner and g10 Code know the GPG code base 
better than I do.


-- Jacob



From rjh at sixdemonbag.org  Tue Apr 14 07:57:34 2026
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Tue, 14 Apr 2026 01:57:34 -0400
Subject: Plans for Post-Quantum Cryptography in GnuPG
In-Reply-To: <bdbd2be2-a54a-45a7-a913-967941fc9a3c@gmail.com>
References: <CALVR1Mfd6037snU8Z=0FBacs3btMddYNswAz2CQLa4Czsy7yvQ@mail.gmail.com>
 <fc8a27bd-36bf-4d06-a05d-da212f2d77a0@sixdemonbag.org>
 <dcddd516-6e60-474b-971d-c02d32945f61@gmail.com>
 <f4a35154-07ce-4a41-97f6-c750318382e1@sixdemonbag.org>
 <bdbd2be2-a54a-45a7-a913-967941fc9a3c@gmail.com>
Message-ID: <036ba6b6-ce9e-4553-8370-b58b3fd214ff@sixdemonbag.org>

> Since we already *have* RSA, I would expect expanding the supported key 
> size to be trivial, but Werner and g10 Code know the GPG code base 
> better than I do.

It's not the codebase. It's the support.

Let's say that GnuPG 2.6 comes out with RSA-16k support as a way to 
provide realistic PQC signing today.

What happens to all the GnuPG 2.4 installations out there? Or the 2.2? 
Or the 2.0? Or the 1.4? (Remember, we still regularly see support 
requests for the 1.4 series. Some people really don't want to upgrade.)

"My buddy says he's using an RSA key, he generated it in GnuPG, and my 
own version of GnuPG is rejecting it! GnuPG is awful!"

Then, on top of that, we're still stuck carrying around RSA-16k support 
into the future for thirty years (because some people have realistic 
30-year windows they need their signatures to be good for -- think 
financial contracts, mortgages, and whatnot).

All this, in order to do what, exactly? In a year or so we'll have 
Dilithium in the LibrePGP spec and then we'll have a proper PQC signing 
algorithm. By 2029 it should be in place and ready for users. Then 
Werner says, "ladies and gentlemen, commence the migration plans we 
emphatically recommended you start preparing for in 2026", and in a few 
months everyone who needs PQC signing has it.

Remember, the US Government still says ECC is fine for signatures until 
2030.

So when the migration plan is like this, and everyone believes we'll 
have Dilithium in GA releases of GnuPG by 2029, then what does this 
short-term RSA-16k 'fix' give us except headaches?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260414/83d715d6/attachment.sig>

From rjh at sixdemonbag.org  Tue Apr 14 09:01:22 2026
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Tue, 14 Apr 2026 03:01:22 -0400
Subject: Thoughts on PQC
In-Reply-To: <dfe3f744-45b7-4763-b0bc-76cccc5a29b2@gmail.com>
References: <7cd19ad7-62c7-4ebc-8faf-de67ae8036f8@sixdemonbag.org>
 <377e96cf-8734-401f-a8ba-58527d9b32c5@mail.com>
 <8701e900-66dc-4939-8be9-c18b55d3052d@sixdemonbag.org>
 <b1e3df98-941a-488f-8f2b-13c5da7284ca@mail.com>
 <360b1c88-896e-483f-a50b-6e571d0169fa@sixdemonbag.org>
 <dfe3f744-45b7-4763-b0bc-76cccc5a29b2@gmail.com>
Message-ID: <795937bb-2aa7-49e5-b40c-4268adde5b58@sixdemonbag.org>

> My understanding (based on the "heffalumps" paper) is that past PQC 
> systems have had nasty tendencies to unravel under conventional 
> computing.? You have looked at this much more than I have.? Have we 
> finally found problems that are reliably hard for both quantum and 
> conventional computing?

I have no idea.

What I have heard from the mathematicians I trust is there is good 
reason to believe the learning-with-errors problem in lattice 
cryptography is Just Plain Hard. I have no reason to disbelieve them. 
The discovery of learning-with-errors problems earned Oded Regev a G?del 
prize (theoretical computer science's version of a Nobel; comparable to 
a Turing award). The underlying math appears to be, as you ask, reliably 
hard for both quantum and conventional computing.

But the complexity is mind-boggling. You need a strong undergraduate 
math degree just to understand the language used in the NIST 
publications defining Kyber and Dilithium.

Complex algorithms overwhelmingly tend to be fragile ones.

> How does its performance compare to existing TRNGs?? (Presumably a 
> random quantum circuit would produce random output... or is my ignorance 
> showing and most of them just produce zero or some constant not 
> characteristic of the circuit?)

Quantum random circuits can be thought of as the quantum computing 
analogue of a mathematical random matrix. A matrix is a structured 
collection of numbers: for instance, the simple set of linear equations

	3x + y  = 4
	2x - 3y = 7

... can be expressed as the mathematical matrix

	+-     -+
	| 3 1 4 |
	| 2 3 7 |
	+-     -+

... and then you can do things like Gauss-Jordan elimination to solve 
the matrix, etc. Hey, x = 19/11 and y = -13/11. See that? We did 
something with our matrix. We put it to use.

Well, what if instead of the coefficients of linear equations we put in 
probabilities instead? Instead of "2" in the lower-left corner we put 
something like "60%"? Now we have a matrix that incorporates 
nondeterminism -- randomness -- a random matrix.

Now if instead of "60%" you allow probabilities to be negative as well 
as positive, and to even represent complex numbers, suddenly you're now 
plugging quantum mechanical probability distributions into this 
fantastically useful mathematical tool. And that's the final evolution 
of random matrices.

A good first approximation of "what's a quantum random circuit?" is, "a 
random matrix implemented on a quantum computer." That's all.

My frustration with Google's paper about "look at us! We demonstrated 
quantum supremacy by creating a random quantum circuit and sampling it!" 
is, okay, great, they might have demonstrated a fantastic capability, 
but _what did they do with it_? What was the overall _effect_ of this?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260414/7d241f4f/attachment-0001.sig>

From wk at gnupg.org  Tue Apr 14 10:09:31 2026
From: wk at gnupg.org (Werner Koch)
Date: Tue, 14 Apr 2026 10:09:31 +0200
Subject: Plans for Post-Quantum Cryptography in GnuPG
In-Reply-To: <036ba6b6-ce9e-4553-8370-b58b3fd214ff@sixdemonbag.org> (Robert
 J. Hansen via Gnupg-users's message of "Tue, 14 Apr 2026 01:57:34
 -0400")
References: <CALVR1Mfd6037snU8Z=0FBacs3btMddYNswAz2CQLa4Czsy7yvQ@mail.gmail.com>
 <fc8a27bd-36bf-4d06-a05d-da212f2d77a0@sixdemonbag.org>
 <dcddd516-6e60-474b-971d-c02d32945f61@gmail.com>
 <f4a35154-07ce-4a41-97f6-c750318382e1@sixdemonbag.org>
 <bdbd2be2-a54a-45a7-a913-967941fc9a3c@gmail.com>
 <036ba6b6-ce9e-4553-8370-b58b3fd214ff@sixdemonbag.org>
Message-ID: <87se8yj744.fsf@jacob.g10code.de>

On Tue, 14 Apr 2026 01:57, Robert J. Hansen said:

> What happens to all the GnuPG 2.4 installations out there? Or the 2.2?
> Or the 2.0? Or the 1.4? (Remember, we still regularly see support
> requests for the 1.4 series. Some people really don't want to

They all support large RSA keys.  gpg even has an option
--enable-large-ras which is used at key egeneration time:

  const unsigned maxsize = (opt.flags.large_rsa ? 8192 : 4096);

It is easy to increase to 16k - but pretty please don't do that: it will
make the WoT and general use of signatures very annoying due to the
slowness


Shalom-Salam,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 284 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260414/c4206311/attachment.sig>

From rjh at sixdemonbag.org  Tue Apr 14 13:24:47 2026
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Tue, 14 Apr 2026 07:24:47 -0400
Subject: Plans for Post-Quantum Cryptography in GnuPG
In-Reply-To: <87se8yj744.fsf@jacob.g10code.de>
References: <CALVR1Mfd6037snU8Z=0FBacs3btMddYNswAz2CQLa4Czsy7yvQ@mail.gmail.com>
 <fc8a27bd-36bf-4d06-a05d-da212f2d77a0@sixdemonbag.org>
 <dcddd516-6e60-474b-971d-c02d32945f61@gmail.com>
 <f4a35154-07ce-4a41-97f6-c750318382e1@sixdemonbag.org>
 <bdbd2be2-a54a-45a7-a913-967941fc9a3c@gmail.com>
 <036ba6b6-ce9e-4553-8370-b58b3fd214ff@sixdemonbag.org>
 <87se8yj744.fsf@jacob.g10code.de>
Message-ID: <babc0d71-e230-4fcd-a143-3595ec03eaac@sixdemonbag.org>

> They all support large RSA keys.  gpg even has an option
> --enable-large-ras which is used at key egeneration time:

I stand corrected: thank you!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260414/8b159892/attachment.sig>

From jb-gnumlists at wisemo.com  Tue Apr 14 14:21:13 2026
From: jb-gnumlists at wisemo.com (Jakob Bohm)
Date: Tue, 14 Apr 2026 14:21:13 +0200
Subject: Thoughts on PQC
In-Reply-To: <7cd19ad7-62c7-4ebc-8faf-de67ae8036f8@sixdemonbag.org>
References: <7cd19ad7-62c7-4ebc-8faf-de67ae8036f8@sixdemonbag.org>
Message-ID: <ef6a210b-e5ec-8288-d820-415a8995b1d1@wisemo.com>

On 13/04/2026 18:47, Robert J. Hansen via Gnupg-users wrote:
> ...
> Trinity depended on massive advances in plutonium breeding and 
> enrichment. We had to invent new electrical switches (krytrons) to 
> very precisely send electrical signals to entirely new explosive 
> detonators (exploding bridgewires) embedded in entirely new explosives 
> (castables) that formed complex geometries never before done in 
> explosives (explosive lenses) that required entirely new branches of 
> mathematics to be invented (hydrodynamics). The engineering 
> infrastructure to support the Bomb was *huge*.
>
Actually, krytrons were an existing technology from high speed photography
(they were used to set off flashes to capture images at very precise
times), someone in the project was an expert in high speed photography and
realized their flash photography timer could provide the required timing
of the explosive lens.

Exploding bridgewires was also an existing technology used in "proximity
fuse" secret artillery shells.

Explosive lenses was the existing technology in certain destruction
charges used by special forces and anti-tank weapons.? But to use them at
the speeds needed for the implosion bomb, they needed to be assembled
slightly differently.

 > ...

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded



From jb-gnumlists at wisemo.com  Tue Apr 14 14:28:09 2026
From: jb-gnumlists at wisemo.com (Jakob Bohm)
Date: Tue, 14 Apr 2026 14:28:09 +0200
Subject: Plans for Post-Quantum Cryptography in GnuPG
In-Reply-To: <87zf37kyi4.fsf@jacob.g10code.de>
References: <CALVR1Mfd6037snU8Z=0FBacs3btMddYNswAz2CQLa4Czsy7yvQ@mail.gmail.com>
 <fc8a27bd-36bf-4d06-a05d-da212f2d77a0@sixdemonbag.org>
 <87zf37kyi4.fsf@jacob.g10code.de>
Message-ID: <1f94a976-4a5b-3e76-a161-de4c81b197f8@wisemo.com>

On 13/04/2026 11:20, Werner Koch via Gnupg-users wrote:
> On Sun, 12 Apr 2026 22:37, Robert J. Hansen said:
>
>> IMO, the necessary algorithms for PQC signing/certifying are not yet
>> ready for primetime. Dilithium is obviously the biggest component of a
> Right.  Experience from 30 years showed that deploying a stable and
> secure signing system is much more challenging than an encryption
> system.  Given that the claimed threat is store-now-maybe-decrypt-later
> the deployment of signatures is not yet not needed.
Another threat based on similar use of time as an attack tool is to
"fake signature later and pretend it is a long term contract signed
25 years earlier"

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded



From rjh at sixdemonbag.org  Tue Apr 14 14:49:12 2026
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Tue, 14 Apr 2026 08:49:12 -0400
Subject: Thoughts on PQC
In-Reply-To: <ef6a210b-e5ec-8288-d820-415a8995b1d1@wisemo.com>
References: <7cd19ad7-62c7-4ebc-8faf-de67ae8036f8@sixdemonbag.org>
 <ef6a210b-e5ec-8288-d820-415a8995b1d1@wisemo.com>
Message-ID: <18ec8344-1c9c-4747-bf87-02fe27a0e8c4@sixdemonbag.org>

> Actually, krytrons were an existing technology from high speed photography

According to the sources I've seen they were descended from military 
thyratrons, and were unknown prior to the mid-1940s. Wikipedia says they 
originated as one of the first products of the EG&G Corporation, 
established in 1947.

> Exploding bridgewires was also an existing technology used in "proximity
> fuse" secret artillery shells.

According to John Coster-Mullens' excellent _Atom Bombs: The Top Secret 
Inside Story of Little Boy and Fat Man_, EBWs were invented by future 
Nobel laureate Luis Alvarez and Lawrence Johnston specifically for use 
in early implosion weapons.

> Explosive lenses was the existing technology in certain destruction
> charges used by special forces and anti-tank weapons.

The first patent on explosive lenses is credited to John von Neumann, 
James Tuck, and Seth Neddermeyer.

Tuck's declassified CV from Los Alamos credits him as having devised the 
explosive lens in 1944.

https://ahf.nuclearmuseum.org/wp-content/uploads/2015/04/JamesTuck%20-%20C.V.pdf

Looking over Wikipedia's page on explosive lenses, no mention is made of 
its use in antitank weapons or demolition charges.

If you have contradictory sources I'd be happy to hear of it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260414/5dff7170/attachment.sig>

From rjh at sixdemonbag.org  Tue Apr 14 14:56:51 2026
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Tue, 14 Apr 2026 08:56:51 -0400
Subject: Plans for Post-Quantum Cryptography in GnuPG
In-Reply-To: <1f94a976-4a5b-3e76-a161-de4c81b197f8@wisemo.com>
References: <CALVR1Mfd6037snU8Z=0FBacs3btMddYNswAz2CQLa4Czsy7yvQ@mail.gmail.com>
 <fc8a27bd-36bf-4d06-a05d-da212f2d77a0@sixdemonbag.org>
 <87zf37kyi4.fsf@jacob.g10code.de>
 <1f94a976-4a5b-3e76-a161-de4c81b197f8@wisemo.com>
Message-ID: <082b3141-f95e-4314-8a0f-3e26e3555322@sixdemonbag.org>

> Another threat based on similar use of time as an attack tool is to
> "fake signature later and pretend it is a long term contract signed
> 25 years earlier"

This is not a serious threat.

"Your Honor, there is no evidence in the historical record to support 
the claim this contract was entered into. None. We request discovery on 
plaintiff's computers and accounts. Our digital forensics nerds will get 
to the bottom of this. With the fact the algorithm used to allegedly 
sign this contract a quarter-century ago can be trivially forged today, 
we repudiate the signature, allege there has been fraud on this court, 
and ask the court to get involved."

Lawyers repudiate forged documents all the time. They're pretty good at it.



From rjh at sixdemonbag.org  Tue Apr 14 15:09:28 2026
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Tue, 14 Apr 2026 09:09:28 -0400
Subject: Thoughts on PQC
In-Reply-To: <CAF5O_jzJkP6UnuSCDpf=e7ca-7vBZV84a_aZo6HSQZ8aMjRL6Q@mail.gmail.com>
References: <7cd19ad7-62c7-4ebc-8faf-de67ae8036f8@sixdemonbag.org>
 <377e96cf-8734-401f-a8ba-58527d9b32c5@mail.com>
 <CAF5O_jzJkP6UnuSCDpf=e7ca-7vBZV84a_aZo6HSQZ8aMjRL6Q@mail.gmail.com>
Message-ID: <9fff7c12-75de-4ca0-82b2-e9b04bec435e@sixdemonbag.org>

> the math or science behind his claims. His old FAQ on sixdemonbag was
> a complete eye-opener for anyone who understood basic physics and
> algebra.
I still have it, incidentally. Last updated in 2009, so it's a 
historical curiosity. Maybe I should see about restoring it...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260414/c0c1cb15/attachment-0001.sig>

From bwalzer at 59.ca  Tue Apr 14 16:47:32 2026
From: bwalzer at 59.ca (Bruce Walzer)
Date: Tue, 14 Apr 2026 09:47:32 -0500
Subject: Post-quantum defaults
Message-ID: <ad5ThAKpMYPPr_DM@ohm.59.ca>

On Tue Apr 7 00:59:44 CEST 2026, Bruce Walzer via Gnupg-users wrote:

> There seem to be two papers that have sparked the recent
> excitement. One involves boring old superconducting qubits. AFAIK,
> it assumes a significant improvement in noise performance to
> work. So the fact that it uses less qubits isn't very interesting in
> the absence of increased noise performance. Impossible is still
> impossible.

> The other one involves something called neutral atoms. This
> technology has better noise performance. But it is a different
> technology. It appears that we don't know how to run a relevant
> algorithm on it at this time in a useful way. The paper refers to
> "engineering challenges". So I think this is the one to pay
> attention to in the next few months. We need to wait for comments
> from knowledgeable critics.

Dunno how knowledgeable this this critic that posted on Twitter is:

* https://nitter.net/bergealex4/status/2038908698915926516

... but they do bring up a relevent point about entanglement performance from the neutral atom technology. The paper says:

> By rastering the beam dynamically to increase the active duty cycle,
> the number of atoms that can be addressed and entangled at high
> fidelity could thus be directly increased by three orders of
> magnitude. Although integrating these capabilities at larger scales
> requires substantial development effort, they appear to be mutually
> compatible, such that an appropriately designed architecture could
> realize the functionality illustrated in Fig. 1a.

For superconducting qubits the noise performance needs to be increased
1-2 orders of magnetite to enter the realm of the possible. Dunno if
entanglement capability comes in on top of that to do Shor's.

So both papers describe an impossible world and don't help for
planning a post quantum encryption rollout. That would change in the
event someone invents suitable hardware based on some fundamentual
breaktrhough in physics. Then we would have some idea of the extra effort required on the algorithm side of the problem. 

Bruce


From wk at gnupg.org  Tue Apr 21 12:28:09 2026
From: wk at gnupg.org (Werner Koch)
Date: Tue, 21 Apr 2026 12:28:09 +0200
Subject: [Announce] [Security fixes] Libgcrypt 1.12.2, 1.11.3, 1.10.x released
Message-ID: <87jyu038w6.fsf@jacob.g10code.de>

Hello!

We are pleased to announce the availability of couple of new Libgcrypt
versions: 1.12.2, 1.11.3, and 1.10.4 .  It is suggested to use 1.12.2
which is fully compatible with all earlier versions.

This version fixes a security bug [T8211] which can be used used to
mount a DoS using ECDH encryption (with NIST, Brainpool, X448, or X25519
curves).  Note that GnuPG versions since 2.5.7 are not affected by this
bug due to the use of a different encryption API.

Another security bug [T8208] was fixed in the Dilithium signing
algorithm which is available since version 1.12.0.


Noteworthy changes in version 1.12.2 (2026-04-15)
====================================

 * Bug fixes:

   - Fix possible ECDH buffer overwrite with zeroes.  [T8211]

   - Add a missing bounds check to the Dilithium context handling.
     Reported by Calif.io in collaboration with Claude and Anthropic
     Research.  [T8208]

   - Add point validation when using the new KEM interface.  [T8212]

 * Other:

   - Fix the dead-code of stronger_key_check for RSA.  [T8171]

 For a list of links to commits and bug numbers see the release info at
 https://dev.gnupg.org/T8114 .  However, due to an ongoing AI scraper
 DDoS the site might not be reachable at all times or from all IPs.


Noteworthy changes in version 1.11.3 (2026-04-21)
====================================

 * Bug fixes:

   - Fix possible ECDH buffer overwrite with zeroes.  [T8211]

   - Add point validation when using the new KEM interface.  [T8212]

   - Fix compiler error on NetBSD.  [T7633]

   - mceliece6688128f: Fix stack overflow crash on win64/wine
     [rCb17ed8d1af]

   - Apply a Kyber patch from upstream.  [rC5ba143d51f]

   - Use CSIDL_COMMON_APPDATA instead of /etc on Windows.  [rC995b870fd2]

   - Use secure MPI in _gcry_mpi_assign_limb_space.  [rC520c699c82]

   - Fix a regression with disabled public-key algo for FIPS.
     [T7338,rCc6e0658004]

 * Other:

   - Handle HAVE_BROKEN_MLOCK for the case of building with ASAN.
     [T7889]

   - Add stack burning for PQC algorithms.  [rC289c0a596f]

 Release-info: https://dev.gnupg.org/T8232


Noteworthy changes in version 1.10.4 (2026-04-21)
====================================

 NOTE: The 1.10 series reaches end-of-life in 6 weeks.

 * Bug fixes:

   - Fix possible ECDH buffer overwrite with zeroes.  [T8211]

   - Fix AESWRAP padding length check.  [T7130]

 * Other:

   - Handle HAVE_BROKEN_MLOCK for the case of building with ASAN.
     [T7889]

 Release-info: https://dev.gnupg.org/T8233



Download
========

Source code is hosted at the GnuPG FTP server and its mirrors as listed
at https://gnupg.org/download/mirrors.html.  On the primary server
the source tarball and its digital signature are:

 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.12.2.tar.bz2
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.12.2.tar.bz2.sig
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.11.3.tar.bz2
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.11.3.tar.bz2.sig
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.10.4.tar.bz2
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.10.4.tar.bz2.sig

or gzip compressed:

 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.12.2.tar.gz
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.12.2.tar.gz.sig
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.11.3.tar.gz
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.11.3.tar.gz.sig
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.10.4.tar.gz
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.10.4.tar.gz.sig

In order to check that the version of Libgcrypt you downloaded is an
original and unmodified file please follow the instructions found at
https://gnupg.org/download/integrity_check.html.  In short, you may
use one of the following methods:

 - Check the supplied OpenPGP signature.  For example to check the
   signature of the file libgcrypt-1.12.2.tar.bz2 you would use this
   command:

     gpg --verify libgcrypt-1.12.2.tar.bz2.sig libgcrypt-1.12.2.tar.bz2

   This checks whether the signature file matches the source file.
   You should see a message indicating that the signature is good and
   made by one or more of the release signing keys.  Make sure that
   this is a valid key, either by matching the shown fingerprint
   against a trustworthy list of valid release signing keys or by
   checking that the key has been signed by trustworthy other keys.
   See the end of this mail for information on the signing keys.

 - If you are not able to use an existing version of GnuPG, you have
   to verify the SHA-1 checksum.  On Unix systems the command to do
   this is either "sha1sum" or "shasum".  Assuming you downloaded the
   file libgcrypt-1.12.2.tar.bz2, you run the command like this:

     sha1sum libgcrypt-1.12.2.tar.bz2

   and check that the output matches the first line from the
   this list:

7b8ff21966a0b6e7a735466b9b9b55d9dac9fa87  libgcrypt-1.12.2.tar.bz2
a1b1d5561e7b743e7e4460a49015053da1901124  libgcrypt-1.12.2.tar.gz
d252f6b0a62fcacb8f82bcb61440b25d698a0a05  libgcrypt-1.11.3.tar.bz2
a89b597965a76bfbe0ad11e3d6153c3709c0b07e  libgcrypt-1.11.3.tar.gz
d824efa873ac210e84573564df4a99f4cd5cdf77  libgcrypt-1.10.4.tar.bz2
5a5bb8d4dd69a2c7828dbf31b12df5e21e604971  libgcrypt-1.10.4.tar.gz

   You should also verify that the checksums above are authentic by
   matching them with copies of this announcement.  Those copies can be
   found at other mailing lists, web sites, and search engines.


Copying
=======

Libgcrypt is distributed under the terms of the GNU Lesser General
Public License (LGPLv2.1+).  The helper programs as well as the
documentation are distributed under the terms of the GNU General Public
License (GPLv2+).  The file LICENSES has notices about contributions
that require that these additional notices are distributed.


Support
=======

For help on developing with Libgcrypt you should read the included
manual and if needed ask on the gcrypt-devel mailing list.

In case of problems specific to this release please first check
https://dev.gnupg.org/T8114 for updated information.

Please also consult the archive of the gcrypt-devel mailing list before
reporting a bug: https://gnupg.org/documentation/mailing-lists.html .
We suggest to send bug reports for a new release to this list in favor
of filing a bug at https://bugs.gnupg.org.  If you need commercial
support go to https://gnupg.com or https://gnupg.org/service.html .

Please see https://gnupg.org/documentation/security.html for information
on how to report security issues and for our threat model.

If you are a developer and you need a certain feature for your project,
please do not hesitate to bring it to the gcrypt-devel mailing list for
discussion.


Thanks
======

Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH
and has mostly been financed by donations.  Several full-time employed
developers and contractors are working exclusively on GnuPG and closely
related software like Libgcrypt, GPGME, Kleopatra and Gpg4win.

Fortunately, and this is still not common with free software, we have
now established a way of financing the development while keeping all our
software free and freely available for everyone.  Our model is similar
to the way RedHat manages RHEL and Fedora: Except for the actual binary
of the MSI installer for Windows and client specific configuration
files, all the software is available under the GNU GPL and other Open
Source licenses.  Thus customers may even build and distribute their own
version of the software as long as they do not use our trademarks
GnuPG Desktop? or GnuPG VS-Desktop?.

We like to thank all the nice people who are helping the GnuPG project,
be it testing, coding, translating, suggesting, auditing, administering
the servers, spreading the word, answering questions on the mailing
lists, or helping with donations.

*Thank you all*

   Your Libgcrypt hackers



p.s.
This is an announcement only mailing list.  Please send replies only to
the gcrypt-devel'at'gnupg.org mailing list.

* List of Release Signing Keys:
  To guarantee that a downloaded version has not been tampered by
  malicious entities we provide signature files for all tarballs and
  binary versions.  The keys are also signed by the long term keys of
  their respective owners.  Current releases are signed by one or more
  of these five keys:

    ed25519 2020-08-24 [SC] [expires: 2030-06-30]
    6DAA 6E64 A76D 2840 571B  4902 5288 97B8 2640 3ADA
    Werner Koch (dist signing 2020)

    ed25519 2021-05-19 [SC] [expires: 2027-04-04]
    AC8E 115B F73E 2D8D 47FA  9908 E98E 9B2D 19C6 C8BD
    Niibe Yutaka (GnuPG Release Key)

    rsa3072 2025-05-09 [SC] [expires: 2033-03-03]
    3B76 1AE4 E63B F351 9CE7  D63B ECB6 64CB E133 2EEF
    Alexander Kulbartsch (GnuPG Release Key)

    brainpoolP256r1 2021-10-15 [SC] [expires: 2029-12-31]
    02F3 8DFF 731F F97C B039  A1DA 549E 695E 905B A208
    GnuPG.com (Release Signing Key 2021)

    brainpoolP384r1 2026-02-23 [SC] [expires: 2034-02-23]
    1493 269D E61F 124A A69A  316E 3ADF 34EB DBB2 00A4
    GnuPG.com (Release Signing Key 2026)

  The keys are available at https://gnupg.org/signature_key.html and in
  any recently released GnuPG tarball in the file g10/distsigkey.gpg .
  Note that this mail has been signed by a different key.

* Debian Package Signing Key:
  The new Debian style packages are signed using this key:

    ed25519 2025-07-08 [SC] [expires: 2035-07-14]
    3209 7B71 9B37 45D6 E61D DA1B 85C4 5AE3 E1A2 B355
    GnuPG.org Package Signing Key <package-maintainers at gnupg.org>

  See the package website (https://repos.gnupg.org/deb/gnupg) for a list
  of supported distributions and a download link for the key.

--
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 284 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260421/6f5f78b8/attachment.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From wk at gnupg.org  Fri Apr 24 13:52:45 2026
From: wk at gnupg.org (Werner Koch)
Date: Fri, 24 Apr 2026 13:52:45 +0200
Subject: [Announce] GnuPG 2.5.19 released
Message-ID: <87o6j8zib6.fsf@jacob.g10code.de>

Hello!

We are pleased to announce the availability of a new GnuPG release:
Version 2.5.19.  This release adds a few new features and fixes a
couple of bugs.

The main features in the 2.5 series are improvements for 64 bit Windows
and the introduction of Kyber (aka ML-KEM or FIPS-203) as PQC encryption
algorithm.  Other than PQC support the 2.6 series will not differ a lot
from 2.4 because the majority of changes are internal to make use of
newer features from the supporting libraries.

Note that the old 2.4 series reaches end-of-life in just two months.
Thus update to 2.5.19 in time.  As always with GnuPG new versions are
fully compatible with previous versions.


What is GnuPG
=============

The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation
of the OpenPGP and S/MIME standards.

GnuPG allows to encrypt and sign data and communication, features a
versatile key management system as well as access modules for public key
directories.  GnuPG itself is a command line tool with features for easy
integration with other applications.  The separate library GPGME provides
a uniform API to use the GnuPG engine by software written in common
programming languages.  A wealth of frontend applications and libraries
making use of GnuPG are available.  As an universal crypto engine GnuPG
provides support for S/MIME and Secure Shell in addition to OpenPGP.

GnuPG is Free Software (meaning that it respects your freedom).  It can
be freely used, modified and distributed under the terms of the GNU
General Public License.


Noteworthy changes in version 2.5.19 (2026-04-24)
=================================================
         [compared to version 2.5.18]
         
 * New and extended features:

   - gpg: New option --use-ocb-sym.  [rGccdcdfbb37]

   - gpg: New options --show-[only-]session-hash.  [rGecd0f7afa1]

   - gpgsm: Allow cipher mode to be part of the algo given to the
     --cipher-algo option.  [T3979]

   - gpgsm: Emit more details when failing to check a crlDP.  [T8221]

   - agent: Improve pinentry behavior and texts in smartcard context.
     [T6425]

   - dirmngr: New keyword "clear" for --keyserver.  [rG2ab4cba36c]

 * Bug fixes:

   - gpg: Fix edge case in --refresh-keys.  [T8197]

   - gpg: Don't call gcry_kdf_derive with empty passphrase.  [T7739]

   - gpgsm: Skip the optional PKCS#12 PBES2 keyLength parameter to
     allow import of recently issued certificates by the German
     Telekom.  [rGc8c9604bba]

   - gpgsm: Fix a bug so that a certificate can be signed using a
     different algo.  [rG66fdafab3c]

   - gpgsm: Make GCM fully compliant in de-vs mode.  [rG04fd775fce]

   - gpgsm: Add a certificate chain check for de-vs compliance.
     [T8188]

   - gpgsm: Show rsaPSS certificates as de-vs compliant in listings.
     [T8222]

   - agent: Rework the trustlist reading code to finally allow a
     trustlist.txt with a missing trailing LF.  [T8078]

   - ssh: Fix RSA padding in signature handling.  [T7882,T8202]

   - gpgtar: Fix -C (--directory) to check the output directory.
     [T8159]

 * Other changes:

   - agent: Raise an error when p >= q for RSA keys to detect
     incorrect generated *PGP keys.  [T8171]

 Release-info: https://dev.gnupg.org/T7998



Getting the Software
====================

Please follow the instructions found at <https://gnupg.org/download/> or
read on:

GnuPG may be downloaded from one of the GnuPG mirror sites or direct
from its primary file server.  The list of mirrors can be found at
<https://gnupg.org/download/mirrors.html>.  Note that GnuPG is not
available at ftp.gnu.org.

The GnuPG source code compressed using BZIP2 and its OpenPGP signature
are available here:

 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.19.tar.bz2 (8127k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.19.tar.bz2.sig

An installer for Windows without any graphical frontend except for a
very minimal Pinentry tool is available here:

 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.19_20260424.exe (5627k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.19_20260424.exe.sig

The source used to build this installer for 64-bit Windows is available as

 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.19_20260424.tar.xz (15M)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.19_20260424.tar.xz.sig

This source tarball may also be used to download all required libraries
at once to build a Unix version on any modern system.  See the included
README.


Debian Packages
===============

We also provide Debian style packages for a couple of Debian variants.
See https://repos.gnupg.org/deb/gnupg/trixie/ or use the menu to switch
to other distros/releases.  If you encounter packaging problems please
report them to the gnupg-devel mailing list.  Due to the holidays it may
take a few days until the packages are available.


Windows Installer
=================

A new Version of Gpg4win is in planning.  For those who are affected by
one of the now fixed bugs, it is possible to install the simple Windows
installer mentioned above on top of gpg4win 5.0.1.


Checking the Integrity
======================

In order to check that the version of GnuPG which you are going to
install is an original and unmodified one, you can do it in one of
the following ways:

 * If you already have a version of GnuPG installed, you can simply
   verify the supplied signature.  For example to verify the signature
   of the file gnupg-2.5.19.tar.bz2 you would use this command:

     gpg --verify gnupg-2.5.19.tar.bz2.sig gnupg-2.5.19.tar.bz2

   This checks whether the signature file matches the source file.
   You should see a message indicating that the signature is good and
   made by one or more of the release signing keys.  Make sure that
   this is a valid key, either by matching the shown fingerprint
   against a trustworthy list of valid release signing keys or by
   checking that the key has been signed by trustworthy other keys.
   See the end of this mail for information on the signing keys.

 * If you are not able to use an existing version of GnuPG, you have
   to verify the SHA-1 checksum.  On Unix systems the command to do
   this is either "sha1sum" or "shasum".  Assuming you downloaded the
   file gnupg-2.5.19.tar.bz2, you run the command like this:

     sha1sum gnupg-2.5.19.tar.bz2

   and check that the output matches the next line:

dbe9ce2aca9d553ed4367692575cee15204a95a6  gnupg-2.5.19.tar.bz2
e4de189d1310893b2f8e565781d25093944b883e  gnupg-w32-2.5.19_20260424.tar.xz
a2b9b2d0ad979209e1c74f28ff910ce6f97f0e41  gnupg-w32-2.5.19_20260424.exe


Internationalization
====================

This version of GnuPG has support for 26 languages with Chinese, Czech,
Dutch, French, Georgian, German, Italian, Japanese, Norwegian, Polish,
Portuguese, Russian, Turkish, and Ukrainian being almost completely
translated.


Documentation and Support
=========================

The file gnupg.info has the complete reference manual of the system.
Separate man pages are included as well but they miss some of the
details available only in the manual.  The manual is also available
online at

  https://gnupg.org/documentation/manuals/gnupg/

or can be downloaded as PDF at

  https://gnupg.org/documentation/manuals/gnupg.pdf

You may also want to search the GnuPG mailing list archives or ask on
the gnupg-users mailing list for advise on how to solve problems.  Most
of the new features are around for several years and thus enough public
experience is available.  https://wiki.gnupg.org has user contributed
information around GnuPG and relate software.

If you are using cleartext signatures in your application please read
https://gnupg.org/blog/20251226-cleartext-signatures.html and maybe
https://gnupg.com/20260122-39C3_reply_gpg_fail.html

In case of build problems specific to this release please first check
https://dev.gnupg.org/T7998 for updated information.  We are sorry that
due to ongoing DoS on this service, you may end up at a "is under
maintenance page".

Please consult the archive of the gnupg-users mailing list before
reporting a bug: https://gnupg.org/documentation/mailing-lists.html.
We suggest to send bug reports for a new release to this list in favor
of filing a bug at https://bugs.gnupg.org.  If you need commercial
support go to https://gnupg.com or https://gnupg.org/service.html.

If you are a developer and you need a certain feature for your project,
please do not hesitate to bring it to the gnupg-devel mailing list for
discussion.


Thanks
======

Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH
and has mostly been financed by donations.  A team of full-time employed
developers and contractors are working exclusively on GnuPG and related
software like Libgcrypt, GPGME, Kleopatra, Okular, and Gpg4win.

Fortunately, and this is still not common with free software, we have
established a way of financing the development while keeping all our
software free and freely available for everyone.  Our model is similar
to the way RedHat manages RHEL and Fedora: Except for the actual binary
of the MSI installer for Windows and client specific configuration
files, all the software is available under the GNU GPL and other Open
Source licenses.  Thus customers may even build and distribute their own
version of the software as long as they do not use our trademarks
GnuPG Desktop? or GnuPG VS-Desktop?.

We like to thank all the nice people who are helping the GnuPG project,
be it testing, coding, translating, suggesting, auditing, administering
the servers, spreading the word, answering questions on the mailing
lists, or helped with donations.

*Thank you all*

   Your GnuPG hackers


p.s.
This is an announcement only mailing list.  Please send replies only to
the gnupg-users at gnupg.org mailing list.

* Debian Package Signing Key:
  The new Debian style packages are signed using this key:

  ed25519 2025-07-08 [SC] [expires: 2035-07-14]
  3209 7B71 9B37 45D6 E61D DA1B 85C4 5AE3 E1A2 B355
  GnuPG.org Package Signing Key <package-maintainers at gnupg.org>

  See the package website (https://repos.gnupg.org/deb/gnupg) for a list
  of supported distributions and a download link for the key.

* List of Release Signing Keys:
  To guarantee that a downloaded version has not been tampered by
  malicious entities we provide signature files for all tarballs and
  binary versions.  The keys are also signed by the long term keys of
  their respective owners.  Current releases are signed by one or more
  of these five keys:

    ed25519 2020-08-24 [SC] [expires: 2030-06-30]
    6DAA 6E64 A76D 2840 571B  4902 5288 97B8 2640 3ADA
    Werner Koch (dist signing 2020)

    ed25519 2021-05-19 [SC] [expires: 2027-04-04]
    AC8E 115B F73E 2D8D 47FA  9908 E98E 9B2D 19C6 C8BD
    Niibe Yutaka (GnuPG Release Key)

    rsa3072 2025-05-09 [SC] [expires: 2033-03-03]
    3B76 1AE4 E63B F351 9CE7  D63B ECB6 64CB E133 2EEF
    Alexander Kulbartsch (GnuPG Release Key)

    brainpoolP256r1 2021-10-15 [SC] [expires: 2029-12-31]
    02F3 8DFF 731F F97C B039  A1DA 549E 695E 905B A208
    GnuPG.com (Release Signing Key 2021)

    brainpoolP384r1 2026-02-23 [SC] [expires: 2034-02-23]
    1493 269D E61F 124A A69A  316E 3ADF 34EB DBB2 00A4
    GnuPG.com (Release Signing Key 2026)

  The keys are available at https://gnupg.org/signature_key.html and in
  any recently released GnuPG tarball in the file g10/distsigkey.gpg .
  Note that this mail has been signed by a different key.

* Debian Package Signing Key:
  The new Debian style packages are signed using this key:

    ed25519 2025-07-08 [SC] [expires: 2035-07-14]
    3209 7B71 9B37 45D6 E61D DA1B 85C4 5AE3 E1A2 B355
    GnuPG.org Package Signing Key <package-maintainers at gnupg.org>

  See the package website (https://repos.gnupg.org/deb/gnupg) for a list
  of supported distributions and a download link for the key.

-- 
Arguing that you don't care about the right to privacy because you have
nothing to hide is no different from saying you don't care about free
speech because you have nothing to say.                - Edward Snowden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 284 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260424/02ad5758/attachment-0001.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From johanw at vulcan.xs4all.nl  Sun Apr 26 20:40:58 2026
From: johanw at vulcan.xs4all.nl (Johan Wevers)
Date: Sun, 26 Apr 2026 20:40:58 +0200
Subject: Post-quantum defaults
In-Reply-To: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org>
References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org>
Message-ID: <e7c6e6ff-bd41-1891-cc58-09196c2ed795@vulcan.xs4all.nl>

On 2026-04-06 21:54, Robert J. Hansen via Gnupg-users wrote:

> It is probably wise to begin deploying post-quantum cryptography. Are
> there any plans in GnuPG to make post-quantum algorithms the default for
> new certificates?

Considering the fact that those algorithms are not as well studied as
the classical asymetric algorithms and already some flaws have been
found I would prefer not to do that, but use 2 algorithms, 1 quantum
resistant and 1 classical, combined.

-- 
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html


From rjh at sixdemonbag.org  Sun Apr 26 23:31:05 2026
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Sun, 26 Apr 2026 17:31:05 -0400
Subject: Post-quantum defaults
In-Reply-To: <e7c6e6ff-bd41-1891-cc58-09196c2ed795@vulcan.xs4all.nl>
References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org>
 <e7c6e6ff-bd41-1891-cc58-09196c2ed795@vulcan.xs4all.nl>
Message-ID: <42fb3889-4f00-4296-b856-ddaf3996f4c9@sixdemonbag.org>

> Considering the fact that those algorithms are not as well studied as
> the classical asymetric algorithms and already some flaws have been
> found I would prefer not to do that, but use 2 algorithms, 1 quantum
> resistant and 1 classical, combined.
This has been discussed at length before. It is not something LibrePGP 
will be adopting on its own. LibrePGP does not innovate with new 
cryptosystems. It only uses vetted, peer-reviewed methods.

If NIST or other similar groups worldwide decide to adopt layered PQC 
then LibrePGP might adopt these (as yet non-existent) new standards.

If this is something you want, might I suggest talking to NIST?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260426/7efc9219/attachment.sig>

From wk at gnupg.org  Mon Apr 27 09:17:11 2026
From: wk at gnupg.org (Werner Koch)
Date: Mon, 27 Apr 2026 09:17:11 +0200
Subject: Post-quantum defaults
In-Reply-To: <e7c6e6ff-bd41-1891-cc58-09196c2ed795@vulcan.xs4all.nl> (Johan
 Wevers via Gnupg-users's message of "Sun, 26 Apr 2026 20:40:58 +0200")
References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org>
 <e7c6e6ff-bd41-1891-cc58-09196c2ed795@vulcan.xs4all.nl>
Message-ID: <87zf2oyirs.fsf@jacob.g10code.de>

On Sun, 26 Apr 2026 20:40, Johan Wevers said:
> the classical asymetric algorithms and already some flaws have been
> found I would prefer not to do that, but use 2 algorithms, 1 quantum
> resistant and 1 classical, combined.

That is what we actually implemented.  The concrete format is based on a
paper and project by the BSI.  The important part from the paper and
prototype project the key-combiner algorithm.  What we changed in
LibrePGP was to replace the way the PGP algorithm ids are assigned to
match how this has always been handled in PGP. The LibrePGP spec is also
easier to read for an implementer as it drops all unneeded theoretical
descriptions.


Salam-Shalom,

   Werner



p.s.

KEM Key Combiner

   For the composite KEM schemes the following procedure MUST be used to
   compute the KEK that wraps a session key.  The construction is a one-
   step key derivation function compliant to [SP800-56C] Section 4,
   based on KMAC256 [SP800-185] and approved by [SP800-227]
   Section 4.6.2.  It is given by the following algorithm:

   multiKeyCombine (eccKeyShare, eccCipherText,
                    mlkemKeyShare, mlkemCipherText,
                    fixedInfo, oBits)

   Input:
   eccKeyShare     - the ECC key share encoded as an octet string
   eccCipherText   - the ECC ciphertext encoded as an octet string
   mlkemKeyShare   - the ML-KEM key share encoded as an octet string
   mlkemCipherText - the ML-KEM ciphertext encoded as an octet string
   fixedInfo       - the fixed information octet string (see below)
   oBits           - the size of the output keying material in bits

   Constants:
   domSeparation       - the UTF-8 encoding of the string
                         "OpenPGPCompositeKeyDerivationFunction"
   counter             - the four-octet big-endian value 0x00000001
   customizationString - the UTF-8 encoding of the string "KDF"

   eccData = eccKeyShare || eccCipherText
   mlkemData = mlkemKeyShare || mlkemCipherText
   encData = counter || eccData || mlkemData || fixedInfo

   result = KMAC256 (domSeparation, encData, oBits, customizationString)

   The fixedinfo is used to provide a binding between the KEK and the
   communication parties.  It is the concatenation of

   *  A one octet algorithm ID describing the symmetric algorithm used
      for the bulk data in the in the SEIPD (packet 18) or the OCBED
      (packet 20).

   *  The 32 octet version 5 fingerprint of the public key.  Note that
      the fingerprint covers the packet format and all other parameters
      of the public key.


-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 284 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260427/7f68725b/attachment.sig>

From andrewg at andrewg.com  Mon Apr 27 10:38:06 2026
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Mon, 27 Apr 2026 09:38:06 +0100
Subject: Post-quantum defaults
In-Reply-To: <87zf2oyirs.fsf@jacob.g10code.de>
References: <87zf2oyirs.fsf@jacob.g10code.de>
Message-ID: <7CC82859-968B-450B-9673-5EAD7BD08B31@andrewg.com>

An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260427/43605c53/attachment.html>

From andrewg at andrewg.com  Mon Apr 27 10:45:55 2026
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Mon, 27 Apr 2026 09:45:55 +0100
Subject: Post-quantum defaults
In-Reply-To: <87zf2oyirs.fsf@jacob.g10code.de>
References: <87zf2oyirs.fsf@jacob.g10code.de>
Message-ID: <DC913F9A-7859-4773-9AC5-B7044EFDACAB@andrewg.com>

An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260427/6fa7b45e/attachment-0001.html>

From andrewg at andrewg.com  Mon Apr 27 11:27:10 2026
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Mon, 27 Apr 2026 10:27:10 +0100
Subject: Post-quantum defaults
In-Reply-To: <87zf2oyirs.fsf@jacob.g10code.de>
References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org>
 <e7c6e6ff-bd41-1891-cc58-09196c2ed795@vulcan.xs4all.nl>
 <87zf2oyirs.fsf@jacob.g10code.de>
Message-ID: <9f0252f7-c907-4f22-a2f8-185f1381ce40@andrewg.com>

Apologies for the triple post, I had trouble forcing apple mail to send 
non-HTML mail. Thunderbird to the rescue! :-D

On 27 Apr 2026, at 08:14, Werner Koch via Gnupg-users 
<gnupg-users at gnupg.org> wrote:
 >
 > The concrete format is based on a
 > paper and project by the BSI.

It?s more than a ?paper and project?, it?s due to be published as an RFC 
any day now, and is widely implemented (by everyone else).

 > The important part from the paper and
 > prototype project the key-combiner algorithm.  What we changed in
 > LibrePGP was to replace the way the PGP algorithm ids are assigned to
 > match how this has always been handled in PGP.

That?s not quite true, there are also differences in the fixedinfo and 
the order of inputs to the KEM combiner (see below) - but I find it 
fascinating that the algorithm numbering convention is the detail you 
highlight. Is it really that important?

 > The LibrePGP spec is also
 > easier to read for an implementer as it drops all unneeded theoretical
 > descriptions.

The other implementers didn?t seem to mind. :-)

 > p.s.
 >
 > KEM Key Combiner

For comparison, the equivalent section in the forthcoming RFC can be 
found at 
https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-pqc#section-4.2.1 :


~~~
KEK = SHA3-256(
           mlkemKeyShare || ecdhKeyShare ||
           ecdhCipherText || ecdhPublicKey ||
           algId || domSep || len(domSep)
       )
return KEK

The value domSep is a constant set to the UTF-8 encoding of the string 
"OpenPGPCompositeKDFv1", that is:

domSep = 4F 70 65 6E 50 47 50 43 6F 6D 70 6F 73 69 74 65 4B 44 46 76 31

Here len(domSep) is the single octet with the value equal to the 
octet-length of domSep, that is, decimal 21.
~~~


Note however that the LibrePGP text below more closely resembles the 
first draft of the document:

https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-pqc-00#section-5.2.2

 >   For the composite KEM schemes the following procedure MUST be used to
 >   compute the KEK that wraps a session key.  The construction is a one-
 >   step key derivation function compliant to [SP800-56C] Section 4,
 >   based on KMAC256 [SP800-185] and approved by [SP800-227]
 >   Section 4.6.2.  It is given by the following algorithm:
 >
 >   multiKeyCombine (eccKeyShare, eccCipherText,
 >                    mlkemKeyShare, mlkemCipherText,
 >                    fixedInfo, oBits)
 >
 >   Input:
 >   eccKeyShare     - the ECC key share encoded as an octet string
 >   eccCipherText   - the ECC ciphertext encoded as an octet string
 >   mlkemKeyShare   - the ML-KEM key share encoded as an octet string
 >   mlkemCipherText - the ML-KEM ciphertext encoded as an octet string
 >   fixedInfo       - the fixed information octet string (see below)
 >   oBits           - the size of the output keying material in bits
 >
 >   Constants:
 >   domSeparation       - the UTF-8 encoding of the string
 >                         "OpenPGPCompositeKeyDerivationFunction"

Not ?LibrePGP?? ;-)

 >   counter             - the four-octet big-endian value 0x00000001
 >   customizationString - the UTF-8 encoding of the string "KDF"
 >
 >   eccData = eccKeyShare || eccCipherText
 >   mlkemData = mlkemKeyShare || mlkemCipherText
 >   encData = counter || eccData || mlkemData || fixedInfo
 >
 >   result = KMAC256 (domSeparation, encData, oBits, customizationString)
 >
 >   The fixedinfo is used to provide a binding between the KEK and the
 >   communication parties.  It is the concatenation of
 >
 >   *  A one octet algorithm ID describing the symmetric algorithm used
 >      for the bulk data in the in the SEIPD (packet 18) or the OCBED
 >      (packet 20).
 >
 >   *  The 32 octet version 5 fingerprint of the public key.  Note that
 >      the fingerprint covers the packet format and all other parameters
 >      of the public key.
 >
 >
 > --
 > The pioneers of a warless world are the youth that
 > refuse military service.             - A. Einstein
 > _______________________________________________
 > Gnupg-users mailing list
 > Gnupg-users at gnupg.org
 > https://lists.gnupg.org/mailman/listinfo/gnupg-users
 > <openpgp-digital-signature.asc>

From wk at gnupg.org  Mon Apr 27 12:26:39 2026
From: wk at gnupg.org (Werner Koch)
Date: Mon, 27 Apr 2026 12:26:39 +0200
Subject: Post-quantum defaults
In-Reply-To: <9f0252f7-c907-4f22-a2f8-185f1381ce40@andrewg.com> (Andrew
 Gallagher via Gnupg-users's message of "Mon, 27 Apr 2026 10:27:10
 +0100")
References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org>
 <e7c6e6ff-bd41-1891-cc58-09196c2ed795@vulcan.xs4all.nl>
 <87zf2oyirs.fsf@jacob.g10code.de>
 <9f0252f7-c907-4f22-a2f8-185f1381ce40@andrewg.com>
Message-ID: <87jytsya00.fsf@jacob.g10code.de>

On Mon, 27 Apr 2026 10:27, Andrew Gallagher said:

> It?s more than a ?paper and project?, it?s due to be published as an
> RFC any day now, and is widely implemented (by everyone else).

Right, preparing an I-D was part of the call for tenders for the BSI PQC
project P580 in 2021.  Actually Ribose, Intevation, and g10 Code took
part in the bid but eventually lost against the offer by MTG AG.

The part to implement PQC also for S/MIME was later dropped so the whole
thing was only for OpenPGP.  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 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 WG later changed more
things which I did not follow in particular because the important
Brainpool support was also removed by them.

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.  And that is what Niibe-san
and me implemented in GnuPG and later specified in LibrePGP.  The
changes affected only protocol format details and not the actual crypto.


Shalom-Salam,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 284 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260427/94a651c2/attachment.sig>

From andrewg at andrewg.com  Mon Apr 27 17:21:03 2026
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Mon, 27 Apr 2026 16:21:03 +0100
Subject: Post-quantum defaults
In-Reply-To: <87jytsya00.fsf@jacob.g10code.de>
References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org>
 <e7c6e6ff-bd41-1891-cc58-09196c2ed795@vulcan.xs4all.nl>
 <87zf2oyirs.fsf@jacob.g10code.de>
 <9f0252f7-c907-4f22-a2f8-185f1381ce40@andrewg.com>
 <87jytsya00.fsf@jacob.g10code.de>
Message-ID: <144d13a7-40d7-4266-9801-39c5b2222d61@andrewg.com>

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

From rjh at sixdemonbag.org  Mon Apr 27 18:29:35 2026
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 27 Apr 2026 12:29:35 -0400
Subject: Post-quantum defaults
In-Reply-To: <144d13a7-40d7-4266-9801-39c5b2222d61@andrewg.com>
References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org>
 <e7c6e6ff-bd41-1891-cc58-09196c2ed795@vulcan.xs4all.nl>
 <87zf2oyirs.fsf@jacob.g10code.de>
 <9f0252f7-c907-4f22-a2f8-185f1381ce40@andrewg.com>
 <87jytsya00.fsf@jacob.g10code.de>
 <144d13a7-40d7-4266-9801-39c5b2222d61@andrewg.com>
Message-ID: <fdb50d1e-68eb-4513-bee7-8b42ec29f9db@sixdemonbag.org>

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
> Gnupg-users at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260427/d00ad52d/attachment.sig>

From andrewg at andrewg.com  Mon Apr 27 18:48:18 2026
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Mon, 27 Apr 2026 17:48:18 +0100
Subject: Post-quantum defaults
In-Reply-To: <fdb50d1e-68eb-4513-bee7-8b42ec29f9db@sixdemonbag.org>
References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org>
 <e7c6e6ff-bd41-1891-cc58-09196c2ed795@vulcan.xs4all.nl>
 <87zf2oyirs.fsf@jacob.g10code.de>
 <9f0252f7-c907-4f22-a2f8-185f1381ce40@andrewg.com>
 <87jytsya00.fsf@jacob.g10code.de>
 <144d13a7-40d7-4266-9801-39c5b2222d61@andrewg.com>
 <fdb50d1e-68eb-4513-bee7-8b42ec29f9db@sixdemonbag.org>
Message-ID: <18fb2f39-72ab-496e-846a-5991bcb14494@andrewg.com>

Hi, Robert.

On 27/04/2026 17:29, Robert J. Hansen via Gnupg-users wrote:
> 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.
I thought long and hard about this email before sending it, but I sent 
it to the list on purpose. I appreciate that I have crossed a line, but 
I did not do so casually or lightly.

Thank you for your consideration, and for your words of caution. I stand 
by my statement that we must foster a more inviting community. I don't 
believe this is currently the inviting community that either of us would 
prefer to see. I desperately hope that it can be.

With love,
A


From wk at gnupg.org  Mon Apr 27 23:01:07 2026
From: wk at gnupg.org (Werner Koch)
Date: Mon, 27 Apr 2026 23:01:07 +0200
Subject: Post-quantum defaults
In-Reply-To: <144d13a7-40d7-4266-9801-39c5b2222d61@andrewg.com> (Andrew
 Gallagher via Gnupg-users's message of "Mon, 27 Apr 2026 16:21:03
 +0100")
References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org>
 <e7c6e6ff-bd41-1891-cc58-09196c2ed795@vulcan.xs4all.nl>
 <87zf2oyirs.fsf@jacob.g10code.de>
 <9f0252f7-c907-4f22-a2f8-185f1381ce40@andrewg.com>
 <87jytsya00.fsf@jacob.g10code.de>
 <144d13a7-40d7-4266-9801-39c5b2222d61@andrewg.com>
Message-ID: <87lde8w224.fsf@jacob.g10code.de>

On Mon, 27 Apr 2026 16:21, Andrew Gallagher said:
> 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.

Gniibe is a long term friend of mine and I asked him to take over my
place in the design team to see whether he can have an eye on the
editing process and check that his SOS proposal and his experience with
ECC encodings makes it into the draft (where he only partly succeeded).

> 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

Andrew, please stop to rewrite history.  What you wrote is simply not
true.  You have not even been part of the design team.  I left the
design time due to our work to get OpenPGP deployed all over Germany's
and Europe's administrations and industries.  At that state only final
editing was due and no more semantics changes were planned.

Gniibe is a very humble man who would never provoke any anger.  I assume
this is the reason he did not asked to be removed for the authors list.
I actually asked to be removed from the authors and design team list
because that would really have given a false credibility to the outcome
of the WG.

> 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.  For signatures I see no immediate need, thus better let the
algorithms settle 2 or 3 years before they get specified in *PGP.


Salam-Shalom,

   Werner


ps.
I guess I should not anymore take your bait and answer your mails.

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 284 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260427/3b1a41ba/attachment-0001.sig>

From rjh at sixdemonbag.org  Tue Apr 28 03:30:42 2026
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 27 Apr 2026 21:30:42 -0400
Subject: Thanks, Andrew.
Message-ID: <f98fb51e-644c-4258-b061-861e3e905ad7@sixdemonbag.org>

I have long had a weird role in @GnuPG. I don't influence the 
specifications (RFC9580 or LibrePGP), I don't touch the codebase, I have 
absolutely no official role. Some people listen to me anyway because of 
my twenty years of active involvement in the GnuPG community.

Today, Andrew wrote one of the bravest criticisms I've ever seen of 
GnuPG's leadership. I thought it was professional, but it was also so 
unflinching I thought it certainly had to be a private communique 
mistakenly sent to the mailing list.

It was not.

First, my hat is off to Andrew for writing that criticism. It is 
important and it should be read by GnuPG supporters.

You can read it ourself in the archives:

https://lists.gnupg.org/pipermail/gnupg-users/2026-April/068280.html

I will have more to say later. I have to be very careful what I say, 
because I do not want to give the impression I'm seeking to influence a 
specification or an implementation.[*]

For now, I will say I am on Andrew's side in this and I commend him for 
what he's done.


[*] If you're wondering why I'm always on the outside: As a former 
contractor for the US government, many people would object if I 
contributed code or spoke up on technical issues relating to the spec. 
These concerns are not unreasonable.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260427/8525b48c/attachment.sig>

From rjh at sixdemonbag.org  Tue Apr 28 05:37:08 2026
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Mon, 27 Apr 2026 23:37:08 -0400
Subject: Bikeshedding while the world burns
Message-ID: <166dd3b5-64d1-4f9d-a4dc-eced780bd512@sixdemonbag.org>

1. INTRODUCTION

Around 1997, Sun Microsystems hauled Microsoft in court over the Java 
virtual machine (JVM) Microsoft was shipping with new versions of 
Windows. Microsoft had entered an agreement with Sun to ship a JVM that 
fully complied with Sun's compatibility tests, but they failed to honor 
this promise. They insisted they were doing the right thing for their 
users, which may have well been true -- but "best for our users" was not 
the same as "best for Java users".

I'm told that after Microsoft lost this lawsuit they decided to embrace 
C# and the Common Language Runtime as sort of a "Java that we control." 
Java and C# started off as very similar languages but drifted apart over 
time; likewise with their virtual machines.

I am afraid GnuPG is soon going to be a retelling of this story.

I downloaded GnuPG 1.0 the day it was released. I was at the time 
writing an RFC1991 ("ClassicPGP") implementation for a now-defunct 
telecom that had very strange ideas about why PGP 2.6 exposed them to 
legal liability, and I wanted to see how GnuPG implemented some packet 
parsing magic. At that time GnuPG's mission statement was crystal clear: 
to provide a libre command-line implementation of the RFC2440 standard.

For a quarter-century GnuPG has been the gold standard of OpenPGP 
implementations and 100% libre software. This is an amazing achievement, 
and I think Werner deserves immense accolades for his persistence and 
determination in achieving this vision.

But I think we're heading down the wrong road by turning away from the RFC.

2. THE COLD TRUTH

You could replace RFC9580 with RFC1991 from thirty years ago and still 
be sufficient for many users.

Seriously. Most users don't need 30-year security, they need 10-year 
security at the outside, for secrets that are relatively low value 
(under $1 million). RSA-1024 still looks solid for that time window. It 
might be possible to break an RSA-1024 key today, but not for a million 
dollars.

A lot of users don't care very much about signatures, either. They care 
a lot about the confidentiality of their email: the authenticity takes a 
back seat. MD5 matters a lot less.

RFC1991 used a single key for authentication and encryption. This meant 
trouble if a user was ever compelled by a court to reveal their 
decryption key. That was a major motivator of RFC2440, and yet it turns 
out compelled turnover of an asymmetric encryption key is incredibly 
rare: it happens so infrequently it might as well not happen.

Over the last thirty years the IETF working group leading RFC design has 
invented an ever-more-impregnable bank vault door, even as the building 
that bank vault is installed in (operating systems and environments) 
have become ever shoddier.

In my mind, the LibrePGP versus OpenPGP technical arguments are about as 
interesting to me as arguing whether a meter-thick tempered steel vault 
door that laughs in the face of explosives, diamond-tipped drill bits, 
and antitank rockets is secure enough, or whether we need to also have a 
Belgian malinois watching things.

Please don't think, "oh, Rob doesn't understand the specifications, 
that's why he's saying these differences don't matter". I _do_ 
understand the specifications. I don't influence the specs. I never said 
I didn't read them or have opinions on them.

Here's the truth: I love Belgian malinois. After German shepherds 
they're my favorite breed. They're a little too energetic and 
high-strung for me to ever own one, but I adore them. I also don't care 
if my vault door is guarded by one.

3. THE REAL RISK

The real risk today is endpoint compromise. It's cheap, it's easy, it's fun.

Many years ago a divorce attorney came to me with a problem: his client 
was divorcing her husband. They lived in separate apartments since the 
divorce petition was filed. She had reason to believe he was lying about 
his assets but had no way to check on his bank accounts without his 
knowledge. Was there any way I could help?

After confirming they lived in a marital joint property state (where, 
until the time a divorce is finalized, all property in the marriage is 
owned by both), I agreed to do the job. The woman wrote a letter 
authorizing me to enter her husband's apartment to look for financial 
records, and I filed this with my attorney.

I showed up at his apartment after he left for work, picked the lock, 
walked into his office and started taking photographs so I could leave 
the place in the exact same state as when I left. I made a forensic 
image of his hard drive, connected a keylogger, and left. I returned the 
next day to pick up the keylogger.

All of his online security measures -- only using HTTPS through a VPN, 
using Bitlocker, not using a password manager, etcetera -- vanished in 
about a day the moment a semi-skilled attacker decided to go after the 
endpoint. Even Bitlocker fails when the enemy has a forensic image of 
your hard drive and, thanks to a keylogger, your BitLocker password.

Had he shared his apartment with a Belgian malinois, I would have been 
deterred. But neither a cryptographic vault door nor a cryptographic 
Belgian malinois proved any obstacle whatsoever.

4. MORE ON ENDPOINTS

Physical endpoint compromise, like what I describe above, is the 
ultimate game over condition. Network endpoint compromise is almost as bad.

The network landscape in 2026 is not what it was in 1996. There is no 
longer any meaningful concept of a secure network perimeter. In the 
cyberwarfare trade the Internet of Things is instead called the 
"Internet of Targets".

Here in Washington D.C., it's widely believed the Chinese government, 
through a cyberwarfare program called SALT TYPHOON, has at-will access 
to any smartphone it wants in the metropolitan area. (This may be 
revenge of a kind: Edward Snowden revealed to them the NSA had at-will 
access to any text message in Hong Kong.)

My apartment building has decided my front door should no longer have a 
physical key, but instead be locked and unlocked from my smartphone. My 
bank encourages me to do all my banking via an app. Local hotels do the 
same thing.

The endpoints are already compromised, and we're ...

... arguing about whether we need a Belgian malinois _and_ a meter-thick 
tempered steel vault door?!

5. C# AND JAVA, REDUX

When Microsoft was told the Java spec was what it was and wouldn't be 
changed to accommodate them and their users' needs, Microsoft made a 
wise call. They walked away and made a clean break. Over time C# has 
become its own thing and a vastly different ecosystem compared to Java.

I would very much like GnuPG to decide either to:

	(a) implement RFC9580 in GnuPG, even if it's not enabled
	    by default
	(b) make a clean break from RFC9580 and go on to solve a
	    similar-but-different set of problems a similar-but-
	    different way

I don't care which is done but I really think we need to do one or the 
other.

This community is suffering, *badly*, because people are arguing over 
the presence of a Belgian malinois. We should stop the bleeding, even if 
the tourniquet hurts.

6. AM I LEAVING THE COMMUNITY?

Of course not. That would be silly. I love this community too much for that.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260427/a97df6c7/attachment.sig>

From gnupg-users at city17.xyz  Tue Apr 28 10:03:07 2026
From: gnupg-users at city17.xyz (jman)
Date: Tue, 28 Apr 2026 10:03:07 +0200
Subject: Bikeshedding while the world burns
In-Reply-To: <166dd3b5-64d1-4f9d-a4dc-eced780bd512@sixdemonbag.org> (Robert
 J. Hansen via Gnupg-users's message of "Mon, 27 Apr 2026 23:37:08
 -0400")
References: <166dd3b5-64d1-4f9d-a4dc-eced780bd512@sixdemonbag.org>
Message-ID: <87pl3jpl50.fsf@nyarlathotep>

"Robert J. Hansen via Gnupg-users" <gnupg-users at gnupg.org> writes:

> Seriously. Most users don't need 30-year security, they need 10-year
> security at the outside, for secrets that are relatively low value
> (under $1 million). RSA-1024 still looks solid for that time
> window. It might be possible to break an RSA-1024 key today, but not
> for a million dollars.

I think that's only part of the story. Would it be accurate to say that many users need, let's say, 
5-year security and need it *yesterday*?

> I would very much like GnuPG to decide either to:
>
> 	(a) implement RFC9580 in GnuPG, even if it's not enabled
> 	    by default
> 	(b) make a clean break from RFC9580 and go on to solve a
> 	    similar-but-different set of problems a similar-but-
> 	    different way
>
> I don't care which is done but I really think we need to do one or the
> other.

Ok, so this is executive summary.

Sorry if my comment is off-topic, I don't know if it relevant to discussing a protocol, but I get 
the feeling that for the users I mention above, GnuPG is just not a choice because it is stuck into 
this "email confidentiality" scenario which has become much less relevant.

I would also would love GnuPG to get up-to-speed with a number of modern threat scenarios and use 
cases that currently are solved (good or bad I can't say) by Signal or Threema or 
<preferred-smartphone-chat-app>.

I don't know if GnuPG is, by design, a tool oriented to other use cases.

Regards,


From bernhard at intevation.de  Wed Apr 29 09:37:17 2026
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 29 Apr 2026 09:37:17 +0200
Subject: Discussion style differences between OpenPGP design groups (Re:
 Post-quantum defaults)
Message-ID: <202604290937.18253.bernhard@intevation.de>

Hi Andrew,

Am Montag 27 April 2026 17:21:03 schrieb Andrew Gallagher via Gnupg-users:
> 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.

a simple explanation for the above and some other references by Werner could 
be that personal communication is confidential and some internal meetings are 
confidential as well. It may just not possible to give some of those details
in public. 

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

I've seen some aggression and unfairness in communication coming 
from that group. Which hurt me personally, but probably Werner much more
(No, I do not want to go into details, I do not want to blame someone 
specific, it is more a description of how I have perceived the communication. 
I've also seen bad communication from Werner and others and probably have 
issued some myself.) Mainly it damaged the process and working relationships.

Just "a bunch of goofy nerds" is not a complete description, there are some 
business values and personal convictions on stake as well. Which is okay in 
principle of course, but it also explains why some extensions are more 
valuable to others in the group. (GCM mode for example.) I think it is better 
to talk about different interests.

> 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*?

<sarcasm>
  It seems the WG also wants to "die" on this hill...
</sarcasm>
What strikes me as odd is that a number of accusations made against LibrePG, 
GnuPG and Werner, could also be turned around and be made (with some 
plausibility) against RFC9580, sequoia and the IETF WG as well.
This statement of yours just an example, I want to point out how aggressive
and imbalanced I perceive the communication here. I do not understand this as
as real question with genuine interested in what can be done together,
good (the group of personal friends trying to do the good thing) and bad
(missing meetings, throwing shades) are already decided. In this style I do 
not see an openess for improvements on side of the "good" group.

So I conclude:
Who is right seems to have become a matter of principle for many participants.

An we all know: Just because a number of people have proposed a document that 
is a "standard" by some organisation, does not make it one in the wild or 
even a good one. Some of those "standards" never get picked up. There is some 
merit in a group getting a consensus together, but they still could be wrong 
on some technical parts.

> We need to foster a more inviting community, or it will die with us.

Then please help with it.
Try to find a description and a language that would be agreeable to Werner to  
describe situations and arguments, before you disagree. Ask questions and 
listen in order to really understand. In this post it is different:
If Werner tries to give some details about how and why LibrePGP and GnuPG are 
how they are now, his statements are to "a conspiracy theory" and a stance to 
a "hill [..] to die on".
This is a communication style that makes it hard for me to respond in a 
helpful way. I mainly interpret it as born out of frustration. That I could
understand very well, but I do not see how it will fostering a more inviting
community.

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

With that attitude and the harshness of these accusation, why should Werner or 
anyone assume that he would be treated fairly on these meetings or occuasions?
Personally I wouldn't want to interact with a group in an atmosphere like 
this. Even if I had a reasonable explanation and defense for all these things
I do not think anyone would really listen.

> But this tinpot disagreement is escalating to the point 
> where end users are abandoning the PGP ecosystem entirely. Is that the
> outcome we want?

If changing course here, on a point that you say does not matter, why doesn't 
the WG just turn into Werner's way here and saves the ecosystem? 
Probably because it is not that easy...
(As you see again, sarcasm is all that I can muster here. What I am trying
to express is that I cannot understand that one-sided blame at all.)

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

I believe this is what you honestly want - that is why I've took the time to 
reply and give you my personal view on your email. My humble suggestion and 
its reasoning is above. Hope it helps at least a little bit.

Best Regards,
Bernhard

-- 
https://intevation.de/~bernhard         +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998
Managing Directors: Frank Koormann, Bernhard Reiter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260429/3c6ea1dc/attachment-0001.sig>

From andrewg at andrewg.com  Wed Apr 29 10:57:07 2026
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 29 Apr 2026 09:57:07 +0100
Subject: Discussion style differences between OpenPGP design groups (Re:
 Post-quantum defaults)
In-Reply-To: <202604290937.18253.bernhard@intevation.de>
References: <202604290937.18253.bernhard@intevation.de>
Message-ID: <dd0c5e4a-7ca7-403d-aabb-5bccbc5c0ff1@andrewg.com>

Hi, Bernhard.

Thanks for replying. I'm going to avoid getting into a point-by-point 
rebuttal here because I fear it would drag us into the weeds and obscure 
my central message.

The IETF WG is not made up of saints. There are some strong (some might 
say difficult!) personalities. The style of argumentation is not always 
constructive. But when I call it a "family argument" I mean it - we are 
a family with both common interests and divergent ones. Managing these 
divergences is the entire point of a WG. And for the most part so far we 
have succeeded.

I would classify this thread also as a "family argument". And the root 
cause of this argument is whether or not Werner has a *personal veto* 
over the specification. There is a well-documented pattern of behaviour 
going back years, where Werner simply ignores criticism he doesn't like 
and makes executive decisions on behalf of everyone else. Many of the 
criticisms that he has faced over the long history of PGP and GnuPG have 
been unwarranted and unfair. I have defended him on many of those 
occasions, and I will continue to do so. Many of the decisions that he 
has made on behalf of the community have been the correct ones, or at 
least arguably correct. And he deserves our gratitude for that.

But there have also been well-founded criticisms of his decisions, 
particularly since he became editor of the rfc4880bis draft. And it is 
how he has responded to those criticisms that has led to the schism. On 
many occasions he has lost an argument on technical merits, or otherwise 
been the lone dissenting voice on a non-technical matter, and he has 
attempted to wield a personal veto in order to get his way. When it 
became clear that nobody else was willing to grant him the power of 
veto, he walked out and attempted to set up an alternative "standard" 
with him as the sole decision-maker.

This is not how a healthy community should work.

I commend you for your attempts to broker peace, and to see the good in 
all sides. I too want to believe in the good of all sides and find a 
compromise position that can resolve this mess. I have attempted on 
numerous occasions to find some clever technical wheeze that would 
bridge the gap between factions, but this is not a technical 
disagreement. Even using the words "factions" or "sides" obscures the 
stark reality that one of the sides consists of a single person.

When Werner's negotiating position is "I will make peace but only if you 
allow me to veto anything I dislike" there is no prospect of compromise. 
And when you ask me "why doesn't the WG just turn into Werner's way here 
and saves the ecosystem?" you are asking me "why don't you just accept 
Werner as your dictator for the sake of peace?". That's a deeply unfair 
thing to ask of any collaborative community.

I don't believe you intend your question that way, but that is the way 
it comes across to most people I know. There is a fundamental difference 
between unfair behaviour and complaining about unfair behaviour. By 
arguing endlessly about the tone and incivility of the complaints, or by 
drawing equivalence between the complaints and the initial unfairness, 
we let the root cause - the unfair behaviour itself - off the hook. 
Constantly bothsidesing a single-issue argument only serves to prolong 
the argument. At some point a decision has to be made.

Do we grant Werner a veto, or not?

Thanks,
Andrew.

On 29/04/2026 08:37, Bernhard Reiter wrote:
> Hi Andrew,
> 
> Am Montag 27 April 2026 17:21:03 schrieb Andrew Gallagher via Gnupg-users:
>> 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.
> 
> a simple explanation for the above and some other references by Werner could
> be that personal communication is confidential and some internal meetings are
> confidential as well. It may just not possible to give some of those details
> in public.
> 
>> 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!)
> 
> I've seen some aggression and unfairness in communication coming
> from that group. Which hurt me personally, but probably Werner much more
> (No, I do not want to go into details, I do not want to blame someone
> specific, it is more a description of how I have perceived the communication.
> I've also seen bad communication from Werner and others and probably have
> issued some myself.) Mainly it damaged the process and working relationships.
> 
> Just "a bunch of goofy nerds" is not a complete description, there are some
> business values and personal convictions on stake as well. Which is okay in
> principle of course, but it also explains why some extensions are more
> valuable to others in the group. (GCM mode for example.) I think it is better
> to talk about different interests.
> 
>> 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*?
> 
> <sarcasm>
>    It seems the WG also wants to "die" on this hill...
> </sarcasm>
> What strikes me as odd is that a number of accusations made against LibrePG,
> GnuPG and Werner, could also be turned around and be made (with some
> plausibility) against RFC9580, sequoia and the IETF WG as well.
> This statement of yours just an example, I want to point out how aggressive
> and imbalanced I perceive the communication here. I do not understand this as
> as real question with genuine interested in what can be done together,
> good (the group of personal friends trying to do the good thing) and bad
> (missing meetings, throwing shades) are already decided. In this style I do
> not see an openess for improvements on side of the "good" group.
> 
> So I conclude:
> Who is right seems to have become a matter of principle for many participants.
> 
> An we all know: Just because a number of people have proposed a document that
> is a "standard" by some organisation, does not make it one in the wild or
> even a good one. Some of those "standards" never get picked up. There is some
> merit in a group getting a consensus together, but they still could be wrong
> on some technical parts.
> 
>> We need to foster a more inviting community, or it will die with us.
> 
> Then please help with it.
> Try to find a description and a language that would be agreeable to Werner to
> describe situations and arguments, before you disagree. Ask questions and
> listen in order to really understand. In this post it is different:
> If Werner tries to give some details about how and why LibrePGP and GnuPG are
> how they are now, his statements are to "a conspiracy theory" and a stance to
> a "hill [..] to die on".
> This is a communication style that makes it hard for me to respond in a
> helpful way. I mainly interpret it as born out of frustration. That I could
> understand very well, but I do not see how it will fostering a more inviting
> community.
> 
>> 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*.
> 
> With that attitude and the harshness of these accusation, why should Werner or
> anyone assume that he would be treated fairly on these meetings or occuasions?
> Personally I wouldn't want to interact with a group in an atmosphere like
> this. Even if I had a reasonable explanation and defense for all these things
> I do not think anyone would really listen.
> 
>> But this tinpot disagreement is escalating to the point
>> where end users are abandoning the PGP ecosystem entirely. Is that the
>> outcome we want?
> 
> If changing course here, on a point that you say does not matter, why doesn't
> the WG just turn into Werner's way here and saves the ecosystem?
> Probably because it is not that easy...
> (As you see again, sarcasm is all that I can muster here. What I am trying
> to express is that I cannot understand that one-sided blame at all.)
> 
>> 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.
> 
> I believe this is what you honestly want - that is why I've took the time to
> reply and give you my personal view on your email. My humble suggestion and
> its reasoning is above. Hope it helps at least a little bit.
> 
> Best Regards,
> Bernhard
> 


From look at my.amazin.horse  Wed Apr 29 11:21:24 2026
From: look at my.amazin.horse (Vincent Breitmoser)
Date: Wed, 29 Apr 2026 11:21:24 +0200
Subject: Discussion style differences between OpenPGP design groups (Re:
 Post-quantum defaults)
In-Reply-To: <dd0c5e4a-7ca7-403d-aabb-5bccbc5c0ff1@andrewg.com>
References: <202604290937.18253.bernhard@intevation.de>
 <dd0c5e4a-7ca7-403d-aabb-5bccbc5c0ff1@andrewg.com>
Message-ID: <50de0df8-e2b0-4a61-98bb-8f6d8fb78133@my.amazin.horse>

For those following along who weren't part of the process, I'd like to 
leave this link here:

https://mailarchive.ietf.org/arch/msg/openpgp/5Xujhn0SxC-P1cWKxwBptDi2dAY/

This email from 2022, and the ones leading up to it, give a lot of 
context about what Andrew is referring to.

  - V

On 4/29/26 10:57, Andrew Gallagher via Gnupg-users wrote:
> Hi, Bernhard.
> 
> Thanks for replying. I'm going to avoid getting into a point-by-point 
> rebuttal here because I fear it would drag us into the weeds and obscure 
> my central message.
> 
> The IETF WG is not made up of saints. There are some strong (some might 
> say difficult!) personalities. The style of argumentation is not always 
> constructive. But when I call it a "family argument" I mean it - we are 
> a family with both common interests and divergent ones. Managing these 
> divergences is the entire point of a WG. And for the most part so far we 
> have succeeded.
> 
> I would classify this thread also as a "family argument". And the root 
> cause of this argument is whether or not Werner has a *personal veto* 
> over the specification. There is a well-documented pattern of behaviour 
> going back years, where Werner simply ignores criticism he doesn't like 
> and makes executive decisions on behalf of everyone else. Many of the 
> criticisms that he has faced over the long history of PGP and GnuPG have 
> been unwarranted and unfair. I have defended him on many of those 
> occasions, and I will continue to do so. Many of the decisions that he 
> has made on behalf of the community have been the correct ones, or at 
> least arguably correct. And he deserves our gratitude for that.
> 
> But there have also been well-founded criticisms of his decisions, 
> particularly since he became editor of the rfc4880bis draft. And it is 
> how he has responded to those criticisms that has led to the schism. On 
> many occasions he has lost an argument on technical merits, or otherwise 
> been the lone dissenting voice on a non-technical matter, and he has 
> attempted to wield a personal veto in order to get his way. When it 
> became clear that nobody else was willing to grant him the power of 
> veto, he walked out and attempted to set up an alternative "standard" 
> with him as the sole decision-maker.
> 
> This is not how a healthy community should work.
> 
> I commend you for your attempts to broker peace, and to see the good in 
> all sides. I too want to believe in the good of all sides and find a 
> compromise position that can resolve this mess. I have attempted on 
> numerous occasions to find some clever technical wheeze that would 
> bridge the gap between factions, but this is not a technical 
> disagreement. Even using the words "factions" or "sides" obscures the 
> stark reality that one of the sides consists of a single person.
> 
> When Werner's negotiating position is "I will make peace but only if you 
> allow me to veto anything I dislike" there is no prospect of compromise. 
> And when you ask me "why doesn't the WG just turn into Werner's way here 
> and saves the ecosystem?" you are asking me "why don't you just accept 
> Werner as your dictator for the sake of peace?". That's a deeply unfair 
> thing to ask of any collaborative community.
> 
> I don't believe you intend your question that way, but that is the way 
> it comes across to most people I know. There is a fundamental difference 
> between unfair behaviour and complaining about unfair behaviour. By 
> arguing endlessly about the tone and incivility of the complaints, or by 
> drawing equivalence between the complaints and the initial unfairness, 
> we let the root cause - the unfair behaviour itself - off the hook. 
> Constantly bothsidesing a single-issue argument only serves to prolong 
> the argument. At some point a decision has to be made.
> 
> Do we grant Werner a veto, or not?
> 
> Thanks,
> Andrew.
> 
> On 29/04/2026 08:37, Bernhard Reiter wrote:
>> Hi Andrew,
>>
>> Am Montag 27 April 2026 17:21:03 schrieb Andrew Gallagher via Gnupg- 
>> users:
>>> 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.
>>
>> a simple explanation for the above and some other references by Werner 
>> could
>> be that personal communication is confidential and some internal 
>> meetings are
>> confidential as well. It may just not possible to give some of those 
>> details
>> in public.
>>
>>> 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!)
>>
>> I've seen some aggression and unfairness in communication coming
>> from that group. Which hurt me personally, but probably Werner much more
>> (No, I do not want to go into details, I do not want to blame someone
>> specific, it is more a description of how I have perceived the 
>> communication.
>> I've also seen bad communication from Werner and others and probably have
>> issued some myself.) Mainly it damaged the process and working 
>> relationships.
>>
>> Just "a bunch of goofy nerds" is not a complete description, there are 
>> some
>> business values and personal convictions on stake as well. Which is 
>> okay in
>> principle of course, but it also explains why some extensions are more
>> valuable to others in the group. (GCM mode for example.) I think it is 
>> better
>> to talk about different interests.
>>
>>> 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*?
>>
>> <sarcasm>
>> ?? It seems the WG also wants to "die" on this hill...
>> </sarcasm>
>> What strikes me as odd is that a number of accusations made against 
>> LibrePG,
>> GnuPG and Werner, could also be turned around and be made (with some
>> plausibility) against RFC9580, sequoia and the IETF WG as well.
>> This statement of yours just an example, I want to point out how 
>> aggressive
>> and imbalanced I perceive the communication here. I do not understand 
>> this as
>> as real question with genuine interested in what can be done together,
>> good (the group of personal friends trying to do the good thing) and bad
>> (missing meetings, throwing shades) are already decided. In this style 
>> I do
>> not see an openess for improvements on side of the "good" group.
>>
>> So I conclude:
>> Who is right seems to have become a matter of principle for many 
>> participants.
>>
>> An we all know: Just because a number of people have proposed a 
>> document that
>> is a "standard" by some organisation, does not make it one in the wild or
>> even a good one. Some of those "standards" never get picked up. There 
>> is some
>> merit in a group getting a consensus together, but they still could be 
>> wrong
>> on some technical parts.
>>
>>> We need to foster a more inviting community, or it will die with us.
>>
>> Then please help with it.
>> Try to find a description and a language that would be agreeable to 
>> Werner to
>> describe situations and arguments, before you disagree. Ask questions and
>> listen in order to really understand. In this post it is different:
>> If Werner tries to give some details about how and why LibrePGP and 
>> GnuPG are
>> how they are now, his statements are to "a conspiracy theory" and a 
>> stance to
>> a "hill [..] to die on".
>> This is a communication style that makes it hard for me to respond in a
>> helpful way. I mainly interpret it as born out of frustration. That I 
>> could
>> understand very well, but I do not see how it will fostering a more 
>> inviting
>> community.
>>
>>> 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*.
>>
>> With that attitude and the harshness of these accusation, why should 
>> Werner or
>> anyone assume that he would be treated fairly on these meetings or 
>> occuasions?
>> Personally I wouldn't want to interact with a group in an atmosphere like
>> this. Even if I had a reasonable explanation and defense for all these 
>> things
>> I do not think anyone would really listen.
>>
>>> But this tinpot disagreement is escalating to the point
>>> where end users are abandoning the PGP ecosystem entirely. Is that the
>>> outcome we want?
>>
>> If changing course here, on a point that you say does not matter, why 
>> doesn't
>> the WG just turn into Werner's way here and saves the ecosystem?
>> Probably because it is not that easy...
>> (As you see again, sarcasm is all that I can muster here. What I am 
>> trying
>> to express is that I cannot understand that one-sided blame at all.)
>>
>>> 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.
>>
>> I believe this is what you honestly want - that is why I've took the 
>> time to
>> reply and give you my personal view on your email. My humble 
>> suggestion and
>> its reasoning is above. Hope it helps at least a little bit.
>>
>> Best Regards,
>> Bernhard
>>
> 
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users



From bernhard.reiter at intevation.de  Wed Apr 29 09:24:39 2026
From: bernhard.reiter at intevation.de (Bernhard E. Reiter)
Date: Wed, 29 Apr 2026 09:24:39 +0200
Subject: Discussion style differences between OpenPGP design groups (Re:
 Post-quantum defaults)
In-Reply-To: <144d13a7-40d7-4266-9801-39c5b2222d61@andrewg.com>
References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org>
 <87jytsya00.fsf@jacob.g10code.de>
 <144d13a7-40d7-4266-9801-39c5b2222d61@andrewg.com>
Message-ID: <202604290924.45486.bernhard.reiter@intevation.de>

Hi Andrew,

Am Montag 27 April 2026 17:21:03 schrieb Andrew Gallagher via Gnupg-users:
> 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.

a simple explanation for the above and some other references by Werner could 
be that personal communication is confidential and some internal meetings are 
confidential as well. It may just not possible to give some of those details
in public. 

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

I've seen some aggression and unfairness in communication coming 
from that group. Which hurt me personally, but probably Werner much more
(No, I do not want to go into details, I do not want to blame someone 
specific, it is more a description of how I have perceived the communication. 
I've also seen bad communication from Werner and others and probably have 
issued some myself.) Mainly it damaged the process and working relationships.

Just "a bunch of goofy nerds" is not a complete description, there are some 
business values and personal convictions on stake as well. Which is okay in 
principle of course, but it also explains why some extensions are more 
valuable to others in the group. (GCM mode for example.) I think it is better 
to talk about different interests.

> 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*?

<sarcasm>
  It seems the WG also wants to "die" on this hill...
</sarcasm>
What strikes me as odd is that a number of accusations made against LibrePG, 
GnuPG and Werner, could also be turned around and be made (with some 
plausibility) against RFC9580, sequoia and the IETF WG as well.
This statement of yours just an example, I want to point out how aggressive
and imbalanced I perceive the communication here. I do not understand this as
as real question with genuine interested in what can be done together,
good (the group of personal friends trying to do the good thing) and bad
(missing meetings, throwing shades) are already decided. In this style I do 
not see an openess for improvements on side of the "good" group.

So I conclude:
Who is right seems to have become a matter of principle for many participants.

An we all know: Just because a number of people have proposed a document that 
is a "standard" by some organisation, does not make it one in the wild or 
even a good one. Some of those "standards" never get picked up. There is some 
merit in a group getting a consensus together, but they still could be wrong 
on some technical parts.

> We need to foster a more inviting community, or it will die with us.

Then please help with it.
Try to find a description and a language that would be agreeable to Werner to  
describe situations and arguments, before you disagree. Ask questions and 
listen in order to really understand. In this post it is different:
If Werner tries to give some details about how and why LibrePGP and GnuPG are 
how they are now, his statements are to "a conspiracy theory" and a stance to 
a "hill [..] to die on".
This is a communication style that makes it hard for me to respond in a 
helpful way. I mainly interpret it as born out of frustration. That I could
understand very well, but I do not see how it will fostering a more inviting
community.

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

With that attitude and the harshness of these accusation, why should Werner or 
anyone assume that he would be treated fairly on these meetings or occuasions?
Personally I wouldn't want to interact with a group in an atmosphere like 
this. Even if I had a reasonable explanation and defense for all these things
I do not think anyone would really listen.

> But this tinpot disagreement is escalating to the point 
> where end users are abandoning the PGP ecosystem entirely. Is that the
> outcome we want?

If changing course here, on a point that you say does not matter, why doesn't 
the WG just turn into Werner's way here and saves the ecosystem? 
Probably because it is not that easy...
(As you see again, sarcasm is all that I can muster here. What I am trying
to express is that I cannot understand that one-sided blame at all.)

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

I believe this is what you honestly want - that is why I've took the time to 
reply and give you my personal view on your email. My humble suggestion and 
its reasoning is above. Hope it helps at least a little bit.

Best Regards,
Bernhard

-- 
https://intevation.de/~bernhard         +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998
Managing Directors: Frank Koormann, Bernhard Reiter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260429/49712044/attachment.sig>

From bernhard at intevation.de  Thu Apr 30 16:19:55 2026
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 30 Apr 2026 16:19:55 +0200
Subject: Discussion style differences between OpenPGP design groups
In-Reply-To: <dd0c5e4a-7ca7-403d-aabb-5bccbc5c0ff1@andrewg.com>
References: <202604290937.18253.bernhard@intevation.de>
 <dd0c5e4a-7ca7-403d-aabb-5bccbc5c0ff1@andrewg.com>
Message-ID: <202604301620.01120.bernhard@intevation.de>

Hi Andrew,

thanks for the writeup, especially the nuanced parts were helpful!

Am Mittwoch 29 April 2026 10:57:07 schrieb Andrew Gallagher via Gnupg-users:
> I would classify this thread also as a "family argument". And the root
> cause of this argument is whether or not Werner has a *personal veto*
> over the specification.

In my view it were at least as much the (some) participants of the working 
group  _and_ Werner who have made this into a power struggle. What I am not 
accepting is the full blame on a single individual or side.

Werner is not alone, and never was, which I know from personal and 
unfortunately private communication. This statement is hard to prove
on my own, but consider for a minute what someone would do who tends to thing 
that LibrePGP is partly the better specification: It would take quite a bit 
of courage to expose one selfes and lot of time to argue against an 
established group.

And the tone has become less constructive over time in my memory. Much so.

> When it became clear that nobody else was willing to grant him the power of
> veto, he walked out and attempted to set up an alternative "standard"
> with him as the sole decision-maker.

I read this differently: It can be a constructive step.
Werner has been putting more time into an implementation and in a 
specification which is closer to what is actual practice over time.
This enables others to see how an updated specification with the experience of 
RFC4480 designers would look like.
It directs efforts away from an unconstructive debate towards setting up a 
specification and working code.

By the way: It is a good approach in family disputes to let things cool down 
and then try to find out what someone really wants. Or to separate and try to 
find out what a part of the family wants. 

> When Werner's negotiating position is "I will make peace but only if you
> allow me to veto anything I dislike" there is no prospect of compromise.

Did anyone really ask him what a constructive way forward would be?
And what about the best alternatives?

In my experience negociating means to find out what others and myself really 
want and to establish a respectful communication in order to do so.
The respectful part was often missing for the specification debate, I am 
merely pointing out where that is the case.

> And when you ask me "why doesn't the WG just turn into Werner's way here
> and saves the ecosystem?" you are asking me "why don't you just accept
> Werner as your dictator for the sake of peace?". That's a deeply unfair
> thing to ask of any collaborative community.

I've asked that question to show that either 
 a part of the community more cares about its own power and the principle then 
the end of the ecosystem
 Or that it is not the end of the ecosystem.

Note that we were talking about a single technical issue that you've said did 
not matter. Of course a community could easily do it Werner's way if the 
point does not really matter and thus "save the ecosystem".

> I don't believe you intend your question that way, but that is the way
> it comes across to most people I know. 

That maybe part of a missunderstanding then. 
How do you think I intend my question?
What should I have written to get my intention across to others?

> By arguing endlessly about the tone and incivility of the complaints, or by
> drawing equivalence between the complaints and the initial unfairness,
> we let the root cause - the unfair behaviour itself - off the hook.

If you accuse me of "endlessly" arguing, I might just stop. 
What would you have won?

> Constantly bothsidesing a single-issue argument only serves to prolong
> the argument. 

I am not giveing both sides the same part of the blame. 
I'll try to explain why your style in your last email is one that I personally 
find aggressive and unfair. And such a style will not get me, or others that 
perceive it in similar way, to spend more time listening to you.
And listen is a fundamental precondition to get common understandings.
Thus the style of your email seemed to contradict that you have wanted to work 
together.

You have a passion for end-to-end cryptography and I respect it and I am 
grateful for your work. Probably you have more time for it than I have, but 
is getting me to react less to you really helping?

> At some point a decision has to be made. 
> Do we grant Werner a veto, or not?

Werner Koch has devoted the major fraction of his professional life
towards creating a Free Software product for end-to-end cryptography.
He is the active technical and architectual lead of the major and 
most widely used OpenPGP implementation (seen over 25 years).
As you have written before, he was right on a number of decision he took
in those roles. He as a lot of experience.

Yes, I think it is worth a real consideration to give him a veto.

It would make talks become much more careful and respectful.
There are some good examples (in society) where groups require a full 
consensus and work successfully under that condition.

Best Regards,
Bernhard

-- 
https://intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260430/ab9d3290/attachment.sig>

From rjh at sixdemonbag.org  Thu Apr 30 19:32:38 2026
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Thu, 30 Apr 2026 13:32:38 -0400
Subject: Discussion style differences between OpenPGP design groups
In-Reply-To: <202604301620.01120.bernhard@intevation.de>
References: <202604290937.18253.bernhard@intevation.de>
 <dd0c5e4a-7ca7-403d-aabb-5bccbc5c0ff1@andrewg.com>
 <202604301620.01120.bernhard@intevation.de>
Message-ID: <b89b1e8b-ed5e-470e-afa1-ff3b4fdbd003@sixdemonbag.org>

> In my view it were at least as much the (some) participants of the
> working group  _and_ Werner who have made this into a power
> struggle. What I am not accepting is the full blame on a single
> individual or side. ... And the tone has become less constructive
> over time in my memory. Much so.

Thank you for starting this on something that's easy to agree with.
(Zero sarcasm.)

> I read this differently: It can be a constructive step.

Putting this out there to maybe help bridge the gap:

IETF's unofficial motto has always been "rough consensus and running
code."[*] At my present level of ignorance[**] this is how I see what
happened:

* People thought RFC4880bis was the right direction
* Werner implemented it, released it, got a large userbase for it.
* The WG changed its mind prior to RFC finalization, as it had every
   right to do.
* The final RFC9580 RFC ("rough consensus") is now in opposition to
   actual internet practice ("running code").

This can be seen as an argument between proscriptivists and
descriptivists.[***]

I am of the belief, with respect to technical standards, that a spec
which does not comply with actual practice is an erroneous spec.
Publishing an erroneous spec and then expecting the world to suddenly
change the way it does things in order to accommodate the spec is ... I
don't have another word to use besides "hubristic".

Werner gets accused of hubris constantly. I think there is some truth
there. I've seen him behave in ways I find unhelpful and
counterproductive. (Werner, as your friend, I'm telling you that Andrew
is trying really really hard to be your friend. Please rethink your
characterization of his criticisms as "bait".)

But at the same time there is an enormous level of hubris in the WG
demanding that all of these recently-installed vault doors be
reinstalled with this newer vault door which offers *no* practical
capability improvements for 95% of users [****] except for "now, with a
Belgian malinois!". We should notice that, too.

[*] https://www.ietf.org/runningcode/
[**] I neither have nor want any special insider knowledge of
     what's happened. Seriously. I violently do not want this.
[***] For benefit of non-English speakers whom I've just sent
     scrambling for a dictionary: proscriptivism is the belief
     that "usage should follow rules," while descriptivism is
     the belief "rules should be follow usage".
[****] As I said a few days ago, *PGP is massively overdesigned
     for the needs of the vast majority of its users.

>> By arguing endlessly about the tone and incivility of the
>> complaints, or by drawing equivalence between the complaints and
>> the initial unfairness, we let the root cause - the unfair
>> behaviour itself - off the hook.
> 
> If you accuse me of "endlessly" arguing, I might just stop.

I didn't read Andrew as accusing you of being dilatory; I read him as
being frustrated with how long this is taking. I share in his
frustration, but I think everyone is talking in good faith.

> What would you have won?

I would have preferred if LibrePGP had become the new standard. This is
no slam on the WG, which put out a spec I believe is technically
superior to LibrePGP. But the LibrePGP spec is definitely good enough
and is already fielded in large numbers.

At the same time, it's not about which one I want to have won. It's 
about *where we are now as a community*, and how do we bridge this rift?

There are genuinely good people in the RFC9580 camp. Our community will 
be stronger and better if we can reconcile with them.

I've already shared my thoughts on how we can do that. I won't rehash 
them here.

> Werner Koch has devoted the major fraction of his professional life 
> towards creating a Free Software product for end-to-end
> cryptography. He is the active technical and architectual lead of
> the major and most widely used OpenPGP implementation (seen over 25
> years). As you have written before, he was right on a number of
> decision he took in those roles. He as a lot of experience.
> 
> Yes, I think it is worth a real consideration to give him a veto.

This is the same logic the FSF has used for decades to justify RMS's
veto power. I think this reasoning leads to bad outcomes (see: RMS).

I am *not* accusing Werner of being an RMS-like figure. I am saying that
if we want to prevent an RMS-like figure from forming, we need to stop
giving dictators-for-life veto authority over projects.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260430/d6bd1f00/attachment-0001.sig>

From aton6074 at Safe-mail.net  Thu Apr 30 16:47:11 2026
From: aton6074 at Safe-mail.net (aton6074 at Safe-mail.net)
Date: Thu, 30 Apr 2026 10:47:11 -0400
Subject: quantum computing and symmetric algotithms
Message-ID: <N1O-hRCplTzi9D@Safe-mail.net>

It would be useful in discussions on quantum computing and cryptography not to miss that vulnerability (if and to the extent it exists) only pertains to the asymmetric algorithms. As far as we know, no modern symmetric block  cipher is affected.