It seems for me that the patches to random/ was written in old days.

• Now, we have getentropy in libc
  • This is most reliable one
  • better than urandom, because it may block when kernel is not yet seeded
  • better than random, because it never blocks once kernel is seeded
• So, the real path in rndlinux.c is actually, call to getentropy
• No access to /dev/random or /dev/urandom any more, in fact
• Although old code remains, non-touched
  • like use of syscall when getentropy function is not available

Add doc in gcrypt.texi.

Thank you. Applied.

In T5617#150908, @gniibe wrote:

OK, let us start discussion by applying the patch first.

I have wondered if introducing another state in FSM would be needed, because:

OK, let us start discussion by applying the patch first.

Applied the RSA part.

Now configure with
--enable-hmac-binary-check="I know engineers. They love to change things." works.

I push a change: rC070935965763: build: Use KEY_FOR_BINARY_CHECK for --enable-hmac-binary-check..

sorry for a confusion. We do not plan to certify DSA so disregard the second part of the patch.

Do we really need to support DSA in FIPS mode? I mean standard DSA and not ECDSA.

Pushed the change: rC082ea0efa9b1: cipher: Add sign+hash, verify+hash, and random-override API.

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

These are great news. Thank you!

Pushed the change to libgpg-error and libgcrypt (1.9 and master).
Let us see if there are any problem(s) for that, I will apply it to other libraries when it will be found no problem.

Thank you for the information.
For the record, I put the link to the email submitted:
https://lists.gnu.org/archive/html/libtool-patches/2020-06/msg00001.html

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.

Oh, you are right, it's not upstream. It's actually applied to Homebrew (https://brew.sh/) libtool formula which is where I originally got libtool.m4, see:

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:

I see your point. I'd like to locate/identify where the change comes from.
I think that what you refer by "new libtool.m4" is actually macOS local change (I mean, not from libtool upstream, AFAIK).
Could you please point out the source of the change?

That would work, however we might hit this issue with a new macOS release. Would it make more sense to update to what the new libtool.m4 is doing? Linker flags are the same, it only changes the way they detect macOS versions:

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

That does indeed not look like something which could introduce a regression.

I misunderstood as if we need to update libtool from upstream.

macOS has low priority for us and I do not want to risk any regression.

About merging our local changes.

We have our own changes for ltmain.sh and libtool.m4.

And update from automake 1.16:

It's better to update the set of files from libtool:

build-aux/ltmain.sh
m4/libtool.m4
m4/ltoptions.m4
m4/ltsugar.m4
m4/ltversion.m4
m4/lt~obsolete.m4

Our libtool was 2.4.2 + Debian patches + our local changes.
Debian patches are:
https://salsa.debian.org/mckinstry/libtool/-/blob/debian/master/debian/patches/link_all_deplibs.patch
https://salsa.debian.org/mckinstry/libtool/-/blob/debian/master/debian/patches/netbsdelf.patch

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?

Thanks for the clarification!

The problem of (2), is local side-channel attacks to ElGamal encryption.
We evaluated the impact, mainly for the use case of GnuPG; ElGamal keys are not that popular any more. When such an attack is possible, easier attacks would be possible.

The paper addresses two issues.
(1) https://ibm.github.io/system-security-research-updates/2021/07/20/insecurity-elgamal-pt1
(2) https://ibm.github.io/system-security-research-updates/2021/09/06/insecurity-elgamal-pt2

And well, the context area of the handle is also wiped at gcry_cipher_close time. Thus any standard use of aeswrap (open,encrypt/decrypt,close) is not affected.

Good catch. Thanks. This patch should fix the leak:

I looks like the "cipher: Hardening ElGamal by introducing exponent blinding too." commit [1] was never applied to 1.8.x. Is that intentional? If so, is there a specific reasoning that it's not needed in 1.8.x? Thanks!

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.