In FIPS we need to accept different key sized than just 2k and 3k. According to NIST.FIPS.186-5 draft, it should be perfectly fine.
For DSA keygen, we need to be able to generate keys based on P and Q parameters for ACVP testing to be able to verify the result.
| rC libgcrypt | |||
| rCe4a450d1d966 rsa: Allow e=0 to select 65537 for keygeneration under X931. | |||
| rCbba63fab1a22 cipher: Allow generation of RSA keys > 2k | |||
sorry for a confusion. We do not plan to certify DSA so disregard the second part of the patch.
Applied the RSA part.
Aside of DSA should be certified or not...
For the DSA part, yes, I know that there has been a patch for DSA, but it was originally written for older libgcrypt (<= 1.8.4). And it's not relevant to apply it directly to master.
I think that DSA for FIPS 186-3 was fixed in rC30ed9593f632: Fix DSA for FIPS 186-3..
If really needed, we should check the intention/meaning of the DSA part of the patch. At least, removing call of sexp_release (deriveparm) is wrong.
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 *swapped = 0; - if (e_value == 1) /* Alias for a secure value. */ + if (e_value == 1 || e_value == 0) /* Alias for a secure value. */ e_value = 65537; /* Point 1 of section 4.1: k = 1024 + 256s with S >= 0 */
This was part of the same patch and probably required for CAVS or ACVP testing (probably from some testing vectors that use(d) the value 0 as default secure value), but so far I do not have clear indication if it will be needed or not.
If you do not find this change problematic, it would be great if it could be applied. Otherwise I will drop it and wait what is going to explode.
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).
It's OK for me adding the case itself. But comment should be reflected.
Let me write in that way.
Thanks. I did some git archeology and found the first mention of this in the following commit in 2011 without much details:
https://src.fedoraproject.org/rpms/libgcrypt/c/16991a5be46cb1617acec215a4e83d0268501b11