In T5975#158113, @werner wrote:

I can imagine thar there are use cases for this. Thus I see no problems for the first part.

The second part is imho not a good idea. Libgcrypt is a building block for all kind of software and there are for sure legitimate reasons to use rsa512 (MCUs, short living keys, etc). Thus I think that the decision on the key size should be done by the software using libgcrypt.

Pushed the change (master and 1.10).

At first, we need to add/enhance new API for KDF in libgcrypt. Currently, the term "KDF" in libgcrypt is used with narrower focus, that is, only for password->key KDF.

I do not claim I understand anything of this assembler syntax :)

Lets implement it for 2.3

For the second, I wonder if newer xlclang++ compiler works with 1.9.

Thank you for the bug report.

Pushed the change.

Thanks for your confirmation.

Okay, confirmed: I was just wrong and the build failure was only ever with --disable-asm (i.e. the log in this bug is the only relevant one). Patch works.

Ok. Thank you for the clarification. I will drop the second part and keep only the FIPS change in the patch. Merge request already updated.

Thanks. Should be applied.

I can imagine thar there are use cases for this. Thus I see no problems for the first part.

Pushed the change. Also, it's backported to 1.10 branch.

Thanks for creating this ticket. I'll reply.

libgcrypt 1.10 is out with the API change for Windows, and we don't see any report (yet).

Pushed the change to master.

GCC 11.3 and GCC 12.1 are out with the fix.

When we implemented this first, Libgcrypt had no appropriate KDF support. I recall that I considered to change this but it turned out the for 2.2 the changes are too large. For 2.3 we will consider such a change.

Feedback from the lab is that they'd recommend returning a specific error code that indicates that the prime search failed and then relying on the caller to decide whether to loop or bubble up the error. I'm not sure who we would consider to be the "caller" of the relevant generation function in this case, though.

Full ack.

Here is my proposal patch:

diff --git a/random/random-drbg.c b/random/random-drbg.c
index 5a46fd92..f1cfe286 100644
--- a/random/random-drbg.c
+++ b/random/random-drbg.c
@@ -341,6 +341,9 @@ enum drbg_prefixes
  * Global variables
  ***************************************************************/

That sounds reasonable. The FIPS 186-5 draft (https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5-draft.pdf) covers this in section A.1.3, although I'm not quite sure why a lower bound for p was chosen compared to q. The comment that seems to have triggered this change is published on page 68 of https://csrc.nist.gov/CSRC/media/Publications/fips/186/4/final/documents/comments-received-fips186-4-december-2015.pdf by Allen Roginsky. It only contains a suggestion of 20, presumably for both numbers.

I checked FIPS 186-4 (and FIPS 186-5-draft). It is Appendix A 1.3.

I was pointed by Daiki to the following patch in Fedora binutils, which allows listing the fdo packaging metadata, but it does not list any other unknown objects and unfortunately fails hard:

I just copied the value of 0xcafe2a8e and the name .note.fdo.integrity from Daiki's implementation. No other reason.

I have one follow-up is that the readelf chokes on the integrity note for some reason:

$ readelf -n /usr/lib64/libgcrypt.so.20.4.1
Displaying notes found in: .note.fdo.integrity
  Owner                Data size 	Description
  FDO                  0x00000020	Unknown note type: (0x8e2afeca)

I assume this is just because the readelf does not know this type. I see this type was initially proposed by Daiki, but I did not find any other sources for this magic number so before filling bugs for readelf, do we have some doc why the 0xcafe2a8e is used?

The set_bit is obvious but we should cross check with the specs. In the non-fips mode we also try w/o a limit.

I think that it is OK to loop forever until we find a prime.

Hi Jussi, yes for some reason, it went missing, I was checking performance numbers and found out the line went missing. Thanks.

Fixed in master. I rechecked that bulk implementation passes tests with qemu-ppc64le.

Looks like that line went missing in third/final version of AES-GCM patch at https://dev.gnupg.org/T5700

you also use the CPU cache size on GNU/Linux. Is it important to have that information on MS-Windows?

The attached patch implements getting the number of processors on MS-Windows.

see rC67b36154f88e for master.

Will add it. The reason I added Brainpool was due to a question on the performacne between Brainpool and other NIST.

Done in master to be 1.11 for server side rC754ad5815b5b: random: Remove use of experimental random daemon.

Done in 1.10.1.

GetNativeSystemInfo. Would you like me to submit a patch that used that in jent_ncpu?

Yes, I see the problem:

In libgcrypt (1.10), we have a copy of the jitterentropy 3.3.0 from:
http://www.chronox.de/jent.html
or https://github.com/smuellerDD/jitterentropy-library

Let me ask a more specific question, since you mentioned "support of detecting numbers of CPU and having more than 1 CPUs": can you point me to the code which detects the number of CPUs on MS-Windows systems, where I could learn how that code is affected by having EOPNOTSUPP defined? I will then hopefully understand better what you are saying, and either agree with you that this is unworkable on Windows, or propose a better solution.

Can you please tell more about how this causes non-working code? MinGW64 defines EOPNOTSUPP to an arbitrary constant which (AFAICT) is never actually returned or used in the MS-Windows runtime. Their documentation, in https://docs.microsoft.com/en-us/cpp/c-runtime-library/errno-constants?view=msvc-170, says:

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.

Thank you for your report.

Thanks for you patches. Most of them applied cleanly despite that I delayed processing them for half a year.

Fix pushed to master. Updated graph:

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