From jb-gnumlists at wisemo.com  Sat Nov  1 08:08:27 2025
From: jb-gnumlists at wisemo.com (Jakob Bohm)
Date: Sat, 1 Nov 2025 08:08:27 +0100
Subject: How to setup trust?
In-Reply-To: <87pla3cca7.fsf@lispclub.com>
References: <87pla3cca7.fsf@lispclub.com>
Message-ID: <014efe78-eb8d-b653-478d-83c098a486c8@wisemo.com>

On 31/10/2025 16:37, Daniel Cerqueira wrote:
> Hi.
>
> Firstly, I am not subscribe to this list.  Please, do reply my address
> in the "To:", and the gnupg-users at gnupg.org in the "Cc:" field.  Thanks!
>
> Second, I am trying to use the trust feature of GnuPG.  My GnuPG uses
> the trust model "pgp".
>
> Now, if I do `gpg -k "<wk at gnupg.org>"` it shows this:
>
> --8<---------------cut here---------------start------------->8---
> pub   ed25519/0x63113AE866587D0A 2018-09-28 [SC] [expires: 2027-01-31]
>        Key fingerprint = AEA8 4EDC F01A D86C 4701  C85C 6311 3AE8 6658 7D0A
> uid                   [ unknown] wk at gnupg.org
> uid                   [ unknown] werner at eifzilla.de
> uid                   [ unknown] wk at g10code.com
> uid                   [ unknown] werner.koch at gnupg.com
> sub   ed25519/0x19CC1C9E085B107A 2020-08-04 [S]
>        Key fingerprint = 8777 461F 2A07 4EBC 480D  3594 19CC 1C9E 085B 107A
> sub   brainpoolP384r1/0x2B999FA9CE046B1B 2021-06-28 [E] [expires: 2027-01-10]
>        Key fingerprint = A1DB 793D C236 63E7 F914  75D8 2B99 9FA9 CE04 6B1B
> sub   ky768_bp256/0x5CF9E3DE6BC9DA95 2025-02-06 [E]
>        Key fingerprint = 5CF9E 3DE6B C9DA9 57ED2 4B39E C2D29 580F7 0B3F8 AF14B 8D7BE
> --8<---------------cut here---------------end--------------->8---
>
> The "[ unknown]" is what shows the trust?  Or it shows something else
> (like PGP's concept of validity)?
"Trust" is PGP's concept of validity.? Not sure if the --list-keys 
output prints out
the full trust result, or only the calculated result from other 
signatures.? Someone
else on the list has to answer that.
>
> Third, how can I make this 0x63113AE866587D0A key, to be marginally
> trusted?
The root of trust in the PGP model is to "ultimately trust" one of your 
own keys (not
necessarily the one you use for regular e-mail), and then count the 
trust levels of keys
that signed other keys.

For gnupg, this ultimate trust is typically granted to all the keys for 
which your copy
of gnupg stores the private key under your user account, plus any 
offline keys listed
in the "--trusted-key" option (which is usually placed in a gnupg config 
file).

On top of the default calculation of trust based on signatures tracing 
back to your
trusts, gnupg has a personal database of "ownertrusts", which can be changed
interactively with the command "gpg --edit-key" and saved with the command
"gpg --export-ownertrust".? Usually, gnupg will prompt you to set the 
trust for
any key where you have not yet set it.? Either when encountering the key 
in its
calculations or when rerunning the calculculations with the command
"gpg --update-trustdb" .?? Much more about this concept can be found in the
gnupg handbook .

> I have tried making a local signature with cert-level of 1 and also have
> edited this key's `trust` to be "marginal", then "save".  Afterwards, I
> did an `gpg --update-trustdb`, and still I get the output above :-( .
>
>
> I am not understanding how the GnuPG's trust feature works.  I want to
> learn.
>
>
> Cheers for Freedom :-) ,
>
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 dan.git at lispclub.com  Sun Nov  2 02:32:11 2025
From: dan.git at lispclub.com (Daniel Cerqueira)
Date: Sun, 02 Nov 2025 01:32:11 +0000
Subject: How to setup trust?
In-Reply-To: <014efe78-eb8d-b653-478d-83c098a486c8@wisemo.com> (Jakob Bohm's
 message of "Sat, 1 Nov 2025 08:08:27 +0100")
References: <87pla3cca7.fsf@lispclub.com>
 <014efe78-eb8d-b653-478d-83c098a486c8@wisemo.com>
Message-ID: <87ecqhcj8k.fsf@lispclub.com>

Jakob Bohm <jb-gnumlists at wisemo.com> writes:

> Much more about this concept can be found in the gnupg handbook .

Thank you, Jakob, for this info.  I haven't read all the GnuPG Handbook,
yet.

I am now reading all past mails to this list about "trust", am also
reading GnuPG Privacy Handbook; all while reading the `man 1 gpg`.  I
will also be reading the GnuPG FAQ.

So, it will take some time for me to getting back on this thread.

Hopefully, after this investment in knowledge, I will get an
understanding about the concept of Trust with GnuPG, the Web of Trust
concept; in order to write Internet Log articles (in a Web Log -- Blog
-- and in a Gopher Log -- Phlog) to clarify people about these concepts.

Unfortunately, I believe there is a big misunderstanding about what the
Web of Trust is, what is Trust to GnuPG, what is Ownertrust in GnuPG,
and what is validity in GnuPG.  I, myself, struggle with these concepts,
even after having read a book about PGP 7 and an introduction to
cryptography.

Lastly, and most important, I want to thank Werner and all the GnuPG
Hackers, for making GnuPG a reality.  I really love this project.  I
also support the LibrePGP initiative; not meaning a defensive move only,
but as a way for the future.  Finally, thank you for you that keep this
list a positive and welcoming environment for learning about GnuPG!

I will be coming to this thread, when the time has come.

Cheers for Freedom,


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

From bwalzer at 59.ca  Sun Nov  2 20:46:58 2025
From: bwalzer at 59.ca (Bruce Walzer)
Date: Sun, 2 Nov 2025 13:46:58 -0600
Subject: My comments on: Legacy Encryption Downgrade Attacks against GnuPG
In-Reply-To: <87ed6fb4g3.fsf@jacob.g10code.de>
References: <87ed6fb4g3.fsf@jacob.g10code.de>
Message-ID: <aQe1MgSrMXvS9qxe@watt.59.ca>

This paper has been discussed on this list before. So I will assume
possible interest and will post a link to my comments:

Legacy Encryption Downgrade Attacks against LibrePGP and CMS: Some Comments
    https://articles.59.ca/doku.php?id=pgpfan:ledowngrade

Bruce


From rjh at sixdemonbag.org  Thu Nov  6 20:53:26 2025
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Thu, 6 Nov 2025 14:53:26 -0500
Subject: GPGMEPP and C++ antipatterns
Message-ID: <13fbd315-e6ba-453a-8403-4286976d3d0a@sixdemonbag.org>

After using GPGMEPP for a week or so, I'm pleased with it. Somebody 
clearly put some thought into how to make it a properly C++ library, 
rather than just a thin wrapper around a C one. Whoever's responsible 
for that (Ingo?), thank you.

However, I do have a couple of minor nits. (Of course I do. It's me.)

First, a number of functions accept unsigned ints as a parameter. This 
involves a minor pain point for those of us working in environments that 
require us to follow the MISRA C++ guidelines. Admittedly, it's a 
one-letter fix:

	(*ctx).setKeyListMode(0);
		|
	     becomes
		|
		V
	(*ctx).setKeyListMode(0U);

but it would be nice if we could find some way to avoid one letter of 
syntactic sugar and let us express code in the most natural way.

Second, MISRA has ? I can only call them _opinions_, shall we say ? on 
the subject of pointers. Look at, e.g., creating a new Context:

	auto ctx = unique_ptr<Context>(OpenPGP);
	if (nullptr == ctx) {
	    // handle the error
	}

Here there are two problems. The first is that GPGMEPP is using 
old-style enums rather than modern C++ class enums, which means they're 
not typesafe and it's harder for static analysis tools to detect when 
you're feeding in garbage. The second is that per MISRA, unique_ptrs and 
shared_ptrs should be created only by calls to make_unique and/or 
make_shared, not by direct application of the constructor.

Hence, two more suggestions. First, replace all enums with C++ class 
enums, and second, make createForProtocol take a template parameter of 
the type of pointer to return, whether unique, shared, or raw.

These minor problems aren't creating any obstacles to my development, 
just requiring me to fill out a small amount of paperwork documenting 
the deviations from MISRA. All in all I quite like GPGMEPP. Thanks for 
the code, guys. :)

-------------- 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/20251106/6d9fae7d/attachment.sig>

From rjh at sixdemonbag.org  Thu Nov  6 22:00:52 2025
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Thu, 6 Nov 2025 16:00:52 -0500
Subject: GPGMEPP and C++ antipatterns
In-Reply-To: <13fbd315-e6ba-453a-8403-4286976d3d0a@sixdemonbag.org>
References: <13fbd315-e6ba-453a-8403-4286976d3d0a@sixdemonbag.org>
Message-ID: <9142e0ea-7a5c-4c38-bf8f-9bf8f4c6cd36@sixdemonbag.org>

>  ????auto ctx = unique_ptr<Context>(OpenPGP);

Gah! I was literally looking at my code while copying it and still 
somehow managed to goof it.

"auto ctx = unique_ptr<Context>(Context::createForProtocol(OpenPGP));"

-------------- 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/20251106/14934410/attachment.sig>

From johndoe65534 at mail.com  Fri Nov  7 07:47:57 2025
From: johndoe65534 at mail.com (john doe)
Date: Fri, 7 Nov 2025 07:47:57 +0100
Subject: GPGMEPP and C++ antipatterns
In-Reply-To: <13fbd315-e6ba-453a-8403-4286976d3d0a@sixdemonbag.org>
References: <13fbd315-e6ba-453a-8403-4286976d3d0a@sixdemonbag.org>
Message-ID: <d5996978-6560-4465-9bc0-77a6eea3f21f@mail.com>

On 11/6/25 20:53, Robert J. Hansen via Gnupg-users wrote:
> After using GPGMEPP for a week or so, I'm pleased with it. Somebody 
> clearly put some thought into how to make it a properly C++ library, 
> rather than just a thin wrapper around a C one. Whoever's responsible 
> for that (Ingo?), thank you.
> 
> However, I do have a couple of minor nits. (Of course I do. It's me.)
> 

I'm not sure why you are posting this here instead of patching this up 
and creating a PR.

-- 
John Doe


From wk at gnupg.org  Fri Nov  7 09:53:09 2025
From: wk at gnupg.org (Werner Koch)
Date: Fri, 07 Nov 2025 09:53:09 +0100
Subject: GPGMEPP and C++ antipatterns
In-Reply-To: <d5996978-6560-4465-9bc0-77a6eea3f21f@mail.com> (john doe via
 Gnupg-users's message of "Fri, 7 Nov 2025 07:47:57 +0100")
References: <13fbd315-e6ba-453a-8403-4286976d3d0a@sixdemonbag.org>
 <d5996978-6560-4465-9bc0-77a6eea3f21f@mail.com>
Message-ID: <87v7jmz0ju.fsf@jacob.g10code.de>

On Fri,  7 Nov 2025 07:47, john doe said:
> I'm not sure why you are posting this here instead of patching this up
> and creating a PR.

Because a mailing list is a better media than a bug tracker because it
reaches a muchwider audience.  The bug tracker is only monitored by a
few hackers.

gnupg-devel might have been more appropriate but gnupg-user may also
mean users of GPGME.


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/20251107/8fa0374f/attachment.sig>

From jtbaldikoski at gmail.com  Fri Nov  7 01:47:22 2025
From: jtbaldikoski at gmail.com (Jack Baldikoski)
Date: Thu, 6 Nov 2025 16:47:22 -0800
Subject: Question/Bug?
Message-ID: <CA+gJm2ZpmFiq5K_wCdjJ-B18vy+CW6g0gj4x7drZ=yDJVi9wyw@mail.gmail.com>

I've tried following Thunderbird's instructions here
<https://mzl.la/4bFoVkJ> to make my private key RFC 4880-compatible with
the --rfc4880 flag, but GPG does not change any of the feature flags. Am I
doing something wrong?

Jack
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251106/7f1c3dd2/attachment.html>

From alci at mecadu.org  Fri Nov  7 11:43:58 2025
From: alci at mecadu.org (Franck Routier (Personnel))
Date: Fri, 7 Nov 2025 11:43:58 +0100
Subject: No PIN asked for with libpam-poldi
Message-ID: <95ba74c7-5a90-4e7e-8df4-c21bb1a554b3@mecadu.org>

Hi,

I'm trying to use my Yubikey with libpam-poldi to sudo on a Ubuntu based 
OS (Tuxedo OS).

My card is working:

$ gpg --card-status

Reader ...........: Yubico YubiKey OTP FIDO CCID 00 00
Application ID ...: Dxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Application type .: OpenPGP
Version ..........: 3.4
Manufacturer .....: Yubico
[...]

When using pass password manager, I am asked for a PIN to unlock the 
card, touch it and I get my password unencrypted.
It also works with browserpass Firefox extension.

So far so good.

Now, I have setup libpam-poldi:
- created the /etc/poldi/localdb/users and linked my user with the 
Application ID
- created the /etc/poldi/localdb/keys/MyAppID file, with

sudo sh -c 'gpg-connect-agent "/datafile 
/etc/poldi/localdb/keys/MyAppID" "SCD READKEY --advanced OPENPGP.3" /bye'

My .gnupg/scdaemon.conf file looks like this:
disable-ccid

My /etc/pam.d/sudo and /etc/pam.d/sudo-i have auth sufficient pam_poldi.so

And finally .gnupg/gpg-agent.conf looks like:
pinentry-program /usr/bin/pinentry-qt
debug-lvel 3
enable-ssh-support
ttyname $GPG_TTY
default-cache-ttl 60
max-cache-ttl 120


Nos, when I try to sudo, I am asked to insert my card, and asked for a 
password, but never for a PIN:

$sudo su
Insert authentication card for user `franck'
Trying authentication as user `franck'...
[sudo] password for franck:

Journalctl -f shows:
gpg-agent[13666]: scdaemon[13666]: detected reader 'Yubico YubiKey 
OTP+FIDO+CCID 00 00'
gpg-agent[13666]: scdaemon[13666]: detected reader 'Yubico YubiKey 
OTP+FIDO+CCID 00 00'

But I am never given the opportunity to unlock the card...
Any idea to fix or to troubleshoot this ?

Thanks
Franck

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251107/69d23db0/attachment.html>

From rjh at sixdemonbag.org  Fri Nov  7 14:20:25 2025
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Fri, 7 Nov 2025 08:20:25 -0500
Subject: The community fringe (was GPGMEPP)
In-Reply-To: <d5996978-6560-4465-9bc0-77a6eea3f21f@mail.com>
References: <13fbd315-e6ba-453a-8403-4286976d3d0a@sixdemonbag.org>
 <d5996978-6560-4465-9bc0-77a6eea3f21f@mail.com>
Message-ID: <cc4dc2ce-2f07-417b-ab75-d594ce98f493@sixdemonbag.org>

> I'm not sure why you are posting this here instead of patching this up 
> and creating a PR.

A couple of solid ones.

1. Do I understand things correctly? We're not talking about a bug fix, 
we're talking about architectural and API changes. These are not things 
to be done lightly. Discussing proposed changes before going through the 
work of implementing them is generally a better option.

2. I'm a former government-funded digital forensics researcher who has 
delivered research results at NSA. That's enough to make me permanently 
suspect in the eyes of some people in the community. For this reason I 
don't touch the code. I don't want anyone who might be thinking of using 
GnuPG decide "no, no, I can't trust it, they accept patches from people 
with NSA ties."

#2 also has a disturbing aspect of there are people in this community 
who are clinically paranoid and mentally ill. 95% of these people are 
harmless victims of a terrible mental illness who deserve our love, 
support, and understanding.

5% of these people send me unhinged emails threatening my life.

=====

If you are legitimate, wait three days for me to cool down you asshole. 
I have sat here and tolerated the pandering to Windows people the Gnu 
people have been telling Microsoft people are stupid long enough. 
Personally, these statements by you are TOTALLY out of character to 
***EVERYTHING*** I have heard from Werner Koch and others say for years. 
  I have assumed all during this time that Werner and the others are 
much more intelligent than me (true).  I have also assumed that they are 
so busy that they haven't had time to do much of anything else (that I 
don't know the truth of).  I don't give a damn how many people have 
signed your god-damn keys. THAT IS WHY I SAY, IF YOU ARE A GOD-DAMN FBI 
AGENT YOU GO TO HELL!!!  I WILL KILL YOU, YOU SON OF SATAN!!!  This 
message is signed and encrypted. Take it for what it is worth.  If the 
filthy United States would allow me to adopt my nom-de-guerre as 
legitimate legal alias I would do so and MAYBE (*JUST* *MAYBE*) the 
signing of this message would have more meaning to you.  I doubt it though.

=====

Really, folks, that's what some users send me. That's about one-sixth of 
the complete email, which is ? well, much the same as that excerpt. That 
guy also dug up my home address, my employer, and my phone number. I had 
to get the police involved and it was a bad experience for everyone.

Also remember that when the SKS keyserver network was poisoned by 
certificates sporting hundreds of thousands of spurious signatures, that 
was almost certainly done by someone who believed they needed to "save 
the GnuPG ecosystem". The fact they used the certificates of Daniel Kahn 
Gillmor and myself to wage this attack also tells you who this deranged 
person thought GnuPG needed to be saved from. The more I touch the code, 
the more the nutcases like the key-poisoner are incentivized to act.

So, yeah. As a general rule I don't touch the code unless explicitly 
invited. I don't want to cause anyone to lose faith in GnuPG, and I 
don't want to provoke the crazies into "saving GnuPG".

-------------- 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/20251107/41a9002a/attachment.sig>

From kloecker at kde.org  Fri Nov  7 15:56:58 2025
From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=)
Date: Fri, 07 Nov 2025 15:56:58 +0100
Subject: No PIN asked for with libpam-poldi
In-Reply-To: <95ba74c7-5a90-4e7e-8df4-c21bb1a554b3@mecadu.org>
References: <95ba74c7-5a90-4e7e-8df4-c21bb1a554b3@mecadu.org>
Message-ID: <4634150.niJfEyVGOH@daneel>

On Freitag, 7. November 2025 11:43:58 Mitteleurop?ische Normalzeit Franck 
Routier (Personnel) via Gnupg-users wrote:
> I'm trying to use my Yubikey with libpam-poldi to sudo on a Ubuntu based
> OS (Tuxedo OS).
[...]
> My .gnupg/scdaemon.conf file looks like this:
> disable-ccid
> 
> My /etc/pam.d/sudo and /etc/pam.d/sudo-i have auth sufficient pam_poldi.so
> 
> And finally .gnupg/gpg-agent.conf looks like:
> pinentry-program /usr/bin/pinentry-qt
> debug-lvel 3

Typo? In any case, avoid the weird debug-level setting. Use "debug ipc" 
instead. Also set log-file so that the logs don't end up in some random place 
(or nowhere).

> enable-ssh-support
> ttyname $GPG_TTY
> default-cache-ttl 60
> max-cache-ttl 120
> 
> 
> Nos, when I try to sudo, I am asked to insert my card, and asked for a
> password, but never for a PIN:
> 
> $sudo su
> Insert authentication card for user `franck'
> Trying authentication as user `franck'...
> [sudo] password for franck:

Very likely gpg-agent fails to start pinentry-qt or pinentry-qt fails to start 
because there's no window manager running. Try using pinentry-curses or 
pinentry-tty instead of pinentry-qt if you are anyway using the terminal.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 265 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251107/b5b9f2c5/attachment.sig>

From alci at mecadu.org  Fri Nov  7 18:36:43 2025
From: alci at mecadu.org (Franck Routier (Personnel))
Date: Fri, 7 Nov 2025 18:36:43 +0100
Subject: No PIN asked for with libpam-poldi
In-Reply-To: <4634150.niJfEyVGOH@daneel>
References: <95ba74c7-5a90-4e7e-8df4-c21bb1a554b3@mecadu.org>
 <4634150.niJfEyVGOH@daneel>
Message-ID: <97fb7b4a-67c1-46a6-989b-48cd32c060ec@mecadu.org>

> Typo? In any case, avoid the weird debug-level setting. Use "debug ipc"
> instead. Also set log-file so that the logs don't end up in some random place
> (or nowhere).
Yes typo. I removed it alltogether for now:

pinentry-program /usr/bin/pinentry-qt
enable-ssh-support
ttyname $GPG_TTY
default-cache-ttl 60
max-cache-ttl 120

> Very likely gpg-agent fails to start pinentry-qt or pinentry-qt fails to start
> because there's no window manager running. Try using pinentry-curses or
> pinentry-tty instead of pinentry-qt if you are anyway using the terminal.
In fact gpg-agent seems to be able to call pinentry-qt, as when I use 
pass or browserpass, it works and I get a pretty pinentry window...

That said, switching to pinentry-tty does not solve the problem with pam.
In fact I can see pinentry-tty working with pass and failing with sudo 
in the same terminal session:

$ pass perso/ameli.fr
Please unlock the card
Number: 10 955 601
Holder: Franck Routier
PIN:
*************************
$ sudo su
Insert authentication card for user `franck'
Trying authentication as user `franck'...
[sudo] password for franck:


Franck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251107/41bd40bb/attachment-0001.html>

From bwalzer at 59.ca  Sat Nov  8 19:16:33 2025
From: bwalzer at 59.ca (Bruce Walzer)
Date: Sat, 8 Nov 2025 12:16:33 -0600
Subject: Question/Bug?
In-Reply-To: <CA+gJm2ZpmFiq5K_wCdjJ-B18vy+CW6g0gj4x7drZ=yDJVi9wyw@mail.gmail.com>
References: <CA+gJm2ZpmFiq5K_wCdjJ-B18vy+CW6g0gj4x7drZ=yDJVi9wyw@mail.gmail.com>
Message-ID: <aQ-JAXshfbPQ8S2h@ohm.59.ca>

On Thu, Nov 06, 2025 at 04:47:22PM -0800, Jack Baldikoski via Gnupg-users wrote:
> I've tried following Thunderbird's instructions here
> <https://mzl.la/4bFoVkJ> to make my private key RFC 4880-compatible with
> the --rfc4880 flag, but GPG does not change any of the feature flags. Am I
> doing something wrong?

Is this now no longer an issue for Thunderbird due to RNP support as
suggested in the comment in the bug report?

The --rfc4880 flag doesn't seem to affect the preferences. The Arch
Wiki suggests you do this:

    setpref AES256 AES192 AES SHA512 SHA384 SHA256 SHA224 ZLIB BZIP2 ZIP

... with expert mode. I dunno what the expert mode does. Seems to work
without.

* https://wiki.archlinux.org/title/GnuPG#OpenPGP_compatibility

I note that the Arch page has gotten very partisan towards the RFC9580
faction at the expense of the LibrePGP faction. Sort of annoying.

Bruce


From wk at gnupg.org  Mon Nov 10 10:43:15 2025
From: wk at gnupg.org (Werner Koch)
Date: Mon, 10 Nov 2025 10:43:15 +0100
Subject: Question/Bug?
In-Reply-To: <aQ-JAXshfbPQ8S2h@ohm.59.ca> (Bruce Walzer via Gnupg-users's
 message of "Sat, 8 Nov 2025 12:16:33 -0600")
References: <CA+gJm2ZpmFiq5K_wCdjJ-B18vy+CW6g0gj4x7drZ=yDJVi9wyw@mail.gmail.com>
 <aQ-JAXshfbPQ8S2h@ohm.59.ca>
Message-ID: <87bjlaxlxo.fsf@jacob.g10code.de>

Hi!

BTW, RFC-4880 compatibily would also mean to drop support for Curve25519
(ed25519 and cv25519) because they are not covered by the ECC extension
to OpenPGP (RFC-6637).  I doubt that anyone wants that.

OCB mode is meanwhile widely used and RNP (the Thunderbird *PGP library)
also supports it (actually cross-tested with GnuPG back in 2018).  The
TB maintainer just refuses to enable this feature in RNP.


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/20251110/c89c886c/attachment.sig>

From bernhard at intevation.de  Mon Nov 10 12:38:21 2025
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 10 Nov 2025 12:38:21 +0100
Subject: @GnuPG@mstdn.social Mastodon account (re: gnupg.social domain)
Message-ID: <202511101238.21660.bernhard@intevation.de>

Am Donnerstag 23 Oktober 2025 22:18:08 schrieb Juergen M. BRUCKNER via 
Gnupg-users:
> Well there is a Mastodon account (@GnuPG at mstdn.social) for GnuPG. Don't
> know who runs it, but it seems to be a official account.

Currently I am the one running https://mstdn.social/@GnuPG
in behalf of the GnuPG (and Gpg4win) initiative. 

(it also says there:
  currently operated by @ber at social.tchncs.de/
and was discussed here on this list, e.g. on 2023-05-31 15:23.)

I used to run it on behalf of the GnuPG e.V (the association was 
discontinued), so now it is more or less the core devs, supporters and other 
helpers here and on gnupg-devel@ that form the core group responsible for 
GnuPG. The majority of technical work for th products is currently done by 
10code as far as I can see.

From my perspective we do not need our own Fediverse or Mastodon instance
at this point. mstdn.social and other servers are maintained well and allow
us to us microblogging in a federated way. 

Best Regards,
Bernhard

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

From hfollmann at itcfollmann.com  Mon Nov 10 14:52:25 2025
From: hfollmann at itcfollmann.com (Henning Follmann)
Date: Mon, 10 Nov 2025 08:52:25 -0500
Subject: @GnuPG@mstdn.social Mastodon account (re: gnupg.social domain)
In-Reply-To: <202511101238.21660.bernhard@intevation.de>
References: <202511101238.21660.bernhard@intevation.de>
Message-ID: <aRHuGUYJ9l-0fnun@fedora>

On Mon, Nov 10, 2025 at 12:38:21PM +0100, Bernhard Reiter via Gnupg-users wrote:
> Am Donnerstag 23 Oktober 2025 22:18:08 schrieb Juergen M. BRUCKNER via 
> Gnupg-users:
> > Well there is a Mastodon account (@GnuPG at mstdn.social) for GnuPG. Don't
> > know who runs it, but it seems to be a official account.
> 
> Currently I am the one running https://mstdn.social/@GnuPG
> in behalf of the GnuPG (and Gpg4win) initiative. 
> 
> (it also says there:
>   currently operated by @ber at social.tchncs.de/
> and was discussed here on this list, e.g. on 2023-05-31 15:23.)
> 
> I used to run it on behalf of the GnuPG e.V (the association was 
> discontinued), so now it is more or less the core devs, supporters and other 
> helpers here and on gnupg-devel@ that form the core group responsible for 
> GnuPG. The majority of technical work for th products is currently done by 
> 10code as far as I can see.
> 
> From my perspective we do not need our own Fediverse or Mastodon instance
> at this point. mstdn.social and other servers are maintained well and allow
> us to us microblogging in a federated way. 
> 

Hello,

I already dropped the domain. If you change your mind, you might be able to
register it again (if no domain hog took it).


-H







From bernhard at intevation.de  Mon Nov 10 15:19:46 2025
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 10 Nov 2025 15:19:46 +0100
Subject: @GnuPG@mstdn.social Mastodon account (re: gnupg.social domain)
In-Reply-To: <aRHuGUYJ9l-0fnun@fedora>
References: <202511101238.21660.bernhard@intevation.de>
 <aRHuGUYJ9l-0fnun@fedora>
Message-ID: <202511101519.46618.bernhard@intevation.de>

Am Montag 10 November 2025 14:52:25 schrieb Henning Follmann:
> I already dropped the domain. If you change your mind, you might be able to
> register it again (if no domain hog took it).

Thanks for having reserved it and the principal idea!
(There are so many toplevel domains these days that someone cannot get all of 
them to prevent typo squatting or domain hogging. At least I believe that 
user just will have to pay more attention.)


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

From loup at loup-vaillant.fr  Tue Nov 11 10:44:01 2025
From: loup at loup-vaillant.fr (Loup Vaillant)
Date: Tue, 11 Nov 2025 10:44:01 +0100
Subject: GnuPG 2.4.4 still using legacy packets?
Message-ID: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>

Hi,

I'm currently trying to implement OpenPGP signatures to sign my code. 
RFC 9580 is fairly readable, but it?s not crystal clear how people do 
signatures in practice, so I?used GnuPG as a reference.  Version 2.4.4, 
as installed by default on my Ubuntu 24.04.

I made a signature with the following command:

     gpg --detach-sign monocypher-4.0.2.tar.gz

Here?s the hex dump of the resulting file:

     0000  88 75 04 00 16 0a 00 1d  16 21 04 bb bc 09 18 65
     0010  b9 94 0a 37 ca 9a df 86  40 f6 ba 7b ff b3 4a 05
     0020  02 69 12 0d 2c 00 0a 09  10 86 40 f6 ba 7b ff b3
     0030  4a fb 3b 00 fe 3f a0 ab  23 e1 5f df e2 21 a2 5b
     0040  2b 9b 01 5d 7c 9a 8d ec  da ac c8 85 96 24 94 bf
     0050  f9 da 57 86 a8 00 f9 01  10 75 54 63 b2 86 7d a7
     0060  7d 13 f5 5e cb 09 82 f9  c2 11 84 4d ae dc 9f fb
     0070  4a 5a e3 8d 82 76 0f
     0077

Reading the RFC, the first bytes should contain a packet header.
The first byte is the Encoded Packet Type ID.  So:

     0x88 = 0b10001000

Broken down, I get:

     10  : Legacy format
     0010: 2 (SIG)
     00  : Length is encoded in one byte

So the next byte, 0x75, should be the length of the body.  Which matches 
the length of my file (0x77 bytes total, minus the 2-byte header).  I 
have yet to decipher the rest of the packet, but that?s not my main 
concern right now. My question is, *did GnuPG really produce a legacy 
packet?*

The RFC states that is should not:

 > The Legacy packet format SHOULD NOT be used to generate new data,
 > unless the recipient is known to only support the Legacy packet
 > format. This latter case is extremely unlikely, as the Legacy packet
 > format was obsoleted by [RFC2440] in 1998.

As far as I can tell, version 2.4.4 is from last year.  And yet it 
outputs *by default* a legacy format that was obsoleted 26 years prior? 
I must be missing something.  Either I read the hex dump wrong, or 
there?s a justification behind GnuPG?s use of the legacy format.  If 
someone could explain, I?d be very grateful.

Thanks,
Loup.



From bwalzer at 59.ca  Tue Nov 11 13:11:59 2025
From: bwalzer at 59.ca (Bruce Walzer)
Date: Tue, 11 Nov 2025 06:11:59 -0600
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
Message-ID: <aRMoD7nyHRNIL92A@ohm.59.ca>

On Tue, Nov 11, 2025 at 10:44:01AM +0100, Loup Vaillant wrote:
[..]
>
>     0x88 = 0b10001000
>
> Broken down, I get:
>
>     10  : Legacy format
[...]
> The RFC {9580} states that is should not:
>
> > The Legacy packet format SHOULD NOT be used to generate new data,
> > unless the recipient is known to only support the Legacy packet
> > format. This latter case is extremely unlikely, as the Legacy packet
> > format was obsoleted by [RFC2440] in 1998.

>From RFC-2440:

>PGP 2.6.x only uses old format packets. Thus, software that
>interoperates with those versions of PGP must only use old format
>packets. If interoperability is not an issue, either format may be
>used.

No preference is expressed at all in RFC-2440. So it appears that
RFC-9580 is simply incorrect.

>From RFC-4880:

>PGP 2.6.x only uses old format packets. Thus, software that
>interoperates with those versions of PGP must only use old format
>packets.  If interoperability is not an issue, the new packet format
>is RECOMMENDED.

So RFC-9580 is also incorrect for RFC-4880 as well. I don't know the
reasoning behind RFC-9580 changing this to "SHOULD NOT" and why the
incorrect language was used. You would probably have to ask on the
appropriate mailing list to find out if anyone from that faction still
knows, is still around, and is interested enough to answer your
question.

There doesn't seem to be any practical reason to use a new packet
header if the packet tag is less than 16. Otherwise you *have* to use
a new packet header.

LibrePGP introduces no changes from RFC-4880 with respect to this. So
in the world of GnuPG the new packet format is only "RECOMMENDED" for
cases where interoperability is not an issue.

Bruce


From andrewg at andrewg.com  Tue Nov 11 15:59:30 2025
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Tue, 11 Nov 2025 14:59:30 +0000
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <aRMoD7nyHRNIL92A@ohm.59.ca>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
Message-ID: <a5b39943-464a-4a7a-8b78-6d2e0ffabb4f@andrewg.com>

Hi, Bruce.

On 11/11/2025 12:11, Bruce Walzer via Gnupg-users wrote:
>
> No preference is expressed at all in RFC-2440. So it appears that
> RFC-9580 is simply incorrect.
...
> So RFC-9580 is also incorrect for RFC-4880 as well.

It is neither accurate nor helpful to use the term "incorrect". None of 
these documents claim correctness, they are merely specifications. That 
means that they can and will differ; it does not mean that any of them 
are more "correct" than any other. All that you can say is that some of 
them are more recent than others.

> I don't know the
> reasoning behind RFC-9580 changing this to "SHOULD NOT" and why the
> incorrect language was used.

Surely the reason is obvious? It is desirable in general to gracefully 
sunset legacy formats. As you have pointed out already, the 
specification changed between RFC2440 and RFC4880, to explicitly prefer 
the newer format (with caveats). RFC9580 merely strengthens the language 
again to more strongly prefer the newer format. This seems to me to be a 
natural evolution of the spec.

> You would probably have to ask on the
> appropriate mailing list to find out if anyone from that faction still
> knows, is still around, and is interested enough to answer your
> question.

This backhanded snark is unbecoming of you, Bruce. The authors of 
RFC9580 are named individuals - three of whom currently work on PGP 
software, and one of those (Niibe) works on GnuPG. Your insinuation that 
RFC9580 was written by shadowy, disinterested figures is an insult to 
its authors, and you should consider issuing an apology.

For reference, the relevant mailing list is openpgp at lists.ietf.org 
(https://mailarchive.ietf.org/arch/browse/openpgp/)
> There doesn't seem to be any practical reason to use a new packet
> header if the packet tag is less than 16. Otherwise you *have* to use
> a new packet header.

The practical reason is that the implementers want the ability 
(eventually) to drop support for the legacy format. This can't be done 
if today's software is still generating it. Considering that all 
RFC2440-compatible software (i.e. anything written in the last 25 years) 
MUST implement the modern format, any software that cannot read it is so 
far out of date that it doesn't support any modern cryptography either 
(for example, it won't support MDC) so is not safe for use anyway, other 
than to read prehistoric archives.

A



From andrewg at andrewg.com  Tue Nov 11 15:59:30 2025
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Tue, 11 Nov 2025 14:59:30 +0000
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <aRMoD7nyHRNIL92A@ohm.59.ca>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
Message-ID: <a5b39943-464a-4a7a-8b78-6d2e0ffabb4f@andrewg.com>

Hi, Bruce.

On 11/11/2025 12:11, Bruce Walzer via Gnupg-users wrote:
>
> No preference is expressed at all in RFC-2440. So it appears that
> RFC-9580 is simply incorrect.
...
> So RFC-9580 is also incorrect for RFC-4880 as well.

It is neither accurate nor helpful to use the term "incorrect". None of 
these documents claim correctness, they are merely specifications. That 
means that they can and will differ; it does not mean that any of them 
are more "correct" than any other. All that you can say is that some of 
them are more recent than others.

> I don't know the
> reasoning behind RFC-9580 changing this to "SHOULD NOT" and why the
> incorrect language was used.

Surely the reason is obvious? It is desirable in general to gracefully 
sunset legacy formats. As you have pointed out already, the 
specification changed between RFC2440 and RFC4880, to explicitly prefer 
the newer format (with caveats). RFC9580 merely strengthens the language 
again to more strongly prefer the newer format. This seems to me to be a 
natural evolution of the spec.

> You would probably have to ask on the
> appropriate mailing list to find out if anyone from that faction still
> knows, is still around, and is interested enough to answer your
> question.

This backhanded snark is unbecoming of you, Bruce. The authors of 
RFC9580 are named individuals - three of whom currently work on PGP 
software, and one of those (Niibe) works on GnuPG. Your insinuation that 
RFC9580 was written by shadowy, disinterested figures is an insult to 
its authors, and you should consider issuing an apology.

For reference, the relevant mailing list is openpgp at lists.ietf.org 
(https://mailarchive.ietf.org/arch/browse/openpgp/)
> There doesn't seem to be any practical reason to use a new packet
> header if the packet tag is less than 16. Otherwise you *have* to use
> a new packet header.

The practical reason is that the implementers want the ability 
(eventually) to drop support for the legacy format. This can't be done 
if today's software is still generating it. Considering that all 
RFC2440-compatible software (i.e. anything written in the last 25 years) 
MUST implement the modern format, any software that cannot read it is so 
far out of date that it doesn't support any modern cryptography either 
(for example, it won't support MDC) so is not safe for use anyway, other 
than to read prehistoric archives.

A



From wk at gnupg.org  Tue Nov 11 16:36:34 2025
From: wk at gnupg.org (Werner Koch)
Date: Tue, 11 Nov 2025 16:36:34 +0100
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr> (Loup
 Vaillant's message of "Tue, 11 Nov 2025 10:44:01 +0100")
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
Message-ID: <87ldkcvawt.fsf@jacob.g10code.de>

On Tue, 11 Nov 2025 10:44, Loup Vaillant said:

> code. RFC 9580 is fairly readable, but it?s not crystal clear how
> people do signatures in practice, so I?used GnuPG as a reference.

Oh and I thought one of the goals was to make it better readable ;-).
Yet another goal not achieved - which is also not a surprise given the
heavily increased size of the the specification.

>     10  : Legacy format

I don't know what you mean by Legacy Format.  It might be that RFC9580
defines that as legacy but there is no reason for this.  The old CTB
works just fine and can't be dropped for backward compatibility reasons.

> As far as I can tell, version 2.4.4 is from last year.  And yet it
> outputs *by default* a legacy format that was obsoleted 26 years

It has never been obsoleted.  BTW, GnuPG does not implement the new
RFC9580 specification but LibrePGP which is just a minor update to the
well matured RFC4880 specification.


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/20251111/dfe7f773/attachment.sig>

From rjh at sixdemonbag.org  Tue Nov 11 16:46:46 2025
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Tue, 11 Nov 2025 10:46:46 -0500
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <a5b39943-464a-4a7a-8b78-6d2e0ffabb4f@andrewg.com>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
 <a5b39943-464a-4a7a-8b78-6d2e0ffabb4f@andrewg.com>
Message-ID: <42c96fd8-d275-4654-86d1-4458cf3f8fb0@sixdemonbag.org>

> This backhanded snark is unbecoming of you, Bruce. The authors of 
> RFC9580 are named individuals - three of whom currently work on PGP 
> software, and one of those (Niibe) works on GnuPG. Your insinuation that 
> RFC9580 was written by shadowy, disinterested figures is an insult to 
> its authors, and you should consider issuing an apology.

Thank you, Andrew, for being the first to say this, and to do it in a 
gentlemanly way.

I completely agree with Andrew.

-------------- 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/20251111/d7e5f7bf/attachment.sig>

From bwalzer at 59.ca  Tue Nov 11 21:57:16 2025
From: bwalzer at 59.ca (Bruce Walzer)
Date: Tue, 11 Nov 2025 14:57:16 -0600
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <a5b39943-464a-4a7a-8b78-6d2e0ffabb4f@andrewg.com>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
 <a5b39943-464a-4a7a-8b78-6d2e0ffabb4f@andrewg.com>
Message-ID: <aROjLAmLnFJU_2kL@ohm.59.ca>

On Tue, Nov 11, 2025 at 02:59:30PM +0000, Andrew Gallagher via Gnupg-users wrote:
> Hi, Bruce.
> 
> On 11/11/2025 12:11, Bruce Walzer via Gnupg-users wrote:
> > 
> > No preference is expressed at all in RFC-2440. So it appears that
> > RFC-9580 is simply incorrect.
> ...
> > So RFC-9580 is also incorrect for RFC-4880 as well.
> 
> It is neither accurate nor helpful to use the term "incorrect". None of
> these documents claim correctness, they are merely specifications. That
> means that they can and will differ; it does not mean that any of them are
> more "correct" than any other. All that you can say is that some of them are
> more recent than others.

RFC-9580 states:

>...as the Legacy packet format was obsoleted by [RFC2440] in 1998.

That statement is literally incorrect for RFC2440. So I don't really
know what you mean here. It is simply wrong and I don't see how any
further discussion is possible.

> 
> > I don't know the
> > reasoning behind RFC-9580 changing this to "SHOULD NOT" and why the
> > incorrect language was used.
> 
> Surely the reason is obvious? It is desirable in general to gracefully
> sunset legacy formats. As you have pointed out already, the specification
> changed between RFC2440 and RFC4880, to explicitly prefer the newer format
> (with caveats). RFC9580 merely strengthens the language again to more
> strongly prefer the newer format. This seems to me to be a natural evolution
> of the spec.

Yes, but *why* was the language strngthened from RFC-4880 to more
strongly prefer the newer format? That is the question at hand. You
can't just claim some inevitable trend in the pursuit of that
question, particularly in this case where it seems that whoever
modified this section incorrectly thought that the old packet format
had been obsoleted in RFC2440. Perhaps that person might feel
differently in light of the corrected information.

> 
> > You would probably have to ask on the
> > appropriate mailing list to find out if anyone from that faction still
> > knows, is still around, and is interested enough to answer your
> > question.
> 
> This backhanded snark is unbecoming of you, Bruce. The authors of RFC9580
> are named individuals - three of whom currently work on PGP software, and
> one of those (Niibe) works on GnuPG. Your insinuation that RFC9580 was
> written by shadowy, disinterested figures is an insult to its authors, and
> you should consider issuing an apology.

If I am insulting someone here, then those someones don't really
exist. This is based on more than one experience. I would go to ITEF
openpgp mailing list and ask why something was the way it was in the
draft that eventually became RFC-9580. In each case I came bath with
the impression that the original proponent was no longer around or was
no longer responding. That's understandable for a process that spanned
so many years, but it is still a thing.

> 
> For reference, the relevant mailing list is openpgp at lists.ietf.org
> (https://mailarchive.ietf.org/arch/browse/openpgp/)
> > There doesn't seem to be any practical reason to use a new packet
> > header if the packet tag is less than 16. Otherwise you *have* to use
> > a new packet header.
> 
> The practical reason is that the implementers want the ability (eventually)
> to drop support for the legacy format. This can't be done if today's
> software is still generating it. Considering that all RFC2440-compatible
> software (i.e. anything written in the last 25 years) MUST implement the
> modern format, any software that cannot read it is so far out of date that
> it doesn't support any modern cryptography either (for example, it won't
> support MDC) so is not safe for use anyway, other than to read prehistoric
> archives.

*Why* drop it? I happen to know that a popular implementation (GnuPG)
generates old packet headers as a matter of course and has been doing
that since forever. So the usage is completely standard in
practice. If you want to change the RFC-4880 wording then you have an
obligation to first convince the implementations to discontinue
use. Standaards should follow practice, not the other way around.

Bruce


From jtbaldikoski at gmail.com  Tue Nov 11 07:52:40 2025
From: jtbaldikoski at gmail.com (Jack Baldikoski)
Date: Mon, 10 Nov 2025 22:52:40 -0800
Subject: Question/Bug?
In-Reply-To: <87bjlaxlxo.fsf@jacob.g10code.de>
References: <CA+gJm2ZpmFiq5K_wCdjJ-B18vy+CW6g0gj4x7drZ=yDJVi9wyw@mail.gmail.com>
 <aQ-JAXshfbPQ8S2h@ohm.59.ca> <87bjlaxlxo.fsf@jacob.g10code.de>
Message-ID: <d6f13431-267a-4a6e-8e69-9c72342431b7@gmail.com>

On 11/10/25 1:43 AM, Werner Koch wrote:
 > Hi!

Hi Werner, and nice to meet you! I really appreciate all the work you?ve 
done for PGP.

 > BTW, RFC-4880 compatibily would also mean to drop support for Curve25519
 > (ed25519 and cv25519) because they are not covered by the ECC extension
 > to OpenPGP (RFC-6637).  I doubt that anyone wants that.
 >
 > OCB mode is meanwhile widely used and RNP (the Thunderbird *PGP library)
 > also supports it (actually cross-tested with GnuPG back in 2018).  The
 > TB maintainer just refuses to enable this feature in RNP.

True, and perhaps I didn?t say what I meant.

At least on macOS, using any flags, such as --rfc4880, --openpgp, and 
--rfc4880bis, when editing the key and setting prefs do not change the 
key feature flags whatsoever. They only change when set manually. I 
don?t mean to change the algorithm of the key, of course.

And I understand what?s *possible* in RNP/TB, but I?d hope to be able to 
set the feature flags of my key to be TB-compatible.

Best,
Jack


From loup at loup-vaillant.fr  Wed Nov 12 02:31:49 2025
From: loup at loup-vaillant.fr (Loup Vaillant)
Date: Wed, 12 Nov 2025 02:31:49 +0100
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <aROjLAmLnFJU_2kL@ohm.59.ca>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
 <a5b39943-464a-4a7a-8b78-6d2e0ffabb4f@andrewg.com>
 <aROjLAmLnFJU_2kL@ohm.59.ca>
Message-ID: <0637cec9-b67b-4f06-867c-de190edc5640@loup-vaillant.fr>

I have to say, what I'm seing for my first interaction with this mailing 
list doesn't encourage me to stick around.  I'll try not to waste too 
much of your time.  Still, I feel compelled to correct a couple 
reasoning flaws.

---

First, a note on the meaning of the word "obsolete".
Just so we understand each other.

To me, and I believe most people, "obsolete" does *not* mean "we can 
drop support right now".  It just means it is time to deprecate it.  The 
way that happens for wire formats (at least those who have a version 
marker) is always the same:

1. Have all readers support both formats.
2. Have all writers output the new format.
3. Let readers drop support for the old format.

When there are very few implementations, the process can be very quick. 
Or it can take forever, if some popular implementation keeps outputting 
the old format decades after the new is supported by all readers.

---

> RFC-9580 states:
> 
>> ...as the Legacy packet format was obsoleted by [RFC2440] in 1998.
> 
> That statement is literally incorrect for RFC2440. So I don't really
> know what you mean here. It is simply wrong and I don't see how any
> further discussion is possible.

In 1998, RFC 2440 introduced a new packet header format.
That new format subsumes the old format.
The new format is required for packets types 16 and higher.
In 2007, RFC 4880 introduced packets 17, 18, and 19.

It would be hard, given the above, to argue that the old format wasn't 
obsolete in 2007.  They didn't say "obsolete" or "deprecated", but still:

- Any fully compliant RFC 2440 reader has to understand the new format.
- Any fully compliant RFC 4880 writer has to sometimes write in the new
   format.

There's also a reasonable argument to be made that deprecation should 
have started as soon as 1998.  I'm personally in that camp, though I 
understand reluctance to do so before 2007, since there was no 
substantial official functionality behind it yet.


> Yes, but *why* was the language strngthened from RFC-4880 to more
> strongly prefer the newer format?

I can make an educated guess: despite the lenient wording of RFC 2440 
and RFC 2880, it is pretty obvious to me that the old format should have 
been deprecated since at least 2007.  The stronger wording is a signal 
to implementers who haven't gotten the memo, so hopefully phase (2) of 
the deprecation process can finally complete.  It is simply the right 
thing to do.

Now of course, I base my guess on two important premises:

- The new format is needed to support functionality from RFC 4880.
- The new format subsumes the old format.

Or in simpler terms, the new format is simply better.  Of course we 
should support only that one, instead of both formats.


> *Why* drop it? I happen to know that a popular implementation (GnuPG)
> generates old packet headers as a matter of course and has been doing
> that since forever. So the usage is completely standard in
> practice.

That, my friend, is circular reasoning.  A form of "Might Makes Right".

It should be obvious by now why we should drop it.  Again:
- It is subsumed by the new format.
- The new format is needed to support RFC 4880.

Once that's established, the onus is on you to show why we should 
support both formats, instead of just one.

Unless GnuPG doesn't read nor write packets of type 17, 18, or 19?  I 
would be genuinely surprised.  Or maybe the header writing logic has 
been duplicated, and the necessary refactoring is difficult?


> If you want to change the RFC-4880 wording then you have an
> obligation to first convince the implementations to discontinue
> use. Standaards should follow practice, not the other way around.

Unless of course practice is bad.  Which it is.  It only takes one 
popular implementation to keep outputting the old format to force 
everyone else to support reading both formats.  Which is more complex 
and more bug prone.  _At scale._

And I am beginning to suspect GnuPG is the only popular application that 
still outputs the old format by default.  I know it's a fairly minor 
detail: the additional format represents less than 30 lines of code in a 
properly written code base.  Still, for an application that is supposed 
to promote security that is quite the bad look.  Please don't do that.

Loup.



From rjh at sixdemonbag.org  Wed Nov 12 03:48:54 2025
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Tue, 11 Nov 2025 21:48:54 -0500
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <0637cec9-b67b-4f06-867c-de190edc5640@loup-vaillant.fr>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
 <a5b39943-464a-4a7a-8b78-6d2e0ffabb4f@andrewg.com>
 <aROjLAmLnFJU_2kL@ohm.59.ca>
 <0637cec9-b67b-4f06-867c-de190edc5640@loup-vaillant.fr>
Message-ID: <0ff24a89-0c7c-4b8f-8272-a543a9723edb@sixdemonbag.org>

> To me, and I believe most people, "obsolete" does *not* mean "we can 
> drop support right now".? It just means it is time to deprecate it.? The 
> way that happens for wire formats (at least those who have a version 
> marker) is always the same:

 From Merriam-Webster's online dictionary:

"obsolete: no longer in use or no longer useful."

Yes, if something is obsolete it is to be dropped. You are confusing 
obsolete with obsolescent:

"obsolescent: going out of use : becoming obsolete"

If it's obsolescent, deprecate it. If it's obsolete, get rid 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/20251111/bfce1aa8/attachment.sig>

From wk at gnupg.org  Wed Nov 12 13:52:46 2025
From: wk at gnupg.org (Werner Koch)
Date: Wed, 12 Nov 2025 13:52:46 +0100
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <a5b39943-464a-4a7a-8b78-6d2e0ffabb4f@andrewg.com> (Andrew
 Gallagher via Gnupg-users's message of "Tue, 11 Nov 2025 14:59:30
 +0000")
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
 <a5b39943-464a-4a7a-8b78-6d2e0ffabb4f@andrewg.com>
Message-ID: <877bvvv2e9.fsf@jacob.g10code.de>

On Tue, 11 Nov 2025 14:59, Andrew Gallagher said:
> RFC9580 are named individuals - three of whom currently work on PGP
> software, and one of those (Niibe) works on GnuPG. Your insinuation

Just for the recods: After we finished the core of rfc4880bis and solved
the litigous things in Summer 2021, I stepped out due to my time
constraints.  Only editorial changes were planned ay the point and thus
I asked the design team to have my colleague Niibe-san to replace me.
Actually he planned to bring his Simple Octet String proposal forward
which makes the encoding of certain objects easier to describe.

That is the background why he is given as author.  I explictly asked the
new editor to drop me from the list of authors, when I realized that
they did substantial changes instead of just editorial changes.


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/20251112/cfb515a9/attachment.sig>

From loup at loup-vaillant.fr  Wed Nov 12 18:47:47 2025
From: loup at loup-vaillant.fr (Loup Vaillant)
Date: Wed, 12 Nov 2025 18:47:47 +0100
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <0ff24a89-0c7c-4b8f-8272-a543a9723edb@sixdemonbag.org>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
 <a5b39943-464a-4a7a-8b78-6d2e0ffabb4f@andrewg.com>
 <aROjLAmLnFJU_2kL@ohm.59.ca>
 <0637cec9-b67b-4f06-867c-de190edc5640@loup-vaillant.fr>
 <0ff24a89-0c7c-4b8f-8272-a543a9723edb@sixdemonbag.org>
Message-ID: <321808bf-6867-4c23-8598-055e06723c57@loup-vaillant.fr>

>> To me, and I believe most people, "obsolete" does *not* mean "we can 
>> drop support right now".? It just means it is time to deprecate it.  
>> The way that happens for wire formats (at least those who have a 
>> version marker) is always the same:
> 
>  From Merriam-Webster's online dictionary:
> 
> "obsolete: no longer in use or no longer useful."

The second part, "or no longer useful", is what I had in mind.
Applied to a wire format, the obvious consequence is "it is time to 
deprecate it".  Because of course we're not gonna break compatibility 
overnight.

---

While we're listing dictionary definitions, "obsolete" can also be a 
transitive verb.  Word reference says:

""" to make obsolete by replacing with something newer or better;
""" antiquate:
""" > Automation has obsoleted many factory workers.

That's how RFC 9580 used the word:

""" [...] the Legacy packet format was obsoleted by [RFC2440] in 1998.

- Considering the definition of "obsolete" as a transitive verb,
- considering RFC 2440 introduced the new packet format 27 years ago,
- considering that the new packet format dominates the old,

RFC 9580 is correct: RFC 2440 made the old format antique, and enabled 
other implementations to support the new, which is the first step for 
deprecation.

---

> Yes, if something is obsolete it is to be dropped. You are confusing 
> obsolete with obsolescent:
> 
> "obsolescent: going out of use : becoming obsolete"
> 
> If it's obsolescent, deprecate it. If it's obsolete, get rid of it.

That interpretation of "obsolete" is too strict in my opinion.  It would 
mean that if I cannot reasonably get rid of the old format, then it is 
not obsolete.

And as a matter of fact, readers can't get rid of it, because GnuPG 
still outputs it.  So under that interpretation, Werner just has to say 
"nope, not gonna change", and just like that the redundant, discouraged, 
old format is declared "not obsolete".

That would be a weird power to have.

Loup.



From loup at loup-vaillant.fr  Wed Nov 12 19:17:14 2025
From: loup at loup-vaillant.fr (Loup Vaillant)
Date: Wed, 12 Nov 2025 19:17:14 +0100
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <aRMoD7nyHRNIL92A@ohm.59.ca>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
Message-ID: <bed78415-177c-4eaa-b1ef-8266d121f70a@loup-vaillant.fr>

> No preference is expressed at all in RFC-2440. So it appears that
> RFC-9580 is simply incorrect.

See my response about the various dictionary meanings of "obsolete" 
(here as a transitive verb), as to why it actually might be correct, 
even if RFC 2440 did not explicitly express a preference.

I won't die on that hill though, I know there's wiggle room.


>  From RFC-4880:
> 
>> PGP 2.6.x only uses old format packets. Thus, software that
>> interoperates with those versions of PGP must only use old format
>> packets.  If interoperability is not an issue, the new packet format
>> is RECOMMENDED.
> 
> So RFC-9580 is also incorrect for RFC-4880 as well. I don't know the
> reasoning behind RFC-9580 changing this to "SHOULD NOT" and why the
> incorrect language was used.

That's where it is so useful to look up the official definition of the 
capital words from the RFCs.  You would have known that in this 
particular instance, RFC 9580 means the exact same thing as RFC 4880.

 From RFC 2119:

"" *SHOULD*  This word, or the adjective "RECOMMENDED", mean that there
"" may exist valid reasons in particular circumstances to ignore a
"" particular item, but the full implications must be understood and
"" carefully weighed before choosing a different course.
""
"" *SHOULD NOT*  This phrase, or the phrase "NOT RECOMMENDED" mean that
"" there may exist valid reasons in particular circumstances when the
"" particular behavior is acceptable or even useful, but the full
"" implications should be understood and the case carefully weighed
"" before implementing any behavior described with this label.

So when RFC 4880 says:

"" If interoperability is not an issue, the new packet format
"" is RECOMMENDED.

It means the exact same thing as:

"" If interoperability is not an issue, the old packet format
"" is NOT RECOMMENDED.

Which means the exact same thing as:

"" If interoperability is not an issue, the old packet format
"" SHOULD NOT be used.

Which (from those who output data) means the exact same thing as:

"" The Legacy packet format SHOULD NOT be used to generate new data,
"" unless the recipient is known to only support the Legacy packet
"" format.

So as you can see, the legal meaning of RFC 9580 here is exactly the 
same as that of RFC 4880.


> LibrePGP introduces no changes from RFC-4880 with respect to this. So
> in the world of GnuPG the new packet format is only "RECOMMENDED" for
> cases where interoperability is not an issue.

Let's be honest, interoperability has not ben an issues for likely more 
than a decade.  Given that, and the legal argument above, in GnuPG word 
you SHOULD output the new format, and you SHOULD NOT output the old format.

And now the real funny part.  The latest version of LibrePGP states:

"" If interoperability is not an issue, the new packet format
"" is RECOMMENDED

Same as RFC 4880.  So not only GnuPG is in clear violation of the legal 
equivalent of a "SHOULD NOT" from a 18 year old RFC, the recommendation 
(and associated violation) persists even through the very draft it 
promotes.

Loup.



From rjh at sixdemonbag.org  Wed Nov 12 20:08:41 2025
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Wed, 12 Nov 2025 14:08:41 -0500
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <321808bf-6867-4c23-8598-055e06723c57@loup-vaillant.fr>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
 <a5b39943-464a-4a7a-8b78-6d2e0ffabb4f@andrewg.com>
 <aROjLAmLnFJU_2kL@ohm.59.ca>
 <0637cec9-b67b-4f06-867c-de190edc5640@loup-vaillant.fr>
 <0ff24a89-0c7c-4b8f-8272-a543a9723edb@sixdemonbag.org>
 <321808bf-6867-4c23-8598-055e06723c57@loup-vaillant.fr>
Message-ID: <527f0f1e-e4e6-496b-8a73-714046becb53@sixdemonbag.org>

> And as a matter of fact, readers can't get rid of it, because GnuPG 
> still outputs it.? So under that interpretation, Werner just has to say 
> "nope, not gonna change", and just like that the redundant, discouraged, 
> old format is declared "not obsolete".

This exact thing is happening with the obsolescent IPv4 format.

IPv6 is out there, has been stable for 20+ years, but major companies 
are still being slow to adopt it for cost reasons: and because they 
refuse to modernize, IPv4 remains obsolescent and not obsolete.

This thing you think would be silly to happen is, in fact, happening 
constantly in the tech space. Right now, at this very moment.

-------------- 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/20251112/2662e9cc/attachment.sig>

From andrewg at andrewg.com  Wed Nov 12 20:41:01 2025
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 12 Nov 2025 19:41:01 +0000
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <527f0f1e-e4e6-496b-8a73-714046becb53@sixdemonbag.org>
References: <527f0f1e-e4e6-496b-8a73-714046becb53@sixdemonbag.org>
Message-ID: <066D98E8-4E5B-497E-B10D-E8E8898351A5@andrewg.com>

On 12 Nov 2025, at 19:10, Robert J. Hansen via Gnupg-users <gnupg-users at gnupg.org> wrote:
> 
> This exact thing is happening with the obsolescent IPv4 format.

I don?t think this is a useful comparison - ipv4 and ipv6 are separate stacks that have to operate in parallel for a long period of time, and we?re not yet at the stage where every single device and network on the internet is ipv6-capable. OpenPGP passed the equivalent stage on the tech adoption timeline somewhere around 2005 or 2006, before RFC4880 introduced packet types that were incompatible with the old framing (e.g. MDC). Aside from network management tools, there are no broadly-supported protocols that have a hard requirement for ipv6 - because entire networks and countless devices still have to be upgraded (at great expense). Whereas we could stop emitting the legacy framing at any time and few people outside this list would even notice? ;-)

A

From alci at mecadu.org  Wed Nov 12 22:07:15 2025
From: alci at mecadu.org (Franck Routier (Personnel))
Date: Wed, 12 Nov 2025 22:07:15 +0100
Subject: No PIN asked for with libpam-poldi
In-Reply-To: <97fb7b4a-67c1-46a6-989b-48cd32c060ec@mecadu.org>
References: <95ba74c7-5a90-4e7e-8df4-c21bb1a554b3@mecadu.org>
 <4634150.niJfEyVGOH@daneel> <97fb7b4a-67c1-46a6-989b-48cd32c060ec@mecadu.org>
Message-ID: <0108f3d9-3cf4-4341-acca-e761d5370e82@mecadu.org>

I managed to get some logs from gpg-agent. No sure how to interpret this 
however. No obvious error I can spot (but I don't know what to look for):

2025-11-12 21:59:02 gpg-agent[15833] gpg-agent (GnuPG) 2.4.4 starting in 
supervised mode.
2025-11-12 21:59:02 gpg-agent[15833] using fd 3 for std socket 
(/run/user/1000/gnupg/S.gpg-agent)
2025-11-12 21:59:02 gpg-agent[15833] using fd 4 for extra socket 
(/run/user/1000/gnupg/S.gpg-agent.extra)
2025-11-12 21:59:02 gpg-agent[15833] using fd 5 for ssh socket 
(/run/user/1000/gnupg/S.gpg-agent.ssh)
2025-11-12 21:59:02 gpg-agent[15833] using fd 6 for browser socket 
(/run/user/1000/gnupg/S.gpg-agent.browser)
2025-11-12 21:59:02 gpg-agent[15833] listening on: std=3 extra=4 
browser=6 ssh=5
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 -> OK Pleased to meet 
you, process 15832
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 <- RESET
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 <- OPTION 
ttyname=/dev/pts/4
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 <- OPTION 
ttytype=xterm-256color
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 <- OPTION display=:0
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 <- OPTION 
xauthority=/run/user/1000/xauth_uyqgiW
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 <- OPTION 
putenv=WAYLAND_DISPLAY=wayland-0
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 <- OPTION 
putenv=XDG_SESSION_TYPE=wayland
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 <- OPTION 
putenv=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 <- OPTION 
lc-ctype=fr_FR.UTF-8
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 <- OPTION 
lc-messages=fr_FR.UTF-8
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 21:59:02 gpg-agent[15833] DBG: chan_12 <- [eof]
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_12 -> OK Pleased to meet 
you, process 15998
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_12 <- SCD GETINFO socket_name
2025-11-12 21:59:54 gpg-agent[15833] no running /usr/lib/gnupg/scdaemon 
daemon - starting it
2025-11-12 21:59:54 gpg-agent[15833] DBG: agent_flush_cache (pincache only)
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_13 <- OK GNU Privacy 
Guard's Smartcard server ready
2025-11-12 21:59:54 gpg-agent[15833] first connection to daemon 
/usr/lib/gnupg/scdaemon established
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_13 -> GETINFO socket_name
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_13 <- D 
/run/user/1000/gnupg/S.scdaemon
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_13 <- OK
2025-11-12 21:59:54 gpg-agent[15833] DBG: additional connections at 
'/run/user/1000/gnupg/S.scdaemon'
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_13 -> OPTION event-signal=12
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_13 <- OK
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_13 -> GETINFO socket_name
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_13 <- D 
/run/user/1000/gnupg/S.scdaemon
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_13 <- OK
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_12 -> D 
/run/user/1000/gnupg/S.scdaemon
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_12 <- BYE
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_12 -> OK closing connection
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_13 -> RESTART
2025-11-12 21:59:54 gpg-agent[15833] DBG: chan_13 <- OK
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 -> OK Pleased to meet 
you, process 16050
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 <- RESET
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 <- OPTION 
ttytype=xterm-256color
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 <- OPTION display=:0
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 <- OPTION 
xauthority=/run/user/1000/xauth_uyqgiW
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 <- OPTION 
putenv=WAYLAND_DISPLAY=wayland-0
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 <- OPTION 
putenv=XDG_SESSION_TYPE=wayland
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 <- OPTION 
putenv=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 -> OK
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 <- KILLAGENT
2025-11-12 22:00:18 gpg-agent[15833] DBG: chan_12 -> OK closing connection
2025-11-12 22:00:18 gpg-agent[15833] random usage: poolsize=600 mixed=0 
polls=0/0 added=0/0
 ? ? ? ? ? ? ? outmix=0 getlvl1=0/0 getlvl2=0/0
2025-11-12 22:00:18 gpg-agent[15833] rndjent stat: 
collector=0x0000000000000000 calls=0 bytes=0
2025-11-12 22:00:18 gpg-agent[15833] secmem usage: 0/65536 bytes in 0 blocks
2025-11-12 22:00:22 gpg-agent[16056] gpg-agent (GnuPG) 2.4.4 starting in 
supervised mode.
2025-11-12 22:00:22 gpg-agent[16056] using fd 3 for std socket 
(/run/user/1000/gnupg/S.gpg-agent)
2025-11-12 22:00:22 gpg-agent[16056] using fd 4 for extra socket 
(/run/user/1000/gnupg/S.gpg-agent.extra)
2025-11-12 22:00:22 gpg-agent[16056] using fd 5 for ssh socket 
(/run/user/1000/gnupg/S.gpg-agent.ssh)
2025-11-12 22:00:22 gpg-agent[16056] using fd 6 for browser socket 
(/run/user/1000/gnupg/S.gpg-agent.browser)
2025-11-12 22:00:22 gpg-agent[16056] listening on: std=3 extra=4 
browser=6 ssh=5
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 -> OK Pleased to meet 
you, process 16055
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 <- RESET
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 -> OK
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 <- OPTION 
ttyname=/dev/pts/4
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 -> OK
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 <- OPTION 
ttytype=xterm-256color
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 -> OK
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 <- OPTION display=:0
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 -> OK
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 <- OPTION 
xauthority=/run/user/1000/xauth_uyqgiW
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 -> OK
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 <- OPTION 
putenv=WAYLAND_DISPLAY=wayland-0
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 -> OK
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 <- OPTION 
putenv=XDG_SESSION_TYPE=wayland
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 -> OK
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 <- OPTION 
putenv=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 -> OK
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 <- OPTION 
lc-ctype=fr_FR.UTF-8
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 -> OK
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 <- OPTION 
lc-messages=fr_FR.UTF-8
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 -> OK
2025-11-12 22:00:22 gpg-agent[16056] DBG: chan_12 <- [eof]
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 -> OK Pleased to meet 
you, process 16072
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 <- SCD GETINFO socket_name
2025-11-12 22:00:31 gpg-agent[16056] no running /usr/lib/gnupg/scdaemon 
daemon - starting it
2025-11-12 22:00:31 gpg-agent[16056] DBG: agent_flush_cache (pincache only)
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK GNU Privacy 
Guard's Smartcard server ready
2025-11-12 22:00:31 gpg-agent[16056] first connection to daemon 
/usr/lib/gnupg/scdaemon established
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 -> GETINFO socket_name
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- D 
/run/user/1000/gnupg/S.scdaemon
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK
2025-11-12 22:00:31 gpg-agent[16056] DBG: additional connections at 
'/run/user/1000/gnupg/S.scdaemon'
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 -> OPTION event-signal=12
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 -> GETINFO socket_name
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- D 
/run/user/1000/gnupg/S.scdaemon
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 -> D 
/run/user/1000/gnupg/S.scdaemon
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 -> OK
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 <- BYE
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 -> OK closing connection
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 -> RESTART
2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK

Trying to sudo at 22:00:31
Before is just normal gpg-agent start (?).

Any idea ?

Regards,
Franck

Le 07/11/2025 ? 18:36, Franck Routier (Personnel) via Gnupg-users a ?crit?:
>> Typo? In any case, avoid the weird debug-level setting. Use "debug ipc"
>> instead. Also set log-file so that the logs don't end up in some random place
>> (or nowhere).
> Yes typo. I removed it alltogether for now:
>
> pinentry-program /usr/bin/pinentry-qt
> enable-ssh-support
> ttyname $GPG_TTY
> default-cache-ttl 60
> max-cache-ttl 120
>
>> Very likely gpg-agent fails to start pinentry-qt or pinentry-qt fails to start
>> because there's no window manager running. Try using pinentry-curses or
>> pinentry-tty instead of pinentry-qt if you are anyway using the terminal.
> In fact gpg-agent seems to be able to call pinentry-qt, as when I use 
> pass or browserpass, it works and I get a pretty pinentry window...
>
> That said, switching to pinentry-tty does not solve the problem with pam.
> In fact I can see pinentry-tty working with pass and failing with sudo 
> in the same terminal session:
>
> $ pass perso/ameli.fr
> Please unlock the card
> Number: 10 955 601
> Holder: Franck Routier
> PIN:
> *************************
> $ sudo su
> Insert authentication card for user `franck'
> Trying authentication as user `franck'...
> [sudo] password for franck:
>
> Franck
>
> _______________________________________________
> 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/20251112/3beb73eb/attachment-0001.html>

From kloecker at kde.org  Wed Nov 12 22:32:27 2025
From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=)
Date: Wed, 12 Nov 2025 22:32:27 +0100
Subject: No PIN asked for with libpam-poldi
In-Reply-To: <0108f3d9-3cf4-4341-acca-e761d5370e82@mecadu.org>
References: <95ba74c7-5a90-4e7e-8df4-c21bb1a554b3@mecadu.org>
 <97fb7b4a-67c1-46a6-989b-48cd32c060ec@mecadu.org>
 <0108f3d9-3cf4-4341-acca-e761d5370e82@mecadu.org>
Message-ID: <2762673.lGaqSPkdTl@daneel>

On Mittwoch, 12. November 2025 22:07:15 Mitteleurop?ische Normalzeit Franck 
Routier (Personnel) via Gnupg-users wrote:
> I managed to get some logs from gpg-agent. No sure how to interpret this
> however. No obvious error I can spot (but I don't know what to look for):
> 
[...]
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 -> OK Pleased to meet
> you, process 16072
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 <- SCD GETINFO socket_name
> 2025-11-12 22:00:31 gpg-agent[16056] no running /usr/lib/gnupg/scdaemon
> daemon - starting it
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: agent_flush_cache (pincache only)
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK GNU Privacy
> Guard's Smartcard server ready
> 2025-11-12 22:00:31 gpg-agent[16056] first connection to daemon
> /usr/lib/gnupg/scdaemon established
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 -> GETINFO socket_name
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- D
> /run/user/1000/gnupg/S.scdaemon
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: additional connections at
> '/run/user/1000/gnupg/S.scdaemon'
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 -> OPTION event-signal=12
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 -> GETINFO socket_name
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- D
> /run/user/1000/gnupg/S.scdaemon
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 -> D
> /run/user/1000/gnupg/S.scdaemon
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 -> OK
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 <- BYE
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 -> OK closing connection
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 -> RESTART
> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK
> 
> Trying to sudo at 22:00:31
> Before is just normal gpg-agent start (?).
> 
> Any idea ?

What we see above for chan_12 looks like the communication between libpam-
poldi (?) and gpg-agent. libpam-poldi asks scdaemon via gpg-agent for its 
socket (SCD GETINFO socket_name). Then for chan_13 we see how gpg-agent talks 
to scdaemon (that it first started) to ask scdaemon for its socket (GETINFO 
socket_name) which replies with /run/user/1000/gnupg/S.scdaemon and OK. I 
don't understand the "additional connections ..." message and the other chat 
on chan_13. In any case, on chan_12 gpg-agent sends the socket back to libpam-
poldi which then ends the connection with BYE.

My guess is that libpam-poldi asked gpg-agent for the socket of scdaemon so 
that it can subsequently talk to scdaemon directly. You might want to add 
'debug ipc' to scdaemon.conf to capture the communication of scdaemon with 
other processes.

Regards,
Ingo

> Le 07/11/2025 ? 18:36, Franck Routier (Personnel) via Gnupg-users a ?crit :
> >> Typo? In any case, avoid the weird debug-level setting. Use "debug ipc"
> >> instead. Also set log-file so that the logs don't end up in some random
> >> place (or nowhere).
> > 
> > Yes typo. I removed it alltogether for now:
> > 
> > pinentry-program /usr/bin/pinentry-qt
> > enable-ssh-support
> > ttyname $GPG_TTY
> > default-cache-ttl 60
> > max-cache-ttl 120
> > 
> >> Very likely gpg-agent fails to start pinentry-qt or pinentry-qt fails to
> >> start because there's no window manager running. Try using
> >> pinentry-curses or pinentry-tty instead of pinentry-qt if you are anyway
> >> using the terminal.> 
> > In fact gpg-agent seems to be able to call pinentry-qt, as when I use
> > pass or browserpass, it works and I get a pretty pinentry window...
> > 
> > That said, switching to pinentry-tty does not solve the problem with pam.
> > In fact I can see pinentry-tty working with pass and failing with sudo
> > in the same terminal session:
> > 
> > $ pass perso/ameli.fr
> > Please unlock the card
> > Number: 10 955 601
> > Holder: Franck Routier
> > PIN:
> > *************************
> > $ sudo su
> > Insert authentication card for user `franck'
> > Trying authentication as user `franck'...
> > [sudo] password for franck:
> > 
> > Franck
> > 
> > _______________________________________________
> > Gnupg-users mailing list
> > Gnupg-users at gnupg.org
> > https://lists.gnupg.org/mailman/listinfo/gnupg-users

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 265 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251112/0c789265/attachment.sig>

From me at chandlerdavis.cc  Thu Nov 13 01:32:33 2025
From: me at chandlerdavis.cc (Chandler Davis)
Date: Thu, 13 Nov 2025 00:32:33 +0000
Subject: Bug Tracker Account Request
Message-ID: <pn8rz8Nvci4F1sakCcy7p-6CQYCtBO0TEMCj2xoUC3fgicc-g4XavEJ0d_2g5UvIA2EE8KtpUFVrBKL24ncMfPmisRWPTvniBD-Djh6JDoc=@chandlerdavis.cc>

Hey folks,

I believe I've found a minor issue in the gpgme documentation, and wanted to open an issue on the bug tracker and submit a patch. I believe that's the correct place for it, but let me know if I should discuss here / in the development list / elsewhere.

If I were to be blessed with an account for the bug tracker, my handle is "bitcrshr", name is "Chandler Davis", and email is "me at chandlerdavis.cc".

Thanks, and have a good one!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 343 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251113/53b92b5e/attachment.sig>

From jcb62281 at gmail.com  Thu Nov 13 05:27:56 2025
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Wed, 12 Nov 2025 22:27:56 -0600
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <bed78415-177c-4eaa-b1ef-8266d121f70a@loup-vaillant.fr>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
 <bed78415-177c-4eaa-b1ef-8266d121f70a@loup-vaillant.fr>
Message-ID: <a20c71bc-bb16-4bbf-bbb5-8a1f72774d73@gmail.com>

On 11/12/25 12:17, Loup Vaillant wrote:
> [...]
>
>> LibrePGP introduces no changes from RFC-4880 with respect to this. So
>> in the world of GnuPG the new packet format is only "RECOMMENDED" for
>> cases where interoperability is not an issue.
>
> Let's be honest, interoperability has not ben an issues for likely 
> more than a decade.? Given that, and the legal argument above, in 
> GnuPG word you SHOULD output the new format, and you SHOULD NOT output 
> the old format.
>
> And now the real funny part.? The latest version of LibrePGP states:
>
> "" If interoperability is not an issue, the new packet format
> "" is RECOMMENDED
>
> Same as RFC 4880.? So not only GnuPG is in clear violation of the 
> legal equivalent of a "SHOULD NOT" from a 18 year old RFC, the 
> recommendation (and associated violation) persists even through the 
> very draft it promotes.

Ah, but that is conditional on interoperability not being an issue.

I propose a more nuanced solution:? output the legacy format iff the 
cryptographic primitives used are compatible with the ancient PGP 
implementations that only understand the legacy format, otherwise output 
the new format since receivers that lack support for the new format 
would not be able to use the message anyway because they also lack the 
required algorithm support.

Note that this could potentially mean supporting the legacy format 
indefinitely for RSA signatures, at least with whatever digests the 
ancient implementations supported.


-- Jacob



From loup at loup-vaillant.fr  Thu Nov 13 08:22:39 2025
From: loup at loup-vaillant.fr (Loup Vaillant)
Date: Thu, 13 Nov 2025 08:22:39 +0100
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <a20c71bc-bb16-4bbf-bbb5-8a1f72774d73@gmail.com>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
 <bed78415-177c-4eaa-b1ef-8266d121f70a@loup-vaillant.fr>
 <a20c71bc-bb16-4bbf-bbb5-8a1f72774d73@gmail.com>
Message-ID: <17e6ae13-bf0c-4456-82c6-7a41418ce719@loup-vaillant.fr>

>> Let's be honest, interoperability has not ben an issues for likely 
>> more than a decade.?[...]
> 
> Ah, but that is conditional on interoperability not being an issue.

As I?said, it's not.  Hasn't been for many years.

Remember, the ability to read the new framing became at least a SHOULD 
27 years ago.  18 years ago, the new packet types made it a MUST.

Can anyone name *one* OpenPGP implementation in notable use today that 
still cannot understand the new framing?  There isn't, right?


> [...] the ancient PGP 
> implementations that only understand the legacy format,

But are these ancient implementations still being used today?
Where?  By who?

Seriously, at this point it's not on me to prove no one such 
implementation still exist.  It's on you to show that it's still being 
used.  So far no one did.  Not a single example.  If there was one, then 
one of you would have answered my first query with "this reader still 
doesn't understand the new framing, we have to still use the old to be 
compatible with it".

Loup



From kloecker at kde.org  Thu Nov 13 08:32:01 2025
From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=)
Date: Thu, 13 Nov 2025 08:32:01 +0100
Subject: Bug Tracker Account Request
In-Reply-To: <pn8rz8Nvci4F1sakCcy7p-6CQYCtBO0TEMCj2xoUC3fgicc-g4XavEJ0d_2g5UvIA2EE8KtpUFVrBKL24ncMfPmisRWPTvniBD-Djh6JDoc=@chandlerdavis.cc>
References: <pn8rz8Nvci4F1sakCcy7p-6CQYCtBO0TEMCj2xoUC3fgicc-g4XavEJ0d_2g5UvIA2EE8KtpUFVrBKL24ncMfPmisRWPTvniBD-Djh6JDoc=@chandlerdavis.cc>
Message-ID: <5002581.OV4Wx5bFTl@daneel>

Hi,

On Donnerstag, 13. November 2025 01:32:33 Mitteleurop?ische Normalzeit 
Chandler Davis via Gnupg-users wrote:
> I believe I've found a minor issue in the gpgme documentation, and wanted to
> open an issue on the bug tracker and submit a patch. I believe that's the
> correct place for it, but let me know if I should discuss here / in the
> development list / elsewhere.

We prefer patches to be sent to the gnupg-devel mailing list. See the file 
doc/HACKING in gpgme for details.

> If I were to be blessed with an account for the bug tracker, my handle is
> "bitcrshr", name is "Chandler Davis", and email is "me at chandlerdavis.cc".

Werner will take care of this.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 265 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251113/15a62347/attachment.sig>

From alci at mecadu.org  Thu Nov 13 11:03:34 2025
From: alci at mecadu.org (Franck Routier (Personnel))
Date: Thu, 13 Nov 2025 11:03:34 +0100
Subject: No PIN asked for with libpam-poldi
In-Reply-To: <2762673.lGaqSPkdTl@daneel>
References: <95ba74c7-5a90-4e7e-8df4-c21bb1a554b3@mecadu.org>
 <97fb7b4a-67c1-46a6-989b-48cd32c060ec@mecadu.org>
 <0108f3d9-3cf4-4341-acca-e761d5370e82@mecadu.org> <2762673.lGaqSPkdTl@daneel>
Message-ID: <ccf2e162-2b33-4bd0-8be8-9a87df98e33a@mecadu.org>

Thanks for helping me interpret this logs !
So I activited logs one component after the other, and finally the 
problem was simply in libpam-poldi configuration...
The opening parenthesis (before "public-key" keyword) was missing in the 
key file :

public-key
(rsa etc...

Well... embarrassing :-)
But it least I progressed in the understanding of this stack !

Thanks again,
Franck

Le 12/11/2025 ? 22:32, Ingo Kl?cker a ?crit?:
> On Mittwoch, 12. November 2025 22:07:15 Mitteleurop?ische Normalzeit Franck
> Routier (Personnel) via Gnupg-users wrote:
>> I managed to get some logs from gpg-agent. No sure how to interpret this
>> however. No obvious error I can spot (but I don't know what to look for):
>>
> [...]
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 -> OK Pleased to meet
>> you, process 16072
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 <- SCD GETINFO socket_name
>> 2025-11-12 22:00:31 gpg-agent[16056] no running /usr/lib/gnupg/scdaemon
>> daemon - starting it
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: agent_flush_cache (pincache only)
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK GNU Privacy
>> Guard's Smartcard server ready
>> 2025-11-12 22:00:31 gpg-agent[16056] first connection to daemon
>> /usr/lib/gnupg/scdaemon established
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 -> GETINFO socket_name
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- D
>> /run/user/1000/gnupg/S.scdaemon
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: additional connections at
>> '/run/user/1000/gnupg/S.scdaemon'
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 -> OPTION event-signal=12
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 -> GETINFO socket_name
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- D
>> /run/user/1000/gnupg/S.scdaemon
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 -> D
>> /run/user/1000/gnupg/S.scdaemon
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 -> OK
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 <- BYE
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_12 -> OK closing connection
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 -> RESTART
>> 2025-11-12 22:00:31 gpg-agent[16056] DBG: chan_13 <- OK
>>
>> Trying to sudo at 22:00:31
>> Before is just normal gpg-agent start (?).
>>
>> Any idea ?
> What we see above for chan_12 looks like the communication between libpam-
> poldi (?) and gpg-agent. libpam-poldi asks scdaemon via gpg-agent for its
> socket (SCD GETINFO socket_name). Then for chan_13 we see how gpg-agent talks
> to scdaemon (that it first started) to ask scdaemon for its socket (GETINFO
> socket_name) which replies with /run/user/1000/gnupg/S.scdaemon and OK. I
> don't understand the "additional connections ..." message and the other chat
> on chan_13. In any case, on chan_12 gpg-agent sends the socket back to libpam-
> poldi which then ends the connection with BYE.
>
> My guess is that libpam-poldi asked gpg-agent for the socket of scdaemon so
> that it can subsequently talk to scdaemon directly. You might want to add
> 'debug ipc' to scdaemon.conf to capture the communication of scdaemon with
> other processes.
>
> Regards,
> Ingo
>
>> Le 07/11/2025 ? 18:36, Franck Routier (Personnel) via Gnupg-users a ?crit :
>>>> Typo? In any case, avoid the weird debug-level setting. Use "debug ipc"
>>>> instead. Also set log-file so that the logs don't end up in some random
>>>> place (or nowhere).
>>> Yes typo. I removed it alltogether for now:
>>>
>>> pinentry-program /usr/bin/pinentry-qt
>>> enable-ssh-support
>>> ttyname $GPG_TTY
>>> default-cache-ttl 60
>>> max-cache-ttl 120
>>>
>>>> Very likely gpg-agent fails to start pinentry-qt or pinentry-qt fails to
>>>> start because there's no window manager running. Try using
>>>> pinentry-curses or pinentry-tty instead of pinentry-qt if you are anyway
>>>> using the terminal.>
>>> In fact gpg-agent seems to be able to call pinentry-qt, as when I use
>>> pass or browserpass, it works and I get a pretty pinentry window...
>>>
>>> That said, switching to pinentry-tty does not solve the problem with pam.
>>> In fact I can see pinentry-tty working with pass and failing with sudo
>>> in the same terminal session:
>>>
>>> $ pass perso/ameli.fr
>>> Please unlock the card
>>> Number: 10 955 601
>>> Holder: Franck Routier
>>> PIN:
>>> *************************
>>> $ sudo su
>>> Insert authentication card for user `franck'
>>> Trying authentication as user `franck'...
>>> [sudo] password for franck:
>>>
>>> Franck
>>>
>>> _______________________________________________
>>> Gnupg-users mailing list
>>> Gnupg-users at gnupg.org
>>> https://lists.gnupg.org/mailman/listinfo/gnupg-users
>
> _______________________________________________
> 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/20251113/ca0f6712/attachment-0001.html>

From roam at ringlet.net  Thu Nov 13 10:23:54 2025
From: roam at ringlet.net (Peter Pentchev)
Date: Thu, 13 Nov 2025 11:23:54 +0200
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <17e6ae13-bf0c-4456-82c6-7a41418ce719@loup-vaillant.fr>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
 <bed78415-177c-4eaa-b1ef-8266d121f70a@loup-vaillant.fr>
 <a20c71bc-bb16-4bbf-bbb5-8a1f72774d73@gmail.com>
 <17e6ae13-bf0c-4456-82c6-7a41418ce719@loup-vaillant.fr>
Message-ID: <aRWjqr130IkWhbvx@straylight.m.ringlet.net>

On Thu, Nov 13, 2025 at 08:22:39AM +0100, Loup Vaillant wrote:
> > > Let's be honest, interoperability has not ben an issues for likely
> > > more than a decade.?[...]
> > 
> > Ah, but that is conditional on interoperability not being an issue.
> 
> As I?said, it's not.  Hasn't been for many years.
> 
> Remember, the ability to read the new framing became at least a SHOULD 27
> years ago.  18 years ago, the new packet types made it a MUST.
> 
> Can anyone name *one* OpenPGP implementation in notable use today that still
> cannot understand the new framing?  There isn't, right?

You'd be surprised what software runs on internal corporate systems that
were set up literally thirty years ago and that were maybe, *maybe*,
upgraded twice since then, with extremely careful testing and
extremely conservative upgrade paths. You may be surprised at what some
tools written last year may need to produce so that some of those
installations can consume it.

So here we come to what I think is the most important point missed by
some of the people in this thread: TL;DR: gnupg has the `--rfc2440`,
`--rfc4880`, and `--rfc4880bis` options; use them as appropriate.

Somewhat more verbose TL;DR: for various tools that support several
output formats, it is actually good practice to specify the exact format
that you want, even if you think it really should be the default or
if it is the current default.

The longer version:
- standards change with time
- implementations change their defaults with time
- these changed defaults may cause problems down the road; see e.g. how
  various Linux distributions (I know for certain about Fedora and Debian,
  there may be others) had a bit of work to do recently when GCC 15
  switched to a new C language standard by default (if the -std option
  was not specified!), and it started failing to compile programs that
  used something that, in my personal opinion, was obsolete twenty years
  ago, but there was still source code like that out there
- yes, it would be nice if stuff could "just work" without additional
  options
- no, it is not possible in the real world
- so, always specify as many standards-compliance and output-format
  options as you can think of; yes, this makes some command-lines
  longer that they might possibly need to be to work today, you will
  be glad you did in three years (or fifteen years) time

And the longer version, *specifically* pertaining to GnuPG:
- AFAIK, GnuPG has always had interoperability in mind (my personal
  opinion about the recent, um, differences in opinion within
  the OpenPGP working group is irrelevant here)
- interoperability includes "this version of GnuPG should not change
  its behavior when invoked by ancient tooling that aims to produce
  output to be consumed by even more ancient tooling"
- so, IF NO `--rfc...` OPTION IS SPECIFIED, GnuPG HAS TO default to
  the least common denominator

G'luck,
Peter

-- 
Peter Pentchev  roam at ringlet.net roam at debian.org peter at morpheusly.com
PGP key:        https://www.ringlet.net/roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251113/62f61172/attachment.sig>

From andrewg at andrewg.com  Thu Nov 13 12:56:32 2025
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Thu, 13 Nov 2025 11:56:32 +0000
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <aRWjqr130IkWhbvx@straylight.m.ringlet.net>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
 <bed78415-177c-4eaa-b1ef-8266d121f70a@loup-vaillant.fr>
 <a20c71bc-bb16-4bbf-bbb5-8a1f72774d73@gmail.com>
 <17e6ae13-bf0c-4456-82c6-7a41418ce719@loup-vaillant.fr>
 <aRWjqr130IkWhbvx@straylight.m.ringlet.net>
Message-ID: <c766096f-1b1b-4fc5-b3dc-3d9a1a22a0dc@andrewg.com>

Hi, Peter.

On 13/11/2025 09:23, Peter Pentchev wrote:
> - so, IF NO `--rfc...` OPTION IS SPECIFIED, GnuPG HAS TO default to
>    the least common denominator

This is not how GnuPG's compliance options currently work though; 
non-default compliance options cause GnuPG to comply with *earlier* 
specs, to improve backwards compatibility at the expense of 
cryptographic strength.

It would be reasonable, and still solidly defensive, for GnuPG to emit 
the old packet framing iff a compliance option such as --rfc2440 was 
supplied, or if the key being encrypted to advertised old defaults, or 
if the key material uses an algorithm or packet version that pre-dates 
rfc4880. But it serves no purpose to continue to use the old format with 
modern cryptography that legacy code can't understand anyway.

A



From jb-gnumlists at wisemo.com  Thu Nov 13 13:35:02 2025
From: jb-gnumlists at wisemo.com (Jakob Bohm)
Date: Thu, 13 Nov 2025 13:35:02 +0100
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <c766096f-1b1b-4fc5-b3dc-3d9a1a22a0dc@andrewg.com>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
 <bed78415-177c-4eaa-b1ef-8266d121f70a@loup-vaillant.fr>
 <a20c71bc-bb16-4bbf-bbb5-8a1f72774d73@gmail.com>
 <17e6ae13-bf0c-4456-82c6-7a41418ce719@loup-vaillant.fr>
 <aRWjqr130IkWhbvx@straylight.m.ringlet.net>
 <c766096f-1b1b-4fc5-b3dc-3d9a1a22a0dc@andrewg.com>
Message-ID: <2e00cf99-ee48-1934-1437-7d1bb02cb94f@wisemo.com>

On 13/11/2025 12:56, Andrew Gallagher via Gnupg-users wrote:
> Hi, Peter.
>
> On 13/11/2025 09:23, Peter Pentchev wrote:
>> - so, IF NO `--rfc...` OPTION IS SPECIFIED, GnuPG HAS TO default to
>> ?? the least common denominator
>
> This is not how GnuPG's compliance options currently work though; 
> non-default compliance options cause GnuPG to comply with *earlier* 
> specs, to improve backwards compatibility at the expense of 
> cryptographic strength.
>
> It would be reasonable, and still solidly defensive, for GnuPG to emit 
> the old packet framing iff a compliance option such as --rfc2440 was 
> supplied, or if the key being encrypted to advertised old defaults, or 
> if the key material uses an algorithm or packet version that pre-dates 
> rfc4880. But it serves no purpose to continue to use the old format 
> with modern cryptography that legacy code can't understand anyway.
>
The important open questions are:

1. Since what version and year does gnupg accept the new framing of 
packets that it can also accept with old framing?? This controls when 
senders will be able to use the new framing by default.

2. Since what year do all then-and-later commonly distributed OpenPGP 
implementations accept the new framing of packets that gnupg can send 
with old framing? This controls when gnupg will be able to send the new 
framing by default.

3. If either of the above questions are answered by "recent" (for 
enterprise-frozen values of "recent"), should gnupg add options to 
specify that the recipient follows a newer spec, such as rfc-4880, and 
can thus decode the new framing of old packet types and can also handle 
the new packet types introduced by that "newer spec"?? Such an option 
might be named --rfc4880plus or --no-rfc2440 (meaning don't implicitly 
trigger option --rfc2440, but be careful not to create a contradictory 
corner case where --rfc2440 is not the exact negative of --no-rfc2440).

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 ametzler at bebt.de  Thu Nov 13 12:50:11 2025
From: ametzler at bebt.de (Andreas Metzler)
Date: Thu, 13 Nov 2025 12:50:11 +0100
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <aRWjqr130IkWhbvx@straylight.m.ringlet.net>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
 <bed78415-177c-4eaa-b1ef-8266d121f70a@loup-vaillant.fr>
 <a20c71bc-bb16-4bbf-bbb5-8a1f72774d73@gmail.com>
 <17e6ae13-bf0c-4456-82c6-7a41418ce719@loup-vaillant.fr>
 <aRWjqr130IkWhbvx@straylight.m.ringlet.net>
Message-ID: <aRXF89gJIBuY-Wtq@argenau.bebt.de>

On 2025-11-13 Peter Pentchev <roam at ringlet.net> wrote:
[...]
> - so, IF NO `--rfc...` OPTION IS SPECIFIED, GnuPG HAS TO default to
>   the least common denominator

Hello,
Is this really true in this strict sense? Afaik GnuPG has not been
emitting rfc-2440 (or even rfc-4880) compliant packets *by* *default*
for ages.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From andrewg at andrewg.com  Thu Nov 13 15:42:37 2025
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Thu, 13 Nov 2025 14:42:37 +0000
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <2e00cf99-ee48-1934-1437-7d1bb02cb94f@wisemo.com>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
 <bed78415-177c-4eaa-b1ef-8266d121f70a@loup-vaillant.fr>
 <a20c71bc-bb16-4bbf-bbb5-8a1f72774d73@gmail.com>
 <17e6ae13-bf0c-4456-82c6-7a41418ce719@loup-vaillant.fr>
 <aRWjqr130IkWhbvx@straylight.m.ringlet.net>
 <c766096f-1b1b-4fc5-b3dc-3d9a1a22a0dc@andrewg.com>
 <2e00cf99-ee48-1934-1437-7d1bb02cb94f@wisemo.com>
Message-ID: <f9d672a5-ca3b-4db6-b476-cf19820e905d@andrewg.com>

On 13/11/2025 12:35, Jakob Bohm via Gnupg-users wrote:
> 
> 1. Since what version and year does gnupg accept the new framing of 
> packets that it can also accept with old framing?? This controls when 
> senders will be able to use the new framing by default.

I believe gnupg has always supported the new framing - it was defined in 
the first OpenPGP spec (RFC2440) in 1998, and gnupg 1.0 was released in 
September 1999.

> 2. Since what year do all then-and-later commonly distributed OpenPGP 
> implementations accept the new framing of packets that gnupg can send 
> with old framing? This controls when gnupg will be able to send the new 
> framing by default.

AIUI the only code that cannot understand the new framing is in 
pre-OpenPGP versions of commercial PGP. PGP5 had partial support for the 
new framing, but note that PGP5 was incomplete in many other areas; for 
example it only had partial support for V4 signatures and its OPS 
handling was buggy. See Section 14 of RFC2440 for a list of caveats:

https://datatracker.ietf.org/doc/html/rfc2440#section-14

Basically, if you are still using a version of commercial PGP that can't 
handle modern packet framing, that's the *least* of your problems.

> 3. If either of the above questions are answered by "recent" (for 
> enterprise-frozen values of "recent"), should gnupg add options to 
> specify that the recipient follows a newer spec, such as rfc-4880, and 
> can thus decode the new framing of old packet types and can also handle 
> the new packet types introduced by that "newer spec"?? Such an option 
> might be named --rfc4880plus or --no-rfc2440 (meaning don't implicitly 
> trigger option --rfc2440, but be careful not to create a contradictory 
> corner case where --rfc2440 is not the exact negative of --no-rfc2440).

Note that it was RFC2440 (1998) that specified modern packet framing 
even for existing features; RFC4880 was the first spec that introduced 
new features with a *requirement* for the modern framing. All 
OpenPGP-compatible software SHOULD therefore accept the modern framing.

A



From wk at gnupg.org  Thu Nov 13 21:17:20 2025
From: wk at gnupg.org (Werner Koch)
Date: Thu, 13 Nov 2025 21:17:20 +0100
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <c766096f-1b1b-4fc5-b3dc-3d9a1a22a0dc@andrewg.com> (Andrew
 Gallagher via Gnupg-users's message of "Thu, 13 Nov 2025 11:56:32
 +0000")
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
 <bed78415-177c-4eaa-b1ef-8266d121f70a@loup-vaillant.fr>
 <a20c71bc-bb16-4bbf-bbb5-8a1f72774d73@gmail.com>
 <17e6ae13-bf0c-4456-82c6-7a41418ce719@loup-vaillant.fr>
 <aRWjqr130IkWhbvx@straylight.m.ringlet.net>
 <c766096f-1b1b-4fc5-b3dc-3d9a1a22a0dc@andrewg.com>
Message-ID: <875xbdsn5b.fsf@jacob.g10code.de>

Hi!

Some background on why we have these compliance options: Back then when
we developed rfc2440, and later rfc4880, it was useful to have them to
test the changes we implemented in PGP and GnuPG.  The --pgp options
were also useful in the early days for an easy migration path from pgp2
to gpg; in particular in MUAs like Pine and such.

These days they are mostly useless because everyone demands MDC and it
is virtually impossible to keep the compliance options exactly up to the
respective specification.  But people are using them and thus it is hard
to remove the option.

The new generalized option --compliance is now used to restrict he GnuPG
behaviour to certain compliance requirements.  Currently only for the
German/EU/NATO compliance but maybe later also for FIPS.


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/20251113/988f5fe9/attachment-0001.sig>

From jcb62281 at gmail.com  Fri Nov 14 02:29:52 2025
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Thu, 13 Nov 2025 19:29:52 -0600
Subject: GnuPG 2.4.4 still using legacy packets?
In-Reply-To: <c766096f-1b1b-4fc5-b3dc-3d9a1a22a0dc@andrewg.com>
References: <cff47ce4-ac11-4023-8e9c-424e5661b2b5@loup-vaillant.fr>
 <aRMoD7nyHRNIL92A@ohm.59.ca>
 <bed78415-177c-4eaa-b1ef-8266d121f70a@loup-vaillant.fr>
 <a20c71bc-bb16-4bbf-bbb5-8a1f72774d73@gmail.com>
 <17e6ae13-bf0c-4456-82c6-7a41418ce719@loup-vaillant.fr>
 <aRWjqr130IkWhbvx@straylight.m.ringlet.net>
 <c766096f-1b1b-4fc5-b3dc-3d9a1a22a0dc@andrewg.com>
Message-ID: <43a61e1c-7564-4ee9-8b1e-8dba8f65c5bc@gmail.com>

On 11/13/25 05:56, Andrew Gallagher via Gnupg-users wrote:
> Hi, Peter.
>
> On 13/11/2025 09:23, Peter Pentchev wrote:
>> - so, IF NO `--rfc...` OPTION IS SPECIFIED, GnuPG HAS TO default to
>> ?? the least common denominator
>
> This is not how GnuPG's compliance options currently work though; 
> non-default compliance options cause GnuPG to comply with *earlier* 
> specs, to improve backwards compatibility at the expense of 
> cryptographic strength.
>
> It would be reasonable, and still solidly defensive, for GnuPG to emit 
> the old packet framing iff a compliance option such as --rfc2440 was 
> supplied, or if the key being encrypted to advertised old defaults, or 
> if the key material uses an algorithm or packet version that pre-dates 
> rfc4880. But it serves no purpose to continue to use the old format 
> with modern cryptography that legacy code can't understand anyway.

This is what I am suggesting:? when using ciphers that were not 
available in the ancient implementations that do not understand the new 
format, use the new format because interoperability is broken (at the 
user's command) anyway.

I also noted that it may be possible for some modern signatures to be 
usable in those ancient implementations.? If that is so, this should 
*not* be gratuitously broken unless we find some serious cryptographic 
flaw in that format.

If there *is* such a flaw, GnuPG could still have an option to generate 
the old form, in case someone out there actually has a workflow that 
depends on it, but should emit a BIG SCARY WARNING explaining the 
problem, both when generating a weak signature and especially upon 
verifying one!


-- Jacob




From kodanevhyz at gmail.com  Fri Nov 14 10:05:48 2025
From: kodanevhyz at gmail.com (Mizar Zhou)
Date: Fri, 14 Nov 2025 17:05:48 +0800
Subject: Inquire about the performance of gcrypt on ARM architecture
Message-ID: <2F7F7E95-C6E2-468D-BD87-C80B37D13D0F@gmail.com>

Hi everyone,



I?d like to ask about the performance of Libgcrypt on ARM architectures.



In my tests, using the same Libgcrypt version on ARMv8 results in performance that is three times slower, or even more, compared to Intel. Is this expected behavior? If not, are there any performance-related configuration options or build switches that I might have overlooked?



I?m using Libgcrypt 1.10.0 in ARMv8, compiled with the default settings.



Arm:

[root at node-2 tests]# ./benchmark --large-buffers --cipher-repetitions 1000 cipher aes256

Running each test 1000 times.

                ECB/Stream    CBC/Poly1305         CFB             OFB             CTR             XTS             CCM             GCM             OCB             EAX

             --------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- ---------------

AES256         380ms   390ms  1350ms   440ms  1360ms   440ms  1350ms  1360ms   430ms   440ms   530ms   550ms  1820ms  1800ms   680ms   670ms   480ms   480ms  1820ms  1810ms



x86:

[root at node-94 tests]# ./benchmark --large-buffers --cipher-repetitions 1000 cipher aes256

Running each test 1000 times.

                ECB/Stream    CBC/Poly1305         CFB             OFB             CTR             XTS             CCM             GCM             OCB             EAX

             --------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- ---------------

AES256          80ms    90ms  1050ms    90ms  1040ms    90ms  1250ms  1250ms    90ms    90ms   120ms   130ms  1140ms  1140ms   160ms   160ms    90ms    90ms  1150ms  1140ms



Thanks and regards,

Zhou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251114/6b2e7a7c/attachment.html>

From ametzler at bebt.de  Sat Nov 15 06:53:14 2025
From: ametzler at bebt.de (Andreas Metzler)
Date: Sat, 15 Nov 2025 06:53:14 +0100
Subject: Inquire about the performance of gcrypt on ARM architecture
In-Reply-To: <2F7F7E95-C6E2-468D-BD87-C80B37D13D0F@gmail.com>
References: <2F7F7E95-C6E2-468D-BD87-C80B37D13D0F@gmail.com>
Message-ID: <aRgVSjYv53Vghq9_@argenau.bebt.de>

On 2025-11-14 Mizar Zhou via Gnupg-users <gnupg-users at gnupg.org> wrote:
> Hi everyone,


> In my tests, using the same Libgcrypt version on ARMv8 results in
> performance that is three times slower, or even more, compared to
> Intel. Is this expected behavior? If not, are there any
> performance-related configuration options or build switches that I
> might have overlooked?

> I?m using Libgcrypt 1.10.0 in ARMv8, compiled with the default settings.
[...]

How about testing with a non-ancient version of libgcrypt?

Also: The performance of the two machines (arm and x86) might not be
identical.

cu Andreas


From jussi.kivilinna at iki.fi  Sun Nov 16 13:21:36 2025
From: jussi.kivilinna at iki.fi (Jussi Kivilinna)
Date: Sun, 16 Nov 2025 14:21:36 +0200
Subject: Inquire about the performance of gcrypt on ARM architecture
In-Reply-To: <2F7F7E95-C6E2-468D-BD87-C80B37D13D0F@gmail.com>
References: <2F7F7E95-C6E2-468D-BD87-C80B37D13D0F@gmail.com>
Message-ID: <4ebe405b-88a2-4509-b531-6a9bdfd76d8f@iki.fi>

Hello,

On 14/11/2025 11:05, Mizar Zhou via Gnupg-users wrote:
> Hi everyone,
> 
> 
> I?d like to ask about the performance of Libgcrypt on ARM architectures.
> 
> 
> In my tests, using the same Libgcrypt version on ARMv8 results in performance that is *three times slower, or even more*, compared to Intel. Is this expected behavior? If not, are there any performance-related configuration options or build switches that I might have overlooked?
> 

When comparing two different systems, you'd need to also check at differences of those systems. For example, does the other system have significantly higher clock speed? When comparing AES performance, does both systems have AES acceleration instructions sets available? With Linux system, you can check /proc/cpuinfo. You can check if libgcrypt is detecting AES acceleration on CPU with 'tests/version'.

Here's example on x86-64 architecture:


$ cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 25
model           : 97
model name      : AMD Ryzen 9 7900X 12-Core Processor
stepping        : 2
microcode       : 0xa60120c
cpu MHz         : 4947.451
cache size      : 1024 KB
physical id     : 0
siblings        : 24
core id         : 0
cpu cores       : 12
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 16
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good amd_lbr_v2 nopl xtopology nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt ***aes*** xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpuid_fault cpb cat_l3 cdp_l3 hw_pstate ssbd mba perfmon_v2 ibrs ibpb stibp ibrs_enhanced vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local avx512_bf16 clzero irperf xsaveerptr rdpru wbnoinvd cppc arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic vgif x2avic v_spec_ctrl vnmi avx512vbmi umip pku ospke avx512_vbmi2 gfni ***vaes*** vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid overflow_recov succor smca fsrm flush_l1d amd_lbr_pmc_freeze
bugs            : sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass srso spectre_v2_user tsa vmscape
bogomips        : 9400.07
TLB size        : 3584 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm hwpstate cpb eff_freq_ro [13] [14]

$ tests/version
version:1.12.0-beta677:10c00:1.51:13300:
cc:150200:gcc:15.2.0:
ciphers:arcfour:blowfish:cast5:des:aes:twofish:serpent:rfc2268:seed:camellia:idea:salsa20:gost28147:chacha20:sm4:aria:
pubkeys:dsa:elgamal:rsa:ecc:kyber:dilithium:
digests:crc:gostr3411-94::md4:md5:rmd160:sha1:sha256:sha512:sha3:tiger:whirlpool:stribog:blake2:sm3:
rnd-mod:getentropy:
cpu-arch:x86:amd64:
mpi-asm:amd64/mpih-add1.S:amd64/mpih-sub1.S:amd64/mpih-mul1.S:amd64/mpih-mul2.S:amd64/mpih-mul3.S:amd64/mpih-lshift.S:amd64/mpih-rshift.S:
mpi-powm:fixed-window
hwflist:intel-bmi2:intel-ssse3:intel-sse4.1:intel-pclmul:***intel-aesni***:intel-rdrand:intel-avx:intel-avx2:intel-rdtsc:intel-shaext:***intel-vaes-vpclmul***:intel-avx512:intel-gfni:
fips-mode:n:::
rng-type:standard:1:3030000:1:
compliance:::


You can disable AES acceleration with --disable-hwf option to 'tests/benchmark' or 'tests/bench-slope'. This way you can check if libgcrypt's AES acceleration is active by default on your target system:


$ tests/benchmark --large-buffers --cipher-repetitions 1000 cipher aes256
Running each test 1000 times.
                 ECB/Stream    CBC/Poly1305         CFB             OFB             CTR             XTS             CCM             GCM             OCB             EAX
              --------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- ---------------
AES256          40ms    50ms   710ms    50ms   670ms    40ms   980ms   980ms    40ms    50ms    50ms    60ms   710ms   710ms    80ms    70ms    50ms    40ms   710ms   710ms

$ ./benchmark --large-buffers --cipher-repetitions 1000 --disable-hwf intel-aesni --disable-hwf intel-vaes-vpclmul cipher aes256
Running each test 1000 times.
                 ECB/Stream    CBC/Poly1305         CFB             OFB             CTR             XTS             CCM             GCM             OCB             EAX
              --------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- ---------------
AES256        3060ms  3870ms  3280ms  3830ms  3250ms  2950ms  3330ms  3320ms  3000ms  3000ms  3110ms  3990ms  6270ms  6290ms  3090ms  3060ms  3020ms  3900ms  6290ms  6260ms


To get some estimate on your CPU frequency during tests, you can use '--cpu-mhz auto' setting of bench-slope tool:

$ tests/bench-slope --cpu-mhz auto cipher aes256
Cipher:
  AES256         |  nanosecs/byte   mebibytes/sec   cycles/byte  auto Mhz
         ECB enc |     0.040 ns/B     23975 MiB/s     0.224 c/B      5624
         ECB dec |     0.040 ns/B     24061 MiB/s     0.223 c/B      5624
         CBC enc |     0.647 ns/B      1473 MiB/s      3.60 c/B      5555?1
         CBC dec |     0.040 ns/B     24044 MiB/s     0.223 c/B      5624
         CFB enc |     0.647 ns/B      1475 MiB/s      3.55 c/B      5487?5
         CFB dec |     0.041 ns/B     23519 MiB/s     0.223 c/B      5500
         OFB enc |     0.937 ns/B      1018 MiB/s      5.27 c/B      5624
         OFB dec |     0.932 ns/B      1024 MiB/s      5.24 c/B      5624
         CTR enc |     0.041 ns/B     23294 MiB/s     0.225 c/B      5500
         CTR dec |     0.041 ns/B     23332 MiB/s     0.225 c/B      5500
         XTS enc |     0.053 ns/B     17877 MiB/s     0.293 c/B      5500
         XTS dec |     0.054 ns/B     17652 MiB/s     0.297 c/B      5500
         CCM enc |     0.692 ns/B      1378 MiB/s      3.90 c/B      5640?3
         CCM dec |     0.688 ns/B      1386 MiB/s      3.74 c/B      5437?5
        CCM auth |     0.647 ns/B      1475 MiB/s      3.65 c/B      5651?1
         EAX enc |     0.691 ns/B      1380 MiB/s      3.95 c/B      5717?4
         EAX dec |     0.692 ns/B      1378 MiB/s      3.80 c/B      5487?5
        EAX auth |     0.646 ns/B      1476 MiB/s      3.54 c/B      5473?1
         GCM enc |     0.072 ns/B     13281 MiB/s     0.395 c/B      5500
         GCM dec |     0.072 ns/B     13271 MiB/s     0.395 c/B      5500
        GCM auth |     0.030 ns/B     31772 MiB/s     0.165 c/B      5500
         OCB enc |     0.041 ns/B     23461 MiB/s     0.224 c/B      5500
         OCB dec |     0.044 ns/B     21456 MiB/s     0.244 c/B      5500
        OCB auth |     0.040 ns/B     23562 MiB/s     0.223 c/B      5500
         SIV enc |     0.693 ns/B      1376 MiB/s      3.82 c/B      5510?1
         SIV dec |     0.696 ns/B      1370 MiB/s      3.82 c/B      5487?5
        SIV auth |     0.650 ns/B      1466 MiB/s      3.67 c/B      5637?4
     GCM-SIV enc |     0.074 ns/B     12831 MiB/s     0.418 c/B      5624
     GCM-SIV dec |     0.079 ns/B     12045 MiB/s     0.445 c/B      5624
    GCM-SIV auth |     0.033 ns/B     29124 MiB/s     0.180 c/B      5500
                 =

> 
> I?m using *Libgcrypt 1.10.0 *in ARMv8, compiled with the default settings.
> 
> 
> Arm:
> 
> [root at node-2 tests]# ./benchmark --large-buffers --cipher-repetitions 1000 cipher aes256
> 
> Running each test 1000 times.
> 
>  ? ? ? ? ? ? ? ? ECB/Stream ? ?CBC/Poly1305 ? ? ? ? CFB ? ? ? ? ? ? OFB ? ? ? ? ? ? CTR *XTS* ? ? ? ? ? ? CCM ? ? ? ? ? ? GCM ? ? ? ? ? ? OCB ? ? ? ? ? ? EAX
> 
>  ? ? ? ? ? ? ?--------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- ---------------
> 
> AES256 ? ? ? ? 380ms ? 390ms ?1350ms ? 440ms ?1360ms ? 440ms ?1350ms ?1360ms ? 430ms ? 440ms *530ms ? 550ms* ?1820ms ?1800ms ? 680ms ? 670ms ? 480ms ? 480ms ?1820ms ?1810ms
> 

My old ARMv8 system (with AES acceleration) shows following results:


$ cat /proc/cpuinfo
processor       : 0
BogoMIPS        : 48.00
Features        : fp asimd evtstrm ***aes*** pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd03
CPU revision    : 4

$ ./version
version:1.11.1-beta23:10b01:1.50-beta2:13200:
cc:130200:gcc:13.2.0:
ciphers:arcfour:blowfish:cast5:des:aes:twofish:serpent:rfc2268:seed:camellia:idea:salsa20:gost28147:chacha20:sm4:aria:
pubkeys:dsa:elgamal:rsa:ecc:
digests:crc:gostr3411-94::md4:md5:rmd160:sha1:sha256:sha512:sha3:tiger:whirlpool:stribog:blake2:sm3:
rnd-mod:getentropy:
cpu-arch:arm:
mpi-asm:arm/mpih-add1.S:arm/mpih-sub1.S:arm/mpih-mul1.S:arm/mpih-mul2.S:arm/mpih-mul3.S:generic/mpih-lshift.c:generic/mpih-rshift.c:
hwflist:arm-neon:***arm-aes***:arm-sha1:arm-sha2:arm-pmull:
fips-mode:n:::
rng-type:standard:1:3030000:2:
compliance:::


With AES acceleration:


$ ./benchmark --large-buffers --cipher-repetitions 1000 cipher aes256
Running each test 1000 times.
                 ECB/Stream    CBC/Poly1305         CFB             OFB             CTR             XTS             CCM             GCM             OCB             EAX
              --------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- ---------------
AES256        6340ms  6540ms  1950ms  1200ms  1830ms  1190ms  6740ms  6740ms  1340ms  1340ms  1560ms  1560ms  3330ms  3350ms  2280ms  2260ms  1560ms  1550ms  3350ms  3340ms

$ ./bench-slope --cpu-mhz auto cipher aes256
Cipher:
  AES256         |  nanosecs/byte   mebibytes/sec   cycles/byte  auto Mhz
         ECB enc |      1.02 ns/B     936.5 MiB/s      1.17 c/B      1152
         ECB dec |      1.02 ns/B     935.9 MiB/s      1.17 c/B      1152
         CBC enc |      1.57 ns/B     605.9 MiB/s      1.81 c/B      1152
         CBC dec |      1.06 ns/B     899.6 MiB/s      1.22 c/B      1152
         CFB enc |      1.63 ns/B     585.7 MiB/s      1.88 c/B      1152
         CFB dec |      1.06 ns/B     899.8 MiB/s      1.22 c/B      1152
         OFB enc |      6.29 ns/B     151.5 MiB/s      7.25 c/B      1152
         OFB dec |      6.29 ns/B     151.5 MiB/s      7.25 c/B      1152
         CTR enc |      1.11 ns/B     857.2 MiB/s      1.28 c/B      1152
         CTR dec |      1.11 ns/B     855.3 MiB/s      1.28 c/B      1152
         XTS enc |      1.44 ns/B     660.5 MiB/s      1.66 c/B      1152
         XTS dec |      1.44 ns/B     661.3 MiB/s      1.66 c/B      1152
         CCM enc |      2.75 ns/B     347.4 MiB/s      3.16 c/B      1152
         CCM dec |      2.74 ns/B     347.5 MiB/s      3.16 c/B      1152
        CCM auth |      1.74 ns/B     549.0 MiB/s      2.00 c/B      1152
         EAX enc |      2.75 ns/B     347.1 MiB/s      3.16 c/B      1152
         EAX dec |      2.76 ns/B     345.9 MiB/s      3.18 c/B      1152
        EAX auth |      1.63 ns/B     583.8 MiB/s      1.88 c/B      1152
         GCM enc |      1.99 ns/B     478.2 MiB/s      2.30 c/B      1152
         GCM dec |      2.00 ns/B     477.9 MiB/s      2.30 c/B      1152
        GCM auth |     0.881 ns/B      1082 MiB/s      1.02 c/B      1152
         OCB enc |      1.21 ns/B     788.1 MiB/s      1.39 c/B      1152
         OCB dec |      1.21 ns/B     785.2 MiB/s      1.40 c/B      1152
        OCB auth |      1.32 ns/B     724.7 MiB/s      1.52 c/B      1152
         SIV enc |      2.76 ns/B     346.1 MiB/s      3.17 c/B      1152
         SIV dec |      2.85 ns/B     334.6 MiB/s      3.28 c/B      1152
        SIV auth |      1.63 ns/B     583.7 MiB/s      1.88 c/B      1152
     GCM-SIV enc |      2.10 ns/B     453.1 MiB/s      2.42 c/B      1152
     GCM-SIV dec |      2.20 ns/B     433.2 MiB/s      2.54 c/B      1152
    GCM-SIV auth |     0.990 ns/B     963.6 MiB/s      1.14 c/B      1152
                 =


Without AES acceleration:


$ ./benchmark --large-buffers --cipher-repetitions 1000 --disable-hwf arm-aes cipher aes256
Running each test 1000 times.
                 ECB/Stream    CBC/Poly1305         CFB             OFB             CTR             XTS             CCM             GCM             OCB             EAX
              --------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- ---------------
AES256       30100ms 30640ms 26200ms 26330ms 26290ms 26180ms 30400ms 30370ms 26740ms 26690ms 26360ms 26380ms 52890ms 52910ms 27640ms 27620ms 27310ms 27520ms 52980ms 52900ms

$ ./bench-slope --cpu-mhz auto --disable-hwf arm-aes cipher aes256
Cipher:
  AES256         |  nanosecs/byte   mebibytes/sec   cycles/byte  auto Mhz
         ECB enc |     30.67 ns/B     31.09 MiB/s     35.33 c/B      1152
         ECB dec |     33.22 ns/B     28.71 MiB/s     38.27 c/B      1152
         CBC enc |     26.99 ns/B     35.33 MiB/s     31.09 c/B      1152
         CBC dec |     29.21 ns/B     32.65 MiB/s     33.64 c/B      1152
         CFB enc |     26.94 ns/B     35.40 MiB/s     31.03 c/B      1152
         CFB dec |     26.94 ns/B     35.40 MiB/s     31.03 c/B      1152
         OFB enc |     30.94 ns/B     30.82 MiB/s     35.64 c/B      1152
         OFB dec |     30.94 ns/B     30.82 MiB/s     35.64 c/B      1152
         CTR enc |     19.82 ns/B     48.12 MiB/s     22.83 c/B      1152
         CTR dec |     19.82 ns/B     48.11 MiB/s     22.83 c/B      1152
         XTS enc |     31.00 ns/B     30.77 MiB/s     35.71 c/B      1152
         XTS dec |     33.49 ns/B     28.47 MiB/s     38.58 c/B      1152
         CCM enc |     46.87 ns/B     20.35 MiB/s     54.00 c/B      1152
         CCM dec |     46.88 ns/B     20.34 MiB/s     53.99 c/B      1152
        CCM auth |     27.10 ns/B     35.19 MiB/s     31.22 c/B      1152
         EAX enc |     46.88 ns/B     20.34 MiB/s     54.00 c/B      1152
         EAX dec |     46.88 ns/B     20.34 MiB/s     54.00 c/B      1152
        EAX auth |     27.05 ns/B     35.25 MiB/s     31.16 c/B      1152
         GCM enc |     20.70 ns/B     46.08 MiB/s     23.84 c/B      1152
         GCM dec |     20.70 ns/B     46.07 MiB/s     23.85 c/B      1152
        GCM auth |     0.877 ns/B      1087 MiB/s      1.01 c/B      1152
         OCB enc |     27.32 ns/B     34.91 MiB/s     31.46 c/B      1152
         OCB dec |     29.58 ns/B     32.24 MiB/s     34.08 c/B      1152
        OCB auth |     27.27 ns/B     34.97 MiB/s     31.42 c/B      1152
         SIV enc |     46.89 ns/B     20.34 MiB/s     54.00 c/B      1152
         SIV dec |     46.97 ns/B     20.30 MiB/s     54.11 c/B      1152
        SIV auth |     27.05 ns/B     35.25 MiB/s     31.16 c/B      1152
     GCM-SIV enc |     32.09 ns/B     29.72 MiB/s     36.96 c/B      1152
     GCM-SIV dec |     32.19 ns/B     29.63 MiB/s     37.08 c/B      1152
    GCM-SIV auth |     0.976 ns/B     976.7 MiB/s      1.12 c/B      1152
                 =


-Jussi

From kodanevhyz at gmail.com  Mon Nov 17 07:33:38 2025
From: kodanevhyz at gmail.com (Mizar Zhou)
Date: Mon, 17 Nov 2025 14:33:38 +0800
Subject: Inquire about the performance of gcrypt on ARM architecture
In-Reply-To: <4ebe405b-88a2-4509-b531-6a9bdfd76d8f@iki.fi>
References: <2F7F7E95-C6E2-468D-BD87-C80B37D13D0F@gmail.com>
 <4ebe405b-88a2-4509-b531-6a9bdfd76d8f@iki.fi>
Message-ID: <C2E60408-1791-4BD8-84BF-4C07A2E2A27C@gmail.com>

Hi, Jussi, Thanks for your patient replying

I have confirmed that AES hardware acceleration is active on my ARM node; without it, the performance drops significantly.

I believe this is not an issue with Libgcrypt?s compilation options on ARM, but rather a limitation of the hardware?s throughput.


Thank you.


ARM:

[root at node-2 tests]# ./version
version:1.12.0-beta679:10c00:1.57-beta1:13900:
cc:110500:gcc:11.5.0 20240719 (Red Hat 11.5.0-5):
ciphers:arcfour:blowfish:cast5:des:aes:twofish:serpent:rfc2268:seed:camellia:idea:salsa20:gost28147:chacha20:sm4:aria:
pubkeys:dsa:elgamal:rsa:ecc:kyber:dilithium:
digests:crc:gostr3411-94::md4:md5:rmd160:sha1:sha256:sha512:sha3:tiger:whirlpool:stribog:blake2:sm3:
rnd-mod:getentropy:
cpu-arch:arm:
mpi-asm:aarch64/mpih-add1.S:aarch64/mpih-sub1.S:aarch64/mpih-mul1.S:aarch64/mpih-mul2.S:aarch64/mpih-mul3.S:generic/mpih-lshift.c:generic/mpih-rshift.c:
mpi-powm:fixed-window
hwflist:arm-neon:arm-aes:arm-sha1:arm-sha2:arm-pmull:
fips-mode:n:::
rng-type:standard:1:3030000:2:
compliance:::


[root at node-2 tests]# ./bench-slope --cpu-mhz auto cipher aes256
Cipher:
 AES256         |  nanosecs/byte   mebibytes/sec   cycles/byte  auto Mhz
        ECB enc |     0.355 ns/B      2689 MiB/s     0.922 c/B      2600
        ECB dec |     0.355 ns/B      2688 MiB/s     0.922 c/B      2600
        CBC enc |      1.32 ns/B     721.5 MiB/s      3.44 c/B      2600
        CBC dec |     0.421 ns/B      2265 MiB/s      1.09 c/B      2600
        CFB enc |      1.32 ns/B     721.6 MiB/s      3.44 c/B      2600
        CFB dec |     0.433 ns/B      2203 MiB/s      1.13 c/B      2600
        OFB enc |      1.32 ns/B     720.2 MiB/s      3.44 c/B      2600
        OFB dec |      1.32 ns/B     720.0 MiB/s      3.44 c/B      2600
        CTR enc |     0.451 ns/B      2115 MiB/s      1.17 c/B      2600
        CTR dec |     0.451 ns/B      2116 MiB/s      1.17 c/B      2600
        XTS enc |     0.535 ns/B      1783 MiB/s      1.39 c/B      2600
        XTS dec |     0.495 ns/B      1926 MiB/s      1.29 c/B      2600
        CCM enc |      1.77 ns/B     538.3 MiB/s      4.61 c/B      2600
        CCM dec |      1.77 ns/B     538.2 MiB/s      4.61 c/B      2600
       CCM auth |      1.32 ns/B     720.9 MiB/s      3.44 c/B      2600
        EAX enc |      1.77 ns/B     537.3 MiB/s      4.61 c/B      2600
        EAX dec |      1.77 ns/B     540.1 MiB/s      4.59 c/B      2600
       EAX auth |      1.32 ns/B     721.5 MiB/s      3.44 c/B      2600
        GCM enc |     0.673 ns/B      1417 MiB/s      1.75 c/B      2600
        GCM dec |     0.648 ns/B      1471 MiB/s      1.69 c/B      2600
       GCM auth |     0.210 ns/B      4541 MiB/s     0.546 c/B      2600
        OCB enc |     0.463 ns/B      2062 MiB/s      1.20 c/B      2600
        OCB dec |     0.463 ns/B      2061 MiB/s      1.20 c/B      2600
       OCB auth |     0.440 ns/B      2165 MiB/s      1.15 c/B      2600
        SIV enc |      1.78 ns/B     537.2 MiB/s      4.62 c/B      2600
        SIV dec |      1.80 ns/B     531.1 MiB/s      4.67 c/B      2600
       SIV auth |      1.32 ns/B     720.8 MiB/s      3.44 c/B      2600
    GCM-SIV enc |     0.641 ns/B      1489 MiB/s      1.67 c/B      2600
    GCM-SIV dec |     0.712 ns/B      1340 MiB/s      1.85 c/B      2600
   GCM-SIV auth |     0.241 ns/B      3963 MiB/s     0.626 c/B      2600


[root at node-2 tests]# ./bench-slope --cpu-mhz auto --disable-hwf arm-aes cipher aes256
Cipher:
 AES256         |  nanosecs/byte   mebibytes/sec   cycles/byte  auto Mhz
        ECB enc |      6.32 ns/B     150.9 MiB/s     16.43 c/B      2600
        ECB dec |      7.69 ns/B     124.1 MiB/s     19.98 c/B      2600
        CBC enc |     10.82 ns/B     88.16 MiB/s     28.12 c/B      2600
        CBC dec |      7.78 ns/B     122.7 MiB/s     20.21 c/B      2600
        CFB enc |     10.87 ns/B     87.71 MiB/s     28.27 c/B      2600
        CFB dec |      6.39 ns/B     149.3 MiB/s     16.60 c/B      2600
        OFB enc |     11.18 ns/B     85.29 MiB/s     29.07 c/B      2600
        OFB dec |     11.16 ns/B     85.49 MiB/s     29.00 c/B      2600
        CTR enc |      6.41 ns/B     148.9 MiB/s     16.66 c/B      2600
        CTR dec |      6.41 ns/B     148.8 MiB/s     16.66 c/B      2600
        XTS enc |      6.44 ns/B     148.2 MiB/s     16.73 c/B      2600
        XTS dec |      7.91 ns/B     120.6 MiB/s     20.57 c/B      2600
        CCM enc |     17.22 ns/B     55.37 MiB/s     44.78 c/B      2600
        CCM dec |     17.23 ns/B     55.36 MiB/s     44.79 c/B      2600
       CCM auth |     10.83 ns/B     88.08 MiB/s     28.15 c/B      2600
        EAX enc |     17.23 ns/B     55.36 MiB/s     44.79 c/B      2600
        EAX dec |     17.23 ns/B     55.36 MiB/s     44.79 c/B      2600
       EAX auth |     10.82 ns/B     88.14 MiB/s     28.13 c/B      2600
        GCM enc |      6.62 ns/B     144.1 MiB/s     17.21 c/B      2600
        GCM dec |      6.62 ns/B     144.1 MiB/s     17.20 c/B      2600
       GCM auth |     0.211 ns/B      4514 MiB/s     0.549 c/B      2600
        OCB enc |      6.38 ns/B     149.6 MiB/s     16.58 c/B      2600
        OCB dec |      7.79 ns/B     122.4 MiB/s     20.26 c/B      2600
       OCB auth |      6.48 ns/B     147.3 MiB/s     16.83 c/B      2600
        SIV enc |     17.28 ns/B     55.20 MiB/s     44.91 c/B      2600
        SIV dec |     17.30 ns/B     55.12 MiB/s     44.98 c/B      2600
       SIV auth |     10.82 ns/B     88.14 MiB/s     28.13 c/B      2600
    GCM-SIV enc |      6.60 ns/B     144.5 MiB/s     17.16 c/B      2600
    GCM-SIV dec |      6.62 ns/B     144.0 MiB/s     17.22 c/B      2600
   GCM-SIV auth |     0.240 ns/B      3970 MiB/s     0.625 c/B      2600
                =


x86:

[root at node-94 tests]# ./version
version:1.12.0-beta679:10c00:1.57-beta1:13900:
cc:110500:gcc:11.5.0 20240719 (Red Hat 11.5.0-5):
ciphers:arcfour:blowfish:cast5:des:aes:twofish:serpent:rfc2268:seed:camellia:idea:salsa20:gost28147:chacha20:sm4:aria:
pubkeys:dsa:elgamal:rsa:ecc:kyber:dilithium:
digests:crc:gostr3411-94::md4:md5:rmd160:sha1:sha256:sha512:sha3:tiger:whirlpool:stribog:blake2:sm3:
rnd-mod:getentropy:
cpu-arch:x86:amd64:
mpi-asm:amd64/mpih-add1.S:amd64/mpih-sub1.S:amd64/mpih-mul1.S:amd64/mpih-mul2.S:amd64/mpih-mul3.S:amd64/mpih-lshift.S:amd64/mpih-rshift.S:
mpi-powm:fixed-window
hwflist:intel-cpu:intel-bmi2:intel-ssse3:intel-sse4.1:intel-pclmul:intel-aesni:intel-rdrand:intel-avx:intel-avx2:intel-rdtsc:intel-shaext:intel-vaes-vpclmul:intel-avx512:intel-gfni:
fips-mode:n:::
rng-type:standard:1:3030000:1:
compliance:::

[root at node-94 tests]# ./bench-slope --cpu-mhz auto cipher aes256
Cipher:
 AES256         |  nanosecs/byte   mebibytes/sec   cycles/byte  auto Mhz
        ECB enc |     0.085 ns/B     11178 MiB/s     0.221 c/B      2594
        ECB dec |     0.084 ns/B     11382 MiB/s     0.217 c/B      2594
        CBC enc |      1.02 ns/B     937.3 MiB/s      2.64 c/B      2594
        CBC dec |     0.085 ns/B     11186 MiB/s     0.221 c/B      2594
        CFB enc |      1.01 ns/B     942.6 MiB/s      2.62 c/B      2593
        CFB dec |     0.085 ns/B     11178 MiB/s     0.221 c/B      2594
        OFB enc |      1.21 ns/B     786.1 MiB/s      3.15 c/B      2594
        OFB dec |      1.22 ns/B     784.3 MiB/s      3.15 c/B      2594
        CTR enc |     0.086 ns/B     11150 MiB/s     0.222 c/B      2594
        CTR dec |     0.085 ns/B     11156 MiB/s     0.222 c/B      2594
        XTS enc |     0.120 ns/B      7978 MiB/s     0.310 c/B      2594
        XTS dec |     0.119 ns/B      8001 MiB/s     0.309 c/B      2594
        CCM enc |      1.10 ns/B     864.9 MiB/s      2.86 c/B      2594
        CCM dec |      1.10 ns/B     865.2 MiB/s      2.86 c/B      2594
       CCM auth |      1.02 ns/B     937.3 MiB/s      2.64 c/B      2594
        EAX enc |      1.11 ns/B     861.7 MiB/s      2.87 c/B      2594
        EAX dec |      1.11 ns/B     860.2 MiB/s      2.88 c/B      2594
       EAX auth |      1.02 ns/B     937.2 MiB/s      2.64 c/B      2594
        GCM enc |     0.155 ns/B      6171 MiB/s     0.401 c/B      2594
        GCM dec |     0.154 ns/B      6182 MiB/s     0.400 c/B      2594
       GCM auth |     0.068 ns/B     13950 MiB/s     0.177 c/B      2594
        OCB enc |     0.090 ns/B     10599 MiB/s     0.233 c/B      2594
        OCB dec |     0.083 ns/B     11444 MiB/s     0.216 c/B      2594
       OCB auth |     0.088 ns/B     10851 MiB/s     0.228 c/B      2594
        SIV enc |      1.11 ns/B     861.3 MiB/s      2.87 c/B      2594
        SIV dec |      1.13 ns/B     847.0 MiB/s      2.92 c/B      2594
       SIV auth |      1.02 ns/B     937.8 MiB/s      2.64 c/B      2594
    GCM-SIV enc |     0.142 ns/B      6735 MiB/s     0.367 c/B      2594
    GCM-SIV dec |     0.170 ns/B      5611 MiB/s     0.441 c/B      2594
   GCM-SIV auth |     0.068 ns/B     13978 MiB/s     0.177 c/B      2594
                =


Regards, Zhou

> 2025?11?16? 20:21?Jussi Kivilinna <jussi.kivilinna at iki.fi> ???
> 
> Hello,
> 
> On 14/11/2025 11:05, Mizar Zhou via Gnupg-users wrote:
>> Hi everyone,
>> I?d like to ask about the performance of Libgcrypt on ARM architectures.
>> In my tests, using the same Libgcrypt version on ARMv8 results in performance that is *three times slower, or even more*, compared to Intel. Is this expected behavior? If not, are there any performance-related configuration options or build switches that I might have overlooked?
> 
> When comparing two different systems, you'd need to also check at differences of those systems. For example, does the other system have significantly higher clock speed? When comparing AES performance, does both systems have AES acceleration instructions sets available? With Linux system, you can check /proc/cpuinfo. You can check if libgcrypt is detecting AES acceleration on CPU with 'tests/version'.
> 
> Here's example on x86-64 architecture:
> 
> 
> $ cat /proc/cpuinfo
> processor       : 0
> vendor_id       : AuthenticAMD
> cpu family      : 25
> model           : 97
> model name      : AMD Ryzen 9 7900X 12-Core Processor
> stepping        : 2
> microcode       : 0xa60120c
> cpu MHz         : 4947.451
> cache size      : 1024 KB
> physical id     : 0
> siblings        : 24
> core id         : 0
> cpu cores       : 12
> apicid          : 0
> initial apicid  : 0
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 16
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good amd_lbr_v2 nopl xtopology nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt ***aes*** xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpuid_fault cpb cat_l3 cdp_l3 hw_pstate ssbd mba perfmon_v2 ibrs ibpb stibp ibrs_enhanced vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local avx512_bf16 clzero irperf xsaveerptr rdpru wbnoinvd cppc arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic vgif x2avic v_spec_ctrl vnmi avx512vbmi umip pku ospke avx512_vbmi2 gfni ***vaes*** vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid overflow_recov succor smca fsrm flush_l1d amd_lbr_pmc_freeze
> bugs            : sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass srso spectre_v2_user tsa vmscape
> bogomips        : 9400.07
> TLB size        : 3584 4K pages
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 48 bits physical, 48 bits virtual
> power management: ts ttp tm hwpstate cpb eff_freq_ro [13] [14]
> 
> $ tests/version
> version:1.12.0-beta677:10c00:1.51:13300:
> cc:150200:gcc:15.2.0:
> ciphers:arcfour:blowfish:cast5:des:aes:twofish:serpent:rfc2268:seed:camellia:idea:salsa20:gost28147:chacha20:sm4:aria:
> pubkeys:dsa:elgamal:rsa:ecc:kyber:dilithium:
> digests:crc:gostr3411-94::md4:md5:rmd160:sha1:sha256:sha512:sha3:tiger:whirlpool:stribog:blake2:sm3:
> rnd-mod:getentropy:
> cpu-arch:x86:amd64:
> mpi-asm:amd64/mpih-add1.S:amd64/mpih-sub1.S:amd64/mpih-mul1.S:amd64/mpih-mul2.S:amd64/mpih-mul3.S:amd64/mpih-lshift.S:amd64/mpih-rshift.S:
> mpi-powm:fixed-window
> hwflist:intel-bmi2:intel-ssse3:intel-sse4.1:intel-pclmul:***intel-aesni***:intel-rdrand:intel-avx:intel-avx2:intel-rdtsc:intel-shaext:***intel-vaes-vpclmul***:intel-avx512:intel-gfni:
> fips-mode:n:::
> rng-type:standard:1:3030000:1:
> compliance:::
> 
> 
> You can disable AES acceleration with --disable-hwf option to 'tests/benchmark' or 'tests/bench-slope'. This way you can check if libgcrypt's AES acceleration is active by default on your target system:
> 
> 
> $ tests/benchmark --large-buffers --cipher-repetitions 1000 cipher aes256
> Running each test 1000 times.
>                ECB/Stream    CBC/Poly1305         CFB             OFB             CTR             XTS             CCM             GCM             OCB             EAX
>             --------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- ---------------
> AES256          40ms    50ms   710ms    50ms   670ms    40ms   980ms   980ms    40ms    50ms    50ms    60ms   710ms   710ms    80ms    70ms    50ms    40ms   710ms   710ms
> 
> $ ./benchmark --large-buffers --cipher-repetitions 1000 --disable-hwf intel-aesni --disable-hwf intel-vaes-vpclmul cipher aes256
> Running each test 1000 times.
>                ECB/Stream    CBC/Poly1305         CFB             OFB             CTR             XTS             CCM             GCM             OCB             EAX
>             --------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- ---------------
> AES256        3060ms  3870ms  3280ms  3830ms  3250ms  2950ms  3330ms  3320ms  3000ms  3000ms  3110ms  3990ms  6270ms  6290ms  3090ms  3060ms  3020ms  3900ms  6290ms  6260ms
> 
> 
> To get some estimate on your CPU frequency during tests, you can use '--cpu-mhz auto' setting of bench-slope tool:
> 
> $ tests/bench-slope --cpu-mhz auto cipher aes256
> Cipher:
> AES256         |  nanosecs/byte   mebibytes/sec   cycles/byte  auto Mhz
>        ECB enc |     0.040 ns/B     23975 MiB/s     0.224 c/B      5624
>        ECB dec |     0.040 ns/B     24061 MiB/s     0.223 c/B      5624
>        CBC enc |     0.647 ns/B      1473 MiB/s      3.60 c/B      5555?1
>        CBC dec |     0.040 ns/B     24044 MiB/s     0.223 c/B      5624
>        CFB enc |     0.647 ns/B      1475 MiB/s      3.55 c/B      5487?5
>        CFB dec |     0.041 ns/B     23519 MiB/s     0.223 c/B      5500
>        OFB enc |     0.937 ns/B      1018 MiB/s      5.27 c/B      5624
>        OFB dec |     0.932 ns/B      1024 MiB/s      5.24 c/B      5624
>        CTR enc |     0.041 ns/B     23294 MiB/s     0.225 c/B      5500
>        CTR dec |     0.041 ns/B     23332 MiB/s     0.225 c/B      5500
>        XTS enc |     0.053 ns/B     17877 MiB/s     0.293 c/B      5500
>        XTS dec |     0.054 ns/B     17652 MiB/s     0.297 c/B      5500
>        CCM enc |     0.692 ns/B      1378 MiB/s      3.90 c/B      5640?3
>        CCM dec |     0.688 ns/B      1386 MiB/s      3.74 c/B      5437?5
>       CCM auth |     0.647 ns/B      1475 MiB/s      3.65 c/B      5651?1
>        EAX enc |     0.691 ns/B      1380 MiB/s      3.95 c/B      5717?4
>        EAX dec |     0.692 ns/B      1378 MiB/s      3.80 c/B      5487?5
>       EAX auth |     0.646 ns/B      1476 MiB/s      3.54 c/B      5473?1
>        GCM enc |     0.072 ns/B     13281 MiB/s     0.395 c/B      5500
>        GCM dec |     0.072 ns/B     13271 MiB/s     0.395 c/B      5500
>       GCM auth |     0.030 ns/B     31772 MiB/s     0.165 c/B      5500
>        OCB enc |     0.041 ns/B     23461 MiB/s     0.224 c/B      5500
>        OCB dec |     0.044 ns/B     21456 MiB/s     0.244 c/B      5500
>       OCB auth |     0.040 ns/B     23562 MiB/s     0.223 c/B      5500
>        SIV enc |     0.693 ns/B      1376 MiB/s      3.82 c/B      5510?1
>        SIV dec |     0.696 ns/B      1370 MiB/s      3.82 c/B      5487?5
>       SIV auth |     0.650 ns/B      1466 MiB/s      3.67 c/B      5637?4
>    GCM-SIV enc |     0.074 ns/B     12831 MiB/s     0.418 c/B      5624
>    GCM-SIV dec |     0.079 ns/B     12045 MiB/s     0.445 c/B      5624
>   GCM-SIV auth |     0.033 ns/B     29124 MiB/s     0.180 c/B      5500
>                =
> 
>> I?m using *Libgcrypt 1.10.0 *in ARMv8, compiled with the default settings.
>> Arm:
>> [root at node-2 tests]# ./benchmark --large-buffers --cipher-repetitions 1000 cipher aes256
>> Running each test 1000 times.
>>                 ECB/Stream    CBC/Poly1305         CFB             OFB             CTR *XTS*             CCM             GCM             OCB             EAX
>>              --------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- ---------------
>> AES256         380ms   390ms  1350ms   440ms  1360ms   440ms  1350ms  1360ms   430ms   440ms *530ms   550ms*  1820ms  1800ms   680ms   670ms   480ms   480ms  1820ms  1810ms
> 
> My old ARMv8 system (with AES acceleration) shows following results:
> 
> 
> $ cat /proc/cpuinfo
> processor       : 0
> BogoMIPS        : 48.00
> Features        : fp asimd evtstrm ***aes*** pmull sha1 sha2 crc32 cpuid
> CPU implementer : 0x41
> CPU architecture: 8
> CPU variant     : 0x0
> CPU part        : 0xd03
> CPU revision    : 4
> 
> $ ./version
> version:1.11.1-beta23:10b01:1.50-beta2:13200:
> cc:130200:gcc:13.2.0:
> ciphers:arcfour:blowfish:cast5:des:aes:twofish:serpent:rfc2268:seed:camellia:idea:salsa20:gost28147:chacha20:sm4:aria:
> pubkeys:dsa:elgamal:rsa:ecc:
> digests:crc:gostr3411-94::md4:md5:rmd160:sha1:sha256:sha512:sha3:tiger:whirlpool:stribog:blake2:sm3:
> rnd-mod:getentropy:
> cpu-arch:arm:
> mpi-asm:arm/mpih-add1.S:arm/mpih-sub1.S:arm/mpih-mul1.S:arm/mpih-mul2.S:arm/mpih-mul3.S:generic/mpih-lshift.c:generic/mpih-rshift.c:
> hwflist:arm-neon:***arm-aes***:arm-sha1:arm-sha2:arm-pmull:
> fips-mode:n:::
> rng-type:standard:1:3030000:2:
> compliance:::
> 
> 
> With AES acceleration:
> 
> 
> $ ./benchmark --large-buffers --cipher-repetitions 1000 cipher aes256
> Running each test 1000 times.
>                ECB/Stream    CBC/Poly1305         CFB             OFB             CTR             XTS             CCM             GCM             OCB             EAX
>             --------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- ---------------
> AES256        6340ms  6540ms  1950ms  1200ms  1830ms  1190ms  6740ms  6740ms  1340ms  1340ms  1560ms  1560ms  3330ms  3350ms  2280ms  2260ms  1560ms  1550ms  3350ms  3340ms
> 
> $ ./bench-slope --cpu-mhz auto cipher aes256
> Cipher:
> AES256         |  nanosecs/byte   mebibytes/sec   cycles/byte  auto Mhz
>        ECB enc |      1.02 ns/B     936.5 MiB/s      1.17 c/B      1152
>        ECB dec |      1.02 ns/B     935.9 MiB/s      1.17 c/B      1152
>        CBC enc |      1.57 ns/B     605.9 MiB/s      1.81 c/B      1152
>        CBC dec |      1.06 ns/B     899.6 MiB/s      1.22 c/B      1152
>        CFB enc |      1.63 ns/B     585.7 MiB/s      1.88 c/B      1152
>        CFB dec |      1.06 ns/B     899.8 MiB/s      1.22 c/B      1152
>        OFB enc |      6.29 ns/B     151.5 MiB/s      7.25 c/B      1152
>        OFB dec |      6.29 ns/B     151.5 MiB/s      7.25 c/B      1152
>        CTR enc |      1.11 ns/B     857.2 MiB/s      1.28 c/B      1152
>        CTR dec |      1.11 ns/B     855.3 MiB/s      1.28 c/B      1152
>        XTS enc |      1.44 ns/B     660.5 MiB/s      1.66 c/B      1152
>        XTS dec |      1.44 ns/B     661.3 MiB/s      1.66 c/B      1152
>        CCM enc |      2.75 ns/B     347.4 MiB/s      3.16 c/B      1152
>        CCM dec |      2.74 ns/B     347.5 MiB/s      3.16 c/B      1152
>       CCM auth |      1.74 ns/B     549.0 MiB/s      2.00 c/B      1152
>        EAX enc |      2.75 ns/B     347.1 MiB/s      3.16 c/B      1152
>        EAX dec |      2.76 ns/B     345.9 MiB/s      3.18 c/B      1152
>       EAX auth |      1.63 ns/B     583.8 MiB/s      1.88 c/B      1152
>        GCM enc |      1.99 ns/B     478.2 MiB/s      2.30 c/B      1152
>        GCM dec |      2.00 ns/B     477.9 MiB/s      2.30 c/B      1152
>       GCM auth |     0.881 ns/B      1082 MiB/s      1.02 c/B      1152
>        OCB enc |      1.21 ns/B     788.1 MiB/s      1.39 c/B      1152
>        OCB dec |      1.21 ns/B     785.2 MiB/s      1.40 c/B      1152
>       OCB auth |      1.32 ns/B     724.7 MiB/s      1.52 c/B      1152
>        SIV enc |      2.76 ns/B     346.1 MiB/s      3.17 c/B      1152
>        SIV dec |      2.85 ns/B     334.6 MiB/s      3.28 c/B      1152
>       SIV auth |      1.63 ns/B     583.7 MiB/s      1.88 c/B      1152
>    GCM-SIV enc |      2.10 ns/B     453.1 MiB/s      2.42 c/B      1152
>    GCM-SIV dec |      2.20 ns/B     433.2 MiB/s      2.54 c/B      1152
>   GCM-SIV auth |     0.990 ns/B     963.6 MiB/s      1.14 c/B      1152
>                =
> 
> 
> Without AES acceleration:
> 
> 
> $ ./benchmark --large-buffers --cipher-repetitions 1000 --disable-hwf arm-aes cipher aes256
> Running each test 1000 times.
>                ECB/Stream    CBC/Poly1305         CFB             OFB             CTR             XTS             CCM             GCM             OCB             EAX
>             --------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- --------------- ---------------
> AES256       30100ms 30640ms 26200ms 26330ms 26290ms 26180ms 30400ms 30370ms 26740ms 26690ms 26360ms 26380ms 52890ms 52910ms 27640ms 27620ms 27310ms 27520ms 52980ms 52900ms
> 
> $ ./bench-slope --cpu-mhz auto --disable-hwf arm-aes cipher aes256
> Cipher:
> AES256         |  nanosecs/byte   mebibytes/sec   cycles/byte  auto Mhz
>        ECB enc |     30.67 ns/B     31.09 MiB/s     35.33 c/B      1152
>        ECB dec |     33.22 ns/B     28.71 MiB/s     38.27 c/B      1152
>        CBC enc |     26.99 ns/B     35.33 MiB/s     31.09 c/B      1152
>        CBC dec |     29.21 ns/B     32.65 MiB/s     33.64 c/B      1152
>        CFB enc |     26.94 ns/B     35.40 MiB/s     31.03 c/B      1152
>        CFB dec |     26.94 ns/B     35.40 MiB/s     31.03 c/B      1152
>        OFB enc |     30.94 ns/B     30.82 MiB/s     35.64 c/B      1152
>        OFB dec |     30.94 ns/B     30.82 MiB/s     35.64 c/B      1152
>        CTR enc |     19.82 ns/B     48.12 MiB/s     22.83 c/B      1152
>        CTR dec |     19.82 ns/B     48.11 MiB/s     22.83 c/B      1152
>        XTS enc |     31.00 ns/B     30.77 MiB/s     35.71 c/B      1152
>        XTS dec |     33.49 ns/B     28.47 MiB/s     38.58 c/B      1152
>        CCM enc |     46.87 ns/B     20.35 MiB/s     54.00 c/B      1152
>        CCM dec |     46.88 ns/B     20.34 MiB/s     53.99 c/B      1152
>       CCM auth |     27.10 ns/B     35.19 MiB/s     31.22 c/B      1152
>        EAX enc |     46.88 ns/B     20.34 MiB/s     54.00 c/B      1152
>        EAX dec |     46.88 ns/B     20.34 MiB/s     54.00 c/B      1152
>       EAX auth |     27.05 ns/B     35.25 MiB/s     31.16 c/B      1152
>        GCM enc |     20.70 ns/B     46.08 MiB/s     23.84 c/B      1152
>        GCM dec |     20.70 ns/B     46.07 MiB/s     23.85 c/B      1152
>       GCM auth |     0.877 ns/B      1087 MiB/s      1.01 c/B      1152
>        OCB enc |     27.32 ns/B     34.91 MiB/s     31.46 c/B      1152
>        OCB dec |     29.58 ns/B     32.24 MiB/s     34.08 c/B      1152
>       OCB auth |     27.27 ns/B     34.97 MiB/s     31.42 c/B      1152
>        SIV enc |     46.89 ns/B     20.34 MiB/s     54.00 c/B      1152
>        SIV dec |     46.97 ns/B     20.30 MiB/s     54.11 c/B      1152
>       SIV auth |     27.05 ns/B     35.25 MiB/s     31.16 c/B      1152
>    GCM-SIV enc |     32.09 ns/B     29.72 MiB/s     36.96 c/B      1152
>    GCM-SIV dec |     32.19 ns/B     29.63 MiB/s     37.08 c/B      1152
>   GCM-SIV auth |     0.976 ns/B     976.7 MiB/s      1.12 c/B      1152
>                =
> 
> 
> -Jussi

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

From rodolfosilva2 at tutanota.com  Tue Nov 18 21:17:52 2025
From: rodolfosilva2 at tutanota.com (rodolfosilva2 at tutanota.com)
Date: Tue, 18 Nov 2025 21:17:52 +0100 (CET)
Subject: Change OpenPGP Smartcard PIN retry counter
Message-ID: <OeNbS3H--F-9@tutanota.com>

Hello,

is it possible to adjust the OpenPGP Smartcard UserPIN Retry counter from 3 to lets say 5 ?
Sometimes 3 is very low, numlock is off and user enters 2 times wrong, only 1 time left until blocked.

Regards
-- 
 Secured with Tuta Mail: 
 https://tuta.com/free-email


From me at chandlerdavis.cc  Wed Nov 19 04:51:02 2025
From: me at chandlerdavis.cc (Chandler Davis)
Date: Wed, 19 Nov 2025 03:51:02 +0000
Subject: Change OpenPGP Smartcard PIN retry counter
In-Reply-To: <_anKDLfiXQTEDUhHpaxEWeePEmSTL-Nlkbw5W3GEiqMkxtn0PcwRY5MRGHPg9EgerJs-RwgzQVBH0-ej_TAeL7E8OW2Zh0-Y6L0SAdZ61aY=@chandlerdavis.cc>
References: <OeNbS3H--F-9@tutanota.com>
 <_anKDLfiXQTEDUhHpaxEWeePEmSTL-Nlkbw5W3GEiqMkxtn0PcwRY5MRGHPg9EgerJs-RwgzQVBH0-ej_TAeL7E8OW2Zh0-Y6L0SAdZ61aY=@chandlerdavis.cc>
Message-ID: <CLIruRj39jDatQGPnUCT1jB_0FEKHKYNpWqpbo21uWCjpeXt335-KAjWanAeQErWWRdeDTiPMyXue2JzUyaPNamEQgFVM8BLdH_xKCJqszw=@chandlerdavis.cc>

Apologies, I mistakenly replied directly to this and not to the list.


On Tuesday, November 18th, 2025 at 10:13 PM, Chandler Davis <me at chandlerdavis.cc> wrote:

> 

> 

> Hello!
> 

> On Tuesday, November 18th, 2025 at 4:39 PM, Rodolfo Silva via Gnupg-users gnupg-users at gnupg.org wrote:
> 

> > is it possible to adjust the OpenPGP Smartcard UserPIN Retry counter from 3 to lets say 5 ?
> 

> 

> I believe it depends on the smart card, some may be hard-coded. Yubikey supports changing it via the ykman tool. What smart card are you using?
> 

> Best,
> Chandler Davis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - me at chandlerdavis.cc - 0x806B3070.asc
Type: application/pgp-keys
Size: 1279 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251119/42faff86/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 343 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251119/42faff86/attachment.sig>

From rodolfosilva2 at tutanota.com  Wed Nov 19 05:08:40 2025
From: rodolfosilva2 at tutanota.com (rodolfosilva2 at tutanota.com)
Date: Wed, 19 Nov 2025 05:08:40 +0100 (CET)
Subject: Change OpenPGP Smartcard PIN retry counter
In-Reply-To: <CLIruRj39jDatQGPnUCT1jB_0FEKHKYNpWqpbo21uWCjpeXt335-KAjWanAeQErWWRdeDTiPMyXue2JzUyaPNamEQgFVM8BLdH_xKCJqszw=@chandlerdavis.cc>
References: <OeNbS3H--F-9@tutanota.com>
 <_anKDLfiXQTEDUhHpaxEWeePEmSTL-Nlkbw5W3GEiqMkxtn0PcwRY5MRGHPg9EgerJs-RwgzQVBH0-ej_TAeL7E8OW2Zh0-Y6L0SAdZ61aY=@chandlerdavis.cc>
 <CLIruRj39jDatQGPnUCT1jB_0FEKHKYNpWqpbo21uWCjpeXt335-KAjWanAeQErWWRdeDTiPMyXue2JzUyaPNamEQgFVM8BLdH_xKCJqszw=@chandlerdavis.cc>
Message-ID: <OePICnO--F-9@tutanota.com>

Is is a?ZeitControl V3.4 one?

-- 
 Secured with Tuta Mail: 
 https://tuta.com/free-email


Nov 19, 2025, 03:51 by me at chandlerdavis.cc:

> Apologies, I mistakenly replied directly to this and not to the list.
>
>
> On Tuesday, November 18th, 2025 at 10:13 PM, Chandler Davis <me at chandlerdavis.cc> wrote:
>
>>
>>
>>
>>
>> Hello!
>>
>> On Tuesday, November 18th, 2025 at 4:39 PM, Rodolfo Silva via Gnupg-users gnupg-users at gnupg.org wrote:
>>
>> > is it possible to adjust the OpenPGP Smartcard UserPIN Retry counter from 3 to lets say 5 ?
>>
>>
>>
>> I believe it depends on the smart card, some may be hard-coded. Yubikey supports changing it via the ykman tool. What smart card are you using?
>>
>> Best,
>> Chandler Davis
>>



From me at chandlerdavis.cc  Wed Nov 19 05:41:16 2025
From: me at chandlerdavis.cc (Chandler Davis)
Date: Wed, 19 Nov 2025 04:41:16 +0000
Subject: Change OpenPGP Smartcard PIN retry counter
In-Reply-To: <OePICnO--F-9@tutanota.com>
References: <OeNbS3H--F-9@tutanota.com>
 <_anKDLfiXQTEDUhHpaxEWeePEmSTL-Nlkbw5W3GEiqMkxtn0PcwRY5MRGHPg9EgerJs-RwgzQVBH0-ej_TAeL7E8OW2Zh0-Y6L0SAdZ61aY=@chandlerdavis.cc>
 <CLIruRj39jDatQGPnUCT1jB_0FEKHKYNpWqpbo21uWCjpeXt335-KAjWanAeQErWWRdeDTiPMyXue2JzUyaPNamEQgFVM8BLdH_xKCJqszw=@chandlerdavis.cc>
 <OePICnO--F-9@tutanota.com>
Message-ID: <9x6NqWYExMk5eu58Xoo6fezBMYu5CLu0IkIqUwtqv6-Tpgc4hJ2Psi9XyiT7GEIj3YM8-zAVz5o-CCSyZneRG-SzE1C61HrP6aZwniLXfYE=@chandlerdavis.cc>

> Is is a?ZeitControl V3.4 one?

I couldn?t find a direct answer, but I think the information needed to see if that card supports it is in section 4.4 of the v3.4 spec. 

Specifically, 4.4.3.7 shows where the card reports support for setting the retry count data object C4 via PUT DATA. You can get the extended capabilities flags from the D0 data object.

Best,
Chandler Davis





-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - me at chandlerdavis.cc - 0x806B3070.asc
Type: application/pgp-keys
Size: 1277 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251119/59263fb3/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 343 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251119/59263fb3/attachment.sig>

From rodolfosilva2 at tutanota.com  Wed Nov 19 07:22:20 2025
From: rodolfosilva2 at tutanota.com (rodolfosilva2 at tutanota.com)
Date: Wed, 19 Nov 2025 07:22:20 +0100 (CET)
Subject: Change OpenPGP Smartcard PIN retry counter
In-Reply-To: <9x6NqWYExMk5eu58Xoo6fezBMYu5CLu0IkIqUwtqv6-Tpgc4hJ2Psi9XyiT7GEIj3YM8-zAVz5o-CCSyZneRG-SzE1C61HrP6aZwniLXfYE=@chandlerdavis.cc>
References: <OeNbS3H--F-9@tutanota.com>
 <_anKDLfiXQTEDUhHpaxEWeePEmSTL-Nlkbw5W3GEiqMkxtn0PcwRY5MRGHPg9EgerJs-RwgzQVBH0-ej_TAeL7E8OW2Zh0-Y6L0SAdZ61aY=@chandlerdavis.cc>
 <CLIruRj39jDatQGPnUCT1jB_0FEKHKYNpWqpbo21uWCjpeXt335-KAjWanAeQErWWRdeDTiPMyXue2JzUyaPNamEQgFVM8BLdH_xKCJqszw=@chandlerdavis.cc>
 <OePICnO--F-9@tutanota.com>
 <9x6NqWYExMk5eu58Xoo6fezBMYu5CLu0IkIqUwtqv6-Tpgc4hJ2Psi9XyiT7GEIj3YM8-zAVz5o-CCSyZneRG-SzE1C61HrP6aZwniLXfYE=@chandlerdavis.cc>
Message-ID: <OePlnpf--J-9@tutanota.com>

Thank you.

Any idea on how i can submit these commands to the card?
-- 
 Secured with Tuta Mail: 
 https://tuta.com/free-email


Nov 19, 2025, 04:41 by me at chandlerdavis.cc:

>> Is is a?ZeitControl V3.4 one?
>>
>
> I couldn?t find a direct answer, but I think the information needed to see if that card supports it is in section 4.4 of the v3.4 spec. 
>
> Specifically, 4.4.3.7 shows where the card reports support for setting the retry count data object C4 via PUT DATA. You can get the extended capabilities flags from the D0 data object.
>
> Best,
> Chandler Davis
>
>
>
>
>



From wk at gnupg.org  Wed Nov 19 14:40:56 2025
From: wk at gnupg.org (Werner Koch)
Date: Wed, 19 Nov 2025 14:40:56 +0100
Subject: Change OpenPGP Smartcard PIN retry counter
In-Reply-To: <OePlnpf--J-9@tutanota.com> (Rodolfo Silva via Gnupg-users's
 message of "Wed, 19 Nov 2025 07:22:20 +0100 (CET)")
References: <OeNbS3H--F-9@tutanota.com>
 <_anKDLfiXQTEDUhHpaxEWeePEmSTL-Nlkbw5W3GEiqMkxtn0PcwRY5MRGHPg9EgerJs-RwgzQVBH0-ej_TAeL7E8OW2Zh0-Y6L0SAdZ61aY=@chandlerdavis.cc>
 <CLIruRj39jDatQGPnUCT1jB_0FEKHKYNpWqpbo21uWCjpeXt335-KAjWanAeQErWWRdeDTiPMyXue2JzUyaPNamEQgFVM8BLdH_xKCJqszw=@chandlerdavis.cc>
 <OePICnO--F-9@tutanota.com>
 <9x6NqWYExMk5eu58Xoo6fezBMYu5CLu0IkIqUwtqv6-Tpgc4hJ2Psi9XyiT7GEIj3YM8-zAVz5o-CCSyZneRG-SzE1C61HrP6aZwniLXfYE=@chandlerdavis.cc>
 <OePlnpf--J-9@tutanota.com>
Message-ID: <87346ata1j.fsf@jacob.g10code.de>

On Wed, 19 Nov 2025 07:22, Rodolfo Silva said:

> Any idea on how i can submit these commands to the card?

$ gpg-connect-agent 'scd apdu HEXHEXHEXHEX' /bye

you just need to compile an APDU for this.  Frankly, I forgot about this
feature and thus gpg-card has no command for it.


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/20251119/d7596146/attachment.sig>

From rodolfosilva2 at tutanota.com  Wed Nov 19 18:37:31 2025
From: rodolfosilva2 at tutanota.com (rodolfosilva2 at tutanota.com)
Date: Wed, 19 Nov 2025 18:37:31 +0100 (GMT+01:00)
Subject: Change OpenPGP Smartcard PIN retry counter
In-Reply-To: <87346ata1j.fsf@jacob.g10code.de>
References: <OeNbS3H--F-9@tutanota.com>
 <_anKDLfiXQTEDUhHpaxEWeePEmSTL-Nlkbw5W3GEiqMkxtn0PcwRY5MRGHPg9EgerJs-RwgzQVBH0-ej_TAeL7E8OW2Zh0-Y6L0SAdZ61aY=@chandlerdavis.cc>
 <CLIruRj39jDatQGPnUCT1jB_0FEKHKYNpWqpbo21uWCjpeXt335-KAjWanAeQErWWRdeDTiPMyXue2JzUyaPNamEQgFVM8BLdH_xKCJqszw=@chandlerdavis.cc>
 <OePICnO--F-9@tutanota.com>
 <9x6NqWYExMk5eu58Xoo6fezBMYu5CLu0IkIqUwtqv6-Tpgc4hJ2Psi9XyiT7GEIj3YM8-zAVz5o-CCSyZneRG-SzE1C61HrP6aZwniLXfYE=@chandlerdavis.cc>
 <OePlnpf--J-9@tutanota.com> <87346ata1j.fsf@jacob.g10code.de>
Message-ID: <OeSBL4p--F-9@tutanota.com>

Ok ill try it myself.

If anybody has more experience and can help me i appreciate it.
-- 
 Secured with Tuta Mail: 
 https://tuta.com/free-email


Nov 19, 2025, 13:38 by wk at gnupg.org:

> On Wed, 19 Nov 2025 07:22, Rodolfo Silva said:
>
>> Any idea on how i can submit these commands to the card?
>>
>
> $ gpg-connect-agent 'scd apdu HEXHEXHEXHEX' /bye
>
> you just need to compile an APDU for this.  Frankly, I forgot about this
> feature and thus gpg-card has no command for it.
>
>
> Salam-Shalom,
>
>  Werner
>
> -- 
> The pioneers of a warless world are the youth that
> refuse military service.             - A. Einstein
>



From borden_c at tutanota.com  Wed Nov 19 20:09:53 2025
From: borden_c at tutanota.com (Borden)
Date: Wed, 19 Nov 2025 20:09:53 +0100 (GMT+01:00)
Subject: Change OpenPGP Smartcard PIN retry counter
In-Reply-To: <OeSBL4p--F-9@tutanota.com>
References: <OeNbS3H--F-9@tutanota.com>
 <_anKDLfiXQTEDUhHpaxEWeePEmSTL-Nlkbw5W3GEiqMkxtn0PcwRY5MRGHPg9EgerJs-RwgzQVBH0-ej_TAeL7E8OW2Zh0-Y6L0SAdZ61aY=@chandlerdavis.cc>
 <CLIruRj39jDatQGPnUCT1jB_0FEKHKYNpWqpbo21uWCjpeXt335-KAjWanAeQErWWRdeDTiPMyXue2JzUyaPNamEQgFVM8BLdH_xKCJqszw=@chandlerdavis.cc>
 <OePICnO--F-9@tutanota.com>
 <9x6NqWYExMk5eu58Xoo6fezBMYu5CLu0IkIqUwtqv6-Tpgc4hJ2Psi9XyiT7GEIj3YM8-zAVz5o-CCSyZneRG-SzE1C61HrP6aZwniLXfYE=@chandlerdavis.cc>
 <OePlnpf--J-9@tutanota.com> <87346ata1j.fsf@jacob.g10code.de>
 <OeSBL4p--F-9@tutanota.com>
Message-ID: <OeSWUA_--F-9@tutanota.com>

Pardon my ignorance, but I thought GPG card hardware sets the PIN counter to lock or destroy the private key after failed attempts precisely to stop someone from trying to brute force the PIN?

Am I to understand that we cannot rely on a PIN counter?


From me at chandlerdavis.cc  Wed Nov 19 21:38:10 2025
From: me at chandlerdavis.cc (Chandler Davis)
Date: Wed, 19 Nov 2025 20:38:10 +0000
Subject: Change OpenPGP Smartcard PIN retry counter
In-Reply-To: <OeSWUA_--F-9@tutanota.com>
References: <OeNbS3H--F-9@tutanota.com>
 <_anKDLfiXQTEDUhHpaxEWeePEmSTL-Nlkbw5W3GEiqMkxtn0PcwRY5MRGHPg9EgerJs-RwgzQVBH0-ej_TAeL7E8OW2Zh0-Y6L0SAdZ61aY=@chandlerdavis.cc>
 <CLIruRj39jDatQGPnUCT1jB_0FEKHKYNpWqpbo21uWCjpeXt335-KAjWanAeQErWWRdeDTiPMyXue2JzUyaPNamEQgFVM8BLdH_xKCJqszw=@chandlerdavis.cc>
 <OePICnO--F-9@tutanota.com>
 <9x6NqWYExMk5eu58Xoo6fezBMYu5CLu0IkIqUwtqv6-Tpgc4hJ2Psi9XyiT7GEIj3YM8-zAVz5o-CCSyZneRG-SzE1C61HrP6aZwniLXfYE=@chandlerdavis.cc>
 <OePlnpf--J-9@tutanota.com> <87346ata1j.fsf@jacob.g10code.de>
 <OeSBL4p--F-9@tutanota.com> <OeSWUA_--F-9@tutanota.com>
Message-ID: <g5le2EPOKQE7-VoIqKviehNc9HEguveSAGJleNkSUkFpI_BoAz4UluKsacPuUmE-RVc3sKCmmqCx8yUqDvdUZVZXMTL20L6d1heF2F05bBQ=@chandlerdavis.cc>


On Wednesday, November 19th, 2025 at 3:07 PM, Borden via Gnupg-users <gnupg-users at gnupg.org> wrote:

> Pardon my ignorance, but I thought GPG card hardware sets the PIN counter to lock or destroy the private key after failed attempts precisely to stop someone from trying to brute force the PIN?

Yes, that's correct. If the retry counter is maxed out, it will be locked and you'll have to use the unblocking pin (PWD.2 I think) to reset the counter and make it usable again.

If you don't know the unblocking pin, the only choice is to reset the card and put new keys on it. You *may* be able to do something with the admin PIN as well, but I don't remember off the top of my head.

> Am I to understand that we cannot rely on a PIN counter?

What we're discussing here is how to increase the number of PIN retries that are allowed before that locking happens. The counter still protects from brute forcing.

The default is 3 attempts, but I think 5 is still reasonable and a bit "safer" in terms of not accidentally locking yourself out.

--
Best,
Chandler Davis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - me at chandlerdavis.cc - 0x806B3070.asc
Type: application/pgp-keys
Size: 1279 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251119/fab8be80/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 343 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251119/fab8be80/attachment-0001.sig>

From borden_c at tutanota.com  Wed Nov 19 22:04:47 2025
From: borden_c at tutanota.com (Borden)
Date: Wed, 19 Nov 2025 22:04:47 +0100 (GMT+01:00)
Subject: Change OpenPGP Smartcard PIN retry counter
In-Reply-To: <g5le2EPOKQE7-VoIqKviehNc9HEguveSAGJleNkSUkFpI_BoAz4UluKsacPuUmE-RVc3sKCmmqCx8yUqDvdUZVZXMTL20L6d1heF2F05bBQ=@chandlerdavis.cc>
References: <OeNbS3H--F-9@tutanota.com>
 <_anKDLfiXQTEDUhHpaxEWeePEmSTL-Nlkbw5W3GEiqMkxtn0PcwRY5MRGHPg9EgerJs-RwgzQVBH0-ej_TAeL7E8OW2Zh0-Y6L0SAdZ61aY=@chandlerdavis.cc>
 <CLIruRj39jDatQGPnUCT1jB_0FEKHKYNpWqpbo21uWCjpeXt335-KAjWanAeQErWWRdeDTiPMyXue2JzUyaPNamEQgFVM8BLdH_xKCJqszw=@chandlerdavis.cc>
 <OePICnO--F-9@tutanota.com>
 <9x6NqWYExMk5eu58Xoo6fezBMYu5CLu0IkIqUwtqv6-Tpgc4hJ2Psi9XyiT7GEIj3YM8-zAVz5o-CCSyZneRG-SzE1C61HrP6aZwniLXfYE=@chandlerdavis.cc>
 <OePlnpf--J-9@tutanota.com> <87346ata1j.fsf@jacob.g10code.de>
 <OeSBL4p--F-9@tutanota.com> <OeSWUA_--F-9@tutanota.com>
 <g5le2EPOKQE7-VoIqKviehNc9HEguveSAGJleNkSUkFpI_BoAz4UluKsacPuUmE-RVc3sKCmmqCx8yUqDvdUZVZXMTL20L6d1heF2F05bBQ=@chandlerdavis.cc>
Message-ID: <OeSvmGh--F-9@tutanota.com>

Thank you for the response. I'm still a bit confused.

> What we're discussing here is how to increase the number of PIN retries that are allowed before that locking happens. The counter still protects from brute forcing.
>
> The default is 3 attempts, but I think 5 is still reasonable and a bit "safer" in terms of not accidentally locking yourself out.
>
What's the control on this to stop a bad actor from stealing an OpenPGP card and setting the reset count to 99999? I know you alluded to hardware implementation, but does the spec require the level 2 password to change this, if it can?


From me at chandlerdavis.cc  Wed Nov 19 22:43:11 2025
From: me at chandlerdavis.cc (Chandler Davis)
Date: Wed, 19 Nov 2025 21:43:11 +0000
Subject: Change OpenPGP Smartcard PIN retry counter
In-Reply-To: <OeSvmGh--F-9@tutanota.com>
References: <OeNbS3H--F-9@tutanota.com> <OePICnO--F-9@tutanota.com>
 <9x6NqWYExMk5eu58Xoo6fezBMYu5CLu0IkIqUwtqv6-Tpgc4hJ2Psi9XyiT7GEIj3YM8-zAVz5o-CCSyZneRG-SzE1C61HrP6aZwniLXfYE=@chandlerdavis.cc>
 <OePlnpf--J-9@tutanota.com> <87346ata1j.fsf@jacob.g10code.de>
 <OeSBL4p--F-9@tutanota.com> <OeSWUA_--F-9@tutanota.com>
 <g5le2EPOKQE7-VoIqKviehNc9HEguveSAGJleNkSUkFpI_BoAz4UluKsacPuUmE-RVc3sKCmmqCx8yUqDvdUZVZXMTL20L6d1heF2F05bBQ=@chandlerdavis.cc>
 <OeSvmGh--F-9@tutanota.com>
Message-ID: <a0c2f006-c45b-429f-bc45-b724a182e23d@chandlerdavis.cc>


On 11/19/25 4:04 PM, Borden via Gnupg-users wrote:

> What's the control on this to stop a bad actor from stealing an > OpenPGP card and setting the reset count to 99999? I know you > 
alluded to hardware implementation, but does the spec require the > 
level 2 password to change this, if it can?

Ah yes, sorry I forgot to mention it requires the Admin PIN a.k.a. PW3 
to change the max attempts.

Just to get my terminology straight:

PW1 (User PIN) - Used for signing and decryption operations

RC (Reset Code) - Only valid for resetting PW1 after reaching max 
attempts. PW3 can be used for this as well.

PW3 (Admin PIN) - Used for sensitive admin operations, such as changing 
the max attempts for PW1 (if supported).

I pulled most of this from section 4.3 of the specification available 
here: https://gnupg.org/ftp/specs/OpenPGP-smart-card-application-3.4.1.pdf

Hope that helps!

-- 
Best,
Chandler Davis

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x00F83CBBF56EBE81.asc
Type: application/pgp-keys
Size: 1774 bytes
Desc: OpenPGP public key
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251119/95f0e4c9/attachment.key>
-------------- 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/20251119/95f0e4c9/attachment.sig>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - Chandler Davis - 0x806B3070.asc
Type: application/pgp-keys
Size: 1331 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251119/95f0e4c9/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 322 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251119/95f0e4c9/attachment-0001.sig>

From andrewg at andrewg.com  Wed Nov 19 22:43:15 2025
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 19 Nov 2025 21:43:15 +0000
Subject: Change OpenPGP Smartcard PIN retry counter
In-Reply-To: <OeSvmGh--F-9@tutanota.com>
References: <OeSvmGh--F-9@tutanota.com>
Message-ID: <563F9344-8E60-4A6D-A133-58F8A26FF0ED@andrewg.com>

On 19 Nov 2025, at 21:05, Borden via Gnupg-users <gnupg-users at gnupg.org> wrote:
> 
> What's the control on this to stop a bad actor from stealing an OpenPGP card and setting the reset count to 99999? I know you alluded to hardware implementation, but does the spec require the level 2 password to change this, if it can?

You need the admin PIN to change settings on zeitcontrol cards. The admin PIN retry count is hardcoded to 10 and can?t be increased. 

A



From simon at josefsson.org  Wed Nov 19 21:48:44 2025
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 19 Nov 2025 21:48:44 +0100
Subject: Change OpenPGP Smartcard PIN retry counter
In-Reply-To: <OeSBL4p--F-9@tutanota.com> (Rodolfo Silva via Gnupg-users's
 message of "Wed, 19 Nov 2025 18:37:31 +0100 (GMT+01:00)")
References: <OeNbS3H--F-9@tutanota.com>
 <_anKDLfiXQTEDUhHpaxEWeePEmSTL-Nlkbw5W3GEiqMkxtn0PcwRY5MRGHPg9EgerJs-RwgzQVBH0-ej_TAeL7E8OW2Zh0-Y6L0SAdZ61aY=@chandlerdavis.cc>
 <CLIruRj39jDatQGPnUCT1jB_0FEKHKYNpWqpbo21uWCjpeXt335-KAjWanAeQErWWRdeDTiPMyXue2JzUyaPNamEQgFVM8BLdH_xKCJqszw=@chandlerdavis.cc>
 <OePICnO--F-9@tutanota.com>
 <9x6NqWYExMk5eu58Xoo6fezBMYu5CLu0IkIqUwtqv6-Tpgc4hJ2Psi9XyiT7GEIj3YM8-zAVz5o-CCSyZneRG-SzE1C61HrP6aZwniLXfYE=@chandlerdavis.cc>
 <OePlnpf--J-9@tutanota.com> <87346ata1j.fsf@jacob.g10code.de>
 <OeSBL4p--F-9@tutanota.com>
Message-ID: <874iqpvjdf.fsf@josefsson.org>

Rodolfo Silva via Gnupg-users <gnupg-users at gnupg.org> writes:

> Ok ill try it myself.
>
> If anybody has more experience and can help me i appreciate it.

This may give you some inspiration:

https://github.com/Yubico/ykneo-openpgp/blob/master/doc/PinRetries.txt

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1251 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251119/5763d111/attachment.sig>

From wk at gnupg.org  Thu Nov 20 11:47:07 2025
From: wk at gnupg.org (Werner Koch)
Date: Thu, 20 Nov 2025 11:47:07 +0100
Subject: Change OpenPGP Smartcard PIN retry counter
In-Reply-To: <563F9344-8E60-4A6D-A133-58F8A26FF0ED@andrewg.com> (Andrew
 Gallagher via Gnupg-users's message of "Wed, 19 Nov 2025 21:43:15
 +0000")
References: <OeSvmGh--F-9@tutanota.com>
 <563F9344-8E60-4A6D-A133-58F8A26FF0ED@andrewg.com>
Message-ID: <87bjkxrnf8.fsf@jacob.g10code.de>

On Wed, 19 Nov 2025 21:43, Andrew Gallagher said:

> You need the admin PIN to change settings on zeitcontrol cards. The
> admin PIN retry count is hardcoded to 10 and can?t be increased.

Nope, the Admin PIN on our Zeitcontrol cards is also set to 3.  check
with gpg-card.


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/20251120/cb8a7427/attachment.sig>

From rodolfosilva2 at tutanota.com  Sat Nov 22 03:12:35 2025
From: rodolfosilva2 at tutanota.com (rodolfosilva2 at tutanota.com)
Date: Sat, 22 Nov 2025 03:12:35 +0100 (CET)
Subject: Change OpenPGP Smartcard PIN retry counter
In-Reply-To: <87bjkxrnf8.fsf@jacob.g10code.de>
References: <OePICnO--F-9@tutanota.com>
 <9x6NqWYExMk5eu58Xoo6fezBMYu5CLu0IkIqUwtqv6-Tpgc4hJ2Psi9XyiT7GEIj3YM8-zAVz5o-CCSyZneRG-SzE1C61HrP6aZwniLXfYE=@chandlerdavis.cc>
 <OePlnpf--J-9@tutanota.com> <87346ata1j.fsf@jacob.g10code.de>
 <OeSBL4p--F-9@tutanota.com> <OeSWUA_--F-9@tutanota.com>
 <g5le2EPOKQE7-VoIqKviehNc9HEguveSAGJleNkSUkFpI_BoAz4UluKsacPuUmE-RVc3sKCmmqCx8yUqDvdUZVZXMTL20L6d1heF2F05bBQ=@chandlerdavis.cc>
 <OeSvmGh--F-9@tutanota.com>
 <563F9344-8E60-4A6D-A133-58F8A26FF0ED@andrewg.com>
 <87bjkxrnf8.fsf@jacob.g10code.de>
Message-ID: <OedKPhU--F-9@tutanota.com>

Where can i file a feature Request/ Bug Report for implementing change functionality into gpg ?

--
Secured with Tuta Mail:
https://tuta.com/free-email


-- 
 Secured with Tuta Mail: 
 https://tuta.com/free-email


Nov 20, 2025, 11:06 by gnupg-users at gnupg.org:

> On Wed, 19 Nov 2025 21:43, Andrew Gallagher said:
>
>> You need the admin PIN to change settings on zeitcontrol cards. The
>> admin PIN retry count is hardcoded to 10 and can?t be increased.
>>
>
> Nope, the Admin PIN on our Zeitcontrol cards is also set to 3.  check
> with gpg-card.
>
>
> Salam-Shalom,
>
>  Werner
>
> -- 
> The pioneers of a warless world are the youth that
> refuse military service.             - A. Einstein
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users
>



From wk at gnupg.org  Sat Nov 22 11:40:14 2025
From: wk at gnupg.org (Werner Koch)
Date: Sat, 22 Nov 2025 11:40:14 +0100
Subject: Change OpenPGP Smartcard PIN retry counter
In-Reply-To: <OedKPhU--F-9@tutanota.com> (Rodolfo Silva via Gnupg-users's
 message of "Sat, 22 Nov 2025 03:12:35 +0100 (CET)")
References: <OePICnO--F-9@tutanota.com>
 <9x6NqWYExMk5eu58Xoo6fezBMYu5CLu0IkIqUwtqv6-Tpgc4hJ2Psi9XyiT7GEIj3YM8-zAVz5o-CCSyZneRG-SzE1C61HrP6aZwniLXfYE=@chandlerdavis.cc>
 <OePlnpf--J-9@tutanota.com> <87346ata1j.fsf@jacob.g10code.de>
 <OeSBL4p--F-9@tutanota.com> <OeSWUA_--F-9@tutanota.com>
 <g5le2EPOKQE7-VoIqKviehNc9HEguveSAGJleNkSUkFpI_BoAz4UluKsacPuUmE-RVc3sKCmmqCx8yUqDvdUZVZXMTL20L6d1heF2F05bBQ=@chandlerdavis.cc>
 <OeSvmGh--F-9@tutanota.com>
 <563F9344-8E60-4A6D-A133-58F8A26FF0ED@andrewg.com>
 <87bjkxrnf8.fsf@jacob.g10code.de> <OedKPhU--F-9@tutanota.com>
Message-ID: <87ldjyqrjl.fsf@jacob.g10code.de>

On Sat, 22 Nov 2025 03:12, Rodolfo Silva said:
> Where can i file a feature Request/ Bug Report for implementing change
> functionality into gpg ?

I did it for you:

https://dev.gnupg.org/T7947

If you need an account there, let me know.  Note that the tracker is
often under siege by AI scrapers.


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/20251122/ad32f635/attachment-0001.sig>

From rodolfosilva2 at tutanota.com  Sun Nov 23 01:46:05 2025
From: rodolfosilva2 at tutanota.com (rodolfosilva2 at tutanota.com)
Date: Sun, 23 Nov 2025 01:46:05 +0100 (CET)
Subject: Change OpenPGP Smartcard PIN retry counter
In-Reply-To: <87ldjyqrjl.fsf@jacob.g10code.de>
References: <OePlnpf--J-9@tutanota.com> <87346ata1j.fsf@jacob.g10code.de>
 <OeSBL4p--F-9@tutanota.com> <OeSWUA_--F-9@tutanota.com>
 <g5le2EPOKQE7-VoIqKviehNc9HEguveSAGJleNkSUkFpI_BoAz4UluKsacPuUmE-RVc3sKCmmqCx8yUqDvdUZVZXMTL20L6d1heF2F05bBQ=@chandlerdavis.cc>
 <OeSvmGh--F-9@tutanota.com>
 <563F9344-8E60-4A6D-A133-58F8A26FF0ED@andrewg.com>
 <87bjkxrnf8.fsf@jacob.g10code.de> <OedKPhU--F-9@tutanota.com>
 <87ldjyqrjl.fsf@jacob.g10code.de>
Message-ID: <OeiAC8c--J-9@tutanota.com>


According to OpenPGP Card Spec 3.4.1?https://www.gnupg.org/ftp/specs/OpenPGP-smart-card-application-3.4.1.pdf


We cannot set retry counters( C4 DO ) via PUT DATA (page 28 of the spec)
I tried to construct a 07 byte DO via put data?

gpg-connect-agent --hex "scd apdu 00 DA 00 C4 07 00404040100303" /bye

but i receive a status code of 6700 (wrong length), which aligns with the spec.Can someone please check how i can update the retry counter?
-- 
 Secured with Tuta Mail: 
 https://tuta.com/free-email


Nov 22, 2025, 10:46 by wk at gnupg.org:

> On Sat, 22 Nov 2025 03:12, Rodolfo Silva said:
>
>> Where can i file a feature Request/ Bug Report for implementing change
>> functionality into gpg ?
>>
>
> I did it for you:
>
> https://dev.gnupg.org/T7947
>
> If you need an account there, let me know.  Note that the tracker is
> often under siege by AI scrapers.
>
>
> Shalom-Salam,
>
>  Werner
>
> -- 
> The pioneers of a warless world are the youth that
> refuse military service.             - A. Einstein
>



From wk at gnupg.org  Mon Nov 24 16:52:29 2025
From: wk at gnupg.org (Werner Koch)
Date: Mon, 24 Nov 2025 16:52:29 +0100
Subject: Change OpenPGP Smartcard PIN retry counter
In-Reply-To: <OeiAC8c--J-9@tutanota.com> (Rodolfo Silva via Gnupg-users's
 message of "Sun, 23 Nov 2025 01:46:05 +0100 (CET)")
References: <OePlnpf--J-9@tutanota.com> <87346ata1j.fsf@jacob.g10code.de>
 <OeSBL4p--F-9@tutanota.com> <OeSWUA_--F-9@tutanota.com>
 <g5le2EPOKQE7-VoIqKviehNc9HEguveSAGJleNkSUkFpI_BoAz4UluKsacPuUmE-RVc3sKCmmqCx8yUqDvdUZVZXMTL20L6d1heF2F05bBQ=@chandlerdavis.cc>
 <OeSvmGh--F-9@tutanota.com>
 <563F9344-8E60-4A6D-A133-58F8A26FF0ED@andrewg.com>
 <87bjkxrnf8.fsf@jacob.g10code.de> <OedKPhU--F-9@tutanota.com>
 <87ldjyqrjl.fsf@jacob.g10code.de> <OeiAC8c--J-9@tutanota.com>
Message-ID: <87see3pgw2.fsf@jacob.g10code.de>

On Sun, 23 Nov 2025 01:46, Rodolfo Silva said:

> gpg-connect-agent --hex "scd apdu 00 DA 00 C4 07 00404040100303" /bye

Let's see using a Gnuk token:

  $ gpg-connect-agent
  > /hex
  > scd apdu  00ca00c400factory r
  D[0000]  01 7F 7F 7F 03 03 03 90  00     

This returns: 01 = PW1 valid for several commands
              7F = UTF PW1 with a max length of 127
              7F = Reset Code with a max length of 127
              7F = UTF PW3 with a max length of 127
              03 - Current error counter for PW1
              03 - Current error counter for the Reset Code
              03 - Current error counter for PW3
           90 00 - Success

You sent:     00 = PW1 valid for one command
              40 = UTF PW1 with a max length of 64
              40 = Reset Code with a max length of 64
              40 = UTF PW3 with a max length of 64
              10 = Not specified in 3.4.1 (4.4.2 DOs for PUT DATA)
              03 = Not specified in 3.4.1
              03 = Not specified in 3.4.1

Thus there is no way in the OpenPGP specs to change the max. retry.  For
Yubikeys you may use a proprietary APDU, though.  Simon already
mentioned this.  Let's do this using the gpg-card command:

  $ gpg-card
  Reader ...........: 1050:0407:X:0
  Card type ........: yubikey
  Card firmware ....: 5.4.3
  Serial number ....: D2760001240100000006154932830000
  Application type .: OpenPGP
  Version ..........: 3.4
  # [...]
  Max. PIN lengths .: 127 127 127
  PIN retry counter : 3 0 3
  Signature counter : 0
  Capabilities .....: key-import algo-change button priv-data
  # [...]
  
  gpg/card> verify D2760001240100000006154932830000[CHV3]
  # shows listing again
  
  gpg/card> apdu 00 f2 00 00 03 05 00 07
  Statusword: 0x9000 (success)

  gpg/card> l
  # shows listing again

  gpg/card> reset 
  gpg/card> l
  # [...]
  Max. PIN lengths .: 127 127 127
  PIN retry counter : 5 0 7
  Signature counter : 0

Et voila, PIN retry counter set to 5 and Admin retry counter set to 7.
The important thing here is that you use the s/n with "[CHV3] appended
as argument to the verify command.  This will only work if the retry
counter is above 2.


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/20251124/91081af5/attachment.sig>

From rodolfosilva2 at tutanota.com  Mon Nov 24 22:38:43 2025
From: rodolfosilva2 at tutanota.com (rodolfosilva2 at tutanota.com)
Date: Mon, 24 Nov 2025 22:38:43 +0100 (CET)
Subject: Change OpenPGP Smartcard PIN retry counter
In-Reply-To: <87see3pgw2.fsf@jacob.g10code.de>
References: <OeSBL4p--F-9@tutanota.com> <OeSWUA_--F-9@tutanota.com>
 <g5le2EPOKQE7-VoIqKviehNc9HEguveSAGJleNkSUkFpI_BoAz4UluKsacPuUmE-RVc3sKCmmqCx8yUqDvdUZVZXMTL20L6d1heF2F05bBQ=@chandlerdavis.cc>
 <OeSvmGh--F-9@tutanota.com>
 <563F9344-8E60-4A6D-A133-58F8A26FF0ED@andrewg.com>
 <87bjkxrnf8.fsf@jacob.g10code.de> <OedKPhU--F-9@tutanota.com>
 <87ldjyqrjl.fsf@jacob.g10code.de> <OeiAC8c--J-9@tutanota.com>
 <87see3pgw2.fsf@jacob.g10code.de>
Message-ID: <OernVD_--F-9@tutanota.com>

In this case the OpenPGP Card Firmware needs to be extended.
Is there a dedicated BugTracker for OpenPGP Card?
-- 
 Secured with Tuta Mail: 
 https://tuta.com/free-email


Nov 24, 2025, 15:50 by wk at gnupg.org:

> On Sun, 23 Nov 2025 01:46, Rodolfo Silva said:
>
>> gpg-connect-agent --hex "scd apdu 00 DA 00 C4 07 00404040100303" /bye
>>
>
> Let's see using a Gnuk token:
>
>  $ gpg-connect-agent
>  > /hex
>  > scd apdu  00ca00c400factory r
>  D[0000]  01 7F 7F 7F 03 03 03 90  00 
>
> This returns: 01 = PW1 valid for several commands
>  7F = UTF PW1 with a max length of 127
>  7F = Reset Code with a max length of 127
>  7F = UTF PW3 with a max length of 127
>  03 - Current error counter for PW1
>  03 - Current error counter for the Reset Code
>  03 - Current error counter for PW3
>  90 00 - Success
>
> You sent:     00 = PW1 valid for one command
>  40 = UTF PW1 with a max length of 64
>  40 = Reset Code with a max length of 64
>  40 = UTF PW3 with a max length of 64
>  10 = Not specified in 3.4.1 (4.4.2 DOs for PUT DATA)
>  03 = Not specified in 3.4.1
>  03 = Not specified in 3.4.1
>
> Thus there is no way in the OpenPGP specs to change the max. retry.  For
> Yubikeys you may use a proprietary APDU, though.  Simon already
> mentioned this.  Let's do this using the gpg-card command:
>
>  $ gpg-card
>  Reader ...........: 1050:0407:X:0
>  Card type ........: yubikey
>  Card firmware ....: 5.4.3
>  Serial number ....: D2760001240100000006154932830000
>  Application type .: OpenPGP
>  Version ..........: 3.4
>  # [...]
>  Max. PIN lengths .: 127 127 127
>  PIN retry counter : 3 0 3
>  Signature counter : 0
>  Capabilities .....: key-import algo-change button priv-data
>  # [...]
>  
>  gpg/card> verify D2760001240100000006154932830000[CHV3]
>  # shows listing again
>  
>  gpg/card> apdu 00 f2 00 00 03 05 00 07
>  Statusword: 0x9000 (success)
>
>  gpg/card> l
>  # shows listing again
>
>  gpg/card> reset 
>  gpg/card> l
>  # [...]
>  Max. PIN lengths .: 127 127 127
>  PIN retry counter : 5 0 7
>  Signature counter : 0
>
> Et voila, PIN retry counter set to 5 and Admin retry counter set to 7.
> The important thing here is that you use the s/n with "[CHV3] appended
> as argument to the verify command.  This will only work if the retry
> counter is above 2.
>
>
> Salam-Shalom,
>
>  Werner
>
> -- 
> The pioneers of a warless world are the youth that
> refuse military service.             - A. Einstein
>



From borden_c at tutanota.com  Tue Nov 25 01:04:06 2025
From: borden_c at tutanota.com (Borden)
Date: Tue, 25 Nov 2025 01:04:06 +0100 (CET)
Subject: gpgsm documentation (2nd attempt)
Message-ID: <OesJlre--F-9@tutanota.com>

Is gpgsm supposed to be openssl compatible? I spent a week trying to create SSL certificates from GPG keys, and neither program would read the other's output.

The gpg/sm documentation, as I previously reported, is pretty newcomer unfriendly. I wonder whether I misunderstood the gpgsm premise, as other sources say that gpg and openssl are not meant to interoperate at all because they have entirely different purposes.

I wanted to see if I could figure out the intended usage from the C source, but it's too impenetrable for me.

I reiterate my offer to assist with the documentation if I can get support in understanding the software.


From wk at gnupg.org  Tue Nov 25 11:18:10 2025
From: wk at gnupg.org (Werner Koch)
Date: Tue, 25 Nov 2025 11:18:10 +0100
Subject: gpgsm documentation (2nd attempt)
In-Reply-To: <OesJlre--F-9@tutanota.com> (Borden via Gnupg-users's message of
 "Tue, 25 Nov 2025 01:04:06 +0100 (CET)")
References: <OesJlre--F-9@tutanota.com>
Message-ID: <87o6oqpg9p.fsf@jacob.g10code.de>

On Tue, 25 Nov 2025 01:04, Borden said:
> Is gpgsm supposed to be openssl compatible? I spent a week trying to

gpgsm is an application implementing X.509 key management and CMS
encryption, decryption, signing, and verification.  openssl ist mostly a
library with a couple of tools tomake use of the core functions.

Here is an example on how to create a self-signed certificate from an
already existing (OpenPGP) key:

List the OpenPGP key 

  $ gpg -k --with-keygrip biko
  pub   rsa2048 2016-06-22 [SC]
        5B83120DB1E3A65AE5A8DCF6AA43F1DCC7FED1B7
        Keygrip = C6A6390E9388CDBAD71EAEA698233FE5E04F001E
  uid           [ unknown] steve.biko at example.net
  sub   rsa2048 2016-06-22 [E]
        4CB4D8C018C57E60EB3847901D777619BE310D79
        Keygrip = D69102E0F5AC6B6DB8E4D16DA8E18CF46D88CAE3

Generate a self-signed certificate (or a CSR):

  $ gpgsm --gen-key
  Please select what kind of key you want:
     (1) RSA
     (2) Existing key
     (3) Existing key from card
  Your selection? 2
  Enter the keygrip: C6A6390E9388CDBAD71EAEA698233FE5E04F001E
  Possible actions for a RSA key:
     (1) sign, encrypt
     (2) sign
     (3) encrypt
  Your selection? 1
  Enter the X.509 subject name: CN=Steven Biko
  Enter email addresses (end with an empty line):
  > biko at example.org
  > 
  Enter DNS names (optional; end with an empty line):
  > 
  Enter URIs (optional; end with an empty line):
  > 
  Enter extensions (optional; end with an empty line):
  > 
  Create self-signed certificate? (y/N) y
  These parameters are used:
      Key-Type: RSA
      Key-Length: 1024
      Key-Grip: C6A6390E9388CDBAD71EAEA698233FE5E04F001E
      Key-Usage: sign, encrypt
      Serial: random
      Name-DN: CN=Steven Biko
      Name-Email: biko at example.org
  
  Proceed with creation? (y/N) y
  Now creating self-signed certificate.  This may take a while ...
  gpgsm: about to sign the certificate for key: &C6A6390E9388CDBAD71EAEA698233FE5E04F001E
  gpgsm: certificate created
  Ready.
  -----BEGIN CERTIFICATE-----
  MIIDAzCCAeugAwIBAgIIL0uIYT/abSkwDQYJKoZIhvcNAQELBQAwFjEUMBIGA1UE
  AxMLU3RldmVuIEJpa28wIBcNMjUxMTI1MDk1MjQzWhgPMjA2MzA0MDUxNzAwMDBa
  [...]

You can also use a CA certificate to sign the new certificate instead of
creating a self-signed one.  Here are some notes on how we create
intenal certificates:

1. Create or copy a config file with the name DOMAIN.param.

2. Change the items "Name-DN" und "Name-DNS" accordingly.

3. Create a keypair
    gpgsm --batch --gen-key DOAMIN.param > DOMAIN.crt

4. Import keypair:
    gpgsm --import DOMAIN.crt

5. Export certificate:
    gpgsm -a --export DOMAIN  > DOMAIN.pem

6. Export private key:
    gpgsm -a --export-secret-key-raw DOMAIN > DOMAIN.key

7. Optionally export certificate and private key:
    gpgsm -a --export-secret-key-p12 DOMAIN > DOMAIN.p12

Take care: The private key and the certificate are still stored in the
local GnuPG installation.

Here is a sample DOMAIN.parm file:

--8<---------------cut here---------------start------------->8---
Key-Type: RSA
Key-Length: 2048
Key-Usage: sign, encrypt
Name-DN: CN=wiki,O=example,C=de
Name-DNS: wiki.example.de
Serial: random
Issuer-DN: CN=My Root-CA 2025,O=Example GmbH,C=DE
Signing-Key: 184977136DA4D5C90C202F22E3812012ABCD7174
--8<---------------cut here---------------end--------------->8---

The signing key is the keygrip of the CA certificate.  We are using a
smartcard here of course.  For mail certificates you need to use other
parameters; see the GnuPG manula (PDF or Info), section 5.5.2.


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/20251125/d8e1419d/attachment.sig>

From wk at gnupg.org  Tue Nov 25 11:22:57 2025
From: wk at gnupg.org (Werner Koch)
Date: Tue, 25 Nov 2025 11:22:57 +0100
Subject: Change OpenPGP Smartcard PIN retry counter
In-Reply-To: <OernVD_--F-9@tutanota.com> (Rodolfo Silva via Gnupg-users's
 message of "Mon, 24 Nov 2025 22:38:43 +0100 (CET)")
References: <OeSBL4p--F-9@tutanota.com> <OeSWUA_--F-9@tutanota.com>
 <g5le2EPOKQE7-VoIqKviehNc9HEguveSAGJleNkSUkFpI_BoAz4UluKsacPuUmE-RVc3sKCmmqCx8yUqDvdUZVZXMTL20L6d1heF2F05bBQ=@chandlerdavis.cc>
 <OeSvmGh--F-9@tutanota.com>
 <563F9344-8E60-4A6D-A133-58F8A26FF0ED@andrewg.com>
 <87bjkxrnf8.fsf@jacob.g10code.de> <OedKPhU--F-9@tutanota.com>
 <87ldjyqrjl.fsf@jacob.g10code.de> <OeiAC8c--J-9@tutanota.com>
 <87see3pgw2.fsf@jacob.g10code.de> <OernVD_--F-9@tutanota.com>
Message-ID: <87jyzepg1q.fsf@jacob.g10code.de>

On Mon, 24 Nov 2025 22:38, Rodolfo Silva said:
> In this case the OpenPGP Card Firmware needs to be extended.
> Is there a dedicated BugTracker for OpenPGP Card?

No.  But I will CC the author of the specs.

I would anyway suggest to use a Yubikey if you have such special
requirements.  In the ~20 years we have not seen a demand for other
retry counter values.  For my experience it does not help if you have
more tries.  Write the PIN down somewhere and store it far away from the
card.


Salam-Shalom,

   Werner


ps:
@achim: This is about a Yubikey feature which allows to set different
max retry counters using a proprietrary APDU with INS F2.

-- 
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/20251125/149fee2d/attachment.sig>

From borden_c at tutanota.com  Tue Nov 25 21:26:51 2025
From: borden_c at tutanota.com (Borden)
Date: Tue, 25 Nov 2025 21:26:51 +0100 (CET)
Subject: gpgsm documentation (2nd attempt)
In-Reply-To: <87o6oqpg9p.fsf@jacob.g10code.de>
References: <OesJlre--F-9@tutanota.com> <87o6oqpg9p.fsf@jacob.g10code.de>
Message-ID: <OewfdcK--F-9@tutanota.com>

Thank you, Werner, for the detailed response.
My query may have been unclear in that I couldn't get openssl or its relying software to understand gpgsm secret keys.

Your instructions are similar to what I found in the documentation. Where I ran into trouble was that openssl could not read the secret key output. Perhaps it's because I was exporting in PKCS#12 and not PKCS#8 (although openssl says that it can read p12 files just fine). Consequently, software expecting openssl certificates also wouldn't read the gpgsm generated certs or keys.


From wk at gnupg.org  Wed Nov 26 11:03:21 2025
From: wk at gnupg.org (Werner Koch)
Date: Wed, 26 Nov 2025 11:03:21 +0100
Subject: gpgsm documentation (2nd attempt)
In-Reply-To: <OewfdcK--F-9@tutanota.com> (Borden via Gnupg-users's message of
 "Tue, 25 Nov 2025 21:26:51 +0100 (CET)")
References: <OesJlre--F-9@tutanota.com> <87o6oqpg9p.fsf@jacob.g10code.de>
 <OewfdcK--F-9@tutanota.com>
Message-ID: <87bjkpp0uu.fsf@jacob.g10code.de>

On Tue, 25 Nov 2025 21:26, Borden said:
> My query may have been unclear in that I couldn't get openssl or its
> relying software to understand gpgsm secret keys.

I guess the problem you encounter could be that OpenSSL and GnuPG have
different formats on how to encode the CRT, which is used to speed up
RSA computation.  However, when exporting in pkcs#12 or pcks#8 format,
gpgsm recomputes the parameters to get them into OpenSSL format.

For details on the difference, see gnupg/sm/import.c:rsa_key_check.


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/20251126/f2d4950f/attachment-0001.sig>

From wk at gnupg.org  Thu Nov 27 14:02:20 2025
From: wk at gnupg.org (Werner Koch)
Date: Thu, 27 Nov 2025 14:02:20 +0100
Subject: [Announce] GnuPG 2.5.14 released
Message-ID: <87y0nrocgz.fsf@jacob.g10code.de>

Hello!

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

Note that this 2.5 series is fully supported and thus ready for
production use.  This means we won't break anything but may add some
more features before 2.6.

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


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

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

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

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


Noteworthy changes in version 2.5.14 (2025-11-19)
=================================================
         [compared to version 2.5.13]
         
  * gpg: Fix possible memory corruption in the armor parser.  [T7906]

  * gpgsm: Fix output of card serial number in colon listing.  [T7914]

  * agent:ssh: Fix RSA signature handling for newer spec.  [T7882]

  * gpg: Improve/relax the checking of preference options.
    [rG6570700fdd]

  * gpg: Fix the check for the END armor line.  [rG62b8bf2f39]

  * gpg: Do not present a default when asking for another output
    filename.  [T7908]

  * gpg: Include ADSK keys in key listings specified by fingerprints.
    [T7892]

  * agent: Fix a decryption failures if the pinentry dialog for the
    first tried recipient is canceled.  Regression since 2.5.7.
    [T7893, T7649]

  * keyboxd: Fix schema of the fingerprint table.  [T7892]

  * dirmngr: Fix OCSP next-update check.  [rG9ef87bcdb0]

  * gpg: New "pfc" record in colons key listings.  [T7897]

  * gpg: Allow import and export of Kyber secret keys.  [T7315]

  * gpg: Escape characters with the high bit set in NOTATION status
    lines.  [T7896]

  * gpg: New import option "force-update".  [T7892,rGf6237ccd31]

  * agent: Accept a trustlist with a missing LF at the end.
    [rG1b4ac98de7]

  * agent: Support protection for Kyber keys.  [T6638,rGaea62817f3]

  * scd:nks: Make newer TCOS signature cards work.  [rG17596e830f]

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


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

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

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

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

 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.14.tar.bz2 (8065k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.14.tar.bz2.sig

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

 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.14_20251119.exe (5563k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.14_20251119.exe.sig

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

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

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


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

We also provide Debian style packages for a couple of Debian variants.
See https://repos.gnupg.org/deb/gnupg/trixie-devel/ or use the menu to
switch to other distros/releases.  If you encounter packaging problems
please report them to the gnupg-devel mailing list.  Due to the upcoming
end-of-life of the current stable version (2.4) the use of the fully
supported -devel versions is suggested.


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

A new beta version of Gpg4win is this time not available.  Please wait
for the upcoming Gpg4win 5.0 release.



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

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

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

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

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

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

     sha1sum gnupg-2.5.14.tar.bz2

   and check that the output matches the next line:

ce1ab578256b93340320f5b46d0f5e6cb7eab89a  gnupg-2.5.14.tar.bz2
f0f9754346dae7ee1788cf6affa95f3fbac0b9b1  gnupg-w32-2.5.14_20251119.tar.xz
e0b8c042dfd22d9c33ccf97c9fcbe2b979815e57  gnupg-w32-2.5.14_20251119.exe



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

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


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

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

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

or can be downloaded as PDF at

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

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

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

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

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


Thanks
======

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

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

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

*Thank you all*

   Your GnuPG hackers


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

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

    ed25519 2020-08-24 [SC] [expires: 2030-06-30]
    6DAA 6E64 A76D 2840 571B  4902 5288 97B8 2640 3ADA
    Werner Koch (dist signing 2020)
  
    ed25519 2021-05-19 [SC] [expires: 2027-04-04]
    AC8E 115B F73E 2D8D 47FA  9908 E98E 9B2D 19C6 C8BD
    Niibe Yutaka (GnuPG Release Key)
  
    rsa3072 2025-05-09 [SC] [expires: 2033-03-03]
    3B76 1AE4 E63B F351 9CE7  D63B ECB6 64CB E133 2EEF
    Alexander Kulbartsch (GnuPG Release Key)
  
    brainpoolP256r1 2021-10-15 [SC] [expires: 2029-12-31]
    02F3 8DFF 731F F97C B039  A1DA 549E 695E 905B A208
    GnuPG.com (Release Signing Key 2021)

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

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

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

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

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

From lakshmikovvuri2277 at gmail.com  Thu Nov 27 14:55:27 2025
From: lakshmikovvuri2277 at gmail.com (Lakshmi Surekha Kovvuri)
Date: Thu, 27 Nov 2025 19:25:27 +0530
Subject: Request for account on gnupg.org
Message-ID: <CANcFhDg_EMV59ZpXJ2ShWz-AnXwd=ii=QEYEFtUFfdeASXzYvQ@mail.gmail.com>

Hi All,

I need an account to report a bug to the gnupg community from AIX.

Preferred handle: LakshmiSurekha
Shown name: Lakshmi Surekha Kovvuri
Email: lakshmikovvuri2277 at gmail.com

Thanks & Regards,
Lakshmi Surekha Kovvuri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251127/fe02a8df/attachment.html>

From borden_c at tutanota.com  Fri Nov 28 10:43:02 2025
From: borden_c at tutanota.com (Borden)
Date: Fri, 28 Nov 2025 10:43:02 +0100 (CET)
Subject: gpgsm documentation (2nd attempt)
In-Reply-To: <87bjkpp0uu.fsf@jacob.g10code.de>
References: <OesJlre--F-9@tutanota.com> <87o6oqpg9p.fsf@jacob.g10code.de>
 <OewfdcK--F-9@tutanota.com> <87bjkpp0uu.fsf@jacob.g10code.de>
Message-ID: <Of8pdxX--F-9@tutanota.com>

26 Nov 2025, 05:00 by wk at gnupg.org:

> However, when exporting in pkcs#12 or pcks#8 format, gpgsm recomputes the parameters to get them into OpenSSL format.
>
I must be using either gpgsm or openssl incorrectly. When I run:
gpgsm --output secret-key.pkcs12 --export-secret-key-p12 $cert_id_goes_here
openssl pkcs12 -in secret-key.pkcs12 -info -noout? # copied straight from the openssl manpage
I get:

MAC: sha1, Iteration 2048
MAC length: 20, salt length: 8
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048
Error outputting keys and certificates
40B7E82EE87F0000:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:../crypto/evp/evp_fetch.c:375:Global default library context, Algorithm (RC2-40-CBC : 0), Properties ()

However, when I run:
gpgsm --output secret-key.pkcs8 --export-secret-key-p8 $cert_id_goes_hereopenssl pkcs8 -in secret-key.pkcs8 -topk8 -nocrypt -out pkcs8-secret-key.pem

That seems to execute if I explicitly state -topk8, and it fails otherwise. I guess that means I need to get the openssl people to explain their documentation to me.
Incidentally, the gpgsm manpage puts --export-secret-key-raw & --export-secret-key-p8 together. Before reading more closely and learning that -raw exports in PKCS#1 format, I thought they were synonymous. Consider breaking the two parameters up to make the distinction obvious.

With thanks,


From jay.kayes at posteo.com  Sun Nov 30 13:15:28 2025
From: jay.kayes at posteo.com (Jay Kayes)
Date: Sun, 30 Nov 2025 12:15:28 +0000
Subject: GnuPG's SSH agent does not work when using SSH host certificates in
 GnuPG 2.4.8
Message-ID: <d321813f19ee82dc34ec948b6de38c86584cca6c.camel@posteo.com>

Hi all,

I've been experimenting with moving my environment to use SSH host
certificates to authenticate hosts.  In my testing I have found that
when the server is using a ssh host certificate, I cannot authenticate
using my PGP key and GnuPG's SSH agent from my Fedora machines.  The
Fedora machines are on GnuPG version 2.4.7 (Fedora 42) or 2.4.8 (Fedora
43).  Authentication with PGP key does work when accessing the test
server from an OpenSUSE machine with GnuPG 2.5.13, and works from all
machines and tested GnuPG versions if I disable the host certificates
on the server.  Host authentication with certificates works if I bypass
GnuPG and use a "normal" file based SSH key, so the problem seems to be
specifically GnuPG 2.4.*.

The error I get on connection:
    ssh jay at testserver
    sign_and_send_pubkey: signing failed for ED25519
"cardno:0000_12345678" from agent: agent refused operation

I did not notice any relevant changes listed in the release notes, but
something has clearly been fixed in the 2.5 series.

Is this a known issue, and is there a known workaround for the 2.4
GnuPG versions?

I'd like to implement SSH host authentication with certificates, but
unfortunately this is a blocker as I am invested in using GPG for SSH
auth.  Moving away from Fedora is not really an option right now, and
installing a more recent GnuPG on Silverblue is rather awkward, so I'll
postpone implementing certificates if there is no workaround.

Cheers!
Jay


P.S.: My SSH keys are on a Yubikey/Nitrokey, I have not tested with
file based PGP keys

P.P.S.: OpenSSH versions do differ somewhat as well, so potentially the
problem could be on the OpenSSH side. The only combination that works
for me is on OpenSUSE Tumbleweed with GnuPG 2.5.13 and OpenSSH 10.2p2.
Fedora with GPG 2.4.7 and OpenSSH 9.9p1, and Debian 13 with 2.4.7 and
OpenSSH 10.0p2 do not work.


From dgouttegattat at incenp.org  Sun Nov 30 18:21:55 2025
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Sun, 30 Nov 2025 17:21:55 +0000
Subject: GnuPG's SSH agent does not work when using SSH host certificates
 in GnuPG 2.4.8
In-Reply-To: <d321813f19ee82dc34ec948b6de38c86584cca6c.camel@posteo.com>
References: <d321813f19ee82dc34ec948b6de38c86584cca6c.camel@posteo.com>
Message-ID: <3665636.dWV9SEqChM@borealin.local.incenp.org>

On Sunday, 30 November 2025 12:15:28 GMT Jay Kayes via Gnupg-users wrote:
> The error I get on connection:
>     ssh jay at testserver
>     sign_and_send_pubkey: signing failed for ED25519
> "cardno:0000_12345678" from agent: agent refused operation

Looks like the same problem I once had with 2.4.x (and still have on another machine that is still running 2.4.x). If so, a workaround is to add the following option to your ~/.ssh/config file:

  PubkeyAuthentication unbound

(It can be set either globally, or in the section for the host(s) where SSH host certificates are used.)

My understanding (which may or may not be correct) is that the host-bound authentication protocol extension (which the option above will disable) is only useful when agent forwarding is used; when not using agent forwarding, disabling this extension should not have any security impact.


> I did not notice any relevant changes listed in the release notes, but
> something has clearly been fixed in the 2.5 series.

I think it might be the fix to https://dev.gnupg.org/T7436, which landed in 2.5.2.

Best,

- Damien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 265 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20251130/705aed07/attachment-0001.sig>