Forwarding this to the list, with Stephan's permission :-) Stephan Mueller <[email protected]> writes:
> Am Montag, dem 22.02.2021 um 16:10 +0100 schrieb Daiki Ueno: >> Hello, >> > Hi Daiki, >> >> Yes, that would be very useful. What I am concerned with this is how it >> would affect FIPS140-2 validation. Once they become part of the public >> API, we may need to add checks to meet the SP800-56A requirements when >> they are called under FIPS140-2 mode. Having said that, I guess the >> implementation of such checks wouldn't be that hard. Stephan (Cc'ed) >> might have some opinion on that. > > The impact on FIPS is as follows: > > - If the newly conceived ECDH API only available in non-FIPS mode, we have no > impact. > > - If the newly conceived ECDH API is only meant to be an "internal" API that > is not supposed to be used by normal users, we are fine. > > - If the newly conceived API is to be used as a truly normal API that offers > generic (EC)DH operation, the following recently added checks must be invoked > by this API: > > * the received remote public key must be validated > > * during local key pair generation, the key pair must be validated > > * after generating the shared secret, it must be validated > > > When offering a general (EC)DH API, you also need to make sure that in FIPS > mode only the approved parameters are allowed: > > * ECC: NIST curves (when FIPS 186-5 is released, also other curves > are allowed) > > * FFC: MODP groups >= 2048 or PQG values generated compliant to > SP800-56A rev 1. Note, if PQG values other than MODP are used, a full key > validation of the remote public key must be performed which requires the > presence of Q! > > Ciao > Stephan > > >> >> Regards, > > > > !DSPAM:6033ce9213789401000011206! _______________________________________________ Gnutls-help mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnutls-help
