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

Pushed rC254fb14044cf: kdf: Change new KDF API.

@jukivili , thank you for your comment.

I planned to reply to your email on mailing-list, but I just have too little time.

For the record, there is a new report on the mailing list about this module on MacOS:

Thank you, applied both of two patches.

Thanks. Looks good to me.

Test cases are recovered in rC535a4d345872: fips: Recover test cases for selftest, add skipping in FIPS mode..

Sorry, it's my misunderstanding.
_gcry_fips_run_selftest can be run by GCRYCTL_SELFTEST.
I was confused by the function name. Perhaps, it is good to change the name of function to _gcry_run_selftest.

@werner Those removed tests are selftests which are only invoked by FIPS mode for its requirement of selftests.

AFAICS, the last commit removes some tests. We should never remove a test just because FIPS does not allow it. The old tests need to be run in non-fips mode.

Hi, @gniibe and @Jakuje. That fulfills the requirement and all the regression tests pass in FIPS mode. Thanks!

Pushed the change in rC76aad97dd312: fips: Reject shorter key for HMAC in FIPS mode..

And we need to fix selftest for shorter keys.

@pmgdeb : IIUC, what we need is:

diff --git a/cipher/md.c b/cipher/md.c
index 34336b5c..4f4fc9bf 100644
--- a/cipher/md.c
+++ b/cipher/md.c
@@ -903,6 +903,9 @@ prepare_macpads (gcry_md_hd_t a, const unsigned char *key, size_t keylen)
 {
   GcryDigestEntry *r;

In T5512#153650, @Jakuje wrote:

This is my draft for the FIPS indicator KDF. I think we do not need to keep the original GCRYCTL_FIPS_SERVICE_INDICATOR if we replace it also in the tests. This will also need some tests and documentation update.

libgcrypt-fips-indicator-kdf.patch3 KBDownload

I'm not completely sure but it might be convenient to mark HMAC keys with lengths less that 112 as non-approved in FIPS mode for both generation and verification. It could be easily implemented by adding a check using cipher/mac-hmac.c:hmac_get_keylen() or at the algo level. What do you think?

Thank you, applied.
Also, add another change.