From nicolas at babelouest.org  Mon Mar  1 02:17:24 2021
From: nicolas at babelouest.org (Nicolas Mora)
Date: Sun, 28 Feb 2021 20:17:24 -0500
Subject: [gnutls-help] ECDH internal functions and FIPS140-2 mode
In-Reply-To: <87k0qwpu9q.fsf-ueno@gnu.org>
References: <b509afdf-3ecd-db16-d577-4bb94abc3626@babelouest.org>
 <87y2fggmu3.fsf-ueno@gnu.org>
 <5547cb4217fea73c442b4f3ae7027b16b2cb34d9.camel@chronox.de>
 <98db6c1c-e6a5-705b-9a30-149605802548@babelouest.org>
 <87k0qwpu9q.fsf-ueno@gnu.org>
Message-ID: <ecf92ff0-cee4-9a12-ea7a-b03013d61d77@babelouest.org>

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>

From ametzler at bebt.de  Sun Mar  7 18:02:19 2021
From: ametzler at bebt.de (Andreas Metzler)
Date: Sun, 7 Mar 2021 18:02:19 +0100
Subject: [gnutls-help] relicensing the core library to "LGPLv3+ or
 GPLv2+ dual" ?
In-Reply-To: <875z2kii82.fsf-ueno@gnu.org>
References: <875z2kii82.fsf-ueno@gnu.org>
Message-ID: <YEUHG0pEUfEvCYnZ@argenau.bebt.de>

On 2021-02-22 Daiki Ueno <ueno at gnu.org> wrote:
> For now the LICENSE file says:

>   Since GnuTLS version 3.1.10, the core library is released under
>   the GNU Lesser General Public License (LGPL) version 2.1 or later
>   (see doc/COPYING.LESSER for the license terms).

> but later on:

>   Note, however, that the nettle and the gmp libraries which are
>   GnuTLS dependencies, they are distributed under a LGPLv3+ or GPLv2+ dual
>   license. As such binaries linking to them need to adhere to either LGPLv3+
>   or the GPLv2+ license.

> I'm wondering if it would cause any problem to explicitly license the
> core library as a LGPLv3+ or GPLv2+ dual license.  Does anyone know of
> any use-case where LGPLv2 is required?
[...]


Hello,

I have forwarded this to debian-legal, trying to get some feedback,
Walter Landry replied with:
| I think this is OK for Debian.  The only tricky clause is Section 4 of
| LGPL 3.  GMP would already make this apply to all of the programs that
| use GnuTLS.  I think the difference, if any, would be what exactly is
| required if someone wanted to modify GnuTLS.  That is not an issue for
| Debian, since Debian releases source code for everything.
| [disclaimer]

Personally I would prefer if yu did not change the license, for the
simple reason that (LGPLv3+ or GPLv2+ dual license) is a lot more
complicated than LGPLv2.1+#

cu Andreas



From ametzler at bebt.de  Sun Mar  7 18:07:17 2021
From: ametzler at bebt.de (Andreas Metzler)
Date: Sun, 7 Mar 2021 18:07:17 +0100
Subject: [gnutls-help] 3.7.1 release?
Message-ID: <YEUIRXYmEWbo8i4w@argenau.bebt.de>

Hello,

I would really appreciate a bugfix release, so I can try to get it into
Debian/soontobereleased, where the hard-freeze is only a couple of days
away.

FWIW I have just uploaded a git snapshot to experimental without
triggereing any unexpected build-errors.

TIA, cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From ueno at gnu.org  Wed Mar 10 14:06:24 2021
From: ueno at gnu.org (Daiki Ueno)
Date: Wed, 10 Mar 2021 14:06:24 +0100
Subject: [gnutls-help] gnutls 3.7.1
Message-ID: <87blbryx7z.fsf-ueno@gnu.org>

Hello,
 We've just released gnutls 3.7.1. This is a bug fix and security
release on the 3.7.x branch.

We'd like to thank everyone who contributed in this release:
Airtower, Andreas Metzler, Daiki Ueno, Dmitriy Tsvettsikh, Dosenpfand,
Evgeny Grin, Fiona Klute, JonasZhou, Martin Storsjo, Norbert Pocs,
Ondrej Moris, Sadie Powell, Stanislav Zidek, Stefan Berger,
Steffen Jaeckel, Tom Carroll, and Tom Vrancken.

The detailed list of changes follows:

* Version 3.7.1 (released 2021-03-10)

