From sega01 at gmail.com  Tue Dec  2 20:05:11 2008
From: sega01 at gmail.com (Teran McKinney)
Date: Tue, 2 Dec 2008 19:05:11 +0000
Subject: [Help-gnutls] Alternate random device for certtool
In-Reply-To: <87tz9mzcy9.fsf@wheatstone.g10code.de>
References: <b245135e0811261604i5d0f4c5eh1e7ebf88f914b6ac@mail.gmail.com>
	<87vdu9qdtt.fsf@squeak.fifthhorseman.net>
	<b245135e0811271002o33ed9dacle63e8156b57c5b21@mail.gmail.com>
	<87y6z5m2c8.fsf@squeak.fifthhorseman.net>
	<b245135e0811271110sbcebf81u5220cbf5b3d67615@mail.gmail.com>
	<4930FB82.2090603@gnutls.org> <87tz9mzcy9.fsf@wheatstone.g10code.de>
Message-ID: <b245135e0812021105p1e503704reef8cf666d4724a6@mail.gmail.com>

Just verified that I do not have this issue when I use libgcrypt
1.4.1. 1.4.2 also seems to have this problem.

Thanks,
Teran

On Tue, Dec 2, 2008 at 17:47, Werner Koch <wk at gnupg.org> wrote:
> On Sat, 29 Nov 2008 09:21, nmav at gnutls.org said:
>
>> I CC to gcrypt-devel since this might be gcrypt related.
>> Could it be that newer versions from 1.4.1 ignore the control:
>>     gcry_control (GCRYCTL_ENABLE_QUICK_RANDOM, 0);
>
> Can you please send me the example code?
>
>
> Salam-Shalom,
>
>   Werner
>
>
> --
> Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.
>
>




From nmav at gnutls.org  Wed Dec  3 08:37:50 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 03 Dec 2008 09:37:50 +0200
Subject: [Help-gnutls] Alternate random device for certtool
In-Reply-To: <87tz9mzcy9.fsf@wheatstone.g10code.de>
References: <b245135e0811261604i5d0f4c5eh1e7ebf88f914b6ac@mail.gmail.com>	<87vdu9qdtt.fsf@squeak.fifthhorseman.net>	<b245135e0811271002o33ed9dacle63e8156b57c5b21@mail.gmail.com>	<87y6z5m2c8.fsf@squeak.fifthhorseman.net>	<b245135e0811271110sbcebf81u5220cbf5b3d67615@mail.gmail.com>	<4930FB82.2090603@gnutls.org>
	<87tz9mzcy9.fsf@wheatstone.g10code.de>
Message-ID: <4936374E.9030807@gnutls.org>

Werner Koch wrote:
> On Sat, 29 Nov 2008 09:21, nmav at gnutls.org said:
> 
>> I CC to gcrypt-devel since this might be gcrypt related.
>> Could it be that newer versions from 1.4.1 ignore the control:
>>     gcry_control (GCRYCTL_ENABLE_QUICK_RANDOM, 0);
> 
> Can you please send me the example code?  

It it the certtool program from gnutls (src/certtool.c) the
generate_private_key function. This after all calls:
pk-libgcrypt.c: _rsa_generate_params (bigint_t * resarr, int
*resarr_len, int bits)

gcry_sexp_build (&parms, NULL, "(genkey(rsa(nbits %d)))", bits);
gcry_pk_genkey (&key, parms);

regards,
Nikos




From nmav at gnutls.org  Thu Dec  4 19:52:33 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 04 Dec 2008 20:52:33 +0200
Subject: [Help-gnutls] Alternate random device for certtool
In-Reply-To: <87skp4xjdl.fsf@wheatstone.g10code.de>
References: <b245135e0811261604i5d0f4c5eh1e7ebf88f914b6ac@mail.gmail.com>	<87vdu9qdtt.fsf@squeak.fifthhorseman.net>	<b245135e0811271002o33ed9dacle63e8156b57c5b21@mail.gmail.com>	<87y6z5m2c8.fsf@squeak.fifthhorseman.net>	<b245135e0811271110sbcebf81u5220cbf5b3d67615@mail.gmail.com>	<4930FB82.2090603@gnutls.org>
	<87skp4xjdl.fsf@wheatstone.g10code.de>
Message-ID: <493826F1.2060206@gnutls.org>

Werner Koch wrote:
> On Sat, 29 Nov 2008 09:21, nmav at gnutls.org said:
> 
>> I upgraded to gcrypt 1.4.4 and I notice the same delay, and strace shows
>> that /dev/random is being used even with this flag.
> 
> What you do in certtool is to call 
> 
>   if (info.quick_random != 0)
>     gcry_control (GCRYCTL_ENABLE_QUICK_RANDOM, 0);
[...]
> you see the flag can't be set in this case.  What you need to do is
> to set this flag during initialization: That is after a first call to
> gcry_check_version.  This is how it is done in by libgcrypt regression
> tests.
> Anyway, using this flag is strongly discouraged.  It is only useful for
> testing.  gpg for example refuse to use a key if the random number
> generator is in this mode and the User ID of the key is not flagged as
> insecure.  That is a bit paranoid but older version of libgcrypt even
> did not used a strong RNG in the quick mode.

Why is this? As far as I understand the only difference was that it uses
/dev/urandom instead of /dev/random.

> If you want to use not so strong keys, you better use the transient-key
> feature available since 1.4.2:
> 
>   @item transient-key
>   This is only meaningful for RSA keys.  This is a flag with no value.  If
>   given the RSA key is created using a faster and a somewhat less secure
>   random number generator.  This flag may be used for keys which are only
>   used for a short time and do not require full cryptographic strength.

