I think so. We did not submit a modules for recertification with these changes, but we do not plan this in close future so you can consider it completed.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jun 19 2024
May 8 2024
May 7 2024
Can we close this?
Apr 3 2024
Feb 9 2024
Applied the change. I write the ChangeLog entry by commit message.
Feb 7 2024
Nov 15 2023
The fix is in 1.10.3.
Fix is in 1.10.3.
Nov 14 2023
Aug 8 2023
Jun 28 2023
Add the check of digest algorithm for EdDSA in: rCd15fe6aac10b: cipher:ecc:fips: Only allow defined digest algo for EdDSA.
No, there are use cases in GnuPG, where we specify the hash algo for signing, and our own tests/benchmark.c.
For the first issue, I added a check in: rCf65c30d470f5: cipher:ecc:fips: Reject use of SHAKE when it's ECDSA with RFC6979.
Jun 27 2023
From the FIPS 186-5 there are some limitations to use the SHAKE in FIPS Mode that we will have to reflect:
Jun 23 2023
Pushed a change in master.
Jun 22 2023
I found the case of X.509, which also uses fixed length output for RSA-PSS and ECDSA: https://www.rfc-editor.org/rfc/rfc8692.html
Jun 20 2023
Thank you for having a look into that! The proposed patch looks good. Should we have this change also in master?
Jun 19 2023
Here is a possible change (... to master, assuming it's good to support use case of RFC 8702):
diff --git a/cipher/keccak.c b/cipher/keccak.c index 22c40302..76e08cb5 100644 --- a/cipher/keccak.c +++ b/cipher/keccak.c @@ -1630,8 +1630,8 @@ const gcry_md_spec_t _gcry_digest_spec_sha3_512 = const gcry_md_spec_t _gcry_digest_spec_shake128 = { GCRY_MD_SHAKE128, {0, 1}, - "SHAKE128", shake128_asn, DIM (shake128_asn), oid_spec_shake128, 0, - shake128_init, keccak_write, keccak_final, NULL, keccak_extract, + "SHAKE128", shake128_asn, DIM (shake128_asn), oid_spec_shake128, 32, + shake128_init, keccak_write, keccak_final, keccak_read, keccak_extract, _gcry_shake128_hash_buffers, sizeof (KECCAK_CONTEXT), run_selftests @@ -1639,8 +1639,8 @@ const gcry_md_spec_t _gcry_digest_spec_shake128 = const gcry_md_spec_t _gcry_digest_spec_shake256 = { GCRY_MD_SHAKE256, {0, 1}, - "SHAKE256", shake256_asn, DIM (shake256_asn), oid_spec_shake256, 0, - shake256_init, keccak_write, keccak_final, NULL, keccak_extract, + "SHAKE256", shake256_asn, DIM (shake256_asn), oid_spec_shake256, 64, + shake256_init, keccak_write, keccak_final, keccak_read, keccak_extract, _gcry_shake256_hash_buffers, sizeof (KECCAK_CONTEXT), run_selftests
Reading RFC 8702, I realized that it defines the hash size in the use of CMS as: SHAKE128 : 32-byte SHAKE256 : 64-byte.
Jun 16 2023
I found this use case: RFC 8702
"Use of the SHAKE One-Way Hash Functions in the Cryptographic Message Syntax (CMS)": https://www.rfc-editor.org/rfc/rfc8702.html
Another possibility for digest&sign API: it is possible to determine the length of required hash function by the underlining field Fp of the curve in use. Then, use this length instead. It's better than to (try to) get the length by _gcry_md_get_algo_dlen (for SHAKE, it's undefined).
Fixed in both of master and 1.10 branch.
For libgcrypt, initially when the code was put, it made some sense.
Now, it's useless, so, let's simply remove the message.
Jun 15 2023
Jun 14 2023
I found that for EdDSA other than pure Ed25519, it can supply context.
I changed the semantics and API for adding context and input data, as we need to support both simultaneously.
I changed the lg-input-data.diff patch not to break the ABI, reusing the published symbol of gcry_pk_random_override_new.
With this approach, if/when needed, backporting may be easier.
Drawback is debugging internal of libgcrypt will be a bit confusing.
Jun 13 2023
Let's fix this in Libgcrypt (ignore setting of the handler)
Another approach would be having "non-hash" algo for gcry_md_open.
Before adding FIPS support flag and tests, we need to modify implementation:
- Adding PCT check for EdDSA
- Adding support of gcry_pk_hash_sign/verify API for EdDSA
Jun 8 2023
I'm going to add selftest of EdDSA with test vectors from RFC 8032.
Jun 5 2023
Jun 1 2023
They re-used the same file name for the update from March and no history section. Anyway that looks promising and may solve the problem of having different algorithms allowed for restricted communication in the EU and the US.
Correct, but the last revision of FIPS 140-3 lists the EdDSA already. The same for the IG for FIPS 140-3:
My understanding is that FIPS 186-x lists more algorithms than approved for FIPS 140-y; the approved algorithms for 140-y are in the latest revisions of SP800-140. I have not checked the latter document, though.
May 31 2023
May 30 2023
Let's schedule that for 2.6
May 25 2023
May 15 2023
GnuPG is and can't be FIPS-140-3 compliant due to the way it is implemented. We may eventually employ the new hash-and-sign API of Libgcrypt to move into this direction but that has not yet been done. However, this also requires the use of the new indicator API and the, well, a RedHat kernel.
May 5 2023
If you experience build problems on macOS see T6442
Apr 13 2023
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Mar 24 2023
Pushed the change.
Mar 21 2023
Mar 20 2023
Mar 8 2023
Thank you.
Applied to both (master and 1.10).
Mar 7 2023
Applied your patch (from gitlab) to both (master and 1.10).
Applied to both (1.10 and master).
You are right, there is no way to use DRBG with SHA384 by libgcrypt.
Applied to both (1.10 and master).
Applied to both (of 1.10 and master).