From nmav at gnutls.org  Mon Aug  2 15:28:28 2004
From: nmav at gnutls.org (Nikos Mavroyanopoulos)
Date: Mon, 2 Aug 2004 16:28:28 +0300
Subject: [gnutls-dev] gnutls 1.0.17
Message-ID: <200408021628.28592.nmav@gnutls.org>

Hello again,

Today I've also released gnutls 1.0.17 which closes most of the
open issues known so far. The changes since 1.0.16 are:
- Updated the SRP authentication to conform to the
  latest (yet unreleased) draft. Unfortunately this breaks
  compatibility with previous versions.
- Changed the makefiles to be more portable.
- Added some default limits in the verification of certificate
  chains, to avoid denial of service attacks. Also added
  gnutls_certificate_set_verify_limits() to override them.
  Issue pointed out by Patrik Hornik <patrik at hornik.sk>.
- Added gnutls_certificate_verify_peers2().

-- 
Nikos Mavroyanopoulos



From nmav at gnutls.org  Mon Aug  2 15:33:48 2004
From: nmav at gnutls.org (Nikos Mavroyanopoulos)
Date: Mon, 2 Aug 2004 16:33:48 +0300
Subject: [gnutls-dev] new gnutls maintainer
Message-ID: <200408021633.48106.nmav@gnutls.org>

Hello,
 Due to some recent engagements, I don't know if i'll have the
time and resources to work on gnutls any more. For that reason
I resigned from being the GNU maintainer for gnutls. I asked
Simon Josefsson, known by his excellent work on several security 
related gnu projects, to take over the project as a maintainer
and he agreed. Thus after he was accepted by the FSF as well, 
the new gnu maintainer for the project is now Simon Josefsson.

Good luck Simon!

-- 
Nikos Mavroyanopoulos



From jas at extundo.com  Mon Aug  2 18:43:37 2004
From: jas at extundo.com (Simon Josefsson)
Date: Mon, 02 Aug 2004 18:43:37 +0200
Subject: [gnutls-dev] Re: new gnutls maintainer
References: <200408021633.48106.nmav@gnutls.org>
Message-ID: <ilu7jshv6bq.fsf@latte.josefsson.org>

Hello everyone.

As a first step of the maintainer handover, I'll be rolling a release
to make sure all steps of the release process is working for me.

I've created 1.0.18rc1, which is essentially the same as 0.0.17,
except some autoconf/automake version differences (use 'diff' to see
the details):

http://josefsson.org/gnutls/releases/

The release has been signed by my key 0xB565716F, which I guess will
be used for my future GnuTLS releases as well (unless Niko's send me
his private key...).

If nobody objects to the rc1 above, I'll release it as 1.0.18 on
August 5.

Perhaps I should explain what I perceive that my role will mean for
gnutls, to avoid false expectations.

First, I won't be doing major coding.

My only initial goal is to make GnuTLS portable, probably by
incorporating compatibility files from the gnulib project
<http://www.gnu.org/software/gnulib/>, and by testing GnuTLS on many
platforms using my Autobuild framework
<http://josefsson.org/autobuild/>.  A self test suite is probably
required to achieve this goal.

I may be looking into making it simpler to replace the cryptographic
library (currently only Libgcrypt) with other libraries (Nettle,
LibTomCrypt, ...), but also with hardware.

I might work on making the manual accessible on more formats, possibly
by switching to Texinfo, or using GTK-DOC and Doxygen.

I'm counting on users to submit patches.  And I'm hoping Nikos will be
around to help review them, and perhaps even write most of them. :)
I'll try to write down feature requests or general suggestions in the
doc/TODO file.

I'm sure Nikos' excellent work on GnuTLS maintenance will be missed,
but with everyone's help, I hope to at least make up some of it.

Regards,
Simon




From jas at extundo.com  Thu Aug  5 00:51:13 2004
From: jas at extundo.com (Simon Josefsson)
Date: Thu, 05 Aug 2004 00:51:13 +0200
Subject: [gnutls-dev] gnutls 1.0.18 and 1.1.13
Message-ID: <ilu7jsefrfi.fsf@latte.josefsson.org>

Hello.  I just released 1.0.18 and 1.1.13.  The changes since the
1.0.17 and 1.1.12, respectively, are:
- Added simple self test suite.

Thanks,
Simon




From jas at extundo.com  Mon Aug  9 03:07:54 2004
From: jas at extundo.com (Simon Josefsson)
Date: Mon, 09 Aug 2004 03:07:54 +0200
Subject: [gnutls-dev] gnutls 1.0.19 and 1.1.14 released
Message-ID: <ilu657t6rv9.fsf@latte.josefsson.org>

Hello.  I managed to make a typo in the self test suite Makefile, so
the last releases didn't build fully.  For the 1.0 branch, version
1.0.19 only fix that problem.  For the 1.1 branch, version 1.1.14 also
include a larger change: the manual has been converted to Texinfo.

I want to release the 1.1.x branch (CVS HEAD) as 1.2 soon.  Version
1.2 would be the new stable branch obsoleting 1.0.  Consider 1.1.14 to
be a first release candidate of the new version 1.2, and let us know
about problems building 1.0 programs with 1.1.14.

Finally, I'm gradually moving gnutls into my build system, logs at
<http://josefsson.org/autobuild-logs/gnutls.html>.  It will take some
time until gnutls (or libgcrypt, etc) build properly on all those
systems, though...

Thanks,
Simon




From jas at extundo.com  Sun Aug 15 03:41:45 2004
From: jas at extundo.com (Simon Josefsson)
Date: Sun, 15 Aug 2004 03:41:45 +0200
Subject: [gnutls-dev] gnutls 1.1.16
Message-ID: <ilupt5t5g9y.fsf@latte.josefsson.org>

Hello again.  Please disregard 1.1.15 and try 1.1.16 instead, which
should actually build better on some non-Linux platforms.  Guess I
should actually build releases on many platforms before releasing
them...  Changes are:
- Fix missing gnulib linker parameter when building certtool.
- Add gnulib module 'progname', needed by module 'error'.
- Improve building with srcdir != objdir.

Thanks,
Simon




