From ludo at gnu.org  Fri Feb  5 15:22:40 2021
From: ludo at gnu.org (=?utf-8?Q?Ludovic_Court=C3=A8s?=)
Date: Fri, 05 Feb 2021 15:22:40 +0100
Subject: [gnutls-help] Bug#964284: guile-gnutls: update to use guile 3.0
In-Reply-To: <87blem41jz.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?=
 =?utf-8?Q?s?= message of "Tue, 22 Dec 2020 10:45:04 +0100")
References: <87v9j2204s.fsf@ponder> <877dpymybw.fsf@yucca>
 <87czzm2ehb.fsf@gnu.org> <87lfe83heg.fsf@trouble.defaultvalue.org>
 <87a6uoutgn.fsf@gnu.org> <87blem41jz.fsf@gnu.org>
Message-ID: <87ft2a4mrz.fsf@gnu.org>

Hi all,

Ludovic Court?s <ludo at gnu.org> skribis:

> Where to go from here?  Here are options that come to mind:
>
>   ? Configure Nettle with ?--enable-mini-gmp?.  However, the manual
>     mentions that it?s ?slower? and ?more likely to leak side-channel
>     information? (info "(nettle) Installation").

I tried building GnuTLS against Nettle-with-mini-GMP, but GnuTLS still
adds a dependency on GMP; quoth ?hooks.m4?:

--8<---------------cut here---------------start------------->8---
  if test "$mini_nettle" != no;then
    GMP_CFLAGS=""
    GMP_LIBS=""
  else
    if test x$GMP_LIBS = x; then
	AC_CHECK_LIB(gmp, __gmpz_cmp, [GMP_LIBS="-lgmp"], [AC_MSG_ERROR([[
***
*** gmp was not found.
]])])
    fi
  fi
--8<---------------cut here---------------end--------------->8---

GMP is used by ?GNUTLS/lib/nettle/ecc/eccdata.c? in particular.  That
makes the use of Nettle-with-mini-GMP moot.

The other option is to build GnuTLS with ?--with-nettle-mini? to use a
bundled Nettle containing mini-GMP, but the ?configure? script bails out
anyway if Nettle is not found, making this option unusable AFAICS.  From
?hooks.m4?:

--8<---------------cut here---------------start------------->8---
  PKG_CHECK_MODULES(NETTLE, [nettle >= $NETTLE_MINIMUM], [cryptolib="nettle"], [
AC_MSG_ERROR([[
  ***
  *** Libnettle $NETTLE_MINIMUM was not found.
]])
  ])
--8<---------------cut here---------------end--------------->8---

Adding Nettle to the build environment *and* passing
?--with-nettle-mini? leads to the GMP link error already mentioned:

