Suggested crypto libs for Diffie-Hellman and Eliptic Curve Diffie-Hellman

[Joseph Sutton]

On 23/11/23 10:05 am, Stefan Metzmacher via samba-technical wrote:
> Am 22.11.23 um 21:26 schrieb Andrew Bartlett via samba-technical:
>> On Wed, 2023-11-22 at 12:07 +0100, Andreas Schneider wrote:
>>> On Thursday, 16 November 2023 07:08:59 CET Andrew Bartlett via samba-
>>> technical
>>> wrote:
>>>> For Group Managed service accounts, which we are working on, for
>>>> reasons around RODCs and a few other things, Microsoft has decided
>>>> to
>>>> internally use a key-agreement between a 'root key' and a 'service
>>>> key', both held in AD.
>>>>
>>>> The password comes, as I understand it, from the key agreement
>>>> derived
>>>> out of a Diffie-Hellman or Eliptic Curve Diffie-Hellman exchanges.
>>>>
>>>> This is all in MS-GKDI, referenced from
>>>> https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/9cd2fc
>>>>
>>>> 5e-7305-4fb8-b233-2a60bc3eec68
>>>>
>>>> I just wanted to check if there are particularly cryptographic
>>>> libraries we should consider for this work.
>>>>
>>>> In the past we have looked to libnettle when gnutls didn't provide
>>>> the
>>>> functions we wanted, but that was backed out fairly fast as another
>>>> method was found (
>>>> https://bugzilla.samba.org/show_bug.cgi?id=13276
>>>>   0784
>>>> 4a9a13506b4ca9181cfde05d9e4170208f88).
>>>>
>>>> Even so, for this case is libnettle still the best first place to
>>>> look?
>>>
>>> If something is missing in GnuTLS you need, open tickets at GnuTLS.
>>> They are
>>> fairly quick implementing the stuff we need.
>>
>> The main issue is the time to get the changes into the distributions so
>> we can get them into master, but yes, it has been an awesome
>> collaboration.
>>
>>> They implemented all the features we needed for Samba so far.
>>> Example:
>>>
>>> https://gitlab.com/gnutls/gnutls/-/merge_requests/1611/
>>>
>>>
>>> Also AES-GMAC, AES-CCM, AES-CBF8 ...
>>>
>>> They also fixed performance issues we discovered ...
>>
>> Thanks.  It looks like we won't need the DH stuff, thankfully, but we
>> might need an alternate key derivation function: SP800-108.
> 
> Isn't that what have in smb2_key_derivation()?
> 
> metze
> 
> 

Thanks for pointing out that function. Yes, it seems to do the right 
thing (once I changed the algorithm from the hardcoded SHA256).

Regards,
Joseph