From jas at extundo.com  Sun Aug 15 03:48:33 2004
From: jas at extundo.com (Simon Josefsson)
Date: Sun, 15 Aug 2004 03:48:33 +0200
Subject: [gnutls-dev] gnutls 1.1.15 -- (repost, for completeness,
	last try didn't show up)
Message-ID: <iluisbl5fym.fsf@latte.josefsson.org>

Hello.  I just release 1.1.15, the changes are:
- Certtool has simplistic --smime-to-p7 to translate RFC 2633 messages into
  PKCS #7 format.
- Ported to Mac OS X / Darwin.
- Ported to FreeBSD.

Internally, GnuTLS has started to use gnulib
<http://www.gnu.org/software/gnulib/>, currently only used by the
certtool --smime-to-p7 parameter.  Eventually other parts of the
package may use it too.  Let me know if this causes any problems.

As the 1.1.x branch will be known as 1.2.0 soon, I'd appreciate if
people would test building applications written for GnuTLS 1.0 using
this release.  In 1.1.x, all GnuTLS typedef's have been suffixed by
'_t', but there is supposed to be CPP #define's to translate from the
1.0 API to the 1.1 API.

I'm currently working on integrating NIST's X.509 path validation test
suite to test 'certtool --verify-chain', see
<http://csrc.nist.gov/pki/testing/x509paths.html>.  When this has been
at least partially been done, I'm ready for 1.2.0.  If someone knows
about other compilations of test vectors for X.509, PKCS #7, PKCS #12,
or other related standards, that could be used by GnuTLS, please let
me know.

Thanks,
Simon




From jas at extundo.com  Sun Aug 15 00:55:23 2004
From: jas at extundo.com (Simon Josefsson)
Date: Sun, 15 Aug 2004 00:55:23 +0200
Subject: [gnutls-dev] gnutls 1.1.15
Message-ID: <iluoeldz5wk.fsf@latte.josefsson.org>

Hello.  I just release 1.1.15, the changes are:
- Certtool has simplistic --smime-to-p7 to translate RFC 2633 messages into
  PKCS #7 format.
- Ported to Mac OS X / Darwin.
- Ported to FreeBSD.

Internally, GnuTLS has started to use gnulib
<http://www.gnu.org/software/gnulib/>, currently only used by the
certtool --smime-to-p7 parameter.  Eventually other parts of the
package may use it too.  Let me know if this causes any problems.

As the 1.1.x branch will be known as 1.2.0 soon, I'd appreciate if
people would test building applications written for GnuTLS 1.0 using
this release.  In 1.1.x, all GnuTLS typedef's have been suffixed by
'_t', but there is supposed to be CPP #define's to translate from the
1.0 API to the 1.1 API.

I'm currently working on integrating NIST's X.509 path validation test
suite to test 'certtool --verify-chain', see
<http://csrc.nist.gov/pki/testing/x509paths.html>.  When this has been
at least partially been done, I'm ready for 1.2.0.  If someone knows
about other compilations of test vectors for X.509, PKCS #7, PKCS #12,
or other related standards, that could be used by GnuTLS, please let
me know.

Thanks,
Simon




From wk at gnupg.org  Mon Aug 16 14:11:55 2004
From: wk at gnupg.org (Werner Koch)
Date: Mon, 16 Aug 2004 14:11:55 +0200
Subject: [gnutls-dev] Re: gnutls 1.1.15 -- (repost, for completeness,
 last try didn't show up)
In-Reply-To: <iluoelb4czf.fsf@latte.josefsson.org> (Simon Josefsson's
	message of "Mon, 16 Aug 2004 12:02:44 +0200")
References: <iluisbl5fym.fsf@latte.josefsson.org>
	<87k6vzqywz.fsf@wheatstone.g10code.de>
	<iluoelb4czf.fsf@latte.josefsson.org>
Message-ID: <877jrzqo38.fsf@wheatstone.g10code.de>

On Mon, 16 Aug 2004 12:02:44 +0200, Simon Josefsson said:

> http://cio.nist.gov/esd/emaildir/lists/pkits/msg00047.html

Interesting.  I'll ask the GNU "legal dept" too; just to be sure. 

> As for size, I think it would only enlarge gnutls-*.tar.gz by ~500kb
> or so, something I wouldn't consider a problem.  Self tests are quite
> important, IMHO.

Agreed.

> Are you looking at the S/MIME tests?  Then the new test suite is

Well, CMS is what I also intend to test but cutting it out from S/MIME
messages isn't too hard ;-).l  I'll have a look at the new test suite.

> I haven't any thoughts on a framework for all this.  My initial
> intention was simply to extract some *.pem or *.crt files, from the
> NIST package, into gnutls/tests/ and then write a script to iterate

Some time ago I looked at the old suite and concluded that it will be
quite some work to integrate it into a "make check". I did progress it
any further mainly due to the license issue.

> over them.  (Like the gnutls/tests/chain script, in CVS only, which
> does this for the old test suite.  It appear to indicate many

I'll have a look at it. 

Thanks,

  Werner




From robey at danger.com  Tue Aug 17 02:46:23 2004
From: robey at danger.com (Robey Pointer)
Date: Mon, 16 Aug 2004 17:46:23 -0700
Subject: [gnutls-dev] bug in _gnutls_pkcs1_rsa_encrypt
Message-ID: <4121555F.5010809@danger.com>

I just figured out what was causing a rare (once every 1000 or so) 
failure in the TLS handshake in our tests.

In the "case 2" section of _gnutls_pkcs1_rsa_encrypt(), there's a big 
loop that attempts to replace any zero bytes with a non-zero random 
number.   This line in particular:

                if (i<2) ps[i] = rnd[i];
                else ps[i] = GMAX( rnd[2] + ps[i-1] + ps[i-2], rnd[1]);

is wrong, because in some cases "rnd[2] + ps[i-1] + ps[i-2]" is 256 or 
512, which will be greater than the random byte, but end up being stored 
as zero.

After poking around in this function, I have to raise the question:  Is 
this loop's complexity absolutely necessary?  For every byte in the 
random buffer, 3 new random bytes are fetched from the random pool, and 
almost always only the 3rd byte is used.  This seems like a waste of the 
random pool, and my hunch is that the fetch of 3 random bytes was meant 
to go OUTSIDE the loop.

Attached is a patch against 1.0.19 which moves the 3-random-byte fetch 
outside the loop, and adds a mask inside the GMAX so that only the lower 
8 bits count.

This bug appears to be in gnutls 1.1.16 too, though the code has been 
reformatted.

robey

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.txt
URL: </pipermail/attachments/20040816/24229502/attachment.txt>

From jas at extundo.com  Tue Aug 17 11:39:44 2004
From: jas at extundo.com (Simon Josefsson)
Date: Tue, 17 Aug 2004 11:39:44 +0200
Subject: [gnutls-dev] Re: bug in _gnutls_pkcs1_rsa_encrypt
References: <4121555F.5010809@danger.com>
Message-ID: <ilullge2jdr.fsf@latte.josefsson.org>

Robey Pointer <robey at danger.com> writes:

> I just figured out what was causing a rare (once every 1000 or so) 
> failure in the TLS handshake in our tests.
>
> In the "case 2" section of _gnutls_pkcs1_rsa_encrypt(), there's a big 
> loop that attempts to replace any zero bytes with a non-zero random 
> number.   This line in particular:
>
>                if (i<2) ps[i] = rnd[i];
>                else ps[i] = GMAX( rnd[2] + ps[i-1] + ps[i-2], rnd[1]);
>
> is wrong, because in some cases "rnd[2] + ps[i-1] + ps[i-2]" is 256 or 
> 512, which will be greater than the random byte, but end up being stored 
> as zero.

Right.

Further, the CPP macros GMIN/GMAX was using unquoted arguments.  I
fixed this in the development branch.

> After poking around in this function, I have to raise the question:  Is 
> this loop's complexity absolutely necessary?  For every byte in the 
> random buffer, 3 new random bytes are fetched from the random pool, and 
> almost always only the 3rd byte is used.  This seems like a waste of the 
> random pool

I agree.

> and my hunch is that the fetch of 3 random bytes was meant to go
> OUTSIDE the loop.

I'm not sure about this, but in either case, it appears to me that the
replaced zero byte would have a skewed bias (that is, more skewed than
might be expected from the knowledge that it must be 1-255).  Not that
this make any critical difference, though.

> Attached is a patch against 1.0.19 which moves the 3-random-byte fetch 
> outside the loop, and adds a mask inside the GMAX so that only the lower 
> 8 bits count.

Whatever the intention was, IMHO, the logic was convoluted, I have now
installed code which says:

	if ((ret =
	     _gnutls_get_random(ps, psize, GNUTLS_STRONG_RANDOM)) < 0) {
	    gnutls_assert();
	    gnutls_afree(edata);
	    return ret;
	}
	for (i = 0; i < psize; i++)
	  while (ps[i] == 0) {
	    if ((ret =
		 _gnutls_get_random(&ps[i], 1, GNUTLS_STRONG_RANDOM)) < 0) {
		gnutls_assert();
		gnutls_afree(edata);
		return ret;
	    }
	  }
	}

It seems easier to argue for correctness of the above.  As this is
important code, more eyes on it would be appreciated.  One might have
qualms about a possible infinite loop.  I looked at PKCS#1 1.5 type 2
padding in OpenSSL, and it also loop until non-zero random data is
generated.  Nettle just replace 0 with 1.  People that want to review
the code might find it helpful to review RFC 2313 section 8 and 8.1:

   A block type BT, a padding string PS, and the data D shall be
   formatted into an octet string EB, the encryption block.

              EB = 00 || BT || PS || 00 || D .           (1)

   The block type BT shall be a single octet indicating the structure of
   the encryption block. For this version of the document it shall have
   value 00, 01, or 02. For a private- key operation, the block type
   shall be 00 or 01. For a public-key operation, it shall be 02.

   The padding string PS shall consist of k-3-||D|| octets. For block
   type 00, the octets shall have value 00; for block type 01, they
   shall have value FF; and for block type 02, they shall be
   pseudorandomly generated and nonzero. This makes the length of the
   encryption block EB equal to k.

Thanks,
Simon




From wk at gnupg.org  Tue Aug 17 13:56:57 2004
From: wk at gnupg.org (Werner Koch)
Date: Tue, 17 Aug 2004 13:56:57 +0200
Subject: [gnutls-dev] bug in _gnutls_pkcs1_rsa_encrypt
In-Reply-To: <4121555F.5010809@danger.com> (Robey Pointer's message of "Mon,
	16 Aug 2004 17:46:23 -0700")
References: <4121555F.5010809@danger.com>
Message-ID: <87oelanfjq.fsf@wheatstone.g10code.de>

On Mon, 16 Aug 2004 17:46:23 -0700, Robey Pointer said:

> and almost always only the 3rd byte is used.  This seems like a waste
> of the random pool, and my hunch is that the fetch of 3 random bytes
> was meant to go OUTSIDE the loop.

FWIW, here is how GnuPG does it:

    p = gcry_random_bytes_secure (i, GCRY_STRONG_RANDOM);
    /* replace zero bytes by new values */
    for(;;) {
	int j, k;
	byte *pp;

	/* count the zero bytes */
	for(j=k=0; j < i; j++ )
	    if( !p[j] )
		k++;
	if( !k )
	    break; /* okay: no zero bytes */
	k += k/128; /* better get some more */
	pp = gcry_random_bytes_secure( k, GCRY_STRONG_RANDOM);
	for(j=0; j < i && k ; j++ )
	    if( !p[j] )
		p[j] = pp[--k];
	xfree (pp);
    }

Libgcrypt also provides pkcs#1 handling.  The code above has not yet
been converted to this new Libgcrypt feature.


Salam-Shalom,

   Werner





From robey at danger.com  Tue Aug 17 19:58:44 2004
From: robey at danger.com (Robey Pointer)
Date: Tue, 17 Aug 2004 10:58:44 -0700
Subject: [gnutls-dev] Re: bug in _gnutls_pkcs1_rsa_encrypt
In-Reply-To: <ilullge2jdr.fsf@latte.josefsson.org>
References: <4121555F.5010809@danger.com> <ilullge2jdr.fsf@latte.josefsson.org>
Message-ID: <41224754.2070704@danger.com>

Simon Josefsson wrote:

>
>>Attached is a patch against 1.0.19 which moves the 3-random-byte fetch 
>>outside the loop, and adds a mask inside the GMAX so that only the lower 
>>8 bits count.
>>    
>>
>
>Whatever the intention was, IMHO, the logic was convoluted, I have now
>installed code which says:
>
>	if ((ret =
>	     _gnutls_get_random(ps, psize, GNUTLS_STRONG_RANDOM)) < 0) {
>	    gnutls_assert();
>	    gnutls_afree(edata);
>	    return ret;
>	}
>	for (i = 0; i < psize; i++)
>	  while (ps[i] == 0) {
>	    if ((ret =
>		 _gnutls_get_random(&ps[i], 1, GNUTLS_STRONG_RANDOM)) < 0) {
>		gnutls_assert();
>		gnutls_afree(edata);
>		return ret;
>	    }
>	  }
>	}
>
>It seems easier to argue for correctness of the above.
>

I agree that this is a lot more appropriate, and it looks correct to 
me.  Werner's version (in a different post) also looks solid (and 
appears to be optimized for making as few calls to _gnutls_get_random as 
possible, in case that's an issue).  I just wasn't sure what the 
original intent of the convoluted code was. :)


>As this is
>important code, more eyes on it would be appreciated.  One might have
>qualms about a possible infinite loop.  I looked at PKCS#1 1.5 type 2
>padding in OpenSSL, and it also loop until non-zero random data is
>generated.  Nettle just replace 0 with 1.
>

The one case that will generate an infinite loop is where the PRNG is 
spewing out a stream of all-zeros.  I think this is a case where you 
would rather lock up anyway. ;)  But yeah, I don't think the loop should 
be an issue.