--8<---------------cut here---------------start------------->8---
/tmp/guix-build-gnutls-3.6.15.drv-0/gnutls-3.6.15/lib/nettle/ecc/eccdata.c:1273: undefined reference to `__gmpz_add_ui'
ld: /tmp/guix-build-gnutls-3.6.15.drv-0/gnutls-3.6.15/lib/nettle/ecc/eccdata.c:1274: undefined reference to `__gmpz_fdiv_q_2exp'
ld: /tmp/guix-build-gnutls-3.6.15.drv-0/gnutls-3.6.15/lib/nettle/ecc/eccdata.c:1299: undefined reference to `__gmpz_add_ui'
[?]
--8<---------------cut here---------------end--------------->8---

(This is all with 3.6.15.)

>   ? Have Guile use mini-GMP; this is not implemented yet.
>
>   ? In Guile-GnuTLS, arrange so that GnuTLS allocations are made through
>     libgc.  Unfortunately, ?gnutls_global_set_mem_functions? was
>     deprecated in GnuTLS 3.3.0 so this doesn?t look like an option.
>
>   ? Build Guile with ?scm_install_gmp_memory_functions = 0?.  This would
>     have a negative impact on the performance of bignum-heavy workloads
>     such as the compiler itself.
>
> I can?t think of a good workaround.  Thoughts?

I?d still appreciate feedback and suggestions.  :-)

Ludo?.


From ludo at gnu.org  Fri Feb  5 16:16:41 2021
From: ludo at gnu.org (=?utf-8?Q?Ludovic_Court=C3=A8s?=)
Date: Fri, 05 Feb 2021 16:16:41 +0100
Subject: [gnutls-help] Bug#964284: guile-gnutls: update to use guile 3.0
In-Reply-To: <87ft2a4mrz.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?=
 =?utf-8?Q?s?= message of "Fri, 05 Feb 2021 15:22:40 +0100")
References: <87v9j2204s.fsf@ponder> <877dpymybw.fsf@yucca>
 <87czzm2ehb.fsf@gnu.org> <87lfe83heg.fsf@trouble.defaultvalue.org>
 <87a6uoutgn.fsf@gnu.org> <87blem41jz.fsf@gnu.org>
 <87ft2a4mrz.fsf@gnu.org>
Message-ID: <87y2g235pi.fsf@gnu.org>

I forgot to mention that a simple workaround (that I?d recommend for
Debian) is to patch Guile >= 2.2.7 (3.0 included) like so:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-patch
Size: 519 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20210205/3084c46a/attachment.bin>
-------------- next part --------------

It slows down bignum-heavy applications, which are rare but include the
compiler itself?.  That?s why I?m also looking at other options.

Ludo?.

? https://lists.gnu.org/archive/html/guile-devel/2020-02/msg00023.html

From elektroniker at elude.in  Mon Feb  8 05:35:52 2021
From: elektroniker at elude.in (elektroniker at elude.in)
Date: Mon, 8 Feb 2021 04:35:52 +0000
Subject: [gnutls-help] (no subject)
Message-ID: <7e024b45-e128-56a2-a2c9-2083f02b629f@elude.in>





From ametzler at bebt.de  Tue Feb  9 08:30:40 2021
From: ametzler at bebt.de (Andreas Metzler)
Date: Tue, 9 Feb 2021 08:30:40 +0100
Subject: [gnutls-help] GnuTLS testsuite error on ppc64 after nettle upgrade
Message-ID: <YCI6IPeYrV+ioaDq@argenau.bebt.de>

Hello,

Upgrading nettle from 3.6 to 3.7 triggers a GnuTLS 3.7.0 testsuite
error on both ppc64 and ppc64el:

(sid_ppc64el-dchroot)ametzler at plummer:~/GNUTLS/gnutls28-3.7.0/b4deb/tests$ ./min
i-record-2
testing aes-cbc
testing aes-cbc-sha256
testing aes-gcm
testing aes-ccm
testing aes-ccm-8
testing null-sha1
testing arcfour-sha1
testing arcfour-md5
testing chacha20-poly1305
testing tls13-chacha20-poly1305
server:330: client: Error: An unexpected TLS packet was received.

Running the same binary dynamically (with LD_LIBRARY_PATH setting) linked
against nettle 3.6 succeeds.

--verbose logs are huge (5-7 MB xz-compressed), I have uploaded them to
https://people.debian.org/~ametzler/tmp/

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 ametzler at bebt.de  Tue Feb  9 13:37:06 2021
From: ametzler at bebt.de (Andreas Metzler)
Date: Tue, 9 Feb 2021 13:37:06 +0100
Subject: [gnutls-help] GnuTLS testsuite error on ppc64 after nettle
 upgrade
In-Reply-To: <YCI6IPeYrV+ioaDq@argenau.bebt.de>
References: <YCI6IPeYrV+ioaDq@argenau.bebt.de>
Message-ID: <YCKB8o8jwldGiZLf@argenau.bebt.de>

On 2021-02-09 Andreas Metzler <ametzler at bebt.de> wrote:
> Hello,

> Upgrading nettle from 3.6 to 3.7 triggers a GnuTLS 3.7.0 testsuite
> error on both ppc64 and ppc64el:

> (sid_ppc64el-dchroot)ametzler at plummer:~/GNUTLS/gnutls28-3.7.0/b4deb/tests$ ./min
[...]
> testing chacha20-poly1305
> testing tls13-chacha20-poly1305
> server:330: client: Error: An unexpected TLS packet was received.

> Running the same binary dynamically (with LD_LIBRARY_PATH setting) linked
> against nettle 3.6 succeeds.

> --verbose logs are huge (5-7 MB xz-compressed), I have uploaded them to
> https://people.debian.org/~ametzler/tmp/

Hello,

I have bisected this[1] in nettle git and found

58a0301437e9beb23130423ff1063a67b6f2b43b
ppc: New assembly for chacha_core4, doing four blocks in parallel.

as first bad commit, the previous one
(58c55046beda976b10ac3ce930696d172e5e5038 Fix a ChangeLog typo.) works.

cu Andreas

[1] twice :-( First try found d56503602134442832e73bc40a657954d3f8db8f
- "Enable fat build by default." so I did a second run with
--enable-fat.
-- 
`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 ametzler at bebt.de  Tue Feb  9 18:12:29 2021
From: ametzler at bebt.de (Andreas Metzler)
Date: Tue, 9 Feb 2021 18:12:29 +0100
Subject: [gnutls-help] GnuTLS testsuite error on ppc64 after nettle
 upgrade
