Interesting idea.

How difficult would it be to teach gpg-agent to fall back to another SSH agent if given an unsupported key?

Which product do you refer to? Kleopatra? gpg4win? Something else?
Which operating system are you using? Windows? Linux? Something else?

I see.

BTW, the reason of the name "pkey" is that because gcry_pk_ctl is already occupied.
It will be changed, if needed.

Today, I pushed an example for RSA-PSS.

I added couple of minor comments. I hope they went into somewhere.

I created an experimental branch:
https://dev.gnupg.org/source/libgcrypt/history/gniibe%252Fnew-pk-api/

Thanks for helping out @werner.

You can write your own pinentry script instead of the loopback thing. The use the envvar PINENTRY-USER_DATA to communicate with the pinentry.

by the way when the applet is selected, I return
D2760001240103045343000000010000
this can be used to detect the manufacturer number

Card ATR at the cool reset
Card ATR is : 3B 9C 95 81 01 50 53 43 50 2D 53 43 53 56 31 2E 30 8E
Historical Byte is 53435356312E30
CARD ATS-to-ATR is : 3B 8C 80 01 50 53 43 50 2D 53 43 53 56 31 2E 30 0A
CARD ATS is : 11 78 80 B8 02 50 53 43 50 2D 53 43 53 56 31 2E 30
Historical Byte is 53435356312E30
This can by detected for the card type.

Is there another way to to detect your card (I assume a Javacard) without relying on the openpgp card application vendor-id like we do it with the Yubikey? I want to avoid a possible early but expensive AID selection just to get the vendor-id.

Actually, I think there's a way to make gpg_strerror_r more usable on its own. I previously said

I find it quite difficult to use strerror_r and gpg_strerror_r. With having to guess and retry to get an appropriate buffer length, a wrapper which dynamically allocates the string seems to be needed.

At first I've had simply tried to give multiple --symmetric options (which of course didn't work).

I have no clear idea on how to style the UI for this feature. Technically it is simple but we need top query several passphrases. loopback mode with a list of passphrases might be easiest way to do that.

@fvogt I've now added a logging category. Thanks for the suggestion.

As far as I understood, $WAYLAND_DISPLAY does not need to be set because there is a well-defined default, but I guess most of the time it's set anyway.

Ah, I understand the point (at least, partially); My understanding is: With FIPS mode, at the module boundary (== libgcrypt), it ensures that all cipher/digest/etc. operations are done under the standard compliance, and it is considered wrong (violation) when non-FIPS mode operation (such as SHA-1) and FIPS mode operation are mixed.

QGuiApplication checks $XDG_SESSION_TYPE maybe to find out whether to use X11 or Wayland if $DISPLAY and $WAYLAND_DISPLAY are both set.

In RHEL, we do not have anything about PCT so the PCT requirement is not completely clear to me: https://git.centos.org/rpms/libgcrypt/blob/c8s/f/SOURCES

I gave it a try and it works here now with $DISPLAY unset, thanks!

Should now work for pinentry-qt on Wayland even if DISPLAY is not set.

bug has been closed as Wontfix [..] I see no reason to continue the discussion in the bugtracker.

This bug has been closed as Wontfix more than a year ago. I see no reason to continue the discussion in the bugtracker.

I share your concerns about centralization of keyserver infrastructure. Rejecting this security fix doesn't help keep keyservers decentralized, though.

It is now over 10 months that the proponents of these additions have not followed up on the discussion.

Huh, can't believe I somehow missed that this actually got a reply three years ago...

And... as long as I read the PCT patches, it is not needed to export those API to users.
It is only needed internally for PCT tests (at most).

I am considering API enhancement, for this task.

(OpenSSL for FIPS support is a bit tricky, which is described in README-FIPS.md in their distribution. It offers OpenSSL FIPS provider as shared library fips.so.)

I have couple of references from libssh:

gniibe: Can you please check what openssl does exactly. The problem is that we currently have no permanent state for Libgcrypt (i.e. something stored on disk per user or even better global)

FWIW: Unfortunately everyone is moving to GCM, even Outlook. While GnuPG was evaluated by the German BSI we had discussions about this and their evaluators were wary about GCM due to its brittleness thus our use of OCB was very welcomed. OTOH, another approved product meanwhile comes with GCM for S/MIME and thus it seems thatGCM is accepted.

There is no point in questioning whether a couple of words change racism or any other human problems of these days. It will not.

Right. The AES-GCM was not allowed in FIPS mode until recently and I think now it is acceptable only for certain protocols (TLS, SSH), which guarantee that the IV is handled "correctly". As mentioned by gniibe, the requirements is that one should not be able to set IV to any specific value. The IV should be incremented automatically inside of the library (with some mask length + some generator configuration), somehow similarly as it is done with openssl, which would probably requite a new API in libgcrypt.

