After consulting with our certs lab and studying the code I think SHAKE should not be a problem for now. All of the _gcry_digest_spec_shakeXXX seem to neither have an mdlen nor a read() function. pk_sign and pk_verify seem to both call md_read() which should fail because of the missing read function, kdf checks _gcry_md_get_algo_dlen() which should also disallow SHAKE.

A finding has been that the icon theme switch is not detected at runtime. It would be nice if we could add this, especially if customers explicitly test the support for high contrast modes.

I forgot to restart Kleo after changing the contrast. Thus for the last one, we use a wrong set of icons. After restarting it looks like

FWIW:The assuan keytocard does not move the key - what you see is a side effect from unrelated code.

In rGeae28f1bd4a5632e8f8e85b7248d1c4d4a10a5ed#76893, @sandro wrote:

I am wondering why the global configs are not for all config options and for all of the various config files. That would make things for us and in general a lot easier. Also that the pinentry-program options was only for debugging was not obvious to us but we might continue to use it to avoid unnecessary wrappers around or symlinks.

Since I have closed T6377 which had high priority I am assigning this issue the same prio. Which I also think is appropriate.

I thought about this related to T6386 and I now agree with @ikloecker KEYTOCARD in SCD may not "move" the key. Otherwise it would be impossible to easily transfer a key to multiple smartcards. Since werner agreed in T6486 that this is a Bug and Unintended it can be closed as a duplicate as we do not need to further discuss this.

I have closed T4699 as a duplicate of this, even though T4699 was about simplification but IMO this is the same underlying problem.

I am downgrading this to wishlist. Even though I had worked on this a lot the regression risk is probably too high to fix this before GpgOL becomes obsolete.

I am closing this as a duplicate of T6117 even though it is not really a duplicate. But for me it does not make sense to keep this as a different issue because simplifying the dialog is directly related to making it more accessible.

We don't want to compile one gnupg for each desktop environment to have it hardcoded relative to gnupg but make it configurable depending on the DE used. As a fallback we could just symlink together gpg and the right gpg-agent which is rather cheap.

gpg-agent (I tested 2.4.something) looks at /etc/gnupg/gpg-agent.conf according to strace. I'm not sure why you think it doesn't, but maybe your older version really doesn't.

Thus the public key differs on wether the raw secret key or the masked (bit255 set, bit0..2 clear) has been used. And at what point in the code this was done. Shall we collect a list describing the differences of applications and on whether they have some mitigation for compatibility.

The code has meanwhile been reworked and the mentioned test server is not anymore available

Good catch. A similar problem might arise with SHA384 according to section D.R which states

One potential pitfall here is that SHAKE-128 and SHAKE-256 must not be available for use in signature operations. That's because https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf section C.C disallows the use of SHAKE in higher-level algorithms:

These look good to me.

Right, we have received the same feedback from our cert lab but I haven't found time to update the bug yet. Here are the updated patches:

This marks GCRY_MD_CRC32, GCRY_MD_CRC24_RFC2440 and GCRY_MD_CRC32_RFC1510 as approved.

CV25519 private key secret part:

• Standard MPI (big-endian) of 255-bit
• The value should have zeros for least significant three bits, its most significant bit (255th bit) should be set.
  • the value should be the one after decodeScalar25519 function in RFC7748

CV25519 public part from secret part:

• Simply calculated by [secret-part]G

Thanks for the report; the regression happened due to fixing T6135.

Added curses-repeat branch which needs testing for wide chars and other stuff in case i missed something

Please use

gpgtar -C /home/matt/data ....

instead of using an absolute name. This makes things much easier to implement in a secure way: You don't want to have absolute file names in the tarball and mapping them to relative names is not easy or even impossible in case of, say "/home/foo/x.data /home/bar/x.data". Keep in mind that gpgtar does also not handle symlinks and other special files.

I guess this is fixed with this commit for 2.2. and 2.4. Given that the report is quite old with not new infos since 2019, I'll close it.

I should probably add that Kleopatra calls this command when reading a smart card to create the key stubs if necessary. Kleopatra does this since gpg4win-3.1.24 (according to the tags) and the KDE Gear 22.04 release (see T5782: Kleopatra: Smartcard unusable secret key until used via command line).

Your report lacks any useful information starting with the version of gpg you are using. Did this ever work? What did you change? Did you probably upgrade the system and have previously been using gpg1, but are now using gpg2?

I have analyzed the problem. It is caused by a serious regression in gpg 2.2: https://dev.gnupg.org/T6386

Thanks

The reason why gpg does not encrypt to multiple subkeys is that the older subkeys are viewed as deprecated. You could write a tool which does a heuristic to check when the time is reached that no more messages are encrypted to an older subkey (or are used to decrypt archived mails). At that point you can take the private part of the old subkey offline.