How about:

• Only when hash-handle is used for multiple purposes, a user needs to compose SEXP
• when hash-handle is used for a single purpose, a user doesn't need to compose SEXP, but static one.

In the original SuSE's patch, _gcry_pk_sign_md function gets data template as SEXP as an argument, and the implementation does decomposing SEXP to get hash-algo. (A user of the function needs to compose SEXP with hash-algo.)

Thanks. This looks good to me.

Thank you for pointing out. Since hmac256.{c,h} can be used by others, I think that it is better to keep those two files, instead of merging it into one.

I tried to generate a tarball from master and I failed to build the hmac256 binary because the hmac256.h was not packaged into the dist tarball in master. If hmac256 should be standalone binary, I propose it should not need have a separate header file:

Tsss, requires to allow JS for Google.

Just FYI, see also how GnuTLS has proposed to implement the service indicator:
https://gitlab.com/gnutls/gnutls/-/merge_requests/1465

Thanks. Applied with a minor change: The string is now in a new third field.

I have a draft, which results in the following "API" of the name-version:

I had in my mind something like this:

While data template preparation for RSA-PSS is a bit tricky, it's simple with ECDSA.

Having hash-algo in the s-exp is useful because a hash handle may carry several hashes. This is sometimes useful if you do not know the hash algorithm in advance and you need to make a guess (various PGP compatibility things in gpg). But of course we can simplify this and use the default algo from the hash handle if hash-algo is missing.

Thanks for your comment.

Thank you. On the first sight, it looks reasonable, but I would like to experiment with it a bit to see all use cases are covered.

Thanks. I think we are good here. If we will decide to pursuate the brainpool switch, I will open a new issue.

Pushed my initial implementation: rC117f5c3f8028: experiment-pk_hash_sign/verify: Implement pk_hash_sign/verify.

I am doing an experiment to implement gcry_pk_hash_sign.

Two third patches are applied to master. (@werner those parts are typo fix and tests improvement, which we agreed to push.)

We can easily extend the gcry_get_config API. You can give a key or have it to return all infos. For examle
"gpgconf --show-versions" prints this about libgcrypt:

If a configure switch to disable Brainpool curves will be added, we also need to add a switch to disable NIST curves.

Oh, my bad. I probably used wrong git command. Uploaded now the patches themselves:

disable-brainpool.patch is a text of list of patches.
I think the first two could be applied.
@Jakuje Could you please upload them?

My suggestion for a combined function is a simple:

2021-09-13 Update:

• Signature operation tested: RSA-PSS, RSA-PKCS#1-v1.5, RSA-X9.31, ECDSA by NIST Curves, DSA (against CAVS test vectors in FIPS 186-4)
  • Newly added features (also useful for standard API of sexp):
    • Support of X9.31 signature scheme with RSA
    • Support of supplying random "k" for DSA/ECDSA
    • Digest mode ASN for SHA512-224 and SHA512-256 (required for RSA PKCS#1-v1.5)

I have one more patch set to improve FIPS testing in test/curves.c. In the past, it was basically skipped altogether in FIPS mode. This implements more fine-grained selection of what is being tested. This is the first part.

I see.

BTW, the reason of the name "pkey" is that because gcry_pk_ctl is already occupied.
It will be changed, if needed.

Today, I pushed an example for RSA-PSS.

I added couple of minor comments. I hope they went into somewhere.

looks good to me. Tested now with master 47e425e07995454573e28c13c08229d2f8a75642 and all tests pass for me in and out of FIPS mode as well as in the "soft" one.

I created an experimental branch:
https://dev.gnupg.org/source/libgcrypt/history/gniibe%252Fnew-pk-api/

We should update jitterentropy to 3.0.2 or newer, which should be easier to get through certification, if we will go this way. From FIPS perspective, we should be fine with either going through getrandom only or with jitter entropy, but the bottom-line was that we should probably keep both as we do now.

From Stephan I got the following response to the allocation handler use case

I think the last user of random-fips was removed with rCed57fed6de1465e02ec5e3bc0affeabdd35e2eb7

Yes, it makes sense to remove it.

iirc Uli Drepper added a hack to dladdr which we made use of. Seems to be integrated into dladdr1 now.

While I don't know if runtime integrity check is required or not by FIPS 140,
I checked OpenSSL, and it has such a check in openssl/providers/fips. The FIPS module configuration file which has the module checksum by HMAC is generated by openssl fipsinstall command.

Ah... I realized that HMAC integrity check with dladdr (using address of constant string) might work (at some point) to determine the filename of libgcrypt.so, when/if glibc implementation allows searching with address of constant string. So, my claim "never worked" was wrong.

We have the same patch (including the hmac key and we use the switch. The reasoning on our side was to be compatible with fipscheck, but it is no longer used since last year and we use just the hmac256 tool:

Just for the records, the whole HMAC thing including the special dlopen trick used to work fine when we did the original FIPS support.

For Linux and FIPS, we should be actually fine with using /dev/random or getrandom().

The CAVS driver can be safely removed. The certification goes through the ACVP these days so it does not make sense to keep this.

For tests with FIPS mode enabled, I manually create the file .libgcrypt.so.20.hmac under src/.libs.

I pushed my further change.
Also, applied and pushed your changes.

Sorry, I didn't test for non-FIPS mode when I committed rC347817438990: fips: Fix tests in fips mode..
Tweaking the value for memory allocation is needed for FIPS mode, because it uses some secure memory by DRBG.

Tested the master on (faked) FIPS and non-FIPS Fedora and I created couple of more changes for master to work in FIPS mode:

Ah, I understand the point (at least, partially); My understanding is: With FIPS mode, at the module boundary (== libgcrypt), it ensures that all cipher/digest/etc. operations are done under the standard compliance, and it is considered wrong (violation) when non-FIPS mode operation (such as SHA-1) and FIPS mode operation are mixed.

In RHEL, we do not have anything about PCT so the PCT requirement is not completely clear to me: https://git.centos.org/rpms/libgcrypt/blob/c8s/f/SOURCES

SUSE has patches and version 3235 of cavs_driver.pl, bud it seems that it doesn't support DSA with Q+HASHALGO yet.

As a start, I applied your patches.

And... as long as I read the PCT patches, it is not needed to export those API to users.
It is only needed internally for PCT tests (at most).

I am considering API enhancement, for this task.

I went through the patches above + what I suggested in previous comments, tested everything against both upstream and libgcrypt in Fedora in FIPS mode. There were slight differences, some cases were already fixed in master, some needed to upstream some of our changes, but the result is 10 patches working in both FIPS and non-fips mode, hopefully enough annotated. If not, please, ask for clarifications.

I went through the OpenSSL drafts. The module boundary in OpenSSL will be separate fips.so object and only non-deprecated functions of OpenSSL 3.0 will be FIPS compliant. There is a global state, that will allow only approved algorithms and modes and there will be API to query the FIPS mode status using OSSL_PARAM_get* functions, but we still have some unknowns so I hope we will know more on the next meeting.

Just FYI, NSS offers following API:

I was so far testing with changes on top of our patches.