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!

Pushed the change in rC76aad97dd312: fips: Reject shorter key for HMAC in FIPS mode..

And we need to fix selftest for shorter keys.

@pmgdeb : IIUC, what we need is:

diff --git a/cipher/md.c b/cipher/md.c
index 34336b5c..4f4fc9bf 100644
--- a/cipher/md.c
+++ b/cipher/md.c
@@ -903,6 +903,9 @@ prepare_macpads (gcry_md_hd_t a, const unsigned char *key, size_t keylen)
 {
   GcryDigestEntry *r;

In T5512#153650, @Jakuje wrote:

This is my draft for the FIPS indicator KDF. I think we do not need to keep the original GCRYCTL_FIPS_SERVICE_INDICATOR if we replace it also in the tests. This will also need some tests and documentation update.

libgcrypt-fips-indicator-kdf.patch3 KBDownload

I'm not completely sure but it might be convenient to mark HMAC keys with lengths less that 112 as non-approved in FIPS mode for both generation and verification. It could be easily implemented by adding a check using cipher/mac-hmac.c:hmac_get_keylen() or at the algo level. What do you think?

Thank you, applied.
Also, add another change.

No, these are simply the technically available algorithms. I'll see what I can do.

I found this post when I was searching everywhere for a solution, and I was delighted. I've recently been trying to upload GpgFrontned in the Apple Store vs Microsoft and I'm having some trouble.

I went through the documentation related to FIPS and updated some wording to match reality. It will probably require still some more work.

This is my draft for the FIPS indicator KDF. I think we do not need to keep the original GCRYCTL_FIPS_SERVICE_INDICATOR if we replace it also in the tests. This will also need some tests and documentation update.

Yes, we should introduce an INDICATOR_KDF thing.

Patch applied, doc updated.
No change of FSM diagram.

The previous comment should have come to the T5600. Sorry for the noise.

Sorry for resurrecting the done task, but I got a message from @pmgdeb who noticed there is mismatch between parenthesis in the --with-fips-module-version help string. The attached patch fixes the issue and add proper help text.

Thanks. Looks good to me (both merged changes and the above proposal). In addition to the changes proposed above, we certainly need to update the documentation about this, probably also the FSM diagram.