If I understand correctly, to conform FIPS, we need to ensure Key/IV pair uniqueness (See "Implementation Guidance for FIPS 140-3", Annex C. "C.H Key/IV Pair Uniqueness Requirements from SP 800-38D").
Use of the API to set IV by any value may be considered bad.

Thanks for the reply, this source code file and suggestions are very useful. Let gpg execute commands is a solution, but it is not optimal compared to providing a functional interface.
In addition, it is reversible to revoke the subkey by expiring it. But I will use the solutions you provide at this stage, knowing that you have time to provide better solutions. thank you!

Sorry, this is not acceptable to me. <rant>You don't change racism by avoid words which are may be connected to racism. Master is a term used for example to indicate that a person is proficient in her profession. Slave is (in theory) a historic term to describe, well slaves. That is humans who are non-free and are not allowed to control their lives - like the majority of humans these days - they are just called different and the methods of suppression are different than in the past. In fact a Roman slave (but not a medieval bondsman) had well defined and esteemed rights not something the majority of US citizen with a dark skin has in practice. Term abolished, racism abolished, works as good as freeing the US slaves in the 1856, the 1960, or still today. It did not work. Mr. Kings hope has not yet realized itself and is now maybe farther away than we all had hoped in the second half of the last century. Don't cover facts by changing words used in a very different context.</rant>

What do you mean by "exporting revocation certificates"? Once such a certificate is imported you simply export the public key including the revocation signature. Otherwise, simply takes the revocation certificates from ${GNUPGHOME}/openpgp-revocs.d where they are written to, if you generate a key. Kleopatra uses gpg directly to generate a revocation certificate mimicking what gpgme would do: See https://dev.gnupg.org/source/kleo/browse/master/src/commands/genrevokecommand.cpp.

ggp-agent has no support for U2F and it can't work with these key types. Given that Yubikeys also have proper keys (even eddsa) I doubt that we will implement support for ecdsa-sk OpenSSH feature any time soon,

Some ideas:

• the someflags thing will probably just be a reserved parameter
• If DATA is not NULL but an MD is set the sign function should fail
• Should ownership of MD be moved to the CTX?

In an email from @werner couple days back, I got a suggestion that we could use hashing tied to the context, rather than this one-shot call tied only to digests. I circled back this suggestion to Stephan and he confirmed that it should be fine from the FIPS point of view so I am posting the suggested API here too:

ctx = gcry_pk_new (someflags)
md = gcry_md_open (...)
gcry_ctx_set_md (md);
gcry_pk_sign_ext (ctx, result, data, skey)
[...]
gcry_ctx_release (ctx);

OK. I think that the patch at SUSE is updated one which works.
As I understand correctly, this is a kind of very old patch, which intended to work around old libgcrypt limitation of RSA PSS.

I think that {D1476} is still a sketch (not real code which works). I would guess an intended use, but it's good to have concrete example program which uses the feature being added.

FWIW, there is also this newer patch: https://dev.gnupg.org/differential/diff/1476/
and SUSE seems to already use a modified API:
https://sources.suse.com/SUSE:Maintenance:15118/libgcrypt.SUSE_SLE-15_Update/26a8df5f96d27d6abca7bd7ba9b0def0/libgcrypt-FIPS-RSA-DSA-ECDSA-hashing-operation.patch

Our public key functions are stateless. For several reasons it would be good to have an option to keep some state (think pre-computations). Our gcry_ctx_t would be a perfect fit for this and it will allow us to join a pubkey function with for example a hash function.

Does the patch really work, or is it a sketch to describe the intended use?

The private key contains the public key. Thus there is no need to export the public key if you already got the secret key.

There is also the issue that options flagged as ignore or forced in the global config file won't have an effect either. But indeed we could mark them as non-change.

I did a new test and found that if it is a single file regardless of disk size, no error appears, but when there are multiple files in a single encrypted folder with a size greater than 1.5GB, the error occurs. Traverse a directory like Zorvek and Aheinecke wrote would be an optimal solution or at least some alert messsage to be aware of the action no supported.

I have allowed myself to edit this task to more reflect what this is about. Although the error is of course in my opinion more of a bug because it is so bad but I would rather fix it with this feature.

I actually agree that this makes sense. I mean at least Kleo could say: "Hey we have detected 50 files that are encryped in this folder tree, do you really want to decrypt them all?"

GnuPG (more precisely gpg-agent) does cache the password for some time in memory. The default is 10 minutes. Add

default-cache-ttl n

where n is the number of seconds to cache the password, to ~/.gnupg/gpg-agent.conf.

Update:
It looks like OpenSSH version 8 now supports ssh-agent's handling REQUEST_IDENTITIES.