Thanks. I did some git archeology and found the first mention of this in the following commit in 2011 without much details:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Dec 3 2021
Adding the case for == 0 only might be problematic, because I don't think it's an alias for a secure value; I think that == 0 means that it's up to libgcrypt to select the value (just like other generate_* functions).
Thank you, applied.
Dec 2 2021
Let me get back to this once more as one of the parts for RSA was initially missed:
diff -up libgcrypt-1.8.4/cipher/rsa.c.fips-keygen libgcrypt-1.8.4/cipher/rsa.c --- libgcrypt-1.8.4/cipher/rsa.c.fips-keygen 2017-11-23 19:16:58.000000000 +0100 +++ libgcrypt-1.8.4/cipher/rsa.c 2019-02-12 14:29:25.630513971 +0100 @@ -696,7 +696,7 @@ generate_x931 (RSA_secret_key *sk, unsig
I went through some more testing and noticed one missing file in the release tarball, that prevents building libgcrypt now. Should be fixed with the attached patch.
I did go through a bit more testing too and the selftests still initialize and use the secure memory (and the t-secmem fails in FIPS mode if we invoke selftests from constructor). Now from run_random_selftests() -> _gcry_random_selftest() -> drbg_healthcheck() -> _gcry_rngdrbg_healthcheck_one(). So this means that we either need to de-initialize secure memory after the constructor selftests or prevent its initialization as I suggested in some of the previous comments.
For the part 1, I created: T5710: FIPS: disable DSA for FIPS
Dec 1 2021
Also, applied the part 2, improving basic.c.
Applied the part 3, the 3DES is no-FIPS patch.
Nov 30 2021
Applied the part 4, the indicator patch.
The change for pubkey-util.c is not needed any more, because
- T5665 handles new functions rejects use of SHA-1 as approved signature.
- pubkey-util.c is used by gcry_pk_sign and gcry_pk_verify.
Nov 26 2021
I do not like the idea of using the get_config interface for this. It should be easily usable by applications to check for single cipher/mode so int/bool return values would be preferred against the string ones (which are now used in the get_config). I am not sure if getting all the configuration in one string blob would be any use (except for some auditing) either.
Nov 23 2021
Thank you. Extending the semantics of GCRYCTL_CLOSE_RANDOM_DEVICE sounds good to me. I think the deinit functions were created initially especially not to change the semantics of existing code using GCRYCTL_CLOSE_RANDOM_DEVICE, but I agree that it will probably not be an issue.
Nov 19 2021
Part 1 was applied. Part 3, Part 4, and Part 7 are irrelevant now, because we now have rndgetentropy which doesn't use device.
Nov 18 2021
Fixed, with using normal memory for ->mem.
->mem is just used to measure the difference of memory access.
It found that newer jitterentropy uses larger mem (128KiB), while older uses 2KiB.
Nov 17 2021
Pushed to master.
Nov 16 2021
We could use a new mode #define GCRY_GET_CONFIG_FIPS 1 with gcry_get_config:
With just implicit indicators, we would have to block all non-approved cipher modes and kdfs including the OCB mode and skcrypt, which would probably make gnupg2 unusable in FIPS mode, which is not our intention.
In the documentation, I found:
Nov 15 2021
Nov 11 2021
I just wanted to add one more note that i just found out that the tests --disable-hwf or gcry_control GCRYCTL_DISABLE_HWF have no effect in case the global_init() is called from constructor.
Nov 10 2021
I'll fix regressions: failures of pubkey and pkcs1v2.
Nov 9 2021
Yes, keep the internal SHA-3.
We will have rnd-getentropy.c
Applied and pushed symmetric algo for basic.
Let me clean up rndlinux.c for current use case, at first.
I decided to use 3.3.0 disabling pthread feature.
Nov 8 2021
Thank you for merging the important parts of the patches and implementing similar stuff for DSA. You are right that DSA is supported in the 140-3 specs so it is fine to keep it enabled with the keylength constraints.
Applied parts except part 2.
The part 3 are modified version, so that memory can be released correctly.
Nov 5 2021
Implicit indicators mean that we need to go through the all algorithms and verify that they work if they have approved key sizes/parameters and do not work when they do not.
Firstly, applied uncontroversial part in rC976673425784: doc: Reference the new FIPS 140-3
Nov 3 2021
If I read it right, the version 3.1.0 adds the pthread requirement. Using 3.0.2 should be fine for us.
Nov 2 2021
The most of the stuff about boot blocking was discussed in the bug https://bugzilla.redhat.com/show_bug.cgi?id=1569393 (private). There were some bugs in our patches, but also some issue in the kernel that locked the boot process (in FIPS mode).
Nov 1 2021
Check for FIPS has been added. (1) and (2) were solved.
Its copyright notice in upstream now refers LICENSE file, which requires some arrangement.
Oct 29 2021
I work on gniibe/jitterent branch.
I realized that full featured jitterentropy now requires pthread. Timer-less mode uses threads for entropy. This is not good for libgcrypt use.
Oct 27 2021
OK. Sorry for the noise. I got a clarification that the test is no longer needed so closing this issue.
Oct 25 2021
From the FIPS Certs draft for RHEL 8.5, I have the following sentence:
We are currently using "implict" service indicators but eventually we may change Libgcrypt to support explicit indicators.
Oct 22 2021
I understand the point in the 1706920, but I'm afraid that the patch itself would not be directly related for the bug. My point: It surely may catch a most serious failure, but not many failures (if we need to check here).
Oct 21 2021
Fair enough. Unfortunately, the separation is not completely clear from the dist git history, so please, excuse any inaccuracies I will provide here. I will try to reference particular bugs so we can get back to them if needed:
Oct 20 2021
At this moment, we agreed on keeping the current behavior and not allowing the SHA1 for verification either. But we might need to revisit that in the future if this will cause issues. Or we might go the way of switching the service to non-fips if needed, rather than creating some more middle ground.
Perhaps, as a library (considering the benefit of users), it would be better to allow signature verification with SHA-1, to defer the decision to application.
Thank you for having a look into that. The change looks fine, but I need to get some clarification about what "Legacy use" means for "Digital signature verification" in the Table 8 of https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf
(3-1) is implemented: rCa23cf78102f3: cipher: Reject SHA-1 for hash+sign/verify when FIPS enabled.
For a programmer like me, it is easier if the behavior will be:
The problem is that the SHA-1 as a digest algorithm itself is allowed in FIPS mode (for non-cryptographic digests), but using it as part of approved signature scheme is not allowed
The current code is inconsistent about its behavior: how non-approved digest algos are supported or not when FIPS enabled.
If .fips will mean FIPS 140-3, why not the following patch?
diff --git a/cipher/sha1.c b/cipher/sha1.c index 3bb24c7e..cb50ef66 100644 --- a/cipher/sha1.c +++ b/cipher/sha1.c @@ -759,7 +759,7 @@ static gcry_md_oid_spec_t oid_spec_sha1[] =
Let me move this ticket as DONE (now Testing status), as the subject was solved (MD5 and soft/forced/inactive things).
Oct 19 2021
In T5433#151041, @gniibe wrote:Sorry, I was wrong. We don't need any changes.
When using gcry_pk_hash_sign and gcry_pk_hash_verify, approved digest algos are guaranteed when FIPS enabled.
Yes, it's a user of the function who supplies HD (handle for hash). (I had wrong assumption HD could be with non-approved digest algo.) But it is needed for the user to enable the HD and to feed message beforehand. At that stage, non-approved digest algo must fail.
I investigated if the possible change above (if applied) constitutes an ABI change: Indeed, it will be an ABI change, and an API change; code should be modified and build.
Sorry, I was wrong. We don't need any changes.
Oct 18 2021
I am going to implement rejecting SHA-1 through new API (hash+sign, hash+verify).
( No need to certify the DSA things)
Oct 15 2021
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.
Oct 14 2021
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.
Oct 12 2021
Now configure with
--enable-hmac-binary-check="I know engineers. They love to change things." works.
Oct 11 2021
Oct 8 2021
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.
Oct 7 2021
Pushed the change: rC082ea0efa9b1: cipher: Add sign+hash, verify+hash, and random-override API.