Thanks!

robey




From smurf at smurf.noris.de  Tue Aug 17 23:19:51 2004
From: smurf at smurf.noris.de (Matthias Urlichs)
Date: Tue, 17 Aug 2004 23:19:51 +0200
Subject: [gnutls-dev] bug in _gnutls_pkcs1_rsa_encrypt
In-Reply-To: <87oelanfjq.fsf@wheatstone.g10code.de>
References: <4121555F.5010809@danger.com>
	<87oelanfjq.fsf@wheatstone.g10code.de>
Message-ID: <20040817211950.GS12895@kiste>

Hi,

Werner Koch:
> FWIW, here is how GnuPG does it:
> 
> 	k += k/128; /* better get some more */

This line doesn't make sense, IMHO.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf at smurf.noris.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: </pipermail/attachments/20040817/2d40ac37/attachment.pgp>

From wk at gnupg.org  Wed Aug 18 11:33:47 2004
From: wk at gnupg.org (Werner Koch)
Date: Wed, 18 Aug 2004 11:33:47 +0200
Subject: [gnutls-dev] bug in _gnutls_pkcs1_rsa_encrypt
In-Reply-To: <20040817211950.GS12895@kiste> (Matthias Urlichs's message of
	"Tue, 17 Aug 2004 23:19:51 +0200")
References: <4121555F.5010809@danger.com>
	<87oelanfjq.fsf@wheatstone.g10code.de> <20040817211950.GS12895@kiste>
Message-ID: <87acwslric.fsf@wheatstone.g10code.de>

On Tue, 17 Aug 2004 23:19:51 +0200, Matthias Urlichs said:

>> k += k/128; /* better get some more */

> This line doesn't make sense, IMHO.

The idea is that when requesting K new random bytes to replace zero
bytes of the initial random string, we request a few bytes more so
that we have some spare random bytes in case the K new bytes contain
zero bytes.

Agreed, requesting just one extra byte for replacing 128 zero bytes is
too less. 

  Werner




From smurf at smurf.noris.de  Wed Aug 18 11:58:19 2004
From: smurf at smurf.noris.de (Matthias Urlichs)
Date: Wed, 18 Aug 2004 11:58:19 +0200
Subject: [gnutls-dev] bug in _gnutls_pkcs1_rsa_encrypt
In-Reply-To: <87acwslric.fsf@wheatstone.g10code.de>
References: <4121555F.5010809@danger.com>
	<87oelanfjq.fsf@wheatstone.g10code.de>
	<20040817211950.GS12895@kiste>
	<87acwslric.fsf@wheatstone.g10code.de>
Message-ID: <20040818095818.GB29683@kiste>

Hi,

Werner Koch:
> > This line doesn't make sense, IMHO.
> 
> The idea is that when requesting K new random bytes to replace zero
> bytes of the initial random string, we request a few bytes more so
> that we have some spare random bytes in case the K new bytes contain
> zero bytes.
> 
I thought so.

However, it would help a great deal if you'd actually skip zero bytes in
the new string when you replace the zeroes in the old string.  ;-)

> Agreed, requesting just one extra byte for replacing 128 zero bytes is
> too less. 

s/is too less/isn't enough/.  (OK, OK, I'll shut up now.)

To be reasonably safe, add three more bytes.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf at smurf.noris.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: </pipermail/attachments/20040818/69b5e44a/attachment.pgp>

From jas at extundo.com  Wed Aug 18 15:36:08 2004
From: jas at extundo.com (Simon Josefsson)
Date: Wed, 18 Aug 2004 15:36:08 +0200
Subject: [gnutls-dev] gnutls 1.0.20 and 1.1.17
Message-ID: <ilu657gwotz.fsf@latte.josefsson.org>

Hello.  Changes:
- Bug fix of padding string in RSA PKCS#1 v1.5 type 2 encryption,
  reported by Robey Pointer <robey at danger.com>.

For 1.1, the changes also include:
- Generic crypto interface for secret key ciphers, hashes and randomness added.
  See section "Experimental" within section "COMPILATION ISSUES" in README.
- Removed length limit on passwords read by 'certtool'.
- Documentation fixes.

Below is the information from README on the new generic crypto
interface.  Note that Libgcrypt is still required (for things the
generic crypto interface doesn't support yet).  If you want to write
crypto wrappers for your favorite crypto library, please go ahead.

  If you specify --with-nettle, the copy of some files from Nettle that
  are included in nettle/ will be used.  It is used via the generic
  crypto interface in crypto/, which would normally invoke Libgcrypt.

  Currently the generic crypto interface only support secret key
  ciphering, hashing and gathering of random data.  Supporting
  RSA/DSA/DH/SEXP/MPI in the generic crypto interface is pending.

  As Nettle do not include a randomness gatherer, if --with-nettle is
  specified, random data will be read from system device files (e.g.,
  /dev/urandom) directly.  The files used are printed when running
  configure, you can override them using --enable-random-device,
  --enable-pseudo-random-device, and --enable-nonce-device.  Please let
  us know if the defaults for some systems are wrong.

  The goal here is to make GnuTLS build standalone, in case Libgcrypt is
  not available, but also to allow easy use of other crypto libraries or
  crypto hardware.

Happy hacking,
Simon




From robey at danger.com  Wed Aug 18 22:58:49 2004
From: robey at danger.com (Robey Pointer)
Date: Wed, 18 Aug 2004 13:58:49 -0700
Subject: [gnutls-dev] bug in _gnutls_pkcs1_rsa_encrypt
In-Reply-To: <20040818095818.GB29683@kiste>
References: <4121555F.5010809@danger.com>	<87oelanfjq.fsf@wheatstone.g10code.de>	<20040817211950.GS12895@kiste>	<87acwslric.fsf@wheatstone.g10code.de>
	<20040818095818.GB29683@kiste>
Message-ID: <4123C309.5040708@danger.com>

Matthias Urlichs wrote:

>Hi,
>
>Werner Koch:
>  
>
>>>This line doesn't make sense, IMHO.
>>>      
>>>
>>The idea is that when requesting K new random bytes to replace zero
>>bytes of the initial random string, we request a few bytes more so
>>that we have some spare random bytes in case the K new bytes contain
>>zero bytes.
>>
>>    
>>
>I thought so.
>
>However, it would help a great deal if you'd actually skip zero bytes in
>the new string when you replace the zeroes in the old string.  ;-)
>
>  
>
>>Agreed, requesting just one extra byte for replacing 128 zero bytes is
>>too less. 
>>    
>>
>
>s/is too less/isn't enough/.  (OK, OK, I'll shut up now.)
>
>To be reasonably safe, add three more bytes.
>  
>

