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.

Ok, I'll add.

Seen. @jukivili can you please add it to the AUTHORS file?

Ok, I have subscribed to the mailing list. I have resent the DCO.

DCO has not appeared on mailing-list. You can this from check list archives, https://lists.gnupg.org/pipermail/gcrypt-devel/2021-December/thread.html

Thanks Jussi, I did not receive the list moderator's email so I am not sure if the it has been posted on gcrypt-devel@gnupg.org. If not, I can resend the DCO. Thanks.

I did some finishing touches on coding style:

Hi Jussi,

Few comments on new patch:

Hi jukivili,

Thank you, applied.

It turned out that the new *.inp files are not part of the release tarball, which makes the tests from generated tarball fail. The attached patch should fix this issue.

Reading compressed point format has been done.
If writing support is needed, please open another task.

This new API is not for FIPS directly (any more), as we introduced pk_hash_sign/verify for FIPS.

Pushed the backport.

Hi jukivili,
I ran some basic tests and it did show the errors. I am in the process investigating what went wrong. In the meantime, i also included test result that I have used in my testing from bench-slope. In this test, I captured the message with 272 bytes buffer from the original libgcrypt repo and my optimized repo. Note that the bulk version of my code do 8x unrolling and the rest will do 16 bytes. So the first 2 128 bytes ran thru gcry_ppc_aes_gcm_encrypt and the rest of the 16 bytes thru gcm_ctr_encrypt (cipher-gcm.c).

Hmm,

$ gpg --with-colons --list-config curve
cfg:curve:cv25519;ed25519;cv448;ed448;nistp256;nistp384;nistp521;brainpoolP256r1;brainpoolP384r1;brainpoolP512r1;secp256k1

How would Kleopatra know that cv* is for encryption, ed* is for signing, and all other curves are for both uses? Or are the cv/ed prefixes a (de facto) standard?

You may run

We have tests in gniibe/new-pk-api, which can be backported.

• t-dsa
• t-ecdsa
• t-rsa-pss
• t-rsa-15

Thank you, applied.

Thanks jukivili for the review.

I have just a note about this issue, that it would be helpful to exercise this new API in some tests. Right now, only the old API is tested.

It turns out that the asymmetric key operations are not yet properly enforced with the .disabled flag. While the other key crypto usually has some "open" api, where this can be simply captured, the pubkey API has several entry points and the "test_algo" is not enough to check for disabled key types.

Just to be correct: Kleopatra takes the default key algorithm from gpg's default_pubkey_algo pseudo option. (Technically, this pseudo option probably uses gpg's --default-new-key-algo option, but only if the latter is set.)

Thanks, however I didn't see your email on mailing-list. Maybe the email got stuck on the way.

I sent a copy to gcrypt-devel@gnupg.org. Hope this is the right process. Thanks.

Please read doc/HACKING carefully on the process of sending DCO the right way.

For the part 1, I created: T5710: FIPS: disable DSA for FIPS

Also, applied the part 2, improving basic.c.

Applied the part 3, the 3DES is no-FIPS patch.

Applied the part 4, the indicator patch.

When the device-side feature was proposed, I had suggested to extend the protocol so that host side can know device side requires user interaction and prompt a user. But... the result was "it can be done with device side only".

I do not like the idea of using the get_config interface for this. It should be easily usable by applications to check for single cipher/mode so int/bool return values would be preferred against the string ones (which are now used in the get_config). I am not sure if getting all the configuration in one string blob would be any use (except for some auditing) either.

Thanks @ikloecker - I'll rebase to the original repo and send it to the email list.

And you may want to read the section "Sending patches" of https://dev.gnupg.org/source/gnupg/browse/master/doc/HACKING.

Hi Werner, Here is the DCO. Thanks.

FWIW: We need a DCO; see doc/HACKING.

No, too much release work. Better just one AppImage. Or well one VSD (based on 2.2) and one regular (based on 2.3)

Just a quick comment regarding GitHub: This mirror of the gpg repo hasn't been updated since many months. Please get the sources of gpg directly from the original source: git://git.gnupg.org/gnupg.git. See https://gnupg.org/download/git.html

Not sure if we want a separate AppImage for gpg & Co. Setting priority to "Needs Triage".