Is this stronger than using /dev/urandom?


regards,
Nikos






From nmav at gnutls.org  Fri Dec  5 08:17:58 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 05 Dec 2008 09:17:58 +0200
Subject: [Help-gnutls] Alternate random device for certtool
In-Reply-To: <87hc5jwt8h.fsf@wheatstone.g10code.de>
References: <b245135e0811261604i5d0f4c5eh1e7ebf88f914b6ac@mail.gmail.com>	<87vdu9qdtt.fsf@squeak.fifthhorseman.net>	<b245135e0811271002o33ed9dacle63e8156b57c5b21@mail.gmail.com>	<87y6z5m2c8.fsf@squeak.fifthhorseman.net>	<b245135e0811271110sbcebf81u5220cbf5b3d67615@mail.gmail.com>	<4930FB82.2090603@gnutls.org>
	<87skp4xjdl.fsf@wheatstone.g10code.de>	<493826F1.2060206@gnutls.org>
	<87hc5jwt8h.fsf@wheatstone.g10code.de>
Message-ID: <4938D5A6.90408@gnutls.org>

Werner Koch wrote:

>>>     gcry_control (GCRYCTL_ENABLE_QUICK_RANDOM, 0);
> 
>> Why is this? As far as I understand the only difference was that it uses
>> /dev/urandom instead of /dev/random.
> 
> Because this has always been the case.  QUICK_RANDOM was and is just a
> testing hack.

I don't understand. The issue for certtool that was reported was that it
was blocking in /dev/random and taking a lot of time to produce any
output. This was the reason I've put QUICK_RANDOM there.

>>>   @item transient-key
> 
>> Is this stronger than using /dev/urandom?
> 
> It is not a matter of being stronger but of being a feature.
> transient-key is suposed to be used for one-off keys and other keys
> which are not that valuable. 


> In general it is always better to use the
> defaults for generating a key; see onl the recent BSD problems with
> their RNG.  This would not have been the case with a blocking one.

I don't think so. Block for indefinite time (can be even hours) does not
offer anything unless you can wait. If you want to generate keys and you
don't care if this will be today or tomorrow it's ok. In all other cases
you will not use this rng, it is broken by design[0].


regards,
Nikos

[0]. Also being blocking does not protect from being a bad algorithm. As
far as I know there are known issues to the blocking linux rng (were
discussed some years ago in gnutls-dev) and they still cannot gather any
entropy from network devices because its state can be compromised!




From nmav at gnutls.org  Fri Dec  5 21:06:38 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 05 Dec 2008 22:06:38 +0200
Subject: [Help-gnutls] Alternate random device for certtool
In-Reply-To: <874p1jvy3f.fsf@wheatstone.g10code.de>
References: <b245135e0811261604i5d0f4c5eh1e7ebf88f914b6ac@mail.gmail.com>	<87vdu9qdtt.fsf@squeak.fifthhorseman.net>	<b245135e0811271002o33ed9dacle63e8156b57c5b21@mail.gmail.com>	<87y6z5m2c8.fsf@squeak.fifthhorseman.net>	<b245135e0811271110sbcebf81u5220cbf5b3d67615@mail.gmail.com>	<4930FB82.2090603@gnutls.org>
	<87skp4xjdl.fsf@wheatstone.g10code.de>	<493826F1.2060206@gnutls.org>
	<87hc5jwt8h.fsf@wheatstone.g10code.de>	<4938D5A6.90408@gnutls.org>
	<874p1jvy3f.fsf@wheatstone.g10code.de>
Message-ID: <493989CE.908@gnutls.org>

Werner Koch wrote:

>> I don't understand. The issue for certtool that was reported was that it
>> was blocking in /dev/random and taking a lot of time to produce any
>> output. This was the reason I've put QUICK_RANDOM there.
> Right, it is blocking because it needs to generate random numbers and do
> do this we need to gather entropy from physical sources.  If the
> bandwidth of these sources is that small it just takes a long time.  If
> the box is idle it may even not finish at all.  Recall that a computer
> is a deterministic machine and that it is hard to extract unpredictable
> events from a deterministic machines (actually impossible, but
> fortunately a general purpose computer is not completely deterministic.)

There are many parts in a typical PC that can feed a prng with
non-deterministic data. Typical examples are the network card and sound
card (mic etc), hard disks, memory accesses, interrupts, thermal sensors
etc. Those provide lots of information that can feed a prng even on
unattended system.

There are two problems with the linux prng:
1. It needs to block when it thinks it does not have enough randomness
2. It does not use all available random data sources because its state
could be compromised by a malicious or broken source.

Fortuna [0] is a suitable PRNG replacement, because it has none of these
issues. It can work even with some sources being malicious and will use
a block cipher to produce large series of data without compromising or
its state.

[0]. http://en.wikipedia.org/wiki/Fortuna_(PRNG)

> Ask the user to work on the box to give it a chnace to collect entroy.
> For example "find /usr -type f | xargs cat >/dev/null" gets the disk to
> work and thus floods the box with interrupts.

The problem is that programs should be able to run both interactive and
not.

Moreover the blocking interface makes it's easy to prevent someone from
creating a key... Just cat /dev/random, or open many tcp connections to
a linux host.

>> [0]. Also being blocking does not protect from being a bad algorithm. As
>> far as I know there are known issues to the blocking linux rng (were
>> discussed some years ago in gnutls-dev) and they still cannot gather any
>> entropy from network devices because its state can be compromised!
> And thus your solution is to give up on it and use a a deterministc
> source like /dev/urandom?  If /dev/random blocks, /dev/urandom will only
> return a sequence of bytes which is predictable if you know the initial
> state of the RNG.

