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.

I have added tooltips to the + ECDH and the + Elgamal checkboxes. Hope this helps.

If the user unselects + ECDH, then the checkmark before Encryption under Certificate Usage is removed. I'm not sure whether adding a tooltip would help if they don't notice this.

It would be awesome if you could implement this \o/

Tested on a big endian machine.

$ uname -a
Linux perotto 5.15.0-2-powerpc64 #1 SMP Debian 5.15.5-2 (2021-12-18) ppc64 GNU/Linux

Thank you, applied both of two patches.

Thanks. Looks good to me.

DANE has been an experimental thing and is imho dead.

Test cases are recovered in rC535a4d345872: fips: Recover test cases for selftest, add skipping in FIPS mode..

Sorry, it's my misunderstanding.
_gcry_fips_run_selftest can be run by GCRYCTL_SELFTEST.
I was confused by the function name. Perhaps, it is good to change the name of function to _gcry_run_selftest.

@werner Those removed tests are selftests which are only invoked by FIPS mode for its requirement of selftests.

AFAICS, the last commit removes some tests. We should never remove a test just because FIPS does not allow it. The old tests need to be run in non-fips mode.

Hi, @gniibe and @Jakuje. That fulfills the requirement and all the regression tests pass in FIPS mode. Thanks!