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: References:

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 > >: > > 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: 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 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: 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: 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 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: 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: References: Message-ID: 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: References: Message-ID: 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 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: 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: (Klaus Ethgen's message of "Mon, 6 Apr 2026 00:35:41 +0100") References: 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: 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: <87wlykrt7l.fsf@jacob.g10code.de> Message-ID: 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 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: 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: References: <87wlykrt7l.fsf@jacob.g10code.de> Message-ID: 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 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: 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: References: <87wlykrt7l.fsf@jacob.g10code.de> Message-ID: 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 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: 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: 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: 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: 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: References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org> <16f50eb3-d238-4bed-8b11-b5d5e7e72d25@mail.com> 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: 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: 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: References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org> <16f50eb3-d238-4bed-8b11-b5d5e7e72d25@mail.com> 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 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: 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: References: <87wlykrt7l.fsf@jacob.g10code.de> 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 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 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: 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> <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: 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: 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 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: 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: 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: References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org> <3650e64a-b30c-6c66-97f4-25883152985e@wisemo.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: > 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: 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: 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 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: 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: References: Message-ID: 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: References: Message-ID: 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: References:

Message-ID: 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 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: 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: References:

Message-ID: 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 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: 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: References:

Message-ID: <877bqgxacs.fsf@gentoo.org> john doe via Gnupg-users 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: 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: References: Message-ID: 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: 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: References: <9795f3f0-0c90-4ecf-a4f6-494ed5f3cf8d@sixdemonbag.org> <3650e64a-b30c-6c66-97f4-25883152985e@wisemo.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