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.

I had thought that we need to combine hkdf so that key and iv can generate within libgcrypt internally.
Probably, this assumption of mine may be wrong.

we replace the encrypted text and attachments with the decrypted / verified parts

The current links should be replaced or removed.

Because I'm just starting with GpgOL: Are we talking about adding links in the "Configure GpgOL" window or are there any other windows? If that is the right window maybe we could add a new tab "FAQ" and add the links there. At first I thought the links could be added to the tab "GpgOL" but there are already many entries and the other tabs don't fit well.

gpgol/doc/gpl.texi (line 9)
gpgol/COPYING-ICONS (line 52)

What are the other to places?

And updated scd_validate2.py:

Wrote a pam module which interacts a user for auth:

When I greped for links to the FSF page (grep with string "fsf" I found out that there is one link to https://emailselfdefense.fsf.org/en/infographic.html in line 722 of src/ribbon-callbacks.cpp. Is that the link that was meant?

I agree. @cklassen can you make a suggestion?

Gook luck on Solaris with this suggestion ;-)

Gook luck on Solaris with this suggestion ;-)

For the record, the typical response to "it doesn't work" support requests for keys.o.o still comes down to killall dirmngr.

I write a prototype in Python using pyassuan:

You are combining two concepts here -- the KDF and the AEAD cipher itself (at least from the FIPS terminology). I would like to avoid mixing these two together in the new API. If you would like to implement the SSH/TLS KDF, I would suggest to use the kdf API you already have. Then we are here left only with a new geniv API to implement. In the T4873 I mentioned example how it is now used in libssh using libgcrypt, which implements the iv increment outside of the libgcrypt:

Is large change to cipher API really needed (new open/encrypt with less flexibility)? How that would affect performance? Would following new interfaces to gcry_cipher API work instead?

• gcry_cipher_setup_geniv(hd, int ivlen, int method): for setting up IV generator with parameters such as IV length, method id (RFC5116, TLS 1.3, SSH, etc), (other parameters?)
• gcry_cipher_geniv(hd, byte *outiv): for generating new iv: generate IV using select method, set IV internally and output generated IV to 'ivout'.
• gcry_cipher_genkey(hd, byte *outkey, int keylen, int method): for generating keys, generate key internally with parameters (method id, other?), setup key internally and output generated key to 'outkey'. (how keys from key exchange protocol be handled? using existing setkey?)

More things to be considered:

• How to connect scdaemon
• How to invoke scdaemon

BTW, there are various use cases for authentication(s), it is better to focus on the part of device and crypto (USB Token and scdaemon).

Here is an experimental shell script for testing:

I think this is not urgent as we are able to FIPS certify libgcrypt without that, but the modern protocols and algorithm use this and if we want to use libgcrypt to implement these in FIPS compliant way, we certainly need something like that.

I don't think it is justified to tag this as "unbreak now" - which we use for severe bugs inhibiting the use of a deployed version.

It may be simpler if we can enhance scdaemon to have an option for PKAUTH, say, --challenge-response, so that it generates a challenge and verify signature internally.

The problem is that we replace the encrypted text and attachments with the decrypted / verified parts. This would already be a modification even without such changes like the category.

In T5837#155062, @werner wrote:

Setting the management key has been implemented only for Yubikeys. So for Gemalto this won't work.

Setting the management key has been implemented only for Yubikeys. So for Gemalto this won't work.