/dev/urandom is not deterministic it just has worse PR.
/dev/random is the SAME as /dev/urandom with the exception that it
blocks when it THINKS randomness gathered is not enough. If it thinks
wrong (like when I control one source of randomness) it exactly the same
as /dev/urandom.


regards,
Nikos




From bortzmeyer at nic.fr  Mon Dec  8 09:53:01 2008
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Mon, 8 Dec 2008 09:53:01 +0100
Subject: [Help-gnutls] Re: Alternate random device for certtool
In-Reply-To: <493989CE.908@gnutls.org>
References: <b245135e0811271002o33ed9dacle63e8156b57c5b21@mail.gmail.com>
	<87y6z5m2c8.fsf@squeak.fifthhorseman.net>
	<b245135e0811271110sbcebf81u5220cbf5b3d67615@mail.gmail.com>
	<4930FB82.2090603@gnutls.org>
	<87skp4xjdl.fsf@wheatstone.g10code.de>
	<493826F1.2060206@gnutls.org>
	<87hc5jwt8h.fsf@wheatstone.g10code.de> <4938D5A6.90408@gnutls.org>
	<874p1jvy3f.fsf@wheatstone.g10code.de> <493989CE.908@gnutls.org>
Message-ID: <20081208085301.GA21485@nic.fr>

On Fri, Dec 05, 2008 at 10:06:38PM +0200,
 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote 
 a message of 66 lines which said:

> There are many parts in a typical PC that can feed a prng with
> non-deterministic data. Typical examples are the network card and
> sound card (mic etc), hard disks, memory accesses, interrupts,
> thermal sensors etc.

Not all are equal. See RFC 4086 <http://www.ietf.org/rfc/rfc4086.txt>
for a discussion of why the hard disk is better than the network card.




From nmav at gnutls.org  Mon Dec  8 15:35:42 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 8 Dec 2008 16:35:42 +0200
Subject: [Help-gnutls] Re: Alternate random device for certtool
In-Reply-To: <20081208085301.GA21485@nic.fr>
References: <b245135e0811271002o33ed9dacle63e8156b57c5b21@mail.gmail.com>
	<b245135e0811271110sbcebf81u5220cbf5b3d67615@mail.gmail.com>
	<4930FB82.2090603@gnutls.org> <87skp4xjdl.fsf@wheatstone.g10code.de>
	<493826F1.2060206@gnutls.org> <87hc5jwt8h.fsf@wheatstone.g10code.de>
	<4938D5A6.90408@gnutls.org> <874p1jvy3f.fsf@wheatstone.g10code.de>
	<493989CE.908@gnutls.org> <20081208085301.GA21485@nic.fr>
Message-ID: <c331d99a0812080635h463a4a71w98e666122686668e@mail.gmail.com>

On Mon, Dec 8, 2008 at 10:53 AM, Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote:
> On Fri, Dec 05, 2008 at 10:06:38PM +0200,
>  Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote
>  a message of 66 lines which said:
>
>> There are many parts in a typical PC that can feed a prng with
>> non-deterministic data. Typical examples are the network card and
>> sound card (mic etc), hard disks, memory accesses, interrupts,
>> thermal sensors etc.
>
> Not all are equal. See RFC 4086 <http://www.ietf.org/rfc/rfc4086.txt>
> for a discussion of why the hard disk is better than the network card.

Of course they are not. What I say is that the PRNG should be able to
use them all at no cost.

regards,
Nikos




From simon at josefsson.org  Wed Dec 10 16:07:30 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 10 Dec 2008 16:07:30 +0100
Subject: [Help-gnutls] Release candidate of 2.6.3
Message-ID: <87oczkdq6l.fsf@mocca.josefsson.org>

We'll need to do another 2.6.x release, to make X.509 certificate chains
ending with RSA-MD2 CA's (i.e., one of VeriSign's CA's) validate
successfully again.  I have prepared a daily build that incorporates
everything we want to release in 2.6.3, please test it now:

http://daily.josefsson.org/gnutls-2.6/gnutls-2.6-20081210.tar.gz
http://daily.josefsson.org/gnutls-2.6/gnutls-2.6-20081210.tar.gz.gpg

I've prepared patches against the two latest stable branches below.

/Simon

Patch against 2.6.2:

diff --git a/lib/x509/verify.c b/lib/x509/verify.c
index 92ef722..00e2422 100644
--- a/lib/x509/verify.c
+++ b/lib/x509/verify.c
@@ -374,6 +374,24 @@ _gnutls_x509_verify_certificate (const gnutls_x509_crt_t * certificate_list,
   int i = 0, ret;
   unsigned int status = 0, output;
 
+  if (clist_size > 1) 
+    {
+      /* Check if the last certificate in the path is self signed.
+       * In that case ignore it (a certificate is trusted only if it
+       * leads to a trusted party by us, not the server's).
+       *
+       * This in addition prevents from verifying self signed certificates
+       * against themselves. This although not bad caused verification
+       * failures on some root self signed certificates that use the MD2
+       * algorithm.
+       */
+      if (gnutls_x509_crt_check_issuer (certificate_list[clist_size - 1],
+  				    certificate_list[clist_size - 1]) > 0)
+        {
+          clist_size--;
+        }
+    }
+
   /* Verify the last certificate in the certificate path
    * against the trusted CA certificate list.
    *

Patch against 2.4.2:

--- gnutls-2.4.2/lib/x509/verify.c.orig	2008-12-10 16:05:39.000000000 +0100
+++ gnutls-2.4.2/lib/x509/verify.c	2008-12-10 16:05:41.000000000 +0100
@@ -376,6 +376,24 @@
   int i = 0, ret;
   unsigned int status = 0, output;
 
+  if (clist_size > 1)
+    {
+      /* Check if the last certificate in the path is self signed.
+       * In that case ignore it (a certificate is trusted only if it
+       * leads to a trusted party by us, not the server's).
+       *
+       * This in addition prevents from verifying self signed certificates
+       * against themselves. This although not bad caused verification
+       * failures on some root self signed certificates that use the MD2
+       * algorithm.
+       */
+      if (gnutls_x509_crt_check_issuer (certificate_list[clist_size - 1],
+					certificate_list[clist_size - 1]) > 0)
+	{
+	  clist_size--;
+	}
+    }
+
   /* Verify the last certificate in the certificate path
    * against the trusted CA certificate list.
    *
@@ -414,17 +432,6 @@
     }
 #endif
 
-  /* Check if the last certificate in the path is self signed.
-   * In that case ignore it (a certificate is trusted only if it
-   * leads to a trusted party by us, not the server's).
-   */
-  if (gnutls_x509_crt_check_issuer (certificate_list[clist_size - 1],
-				    certificate_list[clist_size - 1]) > 0
-      && clist_size > 0)
-    {
-      clist_size--;
-    }
-
   /* Verify the certificate path (chain) 
    */
   for (i = clist_size - 1; i > 0; i--)