In-Reply-To: <cpf8s7xrzdy.fsf@slartibartfast.lysator.liu.se>
References: <YCI6IPeYrV+ioaDq@argenau.bebt.de>
 <YCKB8o8jwldGiZLf@argenau.bebt.de>
 <cpf8s7xrzdy.fsf@slartibartfast.lysator.liu.se>
Message-ID: <YCLCfbpoU9X890Gv@argenau.bebt.de>

On 2021-02-09 Niels M?ller <nisse at lysator.liu.se> wrote:
> Andreas Metzler <ametzler at bebt.de> writes:

> > I have bisected this[1] in nettle git and found
> >
> > 58a0301437e9beb23130423ff1063a67b6f2b43b
> > ppc: New assembly for chacha_core4, doing four blocks in parallel.

> This is indeed new code in nettle-3.7, and particularly suspect since
> the test fails only on ppc. Do you know what the code path is? Is GnuTLS
> using Nettle's chacha_poly1305_* functions, or is it calling chacha and
> poly1305 functions separately?

Hello,

Afaict from
https://gitlab.com/gnutls/gnutls/-/blob/master/lib/nettle/cipher.c#L815
it does use chacha_poly1305_encrypt/decrypt/update/digest/set_key/set_nonce.

I am not 100% sure. -  I thought I could brute-force this with ltrace, but I
only got it to show direct library calls to gnutls_* but not the
indirect ones (gnutls calling nettle).

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 Feb 10 12:38:46 2021
From: ueno at gnu.org (Daiki Ueno)
Date: Wed, 10 Feb 2021 12:38:46 +0100
Subject: [gnutls-help] GnuTLS testsuite error on ppc64 after nettle
 upgrade
In-Reply-To: <cpfzh0dqa35.fsf@slartibartfast.lysator.liu.se> ("Niels
 =?utf-8?Q?M=C3=B6ller=22's?=
 message of "Tue, 09 Feb 2021 21:07:10 +0100")
References: <YCI6IPeYrV+ioaDq@argenau.bebt.de>
 <YCKB8o8jwldGiZLf@argenau.bebt.de>
 <cpf8s7xrzdy.fsf@slartibartfast.lysator.liu.se>
 <YCLCfbpoU9X890Gv@argenau.bebt.de>
 <cpf4kilrsdc.fsf@slartibartfast.lysator.liu.se>
 <cpfzh0dqa35.fsf@slartibartfast.lysator.liu.se>
Message-ID: <87sg645f09.fsf-ueno@gnu.org>

Hello,

nisse at lysator.liu.se (Niels M?ller) writes:

> nisse at lysator.liu.se (Niels M?ller) writes:
>
>> I would guess that means that we got 209 bytes, including the 16-byte
>> poly1305 authentication tag. Message size is then 209 - 16 = 193 bytes.
>> If the first byte is a TLS packet type, the "length: 192" in the next to
>> last line makes sense if the packet type byte is excluded. Right?

That's exactly the case (under TLS 1.3).  As the protocol uses separate
keys for handshake and application traffic (and the error happens in
sending application data and no post-handshake messages are exchanged),
I guess you can also assume that the same data (all bytes are 0x2) with
different lengths is fed into chacha_crypt* in the failing test case
(mini-record-2).

