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