From simon at josefsson.org  Fri Dec 12 20:51:00 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 12 Dec 2008 20:51:00 +0100
Subject: [Help-gnutls] GnuTLS 2.6.3
Message-ID: <87wse5w4t7.fsf@mocca.josefsson.org>

We are proud to announce a new stable GnuTLS release: Version 2.6.3.

GnuTLS is a modern C library that implement the standard network
security protocol Transport Layer Security (TLS), for use by network
applications.  GnuTLS is developed for GNU/Linux, but works on many
Unix-like systems and comes with a binary installer for Windows.

The GnuTLS library is distributed under the terms of the GNU Lesser
General Public License version 2.1 (or later).  The "extra" GnuTLS
library (which contains TLS/IA support, LZO compression and Libgcrypt
FIPS-mode handler), the OpenSSL compatibility library, the self tests
and the command line tools are all distributed under the GNU General
Public License version 3.0 (or later).  The manual is distributed under
the GNU Free Documentation License version 1.2 (or later).

The project page of the library is available at:
  http://www.gnutls.org/
  http://www.gnu.org/software/gnutls/

What's New
==========

Version 2.6.3 is a maintenance release on our stable branch.

** gnutls: Fix chain verification for chains that ends with RSA-MD2 CAs.
Reported by Michael Kiefer <Michael-Kiefer at web.de> in
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507633> forwarded by
Andreas Metzler <ametzler at downhill.at.eu.org> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3309>.

** gnutls: Fix memory leak in PSK authentication.
Reported by Michael Weiser <michael at weiser.dinsnail.net> in
<http://permalink.gmane.org/gmane.network.gnutls.general/1465>.

** certtool: Move gcry_control(GCRYCTL_ENABLE_QUICK_RANDOM, 0) call earlier.
It needs to be invoked before libgcrypt is initialized.

** gnutls-cli: Return non-zero exit code on error conditions.

** gnutls-cli: Corrected bug which caused a rehandshake request to be ignored.

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

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

GnuTLS may be downloaded from one of the mirror sites or direct from
<ftp://ftp.gnu.org/gnu/gnutls/>.  The list of mirrors can be found at
<http://www.gnu.org/software/gnutls/download.html>.

Here are the BZIP2 compressed sources (4.9MB):

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.6.3.tar.bz2
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.6.3.tar.bz2

Here are OpenPGP detached signatures signed using key 0xB565716F:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.6.3.tar.bz2.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.6.3.tar.bz2.sig

Note, that we don't distribute gzip compressed tarballs.

In order to check that the version of GnuTLS which you are going to
install is an original and unmodified one, you should verify the OpenPGP
signature.  You can use the command

     gpg --verify gnutls-2.6.3.tar.bz2.sig

This checks whether the signature file matches the source file.  You
should see a message indicating that the signature is good and made by
that signing key.  Make sure that you have the right key, either by
checking the fingerprint of that key with other sources or by checking
that the key has been signed by a trustworthy other key.  The signing
key can be identified with the following information:

pub   1280R/B565716F 2002-05-05 [expires: 2009-04-21]
      Key fingerprint = 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F
uid                  Simon Josefsson <simon at josefsson.org>
uid                  Simon Josefsson <jas at extundo.com>
sub   1280R/4D5D40AE 2002-05-05 [expires: 2009-04-21]

The key is available from:
  http://josefsson.org/key.txt
  dns:b565716f.josefsson.org?TYPE=CERT

Alternatively, after successfully verifying the OpenPGP signature of
this announcement, you could verify that the files match the following
checksum values.  The values are for SHA-1 and SHA-224 respectively:

f9b6a1d6135ef0a57a5cdd9fcb3e82bc62a27dcd  gnutls-2.6.3.tar.bz2

8b9ab4067b8d761ff0362635f6f47be4595a8c86dbed069f37d37005  gnutls-2.6.3.tar.bz2

Documentation
=============

The manual is available online at:

  http://www.gnu.org/software/gnutls/documentation.html

In particular the following formats are available:

 HTML: http://www.gnu.org/software/gnutls/manual/html_node/index.html
 PDF: http://www.gnu.org/software/gnutls/manual/gnutls.pdf

For developers there is a GnuTLS API reference manual formatted using
the GTK-DOC tools:

  http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html

Community
=========

