Now, unwrapping supports both cases (KW and KWP).

For unwrapping, it is good if we can support "automatic" unwrapping, apply W^-1 and check the first 8 octets to see if it's KW or KWP.

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.

And I'm testing following:

The "at first" change done.

At first, I think that we need to change the way how libgcrypt rejects non-approved cipher/md/mac/pk.

FWIW, We have a similar mechanism for the secure memory

We talked today about the renaming the current "linux" entropy module to "oldlinux" would make sense.

Ok, I'll add.

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

GnuPG needs to be fixed. Done by rGe08225030dfb: w32: Prepare for the case gcrypt.h will not include winsock2.h..

Thank you for comments on random/rndlinux.c.

Pushed another patch to clarify the semantics of --enable-random-daemon;
It's only for building gcryptrnd and the test program getrandom.

Good catch. I pushed the change to remove use of random daemon remained.

Thank you for your quick testing.

Thank you. Tested locally that it does what it is supposed to do and all tests passed for me as expected.

Reading through the changes, the content and usage of the getentropy looks good.

the random daemon is still part of the configure.ac and the undefined _gcry_daemon_initialize_basics() and _gcry_daemon_randomize() is still used under the USE_RANDOM_DAEMON guard in several places. I think at least the following cases should be removed too (or the configure check to be modified to throw error or warning):

Here is the change remained:

diff --git a/src/fips.c b/src/fips.c
index bcadc5f2..5499aee8 100644
--- a/src/fips.c
+++ b/src/fips.c
@@ -82,6 +82,12 @@ static void fips_new_state (enum module_states new_state);

Before rebasing, I pushed a change to simplify access to no_secure_memory variable by rC209d98dcf66b: Simplify the logic for no_secure_memory..

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,

The first is a warning and the other error codes are exactly what we want.

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.

Thank you, applied.

Sorry for the noise. There were couple of other places which I missed initially and which are covered in the v2 patch which follows:

It turns out together with rCe96980022e5e some tests are failing in FIPS mode. The attached patch should handle the failures.

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.

I have been convinced disabling DSA makes more sense.

Done.
(Actually, it's not in the tarball.)

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).

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.

The patch has been 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.

Yeah, remove it.

Thank you. My local tests (in emulated fips mode and normal mode) do not show any errors with current master branch.

And please let me know the change rC751fcadd34ed: random: Release memory in DRBG. affects t-secmem failure.

IIUC, one of the causes for the failure of secmem was resource release of DRBG memory.

Thank you for testing.

Applied. Thank you.

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

Thanks. I did some git archeology and found the first mention of this in the following commit in 2011 without much details:

Adding the case for == 0 only might be problematic, because I don't think it's an alias for a secure value; I think that == 0 means that it's up to libgcrypt to select the value (just like other generate_* functions).