IMHO, best to just leave the loop as-is and not bother to fetch the 
extra k/128 byte(s).  The simplicity outweighs the very very small 
chance that you might avoid an extra loop iteration by obsessively 
checking for (and skipping) zeros in the replacement buffer.

robey




From wk at gnupg.org  Thu Aug 19 09:22:23 2004
From: wk at gnupg.org (Werner Koch)
Date: Thu, 19 Aug 2004 09:22:23 +0200
Subject: [gnutls-dev] bug in _gnutls_pkcs1_rsa_encrypt
In-Reply-To: <4123C309.5040708@danger.com> (Robey Pointer's message of "Wed,
	18 Aug 2004 13:58:49 -0700")
References: <4121555F.5010809@danger.com>
	<87oelanfjq.fsf@wheatstone.g10code.de> <20040817211950.GS12895@kiste>
	<87acwslric.fsf@wheatstone.g10code.de> <20040818095818.GB29683@kiste>
	<4123C309.5040708@danger.com>
Message-ID: <871xi3iocw.fsf@wheatstone.g10code.de>

On Wed, 18 Aug 2004 13:58:49 -0700, Robey Pointer said:

> extra k/128 byte(s).  The simplicity outweighs the very very small
> chance that you might avoid an extra loop iteration by obsessively
> checking for (and skipping) zeros in the replacement buffer.

The thing is that each call to the random function turns out to be a
real performance hog; asking for a few bytes more in one call is far
cheaper.

The loop does now read:

    for(;;) {
	int j, k;
	byte *pp;

	/* count the zero bytes */
	for(j=k=0; j < i; j++ )
	    if( !p[j] )
		k++;
	if( !k )
	    break; /* okay: no zero bytes */
	k += 3; /* better get some more */  /* <========= */
	pp = get_random_bits( k*8, 1, 1);
	for(j=0; j < i && k ; j++ )
	    if( !p[j] && pp[k-1] )          /* <========= */
		p[j] = pp[--k];
	m_free(pp);
    }

Does this look better?

  Werner







From smurf at smurf.noris.de  Thu Aug 19 10:29:28 2004
From: smurf at smurf.noris.de (Matthias Urlichs)
Date: Thu, 19 Aug 2004 10:29:28 +0200
Subject: [gnutls-dev] bug in _gnutls_pkcs1_rsa_encrypt
In-Reply-To: <871xi3iocw.fsf@wheatstone.g10code.de>
References: <4121555F.5010809@danger.com>
	<87oelanfjq.fsf@wheatstone.g10code.de>
	<20040817211950.GS12895@kiste>
	<87acwslric.fsf@wheatstone.g10code.de>
	<20040818095818.GB29683@kiste> <4123C309.5040708@danger.com>
	<871xi3iocw.fsf@wheatstone.g10code.de>
Message-ID: <20040819082927.GL16989@kiste>

Hi,

Werner Koch:
> The loop does now read:
> 
It's still wrong.

> 	k += 3; /* better get some more */  /* <========= */

No, what I meant was

> 	k += 3+(k/128); /* better get some more, plus safety margin */

That should be adequate; a quick run-through with B() in OpenOffice says
that it is the 99.5% solution.


Anyway, your code is still broken (think about it... in fact it's even
worse: if this version hits a zero byte in pp you effectively stop doing
*anything* in the current iteration!):

> 	for(j=0; j < i && k ; j++)
> 	    if( !p[j] && pp[k-1] )          /* <========= */
> 		p[j] = pp[--k];

Replace with:

> 	for(j=0; j < i && k ; )
> 	    if(! p[j])
> 		p[j] = pp[--k];
>	    if(p[j])
>	    	j++;
>	if (k)
>	    break; /* we know we got them all */

> Does this look better?

NOW it does.  ;-)

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf at smurf.noris.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: </pipermail/attachments/20040819/a2540f32/attachment.pgp>

From wk at gnupg.org  Thu Aug 19 11:27:58 2004
From: wk at gnupg.org (Werner Koch)
Date: Thu, 19 Aug 2004 11:27:58 +0200
Subject: [gnutls-dev] bug in _gnutls_pkcs1_rsa_encrypt
In-Reply-To: <20040819082927.GL16989@kiste> (Matthias Urlichs's message of
	"Thu, 19 Aug 2004 10:29:28 +0200")
References: <4121555F.5010809@danger.com>
	<87oelanfjq.fsf@wheatstone.g10code.de> <20040817211950.GS12895@kiste>
	<87acwslric.fsf@wheatstone.g10code.de> <20040818095818.GB29683@kiste>
	<4123C309.5040708@danger.com> <871xi3iocw.fsf@wheatstone.g10code.de>
	<20040819082927.GL16989@kiste>
Message-ID: <871xi3h3z5.fsf@wheatstone.g10code.de>

On Thu, 19 Aug 2004 10:29:28 +0200, Matthias Urlichs said:

>> k += 3+(k/128); /* better get some more, plus safety margin */

> That should be adequate; a quick run-through with B() in OpenOffice says
> that it is the 99.5% solution.

Okay.

> Anyway, your code is still broken (think about it... in fact it's even
> worse: if this version hits a zero byte in pp you effectively stop doing
> *anything* in the current iteration!):

Aiiih.

Thanks,

  Werner