If you need help to use GnuTLS, or want to help others, you are invited
to join our help-gnutls mailing list, see:

  http://lists.gnu.org/mailman/listinfo/help-gnutls

If you wish to participate in the development of GnuTLS, you are invited
to join our gnutls-dev mailing list, see:

  http://lists.gnu.org/mailman/listinfo/gnutls-devel

Windows installer
=================

GnuTLS has been ported to the Windows operating system, and a binary
installer is available.  The installer contains DLLs for application
development, manuals, examples, and source code.  The installer uses
libgpg-error v1.6, libgcrypt v1.4.3, libtasn1 v1.5, and GnuTLS v2.6.3.

For more information about GnuTLS for Windows:
  http://josefsson.org/gnutls4win/

The Windows binary installer and PGP signature:
  http://josefsson.org/gnutls4win/gnutls-2.6.3.exe (14MB)
  http://josefsson.org/gnutls4win/gnutls-2.6.3.exe.sig

The checksum values for SHA-1 and SHA-224 are:

a1623f4485deb3324e1bb35cd348cfdb4af32e37  gnutls-2.6.3.exe

3017d1979bd1520e522582a7f2327340594eb5100438e504d2c3b53b  gnutls-2.6.3.exe

Thanks to Enrico Tassi, we also have mingw32 *.deb's available:
  http://josefsson.org/gnutls4win/mingw32-gnutls_2.6.3-1_all.deb

The checksum values for SHA-1 and SHA-224 are:

4e5dbacd879b6ee6909681acd7080715aa50b02b  mingw32-gnutls_2.6.3-1_all.deb

821abf40661bda63cc529da2d08a24067f0af4e808dc465244395b6d  mingw32-gnutls_2.6.3-1_all.deb

Internationalization
====================

GnuTLS messages have been translated into Dutch, French, German,
Malay, Polish, Swedish, and Vietnamese.  We welcome the addition of
more translations.

Support
=======

Improving GnuTLS is costly, but you can help!  We are looking for
organizations that find GnuTLS useful and wish to contribute back.
You can contribute by reporting bugs, improve the software, or donate
money or equipment.

Commercial support contracts for GnuTLS are available, and they help
finance continued maintenance.  Simon Josefsson Datakonsult, a
Stockholm based privately held company, is currently funding GnuTLS
maintenance.  We are always looking for interesting development
projects.  See http://josefsson.org/ for more details.

The GnuTLS service directory is available at:

  http://www.gnu.org/software/gnutls/commercial.html

Happy Hacking,
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
URL: </pipermail/attachments/20081212/5f07d77d/attachment.pgp>

From massimo.gaspari at alice.it  Tue Dec 16 22:09:49 2008
From: massimo.gaspari at alice.it (Massimo Gaspari)
Date: Tue, 16 Dec 2008 22:09:49 +0100
Subject: [Help-gnutls] GnuTLS 2.6.3
In-Reply-To: <87wse5w4t7.fsf@mocca.josefsson.org>
References: <87wse5w4t7.fsf@mocca.josefsson.org>
Message-ID: <4948191D.4040302@alice.it>

Dear Simon,

I'm compiling GnuTLS using MinGW (latest binutils,gcc4.2.1,latest 
winapi) in a WinXP SP3 environment.

After compiling successfully libgcrypt    1.4.3   and  libgcrypt-err    
1.7 I got an error compiling GnuTLS 2.6.3

Using ./configure --disable-shared --disable-rpath --disable-cxx 
--disable-guile

'make check'  fails with the following message

       ;; 15 03 02 00 40 79 bd 07  d1 a9 42 ea 33 b1 5e f9        ;; 60 
0c c1 3e 91 7a ab 43  37 46 a6 5f c7 68 9d 34        ;; 91 8b db 95 d4 
85 d8 31  1c af ce fc 9c 6d 27 6f        ;; eb af 5d fb a0 90 fe 90  f8 
76 1e 71 a4 f6 3d f9        ;; c5 d3 c0 4e f0
server_pull len 5 has 101
server_pull len 96 has 96
Self test `C:\msys\1.0\home\Massimo\gnutls-2.6.3\tests\finished.exe' 
finished with 0 errors
NOTE: you should run 'diskperf -y' to enable the disk statistics
PASS: finished.exe
gnutls_openpgp_privkey_import rc -59: GnuTLS internal error.
NOTE: you should run 'diskperf -y' to enable the disk statistics
FAIL: pgps2kgnu.exe
===================================
1 of 14 tests failed
Please report to bug-gnutls at gnu.org
===================================
make[3]: *** [check-TESTS] Error 1
make[3]: Leaving directory `/home/Massimo/gnutls-2.6.3/tests'
make[2]: *** [check-am] Error 2
make[2]: Leaving directory `/home/Massimo/gnutls-2.6.3/tests'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory `/home/Massimo/gnutls-2.6.3/tests'
make: *** [check-recursive] Error 1

hope this helps to fix the issue. If you need more info, please let me 
know.

regards

Max






From wkfta at hotmail.com  Tue Dec 16 22:26:47 2008
From: wkfta at hotmail.com (liuxiaoyu)
Date: Wed, 17 Dec 2008 05:26:47 +0800
Subject: [Help-gnutls] Set the priority of the key exchange algorithms on
	the server
Message-ID: <BAY122-W1069289F9229AA3E58C540A0F50@phx.gbl>


Hi,
 
I am using gnutls 2.6.2. I am wondering if we can set the priority of the key exchange algorithms on the server.
 
For example, if client adds some RSA-based ciphersuites as well as some PSK-based ciphersuites to the ClientHello message, how can I make the server to select the PSK-based ciphersuite?
 