** libgnutls: Fixed potential use-after-free in sending "key_share"
   and "pre_shared_key" extensions. When sending those extensions, the
   client may dereference a pointer no longer valid after
   realloc. This happens only when the client sends a large Client
   Hello message, e.g., when HRR is sent in a resumed session
   previously negotiated large FFDHE parameters, because the initial
   allocation of the buffer is large enough without having to call
   realloc (#1151).  [GNUTLS-SA-2021-03-10, CVSS: low]

** libgnutls: Fixed a regression in handling duplicated certs in a
   chain (#1131).

** libgnutls: Fixed sending of session ID in TLS 1.3 middlebox
   compatibiltiy mode. In that mode the client shall always send a
   non-zero session ID to make the handshake resemble the TLS 1.2
   resumption; this was not true in the previous versions (#1074).

** libgnutls: W32 performance improvement with a new sendmsg()-like
   transport implementation (!1377).

** libgnutls: Removed dependency on the external 'fipscheck' package,
   when compiled with --enable-fips140-mode (#1101).

** libgnutls: Added padlock acceleration for AES-192-CBC (#1004).

** API and ABI modifications:
No changes since last version.

Getting the Software
====================

GnuTLS may be downloaded directly from <
ftp://ftp.gnutls.org/gcrypt/gnutls/>;.
A list of GnuTLS mirrors can be found at <
http://www.gnutls.org/download.html>

Here are the XZ compressed sources:

  https://www.gnupg.org/ftp/gcrypt/gnutls/v3.7/gnutls-3.7.1.tar.xz

Here are OpenPGP detached signatures signed using key 0x462225C3B46F34879FC8496CD605848ED7E69871:

  https://www.gnupg.org/ftp/gcrypt/gnutls/v3.7/gnutls-3.7.1.tar.xz.sig

Note that it has been signed with my openpgp key:
pub   rsa4096 2009-07-23 [SC] [expires: 2023-09-25]
      462225C3B46F34879FC8496CD605848ED7E69871
uid           [ultimate] Daiki Ueno <ueno at unixuser.org>
uid           [ultimate] Daiki Ueno <ueno at gnu.org>
sub   rsa4096 2010-02-04 [E]

Regards,
-- 
Daiki Ueno

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20210310/7cfd1ee2/attachment-0001.sig>

From elektroniker at elude.in  Thu Mar 11 14:26:03 2021
From: elektroniker at elude.in (elektroniker at elude.in)
Date: Thu, 11 Mar 2021 13:26:03 +0000
Subject: [gnutls-help] (no subject)
Message-ID: <5b1990a9-e0c5-5bce-93e5-da583ad3d520@elude.in>





From nicolas at babelouest.org  Fri Mar 19 12:44:38 2021
From: nicolas at babelouest.org (Nicolas Mora)
Date: Fri, 19 Mar 2021 07:44:38 -0400
Subject: [gnutls-help] ECDH internal functions and FIPS140-2 mode
In-Reply-To: <ecf92ff0-cee4-9a12-ea7a-b03013d61d77@babelouest.org>
References: <b509afdf-3ecd-db16-d577-4bb94abc3626@babelouest.org>
 <87y2fggmu3.fsf-ueno@gnu.org>
 <5547cb4217fea73c442b4f3ae7027b16b2cb34d9.camel@chronox.de>
 <98db6c1c-e6a5-705b-9a30-149605802548@babelouest.org>
 <87k0qwpu9q.fsf-ueno@gnu.org>
 <ecf92ff0-cee4-9a12-ea7a-b03013d61d77@babelouest.org>
Message-ID: <c561b94b-261e-39fa-3395-ea015348c195@babelouest.org>

Hello, friendly ping for my pull request [1]

Is it possible to get a code review for it?

The PR is to make the ecdh-es function available using gnutls_privkey_t 
and gnutls_pubkey_t instead of raw keys data.

Thanks in advance!

/Nicolas

[1] https://gitlab.com/gnutls/gnutls/-/merge_requests/1395


From ueno at gnu.org  Fri Mar 19 17:00:21 2021
From: ueno at gnu.org (Daiki Ueno)
Date: Fri, 19 Mar 2021 17:00:21 +0100
Subject: [gnutls-help] ECDH internal functions and FIPS140-2 mode
In-Reply-To: <c561b94b-261e-39fa-3395-ea015348c195@babelouest.org> (Nicolas
 Mora's message of "Fri, 19 Mar 2021 07:44:38 -0400")
References: <b509afdf-3ecd-db16-d577-4bb94abc3626@babelouest.org>
 <87y2fggmu3.fsf-ueno@gnu.org>
 <5547cb4217fea73c442b4f3ae7027b16b2cb34d9.camel@chronox.de>
 <98db6c1c-e6a5-705b-9a30-149605802548@babelouest.org>
 <87k0qwpu9q.fsf-ueno@gnu.org>
 <ecf92ff0-cee4-9a12-ea7a-b03013d61d77@babelouest.org>
 <c561b94b-261e-39fa-3395-ea015348c195@babelouest.org>
Message-ID: <87czvv9lre.fsf-ueno@gnu.org>

Hello Nicolas,

Nicolas Mora <nicolas at babelouest.org> writes:

> Hello, friendly ping for my pull request [1]
>
> Is it possible to get a code review for it?
>
> The PR is to make the ecdh-es function available using
> gnutls_privkey_t and gnutls_pubkey_t instead of raw keys data.
>
> Thanks in advance!
>
> /Nicolas
>
> [1] https://gitlab.com/gnutls/gnutls/-/merge_requests/1395

Sorry for the delay; I've added some comments (not a complete review
though).

Regards,
-- 
Daiki Ueno


From nicolas at babelouest.org  Sat Mar 20 19:42:17 2021
From: nicolas at babelouest.org (Nicolas Mora)
Date: Sat, 20 Mar 2021 14:42:17 -0400
Subject: [gnutls-help] ECDH internal functions and FIPS140-2 mode
In-Reply-To: <87czvv9lre.fsf-ueno@gnu.org>
References: <b509afdf-3ecd-db16-d577-4bb94abc3626@babelouest.org>
 <87y2fggmu3.fsf-ueno@gnu.org>
 <5547cb4217fea73c442b4f3ae7027b16b2cb34d9.camel@chronox.de>
 <98db6c1c-e6a5-705b-9a30-149605802548@babelouest.org>
 <87k0qwpu9q.fsf-ueno@gnu.org>
 <ecf92ff0-cee4-9a12-ea7a-b03013d61d77@babelouest.org>
 <c561b94b-261e-39fa-3395-ea015348c195@babelouest.org>
 <87czvv9lre.fsf-ueno@gnu.org>
Message-ID: <1499f3b3-3235-35e4-acd8-5b571851d00a@babelouest.org>

Hello Daiki,

Le 2021-03-19 ? 12 h 00, Daiki Ueno a ?crit?:
> 
> Sorry for the delay; I've added some comments (not a complete review
> though).
> 
Thanks for the first review. I've fixed some of the comments and added 
my answers in two of them.

I'll try and use _gnutls_dh_compute_key to see if I have an expected 
result with Curve25519/Curve448 keys.

/Nicolas

https://gitlab.com/gnutls/gnutls/-/merge_requests/1395
-------------- 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/20210320/b5a13420/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/20210320/b5a13420/attachment.sig>

From nicolas at babelouest.org  Sun Mar 21 01:23:08 2021
From: nicolas at babelouest.org (Nicolas Mora)
Date: Sat, 20 Mar 2021 20:23:08 -0400
Subject: [gnutls-help] ECDH internal functions and FIPS140-2 mode
In-Reply-To: <1499f3b3-3235-35e4-acd8-5b571851d00a@babelouest.org>
References: <b509afdf-3ecd-db16-d577-4bb94abc3626@babelouest.org>
 <87y2fggmu3.fsf-ueno@gnu.org>
 <5547cb4217fea73c442b4f3ae7027b16b2cb34d9.camel@chronox.de>
 <98db6c1c-e6a5-705b-9a30-149605802548@babelouest.org>
 <87k0qwpu9q.fsf-ueno@gnu.org>
 <ecf92ff0-cee4-9a12-ea7a-b03013d61d77@babelouest.org>
 <c561b94b-261e-39fa-3395-ea015348c195@babelouest.org>
 <87czvv9lre.fsf-ueno@gnu.org>
 <1499f3b3-3235-35e4-acd8-5b571851d00a@babelouest.org>
Message-ID: <e6cc0932-f92c-fb73-5b16-6366144adb58@babelouest.org>

Hello,

Le 2021-03-20 ? 14 h 42, Nicolas Mora a ?crit?:
> 
> I'll try and use _gnutls_dh_compute_key to see if I have an expected 
> result with Curve25519/Curve448 keys.
> 

I'm having problems implementing ecdh-es with Curve25519/Curve448.

- If I use an ed25519 key pair to compute, _gnutls_dh_compute_key 
returns -55
- If I use an x25519 key pair to compute, I can't import the key using 
gnutls_pubkey_import/gnutls_privkey_import_x509

Is it possible at this time to calculate a key agreement with these curves?

I have a working prototype in rhonabwy [1] that uses Nettle's functions 
curve25519_mul/curve448_mul. In this case I expect a X25519 or X448 key 
pair.

/Nicolas

[1] https://github.com/babelouest/rhonabwy/blob/master/src/jwe.c#L226
-------------- 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/20210320/5828ed24/attachment-0001.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/20210320/5828ed24/attachment-0001.sig>