From jas at extundo.com  Sun Aug 22 16:19:25 2004
From: jas at extundo.com (Simon Josefsson)
Date: Sun, 22 Aug 2004 16:19:25 +0200
Subject: [gnutls-dev] Is 2MB too large for self tests? (was: Re: gnutls
	1.1.15 -- (repost, for completeness, last try didn't show up))
References: <iluisbl5fym.fsf@latte.josefsson.org>
	<87k6vzqywz.fsf@wheatstone.g10code.de>
	<iluoelb4czf.fsf@latte.josefsson.org>
	<877jrzqo38.fsf@wheatstone.g10code.de>
Message-ID: <ilud61jcl1u.fsf_-_@latte.josefsson.org>

Werner Koch <wk at gnupg.org> writes:

> On Mon, 16 Aug 2004 12:02:44 +0200, Simon Josefsson said:
>
>> http://cio.nist.gov/esd/emaildir/lists/pkits/msg00047.html
>
> Interesting.  I'll ask the GNU "legal dept" too; just to be sure. 

Any news?

>> As for size, I think it would only enlarge gnutls-*.tar.gz by ~500kb
>> or so, something I wouldn't consider a problem.  Self tests are quite
>> important, IMHO.
>
> Agreed.

The old test suite was ~600kb, but the new one is ~2MB, compressed.
Do people feel this is too large?  It might be that both the old and
the new test suite are useful, if so that would enlarge the package by
~2.6MB (compressed).

I'm inclined to say that 2.6MB is cheap compared to knowing that your
recently built software is working reasonably.  But I don't know if
someone here feel strongly about it.

If nobody objects, the next release will incorporate the NIST test
suites (conditioned on licensing issues).

>> over them.  (Like the gnutls/tests/chain script, in CVS only, which
>> does this for the old test suite.  It appear to indicate many
>
> I'll have a look at it. 

CVS now has 'tests/pkits_*' as well, which uses the new test suite.
Simplistic parsing of the structures, but some crypto is involved so I
think it is useful self test.

Thanks,
Simon





From bfriesen at simple.dallas.tx.us  Sun Aug 22 16:42:12 2004
From: bfriesen at simple.dallas.tx.us (Bob Friesenhahn)
Date: Sun, 22 Aug 2004 09:42:12 -0500 (CDT)
Subject: [gnutls-dev] Is 2MB too large for self tests? (was: Re: gnutls
	1.1.15 -- (repost, for completeness, last try didn't show up))
In-Reply-To: <ilud61jcl1u.fsf_-_@latte.josefsson.org>
References: <iluisbl5fym.fsf@latte.josefsson.org>
	<87k6vzqywz.fsf@wheatstone.g10code.de>
	<iluoelb4czf.fsf@latte.josefsson.org>
	<877jrzqo38.fsf@wheatstone.g10code.de>
	<ilud61jcl1u.fsf_-_@latte.josefsson.org>
Message-ID: <Pine.SOC.4.60.0408220940160.15991@blade.simplesystems.org>

On Sun, 22 Aug 2004, Simon Josefsson wrote:
>
> The old test suite was ~600kb, but the new one is ~2MB, compressed.
> Do people feel this is too large?  It might be that both the old and
> the new test suite are useful, if so that would enlarge the package by
> ~2.6MB (compressed).

This seems fine to me.  Many people will receive the software as part 
of a binary distribution and will never download the tests.  Those 
that do build from source code should care that the software they just 
built works correctly so providing the tests as part of the package is 
clearly worth the extra download time.

Bob
======================================
Bob Friesenhahn
bfriesen at simple.dallas.tx.us
http://www.simplesystems.org/users/bfriesen



From jas at extundo.com  Sun Aug 22 18:03:52 2004
From: jas at extundo.com (Simon Josefsson)
Date: Sun, 22 Aug 2004 18:03:52 +0200
Subject: [gnutls-dev] Re: Is 2MB too large for self tests?
In-Reply-To: <Pine.SOC.4.60.0408220940160.15991@blade.simplesystems.org> (Bob
	Friesenhahn's message of "Sun, 22 Aug 2004 09:42:12 -0500 (CDT)")
References: <iluisbl5fym.fsf@latte.josefsson.org>
	<87k6vzqywz.fsf@wheatstone.g10code.de>
	<iluoelb4czf.fsf@latte.josefsson.org>
	<877jrzqo38.fsf@wheatstone.g10code.de>
	<ilud61jcl1u.fsf_-_@latte.josefsson.org>
	<Pine.SOC.4.60.0408220940160.15991@blade.simplesystems.org>
Message-ID: <iluzn4nb1nb.fsf@latte.josefsson.org>

Bob Friesenhahn <bfriesen at simple.dallas.tx.us> writes:

> On Sun, 22 Aug 2004, Simon Josefsson wrote:
>>
>> The old test suite was ~600kb, but the new one is ~2MB, compressed.
>> Do people feel this is too large?  It might be that both the old and
>> the new test suite are useful, if so that would enlarge the package by
>> ~2.6MB (compressed).
>
> This seems fine to me.  Many people will receive the software as part 
> of a binary distribution and will never download the tests.  Those 
> that do build from source code should care that the software they just 
> built works correctly so providing the tests as part of the package is 
> clearly worth the extra download time.

Exactly my sentiment.  Thanks for sharing your view.

FWIW, the test suite has already triggered several bugs.  For example,
it triggered one bug in the DER decoder which was caused by the
recently added BER support in libtasn1.  So the next release will
probably have to wait until there is a new libtasn1 release, and the
license on the test suite has been settled.

Thanks,
Simon



From wk at gnupg.org  Sun Aug 22 19:48:15 2004
From: wk at gnupg.org (Werner Koch)
Date: Sun, 22 Aug 2004 19:48:15 +0200
Subject: [gnutls-dev] Is 2MB too large for self tests?
In-Reply-To: <ilud61jcl1u.fsf_-_@latte.josefsson.org> (Simon Josefsson's
	message of "Sun, 22 Aug 2004 16:19:25 +0200")
References: <iluisbl5fym.fsf@latte.josefsson.org>
	<87k6vzqywz.fsf@wheatstone.g10code.de>
	<iluoelb4czf.fsf@latte.josefsson.org>
	<877jrzqo38.fsf@wheatstone.g10code.de>
	<ilud61jcl1u.fsf_-_@latte.josefsson.org>
Message-ID: <878yc73vz4.fsf@wheatstone.g10code.de>

On Sun, 22 Aug 2004 16:19:25 +0200, Simon Josefsson said:

>> Interesting.  I'll ask the GNU "legal dept" too; just to be sure. 

> Any news?

Not yet done :-(

> Do people feel this is too large?  It might be that both the old and
> the new test suite are useful, if so that would enlarge the package by
> ~2.6MB (compressed).

Its just 1.2MB when repackages as bzip2 compressed tarball.

> CVS now has 'tests/pkits_*' as well, which uses the new test suite.
> Simplistic parsing of the structures, but some crypto is involved so I

FWIW, I have also started to integrate it into gnupg 1.9.

  Werner




From wk at gnupg.org  Mon Aug 23 14:40:51 2004
From: wk at gnupg.org (Werner Koch)
Date: Mon, 23 Aug 2004 14:40:51 +0200
Subject: [gnutls-dev] Re: Is 2MB too large for self tests?
In-Reply-To: <ilu1xhy9m28.fsf@latte.josefsson.org> (Simon Josefsson's
	message of "Mon, 23 Aug 2004 12:38:07 +0200")
References: <iluisbl5fym.fsf@latte.josefsson.org>
	<87k6vzqywz.fsf@wheatstone.g10code.de>
	<iluoelb4czf.fsf@latte.josefsson.org>
	<877jrzqo38.fsf@wheatstone.g10code.de>
	<ilud61jcl1u.fsf_-_@latte.josefsson.org>
	<878yc73vz4.fsf@wheatstone.g10code.de>
	<ilu1xhy9m28.fsf@latte.josefsson.org>
Message-ID: <87u0uu10z0.fsf@wheatstone.g10code.de>

On Mon, 23 Aug 2004 12:38:07 +0200, Simon Josefsson said:

> Should I ask them, or have you done it?  I'm ready to install PKITS in
> GnuTLS now.

Done this morning.  I would not hesitate to install it into the CVS
right now.

> I believe a few of the S/MIME test cases are buggy (bad base64
> encoding).  I've sent David Cooper a message about it.  If you are

I have not yet come to the S/MIME cases.  Needed to fix a couple of
other bugs first.  However please forward the mail so I won't fall
into the same pit.

Thanks,

  Werner




From jas at extundo.com  Mon Aug 23 16:28:03 2004
From: jas at extundo.com (Simon Josefsson)
Date: Mon, 23 Aug 2004 16:28:03 +0200
Subject: [gnutls-dev] Re: Is 2MB too large for self tests?
References: <iluisbl5fym.fsf@latte.josefsson.org>
	<87k6vzqywz.fsf@wheatstone.g10code.de>
	<iluoelb4czf.fsf@latte.josefsson.org>
	<877jrzqo38.fsf@wheatstone.g10code.de>
	<ilud61jcl1u.fsf_-_@latte.josefsson.org>
	<878yc73vz4.fsf@wheatstone.g10code.de>
	<ilu1xhy9m28.fsf@latte.josefsson.org>
	<87u0uu10z0.fsf@wheatstone.g10code.de>
Message-ID: <iluu0uu7wuk.fsf@latte.josefsson.org>

Werner Koch <wk at gnupg.org> writes:

>> I believe a few of the S/MIME test cases are buggy (bad base64
>> encoding).  I've sent David Cooper a message about it.  If you are
>
> I have not yet come to the S/MIME cases.  Needed to fix a couple of
> other bugs first.  However please forward the mail so I won't fall
> into the same pit.

Here goes.  Note that they haven't been confirmed as bugs, so the bug
may be on my part.

While going over the new PKITS test cases, I believe I found a
systematic problem in the base64 encoding of the following files:

 smime/SignedDifferentPoliciesTest4.eml
 smime/SignedInvalidBasicSelfIssuedOldWithNewTest2.eml
 smime/SignedInvalidRFC822nameConstraintsTest22.eml
 smime/SignedInvalidRFC822nameConstraintsTest26.eml
 smime/SignedValidPolicyMappingTest3.eml
 smime/SignedValidSelfIssuedinhibitPolicyMappingTest7.eml

Looking carefully at them, I realize they don't appear to contain
valid base64 data.  Five of them have the same pattern:

smime/SignedDifferentPoliciesTest4.eml:
...
Ckdvb2Qgc3ViQ0ECAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBZtJEbCoUtyenYyyu5gd/A
Ek4TTcN0sg2NvIFLc37VLAxtWcv5iC5hoyiE4f0fXbYTd4G83SimqxsGVk9GIg0KT45wl4NgNJhr
maYOtxbRUF72ygH+rundE/BeJ7XnwDsDuvQRFFi/J0F/RQGJGS5lkkzS7l/8hgArXkZ3Xe3x5AAA==

smime/SignedInvalidBasicSelfIssuedOldWithNewTest2.eml:
...
IE5ldyBLZXkgQ0ECAQMwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYCr3FvVdmJh2CFVoayeJFlN
BuAkhD3VQ+eu52+wWHKhivlTN+ZTkVVUB0XXtXLJujb5icVsIGFHuKLk0AxK0VV61cla8NFMBT1+
SSEUwtI9KzU/COBIsm0nTqwdmnpGL9ewPGrOyG9xlxyRWOD5yRfcZ1K7Ouom8cVmqZOQt+4suQAA==

smime/SignedInvalidRFC822nameConstraintsTest26.eml:
...
IFJGQzgyMiBDQTMCAQIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYAa0s/qZXRqUKiX7bNyT4GG
YQhkU6Hxh+v0iEvtLH2j00ZqnitHQ+dopZT9ioQ4k8gZnsVmQUtAs6XGRgk9u9jc95rHx25UvUnF
D3WVvVfI8WPEcuoXLWSW0UecNSXeBR1FCqV50o100G4mWBxe4sQpJYJzviXX1K+TH2cXFMf6JgAA==

smime/SignedValidPolicyMappingTest3.eml:
...
bzMgc3Vic3ViQ0ECAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBv0VNZTogJWG4Y8F3S1ZJt
wo7fRVFZ1VM8bM761EmBgernXnYVjMAPbWi7j4thYao+Mct0/LsfBMiAJ0FlLVopXbHQk6AOuzsu
WlxwBYAGbS/XwPX6ZlJpA8mhG/lps6KaOaRZqLtNqcI7nEnhfKkqoN7VCNdCF42GsR3q/3JD3gAA==

smime/SignedValidSelfIssuedinhibitPolicyMappingTest7.eml:
...
ZzEgUDEgc3ViQ0ECAQEwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEgYBLP7PAXEAZmOqU4wjBMdEg
YSmq2uCSdM8rTXkHmnsNFFzF3kb631z3XIV0QnNxbf3tnPth1evO3czt7Vg75DA99eyRtAKMp14O
EyNOPY1erx7u/EVjqjuo8eJ36RQ/q+Cl3HpEtmMReKxWimbl1aRvdgEiKMXyX38Wc4NX6/S7QAAA==

If I replace 'AA==' with '==' they all work.  You can verify that the
files doesn't contain valid base64 data, because base64 data ending
with '==' must always be of a specific length (see RFC 3548 or some
other base64 specification).

Perhaps your base64 encoder has problems when the data finish at the
line wrap position.

The sixth file smime/SignedInvalidRFC822nameConstraintsTest22.eml is
more complicated, but still similar.  Here I use ^M to indicate CR:

cyBSRkM4MjIgQ0ExAgECMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUABIGAclFj1HCdFFFrmLLeVTnn^M
U1gINbB7LEpP0adbCR+EX+JfWfzWA5BXS0Gj33yFCrpw3FlfZtrQjG+jxr6kO/rlBrtxWyp9L8/l^M
7t01CHKSFMQ/pI+SGfzyufEOD2l+fgSS7WcGnGLsHBCj48b2y71KQ+zEr1EXXxV5/2MropWW4e0A^M=^M

Here you should replace 'A^M=^M' with '=^M'.




From jas at extundo.com  Tue Aug 24 19:21:37 2004
From: jas at extundo.com (Simon Josefsson)
Date: Tue, 24 Aug 2004 19:21:37 +0200
Subject: [gnutls-dev] gnutls 1.1.18
Message-ID: <ilu8yc4a1um.fsf@latte.josefsson.org>

Hello.  New development version released:
- Corrected handling of certificate with dates after year 2038.
- Corrected DER decoder which could incorrectly treat input as BER and fail.
- Correct certtool --smime-to-p7 end of line character handling.
- Added example client and server for anonymous authentication.
- Added self test that tests anonymous TLS client and server.
- Added self tests of Nettle and generic crypto layer.
- Added API reference manual in HTML format in doc/reference/ using GTK-DOC.
  Online version at <http://www.gnu.org/software/gnutls/reference/>.
- Assume C89 or better; removed checks for size_t, ptrdiff_t and time_t.
- Man pages for API functions are included.

Note that the new PKITS self tests are not included yet, pending
license questions.  Same for the old NIST test suite.  Both are
available in CVS though (run tests/pkits and tests/chain).  FWIW, the
problems I found in PKITS have been confirmed by NIST, but they will
still show up as failure in GnuTLS until NIST release a new package.

As usual, build logs on many platforms are available:
http://josefsson.org/autobuild-logs/gnutls.html

Enjoy,
Simon




From simon.posnjak at cetrtapot.si  Fri Aug 27 01:24:00 2004
From: simon.posnjak at cetrtapot.si (Simon Posnjak)
Date: Fri, 27 Aug 2004 01:24:00 +0200
Subject: [gnutls-dev] Memory leeks?
Message-ID: <1093562548.5633.65.camel@hlod.pustal.lan>

Hi,

I have written a small HTTP server and secured it with GNU TLS. When I
checked it for memory leeks with valgrind i discovered that gnutls
(libgrypt) seams to be leaking. My HTTP server dose not leek (when I
compile it without TLS suport valgrid shows 0 leaked memory and 0 still
reachable). I am all so worried about a large number of still reachable
memory which seams to belong to the libgcrypt. At the end of my program
I call:

gnutls_certificate_free_credentials(http_server_x509_cred);
gnutls_dh_params_deinit(http_server_dh_params);
gnutls_global_deinit();

Which take care of the gnutls allocated memory, but how do I get rid of the 
memory that libgcrypt allocated (I can not find the function to do that)?

The valgrind output (I would like to free the still reachable memory):

==9528== malloc/free: in use at exit: 2962 bytes in 47 blocks.
==9528== malloc/free: 18939 allocs, 18892 frees, 2522428 bytes allocated.
==9528==
==9528== searching for pointers to 47 not-freed blocks.
==9528== checked 4415664 bytes.
==9528==
==9528==
==9528== 62 bytes in 1 blocks are definitely lost in loss record 1 of 6
==9528==    at 0x4002ACB4: malloc (in /usr/lib/valgrind/vgskin_memcheck.so)
==9528==    by 0x806BAEF: generate_rdn_seq (in /stuff1/delo/carneol-cpot/carneol/blocks/http_server_block/tests/simple_web_server_tls/simple_http_tls)
==9528==    by 0x806CBB1: gnutls_certificate_set_x509_trust_file (in /stuff1/delo/carneol-cpot/carneol/blocks/http_server_block/tests/simple_web_server_tls/simple_http_tls)
==9528==    by 0x804A3C2: thread_http (thread_http.c:82)
==9528==
==9528==
==9528== 100 bytes in 5 blocks are definitely lost in loss record 2 of 6
==9528==    at 0x4002ACB4: malloc (in /usr/lib/valgrind/vgskin_memcheck.so)
==9528==    by 0x808A843: _gcry_malloc (global.c:394)
==9528==    by 0x808A9DB: gcry_malloc (global.c:412)
==9528==    by 0x808AA00: gcry_xmalloc (global.c:539)
==9528==
==9528==
==9528== 144 bytes in 6 blocks are still reachable in loss record 3 of 6
==9528==    at 0x4002ACB4: malloc (in /usr/lib/valgrind/vgskin_memcheck.so)
==9528==    by 0x8049FA2: gcry_pthread_mutex_init (thread_http.c:23)
==9528==    by 0x808DE77: _gcry_ath_init (ath.c:67)
==9528==    by 0x808AC2E: global_init (global.c:68)
==9528==
==9528==
==9528== 528 bytes in 4 blocks are still reachable in loss record 4 of 6
==9528==    at 0x4002B236: realloc (in /usr/lib/valgrind/vgskin_memcheck.so)
==9528==    by 0x808A746: gcry_realloc (global.c:455)
==9528==    by 0x808A768: gcry_xrealloc (global.c:553)
==9528==    by 0x80AC801: _gcry_mpi_resize (mpiutil.c:131)
==9528==
==9528==
==9528== 672 bytes in 28 blocks are still reachable in loss record 5 of 6
==9528==    at 0x4002ACB4: malloc (in /usr/lib/valgrind/vgskin_memcheck.so)
==9528==    by 0x808A84E: _gcry_malloc (global.c:396)
==9528==    by 0x808A9DB: gcry_malloc (global.c:412)
==9528==    by 0x80B0E2A: _gcry_module_add (module.c:77)
==9528==
==9528==
==9528== 1456 bytes in 3 blocks are still reachable in loss record 6 of 6
==9528==    at 0x4002ACB4: malloc (in /usr/lib/valgrind/vgskin_memcheck.so)
==9528==    by 0x808A843: _gcry_malloc (global.c:394)
==9528==    by 0x808A9DB: gcry_malloc (global.c:412)
==9528==    by 0x808AA00: gcry_xmalloc (global.c:539)
==9528==
==9528== LEAK SUMMARY:
==9528==    definitely lost: 162 bytes in 6 blocks.
==9528==    possibly lost:   0 bytes in 0 blocks.
==9528==    still reachable: 2800 bytes in 41 blocks.
==9528==         suppressed: 0 bytes in 0 blocks.
--9528--     TT/TC: 0 tc sectors discarded.
--9528--            7774 chainings, 0 unchainings.

		Regards Simon





From wk at gnupg.org  Fri Aug 27 10:57:16 2004
From: wk at gnupg.org (Werner Koch)
Date: Fri, 27 Aug 2004 10:57:16 +0200
Subject: [gnutls-dev] Memory leeks?
In-Reply-To: <1093562548.5633.65.camel@hlod.pustal.lan> (Simon Posnjak's
	message of "Fri, 27 Aug 2004 01:24:00 +0200")
References: <1093562548.5633.65.camel@hlod.pustal.lan>
Message-ID: <87isb55577.fsf@wheatstone.g10code.de>

On Fri, 27 Aug 2004 01:24:00 +0200, Simon Posnjak said:

> checked it for memory leeks with valgrind i discovered that gnutls
> (libgrypt) seams to be leaking. My HTTP server dose not leek (when I

I presume you are using libgcrypt 1.2.0.  Would you mind to use the
CVS version (-r LIBGCRYPT-1-2-BRANCH would be best, but HEAD should
alos do). It is at :pserver:anoncvs at cvs.gnupg.org:/cvs/gnupg (password
is "anoncvs").

We fixed a couple of memory leaks since the last release.

Thanks,

  Werner




From simon.posnjak at cetrtapot.si  Fri Aug 27 18:53:02 2004
From: simon.posnjak at cetrtapot.si (Simon Posnjak)
Date: Fri, 27 Aug 2004 18:53:02 +0200
Subject: [gnutls-dev] Memory leeks?
In-Reply-To: <87isb55577.fsf@wheatstone.g10code.de>
References: <1093562548.5633.65.camel@hlod.pustal.lan>
	<87isb55577.fsf@wheatstone.g10code.de>
Message-ID: <1093625582.28863.92.camel@hlod.pustal.lan>

V pet, 27.08.2004 ob 10:57 je Werner Koch napisal(a):
> On Fri, 27 Aug 2004 01:24:00 +0200, Simon Posnjak said:
> 
> > checked it for memory leeks with valgrind i discovered that gnutls
> > (libgrypt) seams to be leaking. My HTTP server dose not leek (when I
> 
> I presume you are using libgcrypt 1.2.0.  Would you mind to use the
> CVS version (-r LIBGCRYPT-1-2-BRANCH would be best, but HEAD should
> alos do). It is at :pserver:anoncvs at cvs.gnupg.org:/cvs/gnupg (password
> is "anoncvs").
> 
> We fixed a couple of memory leaks since the last release.

Sorry, I was a bit tired (been writing the mail at 1 am) and forget to
write down the versions of my library. They are:
libgpg-error-1.0.tar.bz2
libgcrypt-1.2.0.tar.bz2
gnutls-1.0.20.tar.bz2

OK, next: I checked out LIBGCRYPT-1-2-BRANCH and HEAD revisions from
CVS, tried them and discovered that there is no change. Still leaking
almost the same amount of memory in almost the same way:

==28765== malloc/free: in use at exit: 2206 bytes in 37 blocks.
==28765== malloc/free: 17348 allocs, 17311 frees, 2503586 bytes
allocated.
==28765==
==28765== searching for pointers to 37 not-freed blocks.
==28765== checked 4411420 bytes.
==28765==
==28765==
==28765== 62 bytes in 1 blocks are definitely lost in loss record 1 of 4
==28765==    at 0x4002ACB4: malloc (in
/usr/lib/valgrind/vgskin_memcheck.so)
==28765==    by 0x806B91F: generate_rdn_seq (in
/stuff1/delo/carneol-cpot/carneol/blocks/http_server_block/tests/simple_web_server_tls/simple_http_tls)
==28765==    by 0x806C9E1: gnutls_certificate_set_x509_trust_file (in
/stuff1/delo/carneol-cpot/carneol/blocks/http_server_block/tests/simple_web_server_tls/simple_http_tls)
==28765==    by 0x804A3C2: thread_http (thread_http.c:82)
==28765==
==28765==
==28765== 144 bytes in 6 blocks are still reachable in loss record 2 of
4
==28765==    at 0x4002ACB4: malloc (in
/usr/lib/valgrind/vgskin_memcheck.so)
==28765==    by 0x8049FA2: gcry_pthread_mutex_init (thread_http.c:23)
==28765==    by 0x808DCA7: _gcry_ath_init (ath.c:67)
==28765==    by 0x808AA5E: global_init (global.c:67)
==28765==
==28765==
==28765== 672 bytes in 28 blocks are still reachable in loss record 3 of
4
==28765==    at 0x4002ACB4: malloc (in
/usr/lib/valgrind/vgskin_memcheck.so)
==28765==    by 0x808A67E: _gcry_malloc (global.c:404)
==28765==    by 0x808A80B: gcry_malloc (global.c:420)
==28765==    by 0x80B0C3A: _gcry_module_add (module.c:76)
==28765==
==28765==
==28765== 1328 bytes in 2 blocks are still reachable in loss record 4 of
4
==28765==    at 0x4002ACB4: malloc (in
/usr/lib/valgrind/vgskin_memcheck.so)
==28765==    by 0x808A673: _gcry_malloc (global.c:402)
==28765==    by 0x808A80B: gcry_malloc (global.c:420)
==28765==    by 0x808A830: gcry_xmalloc (global.c:547)


I attached a patch to make LIBGCRYPT-1-2-BRANCH compile and all so in
the HEAD revision there is no mpi.c file in tests directory - you have
to edit Makefile.am to make it compile.

As I understand this output, the still reachable blocks mean that you
have a live pointer to the occupied memory, but you did not release it.
Whats fun about it is that if I run my http_server in a thread and stop
that thread (doing TLS cleanup) and then start it again (initing TLS
again) the still reachable memory stays the same - the lost memory
(generate_rdn_seq) doubles. So I think (and please correct me if I am
wrong) that this still reachable memory is libgcypt global state or some
thing like that - it would be nice if there would be a function to free
this stuff. (I am on a embedded platform with 16 MB of RAM and every
byte counts;).

The only "real" memory leak seams to be in generate_rdn_seq function,
but looking at the code I can not find it - everything looks fine to me.

Thank you.

		Regards Simon

-------------- next part --------------
A non-text attachment was scrubbed...
Name: libgcrypt-1.2.0-cvs.diff
Type: text/x-patch
Size: 1454 bytes
Desc: not available
URL: </pipermail/attachments/20040827/3f77e336/attachment.bin>

From wk at gnupg.org  Fri Aug 27 21:49:17 2004
From: wk at gnupg.org (Werner Koch)
Date: Fri, 27 Aug 2004 21:49:17 +0200
Subject: [gnutls-dev] Memory leeks?
In-Reply-To: <1093625582.28863.92.camel@hlod.pustal.lan> (Simon Posnjak's
	message of "Fri, 27 Aug 2004 18:53:02 +0200")
References: <1093562548.5633.65.camel@hlod.pustal.lan>
	<87isb55577.fsf@wheatstone.g10code.de>
	<1093625582.28863.92.camel@hlod.pustal.lan>
Message-ID: <87fz681hvm.fsf@wheatstone.g10code.de>

On Fri, 27 Aug 2004 18:53:02 +0200, Simon Posnjak said:

> (generate_rdn_seq) doubles. So I think (and please correct me if I am
> wrong) that this still reachable memory is libgcypt global state or some
> thing like that - it would be nice if there would be a function to free

Correct.  There is no way to tyerminate libgcrypt and reload it later
from the same process.  Thread initialization must be done right at
the first start up and then we setup some global state - I doubt that
freeing all memory is really worth the effort - better terminate your
process

> this stuff. (I am on a embedded platform with 16 MB of RAM and every
> byte counts;).

You should be more worried on how to get enough entropy for the RNG; I
have once experimented with a Coldfire board and tehre is no clean
solution except for installing a unique random_seed file and hope for
the best.

  Werner





From jas at extundo.com  Fri Aug 27 23:56:33 2004
From: jas at extundo.com (Simon Josefsson)
Date: Fri, 27 Aug 2004 23:56:33 +0200
Subject: [gnutls-dev] Re: Memory leeks?
References: <1093562548.5633.65.camel@hlod.pustal.lan>
	<87isb55577.fsf@wheatstone.g10code.de>
	<1093625582.28863.92.camel@hlod.pustal.lan>
	<87fz681hvm.fsf@wheatstone.g10code.de>
Message-ID: <iluoekw1bzi.fsf@latte.josefsson.org>

Werner Koch <wk at gnupg.org> writes:

> You should be more worried on how to get enough entropy for the RNG; I
> have once experimented with a Coldfire board and tehre is no clean
> solution except for installing a unique random_seed file and hope for
> the best.

This is a good point.  Currently, GnuTLS support randomness from
Libgcrypt, and (in 1.1, via --with-nettle) by reading /dev/*random.

It seems like it would make sense to provide a new randomness mode.
The new mode would work similar to what LSH do: read a seed file, and
use a PRNG to generate more random data as needed.  This approach
would be useful on embedded platforms, but also on platforms with
closed source and/or otherwise dubious /dev/*random devices.

How to generate randomness should probably be orthogonal to the crypto
back end used as well.  So here's the plan:

There should be --with-nettle to select between Libgcrypt/Nettle for
secret key ciphers, hashes etc, but _not_ randomness.

There should be --with-libgcrypt-random (the default),
--with-device-random (my new code that access /dev/*random directly),
and a third option --with-seeded-random that require a secret seed
file.

If ever GnuTLS drop the hard requirement on libgcrypt, then
--with-nettle naturally would have to enable --with-device-random to
avoid the libgcrypt dependency for randomness only.

Thoughts on this appreciated.  I guess the choice of PRNG can be
discussed.  Supporting Yarrow is simple, it is part of Nettle, but
perhaps people dislike it.  Preferably, it should be easy to replace
the PRNG used.

Btw, is it possible to build vanilla Libgcrypt on ColdFire?  I get MPI
assembler failures.  I recall that the ColdFire architecture wasn't
completely m68k compatible, but the errors look too basic to be
because of that.

make[2]: Entering directory `/home/jas/src/libgcrypt/mpi'
/bin/sh ../libtool --mode=compile m68k-uclinux-gcc  -g -O2 -c -o mpih-add1.lo `test -f 'mpih-add1.S' || echo './'`mpih-add1.S
 m68k-uclinux-gcc -g -O2 -c mpih-add1.S -o mpih-add1.o
mpih-add1.S: Assembler messages:
mpih-add1.S:51: Error: parse error -- statement `movel d2,sp at -' ignored
mpih-add1.S:52: Error: parse error -- statement `movel a2,sp at -' ignored
mpih-add1.S:55: Error: parse error -- statement `movel sp@(12),a2' ignored
mpih-add1.S:56: Error: parse error -- statement `movel sp@(16),a0' ignored
mpih-add1.S:57: Error: parse error -- statement `movel sp@(20),a1' ignored
mpih-add1.S:58: Error: parse error -- statement `movel sp@(24),d2' ignored
mpih-add1.S:61: Error: operands mismatch -- statement `lsrl #1,d2' ignored
mpih-add1.S:66: Error: parse error -- statement `movel a0 at +,d0' ignored
mpih-add1.S:67: Error: parse error -- statement `movel a1 at +,d1' ignored
mpih-add1.S:68: Error: operands mismatch -- statement `addxl d1,d0' ignored
mpih-add1.S:69: Error: parse error -- statement `movel d0,a2 at +' ignored
...
jas at latte:~/src/libgcrypt$ m68k-uclinux-gcc --version
m68k-uclinux-gcc (GCC) 3.4.0

Thanks,
Simon




From wk at gnupg.org  Mon Aug 30 16:15:32 2004
From: wk at gnupg.org (Werner Koch)
Date: Mon, 30 Aug 2004 16:15:32 +0200
Subject: [gnutls-dev] Re: Memory leeks?
In-Reply-To: <iluoekw1bzi.fsf@latte.josefsson.org> (Simon Josefsson's
	message of "Fri, 27 Aug 2004 23:56:33 +0200")
References: <1093562548.5633.65.camel@hlod.pustal.lan>
	<87isb55577.fsf@wheatstone.g10code.de>
	<1093625582.28863.92.camel@hlod.pustal.lan>
	<87fz681hvm.fsf@wheatstone.g10code.de>
	<iluoekw1bzi.fsf@latte.josefsson.org>
Message-ID: <87oeks1zln.fsf@wheatstone.g10code.de>

On Fri, 27 Aug 2004 23:56:33 +0200, Simon Josefsson said:

> It seems like it would make sense to provide a new randomness mode.
> The new mode would work similar to what LSH do: read a seed file, and
> use a PRNG to generate more random data as needed.  This approach
> would be useful on embedded platforms, but also on platforms with
> closed source and/or otherwise dubious /dev/*random devices.

This is also current possible, you merely need to change the name of
/dev/random to /dev/null in configure ;-).  The design uses a PRNG
anyway.

However I doubt that this is something one should suggest except in
very rare cases.

> How to generate randomness should probably be orthogonal to the crypto
> back end used as well.  So here's the plan:

I don't think so.  A RNG is a basic building from cryptographic and
actually the hardest thing to do.  Not providing an easy API for this
will for sure lead to improper use of the other building blocks.  We
have seen in the past forgotten RNG intialization in many applications
and thus Libgcrypt tries its best to provide random by default.

What properties you need from your RNG depends highly on the
application and is something the protocol designers have to decide -
not the application implementor.

Anyway, DSA and Elgamal algorithms require random numbers anyway and
thus access to an RNG needs to be available inside the library.

> Btw, is it possible to build vanilla Libgcrypt on ColdFire?  I get MPI
> assembler failures.  I recall that the ColdFire architecture wasn't
> completely m68k compatible, but the errors look too basic to be

I am not sure; I have ported GnupG to Coldfire and givfen that the
code is basically the same it should not be really hard to do.  You
may want to look at scripts/autogen.sh from gnupg 1.2.

> jas at latte:~/src/libgcrypt$ m68k-uclinux-gcc --version
> m68k-uclinux-gcc (GCC) 3.4.0

I used gcc 2.95.3 with a couple of patches.  


  Werner




From simon.posnjak at cetrtapot.si  Tue Aug 31 02:18:15 2004
From: simon.posnjak at cetrtapot.si (Simon Posnjak)
Date: Tue, 31 Aug 2004 02:18:15 +0200
Subject: [gnutls-dev] [PATCH] Memory leaks (2.)
Message-ID: <1093911440.808.23.camel@hlod.pustal.lan>

Hi,

I found two memory leaks. The can be found in both - the stable and
development versions of gnutls (1.0.20 and 1.1.18)

First one (this one leaks every time you call
gnutls_certificate_verify_peers [and it was a pain in the ass to track
down]):
In function gnutls_x509_crt_check_revocation there are two
gnutls_datum-s declared, which are then field with 
_gnutls_x509_crl_get_raw_issuer_dn function and the data is never released.

Second one:
All so the gnutls_certificate_free_credentials function does not free 
x509_rdn_sequence data.

The attached patch solves both problems. I tested it with 1.0.20 version - 
should work all so with cvs/development version.

		Regards Simon

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnutls-memleak.patch
Type: text/x-patch
Size: 868 bytes
Desc: not available
URL: </pipermail/attachments/20040831/3ba1f2d4/attachment.bin>

From jas at extundo.com  Tue Aug 31 10:18:18 2004
From: jas at extundo.com (Simon Josefsson)
Date: Tue, 31 Aug 2004 10:18:18 +0200
Subject: [gnutls-dev] Re: [PATCH] Memory leaks (2.)
References: <1093911440.808.23.camel@hlod.pustal.lan>
Message-ID: <ilun00bn2k5.fsf@latte.josefsson.org>

Simon Posnjak <simon.posnjak at cetrtapot.si> writes:

> Hi,
>
> I found two memory leaks. The can be found in both - the stable and
> development versions of gnutls (1.0.20 and 1.1.18)

Hello.  I have applied your patch, to both branches.

Thanks,
Simon