[gnutls-help] ECDH internal functions and FIPS140-2 mode

[Daiki Ueno]

Forwarding this to the list, with Stephan's permission :-)

Stephan Mueller <smueller at chronox.de> 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!