Funnily I created a file dirmngr/rfc3161.c last Sunday. I can't tell how long it will take but I am definitely interested in using GnuPG to create qualified signatures. Timestamp support is at least good for testing.

Thanks @jukivili. I have never thought of interleaving with interger poly1305 operation and that's a good suggestion. Will think about that one.

@werner There's renewed interest with protecting supply chains. GnuPG is used by a lot of open source systems. Is it possible to bump the priority on this?

I meant interleaving integer register based 1xPoly1305 with 8xChacha20 as is done for 4xChacha20 in cipher/chacha20-ppc.c (interleaved so that for each 4xChaCha20 processed, 4 blocks of 1xPoly1305 is executed). Quite often microarchitectures have separate execution units for integer registers and vector registers and then it makes sense to interleave integer-poly1305 with vector-chacha20 as algorithms do not end up competing for same execution resources. Interleaving vector-poly1305 and vector-chacha20 is not likely to give performance increase (and likely to run problems with running out of vector registers).

HI @jukivili , Thanks for the updates. For f14-f31 registers that was my mistake that did not think floating point will be used. Will correct that. For poly1305, it can be used on ARCH_3.0 so checking use_p10 doesn't seem to be necessary but I can include that as well.

I learned that it's now called "OneStep KDF" in SP 800-56Cr2.
It's "SSKDF" in OpenSSL (Single Step KDF, perhaps).

Problem is that new assembly is using VSX registers vs14-vs31 which overlap with floating-point registers f14-f31. f14-f31 are ABI callee saved, so those need to be stored and restored.

Tested patch with small change so that HWF_PPC_ARCH_3_00 is used instead of HWF_PPC_ARCH_3_10. Building bench-slope with "-O3 -flto" makes bug in new implementation visible. Without new implementations bench-slope is ok (testing with QEMU):

$ tests/bench-slope --disable-hwf ppc-arch_3_00 cipher chacha20
Cipher:
 CHACHA20       |  nanosecs/byte   mebibytes/sec   cycles/byte
     STREAM enc |      2.35 ns/B     405.0 MiB/s         - c/B
     STREAM dec |      2.32 ns/B     410.7 MiB/s         - c/B
   POLY1305 enc |      2.46 ns/B     388.0 MiB/s         - c/B
   POLY1305 dec |      2.34 ns/B     408.1 MiB/s         - c/B
  POLY1305 auth |     0.238 ns/B      4003 MiB/s         - c/B

-O2 problem with bench-slope seems strange. Does problem appear after this patch is applied?

With the change for T5996 applied, the semantics is clear. "Use-for-ssh" flag is a key not for "OpenPGP.3", but other keys (not only OpenPGP.[12], but also for normal keys.)

This feature is implemented in different way, by T5099.

Besides, if lower layer solution is preferred, Yubikey can support having the special BWT value 0xff when bmCommandStatus = 2 (Time extension) is returned to host. The CCID driver recognizes this special value to prompt a user the dialog window.

Please let us turn this into a fatal error again. I had too many support cases where Kleo was actually run with Admin rights and messed up the permissions. To help with development issues and for the sake of some blockheads introduce an envvar to bypass the error.

Pushed rGea97683d5820: scd: Support automatic card selection for READCERT with keygrip..
I think that it works for PIV card.

For testing, I can use these sites for client certificate authentication:
https://stackoverflow.com/questions/38095559/https-test-server-that-checks-client-certificates

In T5975#158113, @werner wrote:

I can imagine thar there are use cases for this. Thus I see no problems for the first part.

The second part is imho not a good idea. Libgcrypt is a building block for all kind of software and there are for sure legitimate reasons to use rsa512 (MCUs, short living keys, etc). Thus I think that the decision on the key size should be done by the software using libgcrypt.

I did some research about scree lockers (xtrlock, slock, swaylock, etc.).

I put another change for T5099. This feature can be used for any keys, no matter if it's on Yubikey or not, no matter if token supports touch confirmation or not.

Pushed the change (master and 1.10).

At first, we need to add/enhance new API for KDF in libgcrypt. Currently, the term "KDF" in libgcrypt is used with narrower focus, that is, only for password->key KDF.

A concrete example use case in my mind is:

• (Usual display manager (authentication by password or no-password))
• session starts with "locked" state of screen
  • In the beginning, user needs to "unlock" the screen, by scdaemon authentication
• (optionally, if needed) our-own-screen-locker should detect device removal, then, automatically locks the screen
• our-own-screen-locker should detect idling user session, then, disabling the card, automatically locks the screen
• our-own-screen-locker does authentication by scdaemon when it unlocks the screen

Note that this doesn't work if pinentry is pinentry-gnome3. pinentry-qt works well, too, because it supports curses fallback.

I added the last line, to recover tty state:

With cmatrix command and pinentry-gtk2, I now do experiment with this script:

This is updated version of gpg-auth, which clears the authentication state before trying PKAUTH.
Access is controlled by ~/.ssh/authorized_keys.

Lets implement it for 2.3

This is the one for login authentication (which invokes scdaemon to authenticate, instead of connecting by socket).

We meanwhile released two versions to our clients and are looking on how we can make it available to the community.

We have everything ready for a GnuPG Desktop Appimage but we first need a business case to maintain it.

Ok. Thank you for the clarification. I will drop the second part and keep only the FIPS change in the patch. Merge request already updated.

I can imagine thar there are use cases for this. Thus I see no problems for the first part.

Pushed the changes for http.c.

Is there any progress on this issue? The code looks reasonable but does not apply on top of 2.2.35 (I didn't try master yet) and I didn't find a submission to the mailing list. I would really appreciate this patch, as it is a significant speedbump in my workflow.

When we implemented this first, Libgcrypt had no appropriate KDF support. I recall that I considered to change this but it turned out the for 2.2 the changes are too large. For 2.3 we will consider such a change.

@werner Please backport to 2.2.

Should also go into 2.2

Seems we can close this bug.

Printing a note as we do in --edit-key is a good idea.

Passing fds etc adds complex extra code to gpg-agent. This was not the original design goal, although we violated this anyway by have some OpenPGP specific code there. This needs more thinking. Due to our internal use of OCB we can't make it FIPS compliant without large changes.

We should give this higher priority as users need to change their e-mail through kleopatra. A customer also wishes this.

GPGME has its own system hooks to provide a (different) solution for portability (Windows and POSIX).

Last part is applied. Let me consider how to solve, for other parts.

I guess I don't understand what you mean by "native building". This build was with MinGW, which is as "native" as MinGW64 is.
The reason for the problem is (AFAIU) that MinGW64 went after Microsoft's change in stat due to the 32-bit vs 64-bit time and off_t values issue.s That change breaks backward compatibility in more than one way: programs compiled on some versions of Windows will not run on other versions. mingw.org's MinGW kept the original semantics and symbols, which is why _stat32 exists in the mingw.org's headers, but is not exposed by default.

Turned into a feature request because native building on Windows is not supported.