I noticed gnutls_kx_set_priority() only works on the client, is that ture? So how can I set the priority of the key exchange algorithms on the server?
 
Thanks in adanve.
 
Regards,
 
Sean
_________________________________________________________________
????????????????????
http://ditu.live.com/?form=MRAHAB&rtp=pos.30.454167_116.308611_%E5%A4%AA%E6%B9%96__~pos.29.554046_115.983427_%E5%BA%90%E5%B1%B1__~pos.29.116111_110.478889_%E5%BC%A0%E5%AE%B6%E7%95%8C__&rtop=0~0~0&encType=1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20081217/dee8ae9f/attachment.htm>

From simon at josefsson.org  Tue Dec 16 23:57:54 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 16 Dec 2008 23:57:54 +0100
Subject: [Help-gnutls] Re: GnuTLS 2.6.3
In-Reply-To: <4948191D.4040302@alice.it> (Massimo Gaspari's message of "Tue,
	16 Dec 2008 22:09:49 +0100")
References: <87wse5w4t7.fsf@mocca.josefsson.org> <4948191D.4040302@alice.it>
Message-ID: <87r6477mod.fsf@mocca.josefsson.org>

Massimo Gaspari <massimo.gaspari at alice.it> writes:

> Dear Simon,
>
> I'm compiling GnuTLS using MinGW (latest binutils,gcc4.2.1,latest
> winapi) in a WinXP SP3 environment.
>
> After compiling successfully libgcrypt    1.4.3   and  libgcrypt-err
> 1.7 I got an error compiling GnuTLS 2.6.3
>
> Using ./configure --disable-shared --disable-rpath --disable-cxx
> --disable-guile
>
> 'make check'  fails with the following message
>
>       ;; 15 03 02 00 40 79 bd 07  d1 a9 42 ea 33 b1 5e f9        ;; 60
> 0c c1 3e 91 7a ab 43  37 46 a6 5f c7 68 9d 34        ;; 91 8b db 95 d4
> 85 d8 31  1c af ce fc 9c 6d 27 6f        ;; eb af 5d fb a0 90 fe 90
> f8 76 1e 71 a4 f6 3d f9        ;; c5 d3 c0 4e f0
> server_pull len 5 has 101
> server_pull len 96 has 96
> Self test `C:\msys\1.0\home\Massimo\gnutls-2.6.3\tests\finished.exe'
> finished with 0 errors
> NOTE: you should run 'diskperf -y' to enable the disk statistics
> PASS: finished.exe
> gnutls_openpgp_privkey_import rc -59: GnuTLS internal error.
> NOTE: you should run 'diskperf -y' to enable the disk statistics
> FAIL: pgps2kgnu.exe

OpenPGP does not appear to work under Windows, so build with
--disable-openpgp-authentication.

It would be great if someone had time to debug why the pgps2kgnu
self-test fails under Windows.

See also http://josefsson.org/gnutls4win/ for pre-built binaries, there
is also a makefile which can be useful to study if you want to build
things yourself.

/Simon




From simon at josefsson.org  Wed Dec 17 00:01:29 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 17 Dec 2008 00:01:29 +0100
Subject: [Help-gnutls] Re: Set the priority of the key exchange algorithms
	on the server
In-Reply-To: <BAY122-W1069289F9229AA3E58C540A0F50@phx.gbl> (liuxiaoyu's
	message of "Wed, 17 Dec 2008 05:26:47 +0800")
References: <BAY122-W1069289F9229AA3E58C540A0F50@phx.gbl>
Message-ID: <87myev7mie.fsf@mocca.josefsson.org>

liuxiaoyu <wkfta at hotmail.com> writes:

> Hi,
>  
> I am using gnutls 2.6.2. I am wondering if we can set the priority of the key exchange algorithms on the server.
>  
> For example, if client adds some RSA-based ciphersuites as well as some PSK-based ciphersuites to the ClientHello message, how can I make the server to select the PSK-based ciphersuite?
>  
> I noticed gnutls_kx_set_priority() only works on the client, is that ture? So how can I set the priority of the key exchange algorithms on the server?

No, it should work in servers too, and is the recommended way to handle
this.

/Simon




From michael at dinsnail.net  Tue Dec 23 14:13:22 2008
From: michael at dinsnail.net (Michael Weiser)
Date: Tue, 23 Dec 2008 14:13:22 +0100
Subject: [Help-gnutls] loading psk credentials from encrypted file
Message-ID: <20081223131322.GB26710@dinsnail.net>

Hello,

I've written a small program that uses gnutls for authentication. I've
chosen to use PSK authentication because it is simple to implement (no
certificate checking and the like) and fits my use case well (single
user). Now I've got a small usability problem:

On the client side I have to enter a password to derive the PSK key
from. Whether I've entered it correctly or not can only be determined by
trying a handshake. With my application this can be some time after I've
entered the password and can be confused with connectivity and other
problems on the network or server side.

So I'd like to enter the password just once, derive the PSK key from it
and store it in an AES-encrypted file. When starting my client
application, it would then ask for the passphrase of that file and could
immediately determine if the file can be decrypted using that key. This
way it can produce a proper error message or just ask for the passphrase
again.

(This would be analogous to using an encrypted RSA private key for X509
authentication and being asked for its passphrase.)

Is this directly supported by gnutls?
How would I best go about implementing it?
Is this a case for enhancing gnutls or should I rather implement the
neccessary logic in my application?
-- 
Thanks in advance,
Michael




From sgros.ml at gmail.com  Mon Dec 29 22:32:31 2008
From: sgros.ml at gmail.com (Stjepan Gros)
Date: Mon, 29 Dec 2008 22:32:31 +0100
Subject: [Help-gnutls] Segfault when loading certificate...
Message-ID: <4d7b043c0812291332yee068c5g1d209722f9c46588@mail.gmail.com>

Hi all,

before I go and fill a bug report I want to check if I'm doing
something wrong here. Attached is a simple C program I wrote (based on
the examples in the documentation) whose only purpose is to load a
certificate. While trying to use this program on the attached
certificate, the program segfaults and gdb shows that the segfault
happened in the asn1_der_decoding function.

Does anyone has a suggestion where I might be wrong? BTW, I'm using
gnutls shipped with Fedora 10.

I'm speculating that the problem might be the use of UTF-8 character
set in the certificate, but I'm not certain.

Thanks for help,
SG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crt.c
Type: text/x-csrc
Size: 1327 bytes
Desc: not available
URL: </pipermail/attachments/20081229/97b4e490/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cert.pem
Type: application/x-x509-ca-cert
Size: 1207 bytes
Desc: not available
URL: </pipermail/attachments/20081229/97b4e490/attachment.crt>

From jottos at gmail.com  Tue Dec 30 06:04:01 2008
From: jottos at gmail.com (John Schneider)
Date: Mon, 29 Dec 2008 21:04:01 -0800
Subject: [Help-gnutls] vista version not passing acid test
Message-ID: <ba60edda0812292104v782b96b0o51417b9be592c005@mail.gmail.com>

Hi,

I've downloaded and installed version 2.7.3 from
http://josefsson.org/gnutls4win/ and followed instructions for
running a quick test and no addresses I've tried have worked in the
manner that is displayed on the gnutls4win page. I've installed on a
Vista laptop with SP1 Is there something simple I'm missing?

Thanks for any help,

jos


Trying the address www.hotmail.com just hangs.
Addresses that don't hang:

C:\Users\jos>gnutls-cli-debug pop.live.com
Resolving 'pop.live.com'...
Connecting to '65.55.206.154:443'...
Checking for TLS 1.1 support... no
Checking fallback from TLS 1.1 to... failed
Checking for TLS 1.0 support... no
Checking for SSL 3.0 support... no

Server does not support any of SSL 3.0, TLS 1.0 and TLS 1.1


C:\Users\jos>gnutls-cli-debug -p 995 pop.gmail.com
Resolving 'pop.gmail.com'...
Connecting to '209.85.147.109:995'...
Checking for TLS 1.1 support... no
Checking fallback from TLS 1.1 to... failed
Checking for TLS 1.0 support... no
Checking for SSL 3.0 support... no

Server does not support any of SSL 3.0, TLS 1.0 and TLS 1.1


C:\Users\jos>gnutls-cli-debug -p 993 imap.gmail.com
Resolving 'imap.gmail.com'...
Connecting to '72.14.253.109:993'...
Checking for TLS 1.1 support... no
Checking fallback from TLS 1.1 to... failed
Checking for TLS 1.0 support... no
Checking for SSL 3.0 support... no

Server does not support any of SSL 3.0, TLS 1.0 and TLS 1.1


C:\Users\jos>gnutls-cli-debug -p 465 smtp.gmail.com
Resolving 'smtp.gmail.com'...
Connecting to '209.85.201.109:465'...
Checking for TLS 1.1 support... no
Checking fallback from TLS 1.1 to... failed
Checking for TLS 1.0 support... no
Checking for SSL 3.0 support... no

Server does not support any of SSL 3.0, TLS 1.0 and TLS 1.1

C:\Users\jos>gnutls-cli-debug -v
gnutls-cli-debug (GnuTLS) 2.7.3
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Nikos Mavrogiannopoulos.

John Schneider
C 408 203 7891
E jottos at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20081229/016cc18a/attachment.htm>

From webmaster at technoplaza.net  Tue Dec 30 09:25:29 2008
From: webmaster at technoplaza.net (John Ratliff)
Date: Tue, 30 Dec 2008 03:25:29 -0500
Subject: [Help-gnutls] undefined symbols on os x tiger
Message-ID: <C6FC2A5B-CB8C-4B31-8A33-96D6260462D0@technoplaza.net>

I am trying to compile FileZilla on Mac OS X Tiger (10.4). FileZilla  
requires gnutls >= 2.04.

I can't seem to compile gnutls. This is the error I get. I didn't  
find anything on google about this error, only about problems with  
zlib. Using --without-zlib did not fix this problem.

/bin/sh ../libtool --tag=CC   --mode=link gcc -std=gnu99 -I/Users/ 
jdratlif/temp/filezilla/include -g -O2 -Wno-pointer-sign   -o  
errcodes errcodes.o ../lib/libgnutls.la -L/Users/jdratlif/temp/ 
filezilla/lib -lgcrypt -lgpg-error  ../gl/libgnu.la ../lgl/liblgnu.la
libtool: link: gcc -std=gnu99 -I/Users/jdratlif/temp/filezilla/ 
include -g -O2 -Wno-pointer-sign -o errcodes errcodes.o  ../lib/.libs/ 
libgnutls.a -L/Users/jdratlif/temp/filezilla/lib -lz /Users/jdratlif/ 
temp/filezilla/lib/libgcrypt.a /Users/jdratlif/temp/filezilla/lib/ 
libgpg-error.a ../gl/.libs/libgnu.a ../lgl/.libs/liblgnu.a
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: Undefined symbols:
__gnutls_log_func
collect2: ld returned 1 exit status
make[3]: *** [errcodes] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

I thought it might be specific to this version 2.6.3, but it also  
happens in 2.6.2, 2.4.2, and 2.2.5.

Any thoughts on what this means or how I can fix it?

I am using Intel Mac OS X Tiger 10.4.
Xcode 2.5
gcc/g++ i686-apple-darwin8-g++-4.0.1 (GCC) 4.0.1 (Apple Computer,  
Inc. build 5370)

I had to compile libgpg-error and libgcrypt before I could finish the  
configure script.

libgpg-error-1.7:
./configure --disable-shared --prefix $HOME/temp/filezilla
make && make install

libgcrypt-1.4.3:
./configure --disable-shared --with-gpg-error-prefix=$HOME/temp/ 
filezilla --prefix $HOME/temp/filezilla
make && make install

gnutls-2.6.3:
./configure --disable-shared --with-libgcrypt-prefix=$HOME/temp/ 
filezilla --prefix $HOME/temp/filezilla
make

I have complete configure and build logs available at http:// 
www.technoplaza.net/temp/ for all three projects.

Thanks,

--John Ratliff





From sgros.ml at gmail.com  Tue Dec 30 13:07:20 2008
From: sgros.ml at gmail.com (Stjepan Gros)
Date: Tue, 30 Dec 2008 13:07:20 +0100
Subject: [Help-gnutls] Re: Segfault when loading certificate...
In-Reply-To: <4d7b043c0812291332yee068c5g1d209722f9c46588@mail.gmail.com>
References: <4d7b043c0812291332yee068c5g1d209722f9c46588@mail.gmail.com>
Message-ID: <4d7b043c0812300407x4d2fd4f3tea39b9d2711dd6af@mail.gmail.com>

Well, sorry for the false alarm. I mistakenly assumed if I'm not using
TLS then there is no need for the initialization of the library and
thus I didn't call the gnutls_global_init() function.

SG

On Mon, Dec 29, 2008 at 10:32 PM, Stjepan Gros <sgros.ml at gmail.com> wrote:
> Hi all,
>
> before I go and fill a bug report I want to check if I'm doing
> something wrong here. Attached is a simple C program I wrote (based on
> the examples in the documentation) whose only purpose is to load a
> certificate. While trying to use this program on the attached
> certificate, the program segfaults and gdb shows that the segfault
> happened in the asn1_der_decoding function.
>
> Does anyone has a suggestion where I might be wrong? BTW, I'm using
> gnutls shipped with Fedora 10.
>
> I'm speculating that the problem might be the use of UTF-8 character
> set in the certificate, but I'm not certain.
>
> Thanks for help,
> SG
>




From webmaster at technoplaza.net  Wed Dec 31 04:36:09 2008
From: webmaster at technoplaza.net (John Ratliff)
Date: Tue, 30 Dec 2008 22:36:09 -0500
Subject: [Help-gnutls] undefined symbols on os x tiger
In-Reply-To: <C6FC2A5B-CB8C-4B31-8A33-96D6260462D0@technoplaza.net>
References: <C6FC2A5B-CB8C-4B31-8A33-96D6260462D0@technoplaza.net>
Message-ID: <495AE8A9.7000406@technoplaza.net>

John Ratliff wrote:
> I am trying to compile FileZilla on Mac OS X Tiger (10.4). FileZilla 
> requires gnutls >= 2.04.
>
> I can't seem to compile gnutls. This is the error I get. I didn't find 
> anything on google about this error, only about problems with zlib. 
> Using --without-zlib did not fix this problem.
>
> /bin/sh ../libtool --tag=CC   --mode=link gcc -std=gnu99 
> -I/Users/jdratlif/temp/filezilla/include -g -O2 -Wno-pointer-sign   -o 
> errcodes errcodes.o ../lib/libgnutls.la 
> -L/Users/jdratlif/temp/filezilla/lib -lgcrypt -lgpg-error  
> ../gl/libgnu.la ../lgl/liblgnu.la
> libtool: link: gcc -std=gnu99 -I/Users/jdratlif/temp/filezilla/include 
> -g -O2 -Wno-pointer-sign -o errcodes errcodes.o  
> ../lib/.libs/libgnutls.a -L/Users/jdratlif/temp/filezilla/lib -lz 
> /Users/jdratlif/temp/filezilla/lib/libgcrypt.a 
> /Users/jdratlif/temp/filezilla/lib/libgpg-error.a ../gl/.libs/libgnu.a 
> ../lgl/.libs/liblgnu.a
> /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: Undefined symbols:
> __gnutls_log_func
> collect2: ld returned 1 exit status
> make[3]: *** [errcodes] Error 1
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
>
> I thought it might be specific to this version 2.6.3, but it also 
> happens in 2.6.2, 2.4.2, and 2.2.5.
>
> Any thoughts on what this means or how I can fix it?
>
> I am using Intel Mac OS X Tiger 10.4.
> Xcode 2.5
> gcc/g++ i686-apple-darwin8-g++-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. 
> build 5370)
>
> I had to compile libgpg-error and libgcrypt before I could finish the 
> configure script.
>
> libgpg-error-1.7:
> ./configure --disable-shared --prefix $HOME/temp/filezilla
> make && make install
>
> libgcrypt-1.4.3:
> ./configure --disable-shared 
> --with-gpg-error-prefix=$HOME/temp/filezilla --prefix 
> $HOME/temp/filezilla
> make && make install
>
> gnutls-2.6.3:
> ./configure --disable-shared 
> --with-libgcrypt-prefix=$HOME/temp/filezilla --prefix 
> $HOME/temp/filezilla
> make
>
> I have complete configure and build logs available at 
> http://www.technoplaza.net/temp/ for all three projects.

Apparently, the library already compiled, but the samples don't. So if I 
remove the samples from compiling, I can use the library fine.

--John Ratliff