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

[Daiki Ueno]

Nicolas Mora <nicolas at babelouest.org> writes:

> I'll describe my context to explain my needs with ECDH.
>
> I'm the author of a library called Rhonabwy [1], this library
> implements JOSE standards [2], in C, using GnuTLS to implement all
> cryptographic routines.
>
> This library is used in my SSO Server glewlwyd [3] to implement signed
> and/or encrypted requests and response between parties.
>
> In my prototype, the ECDH-ES key management works using
> _gnutls_ecdh_compute_key (I only need this function).
>
> There are 2 feedbacks though:
> 1- I have a memory leak in the _gnutls_ecdh_compute_key function
> I've attached a sample code to reproduce the problem and the valgrind output

I believe this should be fixed in:
https://gitlab.com/gnutls/gnutls/-/merge_requests/1380
which is not part of any release yet.

> 2- The input paramters for the _gnutls_ecdh_compute_key functions are
> gnutls_datum_t of exported values from the ECC keys. I think a public
> function would rather have gnutls_privkey_t, gnutls_pubkey_t and the
> gnutls_datum_t *Z output

That sounds reasonable.

> Le 2021-02-22 à 10 h 32, Stephan Mueller a écrit :
>
>> 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
>> 
> In my opinion, I'd rather have an official API that offers (EC)DH
> operation as described in my point 2- above, with of course, added
> checks to make sure the call is valid

I second that the option would be most desirable.  FWIW I also have an
use-case that is to add a GnuTLS backend to libsecret, which requires DH
key exchange on the wire (I'm trying to get rid of it[1], though it will
be there for a while for compatibility reasons).

> I'm very willing to help with that with test cases and help with the
> code if required.

Sure, if you come up with an MR, that would be greatly appreciated.

Regards,

Footnotes:
[1]  https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/33

-- 
Daiki Ueno