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

I think this is not urgent as we are able to FIPS certify libgcrypt without that, but the modern protocols and algorithm use this and if we want to use libgcrypt to implement these in FIPS compliant way, we certainly need something like that.

I don't think it is justified to tag this as "unbreak now" - which we use for severe bugs inhibiting the use of a deployed version.

I simplified the script not to use cmp: rC3c8b6c4a9cad: fips: Fix gen-note-integrity.sh script not to use cmp utility.
And I clarified the semantics of the integrity check.

Ah, right, I can get that added to the containers tomorrow.

I located the cause:

../../src/gen-note-integrity.sh: line 78: cmp: command not found

That only seems to work in some configurations: https://gitlab.com/redhat-crypto/libgcrypt/libgcrypt-mirror/-/pipelines/472626834

I pushed the change: rCa340e9803882: fips: More portable integrity check.
It uses .note.fdo.integrity section, not loaded onto memory.
It simplifies the logic, and switches to dladdr (from dladdr1).

Pushed the change which fixes the build with ld.gold.
rC9dcf9305962b: fips: Integrity check improvement, with only loadable segments.

Thank you for your suggestions, @werner.
I agree that we should not put much effort to develop our own methodology here; Too much effort may introduce possibility of unmaintainable code, which should be avoided for the particular purpose of "integrity".

Folks, you are opening a can of worms. The only secure why to sign a file is to have a detached signature. That is often non-practical and thus putting the signature/MAC at one certain position and exempt just this one position from hashing is the next best alternative. Any more complicated rules will inevitably introduce security flaws. If a binary is stripped, it is a different binary than a non-stripped one, if it is linked with another linker, it is a different one. And that binary will even be able to figure this out and change behavior. Please keep it simple.

Thanks! Maybe it would be simpler to use dl_iterate_phdr(3) for this. I wasn't aware of the function, but a colleague just implemented a proof-of-concept of what you're proposing in https://gitlab.com/dueno/integrity-notes.

I am going to apply https://gitlab.com/redhat-crypto/libgcrypt/libgcrypt-mirror/-/commit/64ccc25c4b4a2c8c4e13e7e37ff1c8c60a3d8401
And consider adding the code to limit hashing content (from start of the file to end of data section).

It was addressed in rC04f325d8917d: released 1.1.4 as "(obsolete)" feature, in Aug 2001.

Instead, let us remove the feature.

Tested on a big endian machine.

$ uname -a
Linux perotto 5.15.0-2-powerpc64 #1 SMP Debian 5.15.5-2 (2021-12-18) ppc64 GNU/Linux

it will be but we first prefer to do some final tests with that version. Feel free to also test. Either this or the next micro version will eventually be announced.

Hi there, is this the new stable version of libgcrypt? Apologies if this is the wrong place to ask; I just couldn’t find any other release announcement for 1.10.0.

Thanks, Werner. This was originally reported by Alejandro Masino.

Thanks