Nicolas Mora <[email protected]> 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 _______________________________________________ Gnutls-help mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnutls-help
