From ueno at unixuser.org  Thu Aug 20 09:32:41 2009
From: ueno at unixuser.org (Daiki Ueno)
Date: Thu, 20 Aug 2009 16:32:41 +0900
Subject: memleak (Re: GnuTLS 2.9.3)
In-Reply-To: <edd1458f-9bfd-4282-9aa6-22d15d61aabe@broken.deisui.org> (Daiki
	Ueno's message of "Thu, 20 Aug 2009 10:33:00 +0900")
References: <87tz034hkv.fsf@mocca.josefsson.org>
	<edd1458f-9bfd-4282-9aa6-22d15d61aabe@broken.deisui.org>
Message-ID: <7c32656e-ab95-4acf-970c-b1b73adf9afb_-_@broken.deisui.org>

>>>>> In <edd1458f-9bfd-4282-9aa6-22d15d61aabe at broken.deisui.org> 
>>>>>	Daiki Ueno <ueno at unixuser.org> wrote:
> Now I run make check and found several memleaks.  One is in
> cdk_keydb_get_pk, and others are in tests (including session ticket
> test...sorry).

...and yet another one is in libgcrypt.  It seems that dsa_generate_ext
does not release the factors array after copying its elements to modern
r_extrainfo.

It can be reproduced with:

$ valgrind --leak-check=full ./cve-2009-1416

in gnutls/tests/.

Here is a fix:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: memleak.diff
Type: text/x-diff
Size: 407 bytes
Desc: not available
URL: </pipermail/attachments/20090820/32b7a49d/attachment.diff>
-------------- next part --------------

Regards,
-- 
Daiki Ueno

From wk at gnupg.org  Fri Aug 21 10:22:13 2009
From: wk at gnupg.org (Werner Koch)
Date: Fri, 21 Aug 2009 10:22:13 +0200
Subject: memleak (Re: GnuTLS 2.9.3)
In-Reply-To: <7c32656e-ab95-4acf-970c-b1b73adf9afb_-_@broken.deisui.org>
	(Daiki Ueno's message of "Thu, 20 Aug 2009 16:32:41 +0900")
References: <87tz034hkv.fsf@mocca.josefsson.org>
	<edd1458f-9bfd-4282-9aa6-22d15d61aabe@broken.deisui.org>
	<7c32656e-ab95-4acf-970c-b1b73adf9afb_-_@broken.deisui.org>
Message-ID: <87ljldwp8q.fsf@wheatstone.g10code.de>

On Thu, 20 Aug 2009 09:32, ueno at unixuser.org said:

> +          gcry_free (*retfactors);
>            *retfactors = NULL;

Yeah.  Pretty obvious.  I fixed in in trunk and 1.4



Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.



From ueno at unixuser.org  Tue Aug 25 01:15:30 2009
From: ueno at unixuser.org (Daiki Ueno)
Date: Tue, 25 Aug 2009 08:15:30 +0900
Subject: [PATCH] OAEP support
In-Reply-To: <87ab3prmgk.fsf@broken.deisui.org> (Daiki Ueno's message of "Wed, 
	01 Jul 2009 14:39:23 +0900")
References: <87iqiecr7y.fsf@broken.deisui.org>
	<87zlbqc8ny.fsf@wheatstone.g10code.de>
	<87ab3prmgk.fsf@broken.deisui.org>
Message-ID: <05ff195c-5571-4bd4-bbf1-8737672bbe0c@broken.deisui.org>

Hi,

The attached is the current version of the OAEP patch, reflecting your
suggestion for the interface.  Since I think the patch still lacks
polish, further comments and suggestions are appreciated.

>>>>> In <87ab3prmgk.fsf at broken.deisui.org> 
>>>>>	Daiki Ueno <ueno at unixuser.org> wrote:
> > I would like to keep the flags list a real flags list without
> > parameters.  Would anything speak against:

> >    (data
> >      (flags oaep)
> >      (hash sha1)
> >      (label "test")
> >      (value #11223344556677889900AA#))

> > I can do this change if you agree.

Done.  I renamed "hash" to "hash-algo" since "hash" is used in different
meaning.  The current interface is as follows:

* gcry_pk_encrypt takes the following sexp:

(data
  (flags oaep)
  (hash-algo sha1)
  (label "test")
  (value #11223344556677889900AA#))

and returns:

(enc-val (rsa ...))

* gcry_pk_decrypt takes the following sexp:

(enc-val
  (flags oaep unpad)
  (hash-algo sha1)
  (label "test")
  (rsa ...))

and returns:

(data (value ...))

* Both functions do padding internally.  Note that "unpad" in flags,
which indicates the output plaintext is un-padded, while the library
currently do not handle un-padding.

* Q: Can I implement PSS similarly?  RFC3447 insists that, there is a
patent pending by the University of California, but they promises(?)
that they will freely license confirming implementation, once PSS is
standardised.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: oaep-2009-08-25.diff
Type: text/x-diff
Size: 27057 bytes
Desc: not available
URL: </pipermail/attachments/20090825/de280301/attachment-0001.diff>
-------------- next part --------------

Regards,
-- 
Daiki Ueno

From ueno at unixuser.org  Tue Aug 25 14:34:49 2009
From: ueno at unixuser.org (Daiki Ueno)
Date: Tue, 25 Aug 2009 21:34:49 +0900
Subject: ECC cipher suites
Message-ID: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org>

Hello,

I looked at the feature comparison table of TLS libraries and noticed
that GnuTLS still lacks ECC support:
http://www.gnu.org/software/gnutls/comparison.html

Is anyone working on this?  Otherwise, I would like to give it a try[1].

After a quick search on Gmane, the primary (technical) reason seems that
there is no way to compute ECDH with libgcrypt.  If so, how about simply
exporting the EC version of powm and curve selection API[2]?

Anyway, would it make sense?  Comments are appreciated.

Footnotes: 
[1] I recently got my paperwork done for both GnuTLS/libgcrypt, and I am
seeking for next interesting project.

[2] I have first considered a generic key-agreement interface in
libgcrypt, but I now think that it's too much - currently only DH
variants are used in practice.

Regards,
-- 
Daiki Ueno


From wk at gnupg.org  Tue Aug 25 17:15:10 2009
From: wk at gnupg.org (Werner Koch)
Date: Tue, 25 Aug 2009 17:15:10 +0200
Subject: ECC cipher suites
In-Reply-To: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org> (Daiki
	Ueno's message of "Tue, 25 Aug 2009 21:34:49 +0900")
References: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org>
Message-ID: <87eir07wn5.fsf@vigenere.g10code.de>

On Tue, 25 Aug 2009 14:34, ueno at unixuser.org said:

> After a quick search on Gmane, the primary (technical) reason seems that
> there is no way to compute ECDH with libgcrypt.  If so, how about simply

We need this (or a variant) for OpenPGP as well, by Sergi Blanch i Torne,
(sergi at calcurco dot org) is working on that.

> exporting the EC version of powm and curve selection API[2]?

I am not sure whether whether the current API is okay, thus I hesitate
to publish it.

> Anyway, would it make sense?  Comments are appreciated.

Yes.  There is the potential patent problem of course.  FWIW, RedHat
removed all ECC code from Lobgcrypt.

> [1] I recently got my paperwork done for both GnuTLS/libgcrypt, and I am
> seeking for next interesting project.

I noticed :-)

> [2] I have first considered a generic key-agreement interface in
> libgcrypt, but I now think that it's too much - currently only DH
> variants are used in practice.

I also though of that when I wrote an ssh library but came to the
conclusion that we need to exchnage too much data in a very portable
way.  In the end such an abstract interface would be too complex.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.



From simon at josefsson.org  Wed Aug 26 00:24:43 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 26 Aug 2009 00:24:43 +0200
Subject: ECC cipher suites
In-Reply-To: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org> (Daiki
	Ueno's message of "Tue, 25 Aug 2009 21:34:49 +0900")
References: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org>
Message-ID: <87eiqzedlg.fsf@mocca.josefsson.org>

Daiki Ueno <ueno at unixuser.org> writes:

> Hello,
>
> I looked at the feature comparison table of TLS libraries and noticed
> that GnuTLS still lacks ECC support:
> http://www.gnu.org/software/gnutls/comparison.html
>
> Is anyone working on this?  Otherwise, I would like to give it a try[1].

Nobody is working on it, but there are patent issues with ECC that has
to be resolved.  To avoid wasting time, we may want to approach the FSF
and the SFLC first to get a better understanding of what's involved here
(I've been deferring this since nobody has expressed interest in ECC).

> [1] I recently got my paperwork done for both GnuTLS/libgcrypt, and I am
> seeking for next interesting project.

Finishing the TLS 1.2 support and adding the new cipher suites is a
high-priority task and it shouldn't be too difficult since there are TLS
1.2 test servers out there to test with.

/Simon


From ueno at unixuser.org  Thu Aug 27 13:29:18 2009
From: ueno at unixuser.org (Daiki Ueno)
Date: Thu, 27 Aug 2009 20:29:18 +0900
Subject: ECC cipher suites
In-Reply-To: <87eiqzedlg.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Wed, 26 Aug 2009 00:24:43 +0200")
References: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org>
	<87eiqzedlg.fsf@mocca.josefsson.org>
Message-ID: <71160cd9-7d90-48d5-9af0-0ee7404f2bc7@broken.deisui.org>

>>>>> In <87eiqzedlg.fsf at mocca.josefsson.org> 
>>>>>	Simon Josefsson <simon at josefsson.org> wrote:
> > I looked at the feature comparison table of TLS libraries and noticed
> > that GnuTLS still lacks ECC support:
> > http://www.gnu.org/software/gnutls/comparison.html
> >
> > Is anyone working on this?  Otherwise, I would like to give it a try[1].

> Nobody is working on it, but there are patent issues with ECC that has
> to be resolved.  To avoid wasting time, we may want to approach the FSF
> and the SFLC first to get a better understanding of what's involved here
> (I've been deferring this since nobody has expressed interest in ECC).

Good to know before stepping into further.  I hope that the situation
will change in the near future.

> Finishing the TLS 1.2 support and adding the new cipher suites is a
> high-priority task and it shouldn't be too difficult since there are TLS
> 1.2 test servers out there to test with.

Thanks for the hint.  I'll check which features of TLS 1.2 are not
implemented.  Adding HMAC-SHA256 cipher suites looks one thing to do.

Regards,
-- 
Daiki Ueno