User Details
- User Since
- Jan 30 2018, 2:27 PM (359 w, 6 d)
- Availability
- Available
Feb 5 2024
I'm attaching a proposed patch. We should decide whether this is the correct encoding to use for SHAKE128 and SHAKE256, because they are variable-length output functions and there is an alternative encoding that has a field for the length, which is likely better suited, but currently not really well supported by libgcrypt (since this would be dynamic content in the ASN.1 encoding).
Feb 27 2023
One potential pitfall here is that SHAKE-128 and SHAKE-256 must not be available for use in signature operations. That's because https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf section C.C disallows the use of SHAKE in higher-level algorithms:
These look good to me.
This marks GCRY_MD_CRC32, GCRY_MD_CRC24_RFC2440 and GCRY_MD_CRC32_RFC1510 as approved.
Oct 19 2022
This causes ACVP tests to fail, so apparently the assumption that passphrases must be at least 14 bytes was incorrect. ACVP testing tests values larger than 8 bytes. I'll try to clarify whether that's a limit we need to enforce, or just what NIST wants to test. In any case, we will probably have to revert this.
Jul 6 2022
For the record, the valgrind trace for the crash is:
Jul 5 2022
Here's another one related to this: https://lists.gnupg.org/pipermail/gcrypt-devel/2022-July/005344.html
Jun 28 2022
Key length requirements for KDFs are specified in SP 800-131Ar2 (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf), which is linked from SP 800-140Dr1 (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-140Dr1.pdf) in section "6.2.1 Transitions".
FIPS 140-3 (https://csrc.nist.gov/Projects/cryptographic-module-validation-program/fips-140-3-standards) points to SP 800-140Dr1 (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-140Dr1.pdf) to list acceptable "Security Parameter Generation and Establishment Methods". From this document, RFC 5869 (i.e., HKDF with the counter at the end) can be reached via two paths:
Apr 20 2022
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.
Apr 19 2022
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 5 2022
Feb 17 2022
Ah, right, I can get that added to the containers tomorrow.
Feb 16 2022
That only seems to work in some configurations: https://gitlab.com/redhat-crypto/libgcrypt/libgcrypt-mirror/-/pipelines/472626834
Feb 15 2022
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.
Feb 10 2022
This still seems to be a problem: