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

[Nicolas Mora]

Hello,

Le 2021-02-25 à 00 h 54, Daiki Ueno a écrit :
>>
>> 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.
> 
Indeed, thanks!

> 
>> 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.
> 
So I have created an MR for one of the use case: ecdh keys computation [1].

So far this MR only adds one function to generate a shared secret 
between 2 ecdsa keys.

But after looking at it, it might be extended to other key types, such 
as DH, or even X25519/X448.

But if I'm right, it's not possible yet to generate DH, X25519 or X448 
private keys. gnutls_privkey_generate return -50 when used with 
GNUTLS_PK_ECDH_X25519 or GNUTLS_PK_DH.

I don't see a GNUTLS_PK_ECDH_X448 nor GNUTLS_ECC_CURVE_X448 to calculate 
the curve length, nor GNUTLS_ECC_CURVE_DH, even if there is a GNUTLS_PK_DH.

[DH]
- Would it be a good idea to use _gnutls_dh_generate_key to improve 
gnutls_privkey_generate?

[ECDH]
- I've "released" _gnutls_ecdh_generate_key from ENABLE_FIPS140 but I 
don't use it, is this function different from what 
gnutls_privkey_generate returns when used with GNUTLS_PK_ECDSA? Or 
should it stay hidden in FIPS140 mode?

[X25519]
 From what I understand, an X25519 key is an EDDSA private key, but the 
'x' parameter is calculated using k*G. Nettle seems to has the routines 
required for X25519 key computation [2]
- If my above assumptions are right, one can improve 
gnutls_privkey_generate to generate X25519/X448 private keys

[General]
If other curve types are allowed for gnutls_*_compute_key, I'd go with 
only one function gnutls_ec_compute_key that would have the same 
parameters as gnutls_ecdh_compute_key but would use the correct key 
computation depending on the curve type. What do you think?

It's my first contribution to GnuTLS so I may be very wrong with my 
assumptions and suggestions, I'm open to feedbacks.

/Nicolas

[1] https://gitlab.com/gnutls/gnutls/-/merge_requests/1395
[2] 
https://www.lysator.liu.se/~nisse/nettle/nettle.html#Curve-25519-and-Curve-448
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xFE82139440BD22B9.asc
Type: application/pgp-keys
Size: 3066 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20210228/88466e29/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20210228/88466e29/attachment.sig>