> I've found one problem, although I don't see that it would cause
> precisely the reported problem. It would result in incorrect
> encrypt/decrypt of the data immediately after a call to chacha_crypt or
> chacha_crypt32 with 129 <= (length % 256) <= 192. In code used only on
> ppc64 with the new altivec chacha code enabled.
>
> Tentative patch below, but I need to extend the tests to get proper test
> coverage of this case.

Thank you so much!  The patch fixes the issue (tested on gcc cfarm).

In the gdb trace, I see nettle_chacha_poly1305_encrypt() is called with
the following length pattern: 128, 63, 128, 64, 192, 1, 192, 2.  I can
try to create a test case if necessary.

Also: thank you Andreas for looking into it.

Regards,
-- 
Daiki Ueno


From ametzler at bebt.de  Wed Feb 10 18:25:52 2021
From: ametzler at bebt.de (Andreas Metzler)
Date: Wed, 10 Feb 2021 18:25:52 +0100
Subject: [gnutls-help] GnuTLS testsuite error on ppc64 after nettle
 upgrade
In-Reply-To: <87sg645f09.fsf-ueno@gnu.org>
References: <YCI6IPeYrV+ioaDq@argenau.bebt.de>
 <YCKB8o8jwldGiZLf@argenau.bebt.de>
 <cpf8s7xrzdy.fsf@slartibartfast.lysator.liu.se>
 <YCLCfbpoU9X890Gv@argenau.bebt.de>
 <cpf4kilrsdc.fsf@slartibartfast.lysator.liu.se>
 <cpfzh0dqa35.fsf@slartibartfast.lysator.liu.se>
 <87sg645f09.fsf-ueno@gnu.org>
Message-ID: <YCQXINJEgoKYzIQP@argenau.bebt.de>

On 2021-02-10 Daiki Ueno <ueno at gnu.org> wrote:
> nisse at lysator.liu.se (Niels M?ller) writes:
[...]
> > Tentative patch below, but I need to extend the tests to get proper test
> > coverage of this case.

> Thank you so much!  The patch fixes the issue (tested on gcc cfarm).

Hello,

Just for completeness sake I can confirm that nettle Git master
64837b2e433e2b99b893683949bad3a99acab38f lets gnutls testsuite succeed
on Debian's ppc64el porter machine.

Thank you very much for fixing this so quickly.

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 ametzler at bebt.de  Sat Feb 20 13:41:30 2021
From: ametzler at bebt.de (Andreas Metzler)
Date: Sat, 20 Feb 2021 13:41:30 +0100
Subject: [gnutls-help] debugging "(gnutls_handshake): No supported cipher
 suites have been found"
Message-ID: <YDEDegndHkTzN7Ss@argenau.bebt.de>

Hello,

looking at my mail server logs I have found 

2021-02-20 12:13:53 TLS error on connection from [...] (gnutls_handshake): No supported cipher suites have been found.

for incoming connections, outgoing connections to the same host succeed
with X=TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256

My host is running Debian/stable (gnutls 3.6.7), I have also tried with
gnutls 3.6.15 or with priorities NORMAL:-VERS-TLS1.3 or NORMAL:%COMPAT.

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 nicolas at babelouest.org  Sun Feb 21 23:39:18 2021
From: nicolas at babelouest.org (Nicolas Mora)
Date: Sun, 21 Feb 2021 17:39:18 -0500
Subject: [gnutls-help] ECDH internal functions and FIPS140-2 mode
Message-ID: <b509afdf-3ecd-db16-d577-4bb94abc3626@babelouest.org>

Hello,

I'd like to use ECDH key agreement with GnuTLS. As far as I can see, 
there is no public function to generate a shared secret with ECC keys.

In lib/nettle/pk.c [1], the ECDH functions are defined if ENABLE_FIPS140 
is defined.

According to thee documentation [2], FIPS140-2 mode is not available 
without adding configure option ?enable-fips140-mode.

In an old message on this ML [3], it was offered these functions to be 
exported in the normal API, but this message wasn't answered, and the 
ecdh functions are still private and available only with FIPS140-2 mode.

