The change allows internal use of HMAC with shorter key.
Considering again, I concluded the patch above should be applied.
The use of SALT in HKDF may be not secret and there are valid use cases with no last or shorter salt. It's different to the use case of HMAC, where KEY is secret.
Wed, Jun 22
Thu, Jun 16
I pushed the change needed for GnuPG to t5964 branch.
Added HKDF implementation to master.
Tue, Jun 7
I can only find this one: https://github.com/patrickfav/singlestep-kdf/wiki/NIST-SP-800-56C-Rev1:-Non-Official-Test-Vectors
Tue, May 31
I learned that it's now called "OneStep KDF" in SP 800-56Cr2.
It's "SSKDF" in OpenSSL (Single Step KDF, perhaps).
Fri, May 27
May 23 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
Lets implement it for 2.3
May 13 2022
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.
I can imagine thar there are use cases for this. Thus I see no problems for the first part.
May 12 2022
May 6 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 3 2022
Fixed in GnuPG 2.3.5.
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.
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
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
I checked FIPS 186-4 (and FIPS 186-5-draft). It is Appendix A 1.3.
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.