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.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
May 27 2022
May 27 2022
May 23 2022
May 23 2022
DemiMarie added a comment to T5975: Allow signature verification using specific RSA keys <2k in FIPS mode.
May 19 2022
May 19 2022
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.
May 17 2022
May 17 2022
• werner moved T5975: Allow signature verification using specific RSA keys <2k in FIPS mode from Backlog to Next on the FIPS board.
• werner moved T5964: gnupg should use the KDFs implemented in libgcrypt from Backlog to Next on the FIPS board.
Lets implement it for 2.3
May 13 2022
May 13 2022
Jakuje added a comment to T5975: Allow signature verification using specific RSA keys <2k in FIPS mode.
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.
• werner triaged T5975: Allow signature verification using specific RSA keys <2k in FIPS mode as Normal priority.
I can imagine thar there are use cases for this. Thus I see no problems for the first part.
May 12 2022
May 12 2022
May 6 2022
May 6 2022
• gniibe moved T5933: libgcrypt: Simply use BSS (not secure heap) for DRBG instance from Next to Ready for release on the FIPS board.
• gniibe moved T5918: Disable RSA PKCS #1.5 encryption in FIPS mode from Next to Ready for release on the FIPS board.
May 5 2022
May 5 2022
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.
May 4 2022
May 4 2022
May 3 2022
May 3 2022
• gniibe added a project to T5933: libgcrypt: Simply use BSS (not secure heap) for DRBG instance: backport.
• gniibe moved T5933: libgcrypt: Simply use BSS (not secure heap) for DRBG instance from Backlog to Next on the FIPS board.
• gniibe moved T5929: gnupg fails to add ssh key to control entry in FIPS mode with libgcrypt 1.10.1 from Next to Ready for release on the FIPS board.
• gniibe removed a project from T5929: gnupg fails to add ssh key to control entry in FIPS mode with libgcrypt 1.10.1: Restricted Project.
• gniibe added a comment to T5929: gnupg fails to add ssh key to control entry in FIPS mode with libgcrypt 1.10.1.
Fixed in GnuPG 2.3.5.
• gniibe added a project to T5918: Disable RSA PKCS #1.5 encryption in FIPS mode: Restricted Project.
• gniibe added a project to T5929: gnupg fails to add ssh key to control entry in FIPS mode with libgcrypt 1.10.1: Restricted Project.
• gniibe added a project to T5919: libgcrypt tests/basic.c and tests/keygen.c occasionally fail with "error generating RSA key: Number is not prime": Restricted Project.
• gniibe added a project to T5933: libgcrypt: Simply use BSS (not secure heap) for DRBG instance: Restricted Project.
Apr 20 2022
Apr 20 2022
neverpanic added a comment to T5919: libgcrypt tests/basic.c and tests/keygen.c occasionally fail with "error generating RSA key: Number is not prime".
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.
• werner triaged T5933: libgcrypt: Simply use BSS (not secure heap) for DRBG instance as Normal priority.
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 ***************************************************************/
Apr 19 2022
Apr 19 2022
• gniibe moved T5918: Disable RSA PKCS #1.5 encryption in FIPS mode from Backlog to Next on the FIPS board.
• gniibe moved T5929: gnupg fails to add ssh key to control entry in FIPS mode with libgcrypt 1.10.1 from Backlog to Next on the FIPS board.
neverpanic added a comment to T5919: libgcrypt tests/basic.c and tests/keygen.c occasionally fail with "error generating RSA key: Number is not prime".
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.
Apr 18 2022
Apr 18 2022
• gniibe added a comment to T5919: libgcrypt tests/basic.c and tests/keygen.c occasionally fail with "error generating RSA key: Number is not prime".
I checked FIPS 186-4 (and FIPS 186-5-draft). It is Appendix A 1.3.
Apr 14 2022
Apr 14 2022
Passing fds etc adds complex extra code to gpg-agent. This was not the original design goal, although we violated this anyway by have some OpenPGP specific code there. This needs more thinking. Due to our internal use of OCB we can't make it FIPS compliant without large changes.
• gniibe claimed T5929: gnupg fails to add ssh key to control entry in FIPS mode with libgcrypt 1.10.1.
Patches applied and pushed. For the common/t-ssh-utils, I applied my fix for the use case with key on command line when FIPS mode is enabled (MD5 error is OK, in this case).
Apr 13 2022
Apr 13 2022
Apr 11 2022
Apr 11 2022
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:
Apr 9 2022
Apr 9 2022
I just copied the value of 0xcafe2a8e and the name .note.fdo.integrity from Daiki's implementation. No other reason.
Apr 8 2022
Apr 8 2022
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?
Apr 7 2022
Apr 7 2022
• werner triaged T5919: libgcrypt tests/basic.c and tests/keygen.c occasionally fail with "error generating RSA key: Number is not prime" as Normal priority.
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.
• gniibe added projects to T5919: libgcrypt tests/basic.c and tests/keygen.c occasionally fail with "error generating RSA key: Number is not prime": libgcrypt, FIPS.
I think that it is OK to loop forever until we find a prime.
Apr 5 2022
Apr 5 2022
Mar 29 2022
Mar 29 2022
Done in 1.10.1.
Mar 22 2022
Mar 22 2022
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.
Mar 16 2022
Mar 16 2022
• gniibe moved T5835: libgcrypt: More robust/portable integrity check from Next to Ready for release on the FIPS board.
Mar 9 2022
Mar 9 2022
Mar 8 2022
Mar 8 2022
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:
Mar 7 2022
Mar 7 2022
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?)
Mar 3 2022
Mar 3 2022
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.
• werner lowered the priority of T5870: libgcrypt: AEAD API for FIPS 140 (in future) from Unbreak Now! to Normal.
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.
Feb 23 2022
Feb 23 2022
• gniibe moved T5835: libgcrypt: More robust/portable integrity check from Backlog to Next on the FIPS board.
Feb 17 2022
Feb 17 2022
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
Feb 16 2022
Feb 16 2022
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".
Feb 15 2022
Feb 15 2022
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).
Feb 2 2022
Feb 2 2022
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.
• gniibe closed T5759: Rename rndlinux module to rndoldlinux, a subtask of T5692: New entropy gatherer using the genentropy system call., as Resolved.
• gniibe closed T5636: Run integrity checks + selftests from library constructor in FIPS as Resolved.