I'd like to make a feature request for the ECDH functions to be 
available in the normal API, even in non FIPS140-2 mode. Would it be 
possible in a future version?

Thanks in advance

/Nicolas

[1] https://gitlab.com/gnutls/gnutls/-/blob/master/lib/nettle/pk.c
[2] https://www.gnutls.org/manual/html_node/FIPS140_002d2-mode.html
[3] https://lists.gnupg.org/pipermail/gnutls-help/2019-November/004580.html
-------------- 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/20210221/0bd77641/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/20210221/0bd77641/attachment.sig>

From ueno at gnu.org  Mon Feb 22 10:07:09 2021
From: ueno at gnu.org (Daiki Ueno)
Date: Mon, 22 Feb 2021 10:07:09 +0100
Subject: [gnutls-help] relicensing the core library to "LGPLv3+ or GPLv2+
 dual" ?
Message-ID: <875z2kii82.fsf-ueno@gnu.org>

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?

Regards,
-- 
Daiki Ueno


From ueno at gnu.org  Mon Feb 22 16:10:28 2021
From: ueno at gnu.org (Daiki Ueno)
Date: Mon, 22 Feb 2021 16:10:28 +0100
Subject: [gnutls-help] ECDH internal functions and FIPS140-2 mode
In-Reply-To: <b509afdf-3ecd-db16-d577-4bb94abc3626@babelouest.org> (Nicolas
 Mora's message of "Sun, 21 Feb 2021 17:39:18 -0500")
References: <b509afdf-3ecd-db16-d577-4bb94abc3626@babelouest.org>
Message-ID: <87y2fggmu3.fsf-ueno@gnu.org>

Hello,

Nicolas Mora <nicolas at babelouest.org> writes:

> I'd like to use ECDH key agreement with GnuTLS. As far as I can see,
> there is no public function to generate a shared secret with ECC keys.

I think this is a long wanted feature:
https://gitlab.com/gnutls/gnutls/-/issues/894

> In lib/nettle/pk.c [1], the ECDH functions are defined if
> ENABLE_FIPS140 is defined.
>
> According to thee documentation [2], FIPS140-2 mode is not available
> without adding configure option ?enable-fips140-mode.
>
> In an old message on this ML [3], it was offered these functions to be
> exported in the normal API, but this message wasn't answered, and the
> ecdh functions are still private and available only with FIPS140-2
> mode.
>
> I'd like to make a feature request for the ECDH functions to be
> available in the normal API, even in non FIPS140-2 mode. Would it be
> possible in a future version?

Yes, that would be very useful.  What I am concerned with this is how it
would affect FIPS140-2 validation.  Once they become part of the public
API, we may need to add checks to meet the SP800-56A requirements when
they are called under FIPS140-2 mode.  Having said that, I guess the
implementation of such checks wouldn't be that hard.  Stephan (Cc'ed)
might have some opinion on that.

Regards,
-- 
Daiki Ueno


From ueno at gnu.org  Mon Feb 22 18:22:22 2021
From: ueno at gnu.org (Daiki Ueno)
Date: Mon, 22 Feb 2021 18:22:22 +0100
Subject: [gnutls-help] ECDH internal functions and FIPS140-2 mode
In-Reply-To: <5547cb4217fea73c442b4f3ae7027b16b2cb34d9.camel@chronox.de>
 (Stephan Mueller's message of "Mon, 22 Feb 2021 16:32:12 +0100")
References: <b509afdf-3ecd-db16-d577-4bb94abc3626@babelouest.org>
 <87y2fggmu3.fsf-ueno@gnu.org>
 <5547cb4217fea73c442b4f3ae7027b16b2cb34d9.camel@chronox.de>
Message-ID: <874ki4ggq9.fsf-ueno@gnu.org>

Forwarding this to the list, with Stephan's permission :-)

Stephan Mueller <smueller at chronox.de> writes:

> Am Montag, dem 22.02.2021 um 16:10 +0100 schrieb Daiki Ueno:
>> Hello,
>> 
> Hi Daiki,
>> 
>> Yes, that would be very useful.? What I am concerned with this is how it
>> would affect FIPS140-2 validation.? Once they become part of the public
>> API, we may need to add checks to meet the SP800-56A requirements when
>> they are called under FIPS140-2 mode.? Having said that, I guess the
>> implementation of such checks wouldn't be that hard.? Stephan (Cc'ed)
>> might have some opinion on that.
>
> 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
>
>
> When offering a general (EC)DH API, you also need to make sure that in FIPS
> mode only the approved parameters are allowed:
>
> 	* ECC: NIST curves (when FIPS 186-5 is released, also other curves
> are allowed)
>
> 	* FFC: MODP groups >= 2048 or PQG values generated compliant to
> SP800-56A rev 1. Note, if PQG values other than MODP are used, a full key
> validation of the remote public key must be performed which requires the
> presence of Q!
>
> Ciao
> Stephan
>
>
>> 
>> Regards,
>
>
>
> !DSPAM:6033ce9213789401000011206!


From nicolas at babelouest.org  Wed Feb 24 18:03:17 2021
From: nicolas at babelouest.org (Nicolas Mora)
Date: Wed, 24 Feb 2021 12:03:17 -0500
Subject: [gnutls-help] ECDH internal functions and FIPS140-2 mode
In-Reply-To: <5547cb4217fea73c442b4f3ae7027b16b2cb34d9.camel@chronox.de>
References: <b509afdf-3ecd-db16-d577-4bb94abc3626@babelouest.org>
 <87y2fggmu3.fsf-ueno@gnu.org>
 <5547cb4217fea73c442b4f3ae7027b16b2cb34d9.camel@chronox.de>
Message-ID: <98db6c1c-e6a5-705b-9a30-149605802548@babelouest.org>

Hello Daiki and Stephan, thanks for your feedback!

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

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

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'm very willing to help with that with test cases and help with the 
code if required.

/Nicolas

[1] https://github.com/babelouest/rhonabwy
[2] https://jose.readthedocs.io/en/latest/
[3] https://github.com/babelouest/glewlwyd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_ecdh.c
Type: text/x-csrc
Size: 1982 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20210224/f081ce78/attachment-0001.c>
-------------- next part --------------
==9445== Memcheck, a memory error detector
==9445== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==9445== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==9445== Command: ./test_ecdh
==9445== 
==9445== 
==9445== HEAP SUMMARY:
==9445==     in use at exit: 240 bytes in 10 blocks
==9445==   total heap usage: 1,317 allocs, 1,307 frees, 108,091 bytes allocated
==9445== 
==9445== 32 bytes in 1 blocks are indirectly lost in loss record 1 of 10
==9445==    at 0x483877F: malloc (vg_replace_malloc.c:307)
==9445==    by 0x4FA99A9: __gmp_default_allocate (in /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1)
==9445==    by 0x4FC03D3: __gmpz_realloc (in /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1)
==9445==    by 0x4FB9A98: __gmpz_import (in /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1)
==9445==    by 0x4F5F929: nettle_mpz_set_str_256_u (in /usr/lib/x86_64-linux-gnu/libhogweed.so.6.1)
==9445==    by 0x499867A: wrap_nettle_mpi_scan (mpi.c:146)
==9445==    by 0x48AAB19: _gnutls_mpi_init_scan (mpi.c:122)
==9445==    by 0x48AAE6D: _gnutls_mpi_init_scan_nz (mpi.c:141)
==9445==    by 0x4998177: _gnutls_ecdh_compute_key (pk.c:1981)
==9445==    by 0x10933D: main (test_ecdh.c:24)
==9445== 
==9445== 32 bytes in 1 blocks are indirectly lost in loss record 2 of 10
==9445==    at 0x483877F: malloc (vg_replace_malloc.c:307)
==9445==    by 0x4FA99A9: __gmp_default_allocate (in /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1)
==9445==    by 0x4FC03D3: __gmpz_realloc (in /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1)
==9445==    by 0x4FB9A98: __gmpz_import (in /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1)
==9445==    by 0x4F5F929: nettle_mpz_set_str_256_u (in /usr/lib/x86_64-linux-gnu/libhogweed.so.6.1)
==9445==    by 0x499867A: wrap_nettle_mpi_scan (mpi.c:146)
==9445==    by 0x48AAB19: _gnutls_mpi_init_scan (mpi.c:122)
==9445==    by 0x48AAE6D: _gnutls_mpi_init_scan_nz (mpi.c:141)
==9445==    by 0x4998193: _gnutls_ecdh_compute_key (pk.c:1989)
==9445==    by 0x10933D: main (test_ecdh.c:24)
==9445== 
==9445== 32 bytes in 1 blocks are indirectly lost in loss record 3 of 10
==9445==    at 0x483877F: malloc (vg_replace_malloc.c:307)
==9445==    by 0x4FA99A9: __gmp_default_allocate (in /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1)
==9445==    by 0x4FC03D3: __gmpz_realloc (in /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1)
==9445==    by 0x4FB9A98: __gmpz_import (in /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1)
==9445==    by 0x4F5F929: nettle_mpz_set_str_256_u (in /usr/lib/x86_64-linux-gnu/libhogweed.so.6.1)
==9445==    by 0x499867A: wrap_nettle_mpi_scan (mpi.c:146)
==9445==    by 0x48AAB19: _gnutls_mpi_init_scan (mpi.c:122)
==9445==    by 0x48AAE6D: _gnutls_mpi_init_scan_nz (mpi.c:141)
==9445==    by 0x49981B9: _gnutls_ecdh_compute_key (pk.c:1999)
==9445==    by 0x10933D: main (test_ecdh.c:24)
==9445== 
==9445== 32 bytes in 1 blocks are indirectly lost in loss record 4 of 10
==9445==    at 0x483877F: malloc (vg_replace_malloc.c:307)
==9445==    by 0x4FA99A9: __gmp_default_allocate (in /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1)
==9445==    by 0x4FC03D3: __gmpz_realloc (in /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1)
==9445==    by 0x4FB9A98: __gmpz_import (in /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1)
==9445==    by 0x4F5F929: nettle_mpz_set_str_256_u (in /usr/lib/x86_64-linux-gnu/libhogweed.so.6.1)
==9445==    by 0x499867A: wrap_nettle_mpi_scan (mpi.c:146)
==9445==    by 0x48AAB19: _gnutls_mpi_init_scan (mpi.c:122)
==9445==    by 0x48AAE6D: _gnutls_mpi_init_scan_nz (mpi.c:141)
==9445==    by 0x49981D1: _gnutls_ecdh_compute_key (pk.c:2007)
==9445==    by 0x10933D: main (test_ecdh.c:24)
==9445== 
==9445== 32 bytes in 1 blocks are indirectly lost in loss record 5 of 10
==9445==    at 0x483877F: malloc (vg_replace_malloc.c:307)
==9445==    by 0x4FA99A9: __gmp_default_allocate (in /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1)
==9445==    by 0x4FC03D3: __gmpz_realloc (in /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1)
==9445==    by 0x4FB9A98: __gmpz_import (in /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1)
==9445==    by 0x4F5F929: nettle_mpz_set_str_256_u (in /usr/lib/x86_64-linux-gnu/libhogweed.so.6.1)
==9445==    by 0x499867A: wrap_nettle_mpi_scan (mpi.c:146)
==9445==    by 0x48AAB19: _gnutls_mpi_init_scan (mpi.c:122)
==9445==    by 0x48AAE6D: _gnutls_mpi_init_scan_nz (mpi.c:141)
==9445==    by 0x49981F1: _gnutls_ecdh_compute_key (pk.c:2015)
==9445==    by 0x10933D: main (test_ecdh.c:24)
==9445== 
==9445== 48 (16 direct, 32 indirect) bytes in 1 blocks are definitely lost in loss record 6 of 10
==9445==    at 0x483877F: malloc (vg_replace_malloc.c:307)
==9445==    by 0x4998754: wrap_nettle_mpi_init (mpi.c:79)
==9445==    by 0x48AAB02: _gnutls_mpi_init_scan (mpi.c:117)
==9445==    by 0x48AAE6D: _gnutls_mpi_init_scan_nz (mpi.c:141)
==9445==    by 0x4998177: _gnutls_ecdh_compute_key (pk.c:1981)
==9445==    by 0x10933D: main (test_ecdh.c:24)
==9445== 
==9445== 48 (16 direct, 32 indirect) bytes in 1 blocks are definitely lost in loss record 7 of 10
==9445==    at 0x483877F: malloc (vg_replace_malloc.c:307)
==9445==    by 0x4998754: wrap_nettle_mpi_init (mpi.c:79)
==9445==    by 0x48AAB02: _gnutls_mpi_init_scan (mpi.c:117)
==9445==    by 0x48AAE6D: _gnutls_mpi_init_scan_nz (mpi.c:141)
==9445==    by 0x4998193: _gnutls_ecdh_compute_key (pk.c:1989)
==9445==    by 0x10933D: main (test_ecdh.c:24)
==9445== 
==9445== 48 (16 direct, 32 indirect) bytes in 1 blocks are definitely lost in loss record 8 of 10
==9445==    at 0x483877F: malloc (vg_replace_malloc.c:307)
==9445==    by 0x4998754: wrap_nettle_mpi_init (mpi.c:79)
==9445==    by 0x48AAB02: _gnutls_mpi_init_scan (mpi.c:117)
==9445==    by 0x48AAE6D: _gnutls_mpi_init_scan_nz (mpi.c:141)
==9445==    by 0x49981B9: _gnutls_ecdh_compute_key (pk.c:1999)
==9445==    by 0x10933D: main (test_ecdh.c:24)
==9445== 
==9445== 48 (16 direct, 32 indirect) bytes in 1 blocks are definitely lost in loss record 9 of 10
==9445==    at 0x483877F: malloc (vg_replace_malloc.c:307)
==9445==    by 0x4998754: wrap_nettle_mpi_init (mpi.c:79)
==9445==    by 0x48AAB02: _gnutls_mpi_init_scan (mpi.c:117)
==9445==    by 0x48AAE6D: _gnutls_mpi_init_scan_nz (mpi.c:141)
==9445==    by 0x49981D1: _gnutls_ecdh_compute_key (pk.c:2007)
==9445==    by 0x10933D: main (test_ecdh.c:24)
==9445== 
==9445== 48 (16 direct, 32 indirect) bytes in 1 blocks are definitely lost in loss record 10 of 10
==9445==    at 0x483877F: malloc (vg_replace_malloc.c:307)
==9445==    by 0x4998754: wrap_nettle_mpi_init (mpi.c:79)
==9445==    by 0x48AAB02: _gnutls_mpi_init_scan (mpi.c:117)
==9445==    by 0x48AAE6D: _gnutls_mpi_init_scan_nz (mpi.c:141)
==9445==    by 0x49981F1: _gnutls_ecdh_compute_key (pk.c:2015)
==9445==    by 0x10933D: main (test_ecdh.c:24)
==9445== 
==9445== LEAK SUMMARY:
==9445==    definitely lost: 80 bytes in 5 blocks
==9445==    indirectly lost: 160 bytes in 5 blocks
==9445==      possibly lost: 0 bytes in 0 blocks
==9445==    still reachable: 0 bytes in 0 blocks
==9445==         suppressed: 0 bytes in 0 blocks
==9445== 
==9445== For lists of detected and suppressed errors, rerun with: -s
==9445== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 0 from 0)
-------------- 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/20210224/f081ce78/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/20210224/f081ce78/attachment-0001.sig>

From ueno at gnu.org  Thu Feb 25 06:54:09 2021
From: ueno at gnu.org (Daiki Ueno)
Date: Thu, 25 Feb 2021 06:54:09 +0100
Subject: [gnutls-help] ECDH internal functions and FIPS140-2 mode
In-Reply-To: <98db6c1c-e6a5-705b-9a30-149605802548@babelouest.org> (Nicolas
 Mora's message of "Wed, 24 Feb 2021 12:03:17 -0500")
References: <b509afdf-3ecd-db16-d577-4bb94abc3626@babelouest.org>
 <87y2fggmu3.fsf-ueno@gnu.org>
 <5547cb4217fea73c442b4f3ae7027b16b2cb34d9.camel@chronox.de>
 <98db6c1c-e6a5-705b-9a30-149605802548@babelouest.org>
Message-ID: <87k0qwpu9q.fsf-ueno@gnu.org>

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