From solinym at gmail.com  Wed Mar  1 01:33:06 2006
From: solinym at gmail.com (Travis H.)
Date: Tue, 28 Feb 2006 18:33:06 -0600
Subject: [gnutls-dev] Re: alternative /dev/random
In-Reply-To: <c331d99a0602280348h6d988051v47efe53e7e96186f@mail.gmail.com>
References: <c331d99a0602280348h6d988051v47efe53e7e96186f@mail.gmail.com>
Message-ID: <d4f1333a0602281633o7b8ad1c1rb03110795e2ea89d@mail.gmail.com>

On 2/28/06, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> What would we like from a kernel implemented random generator?
> At least for gnutls two devices would be sufficient.
> /dev/urandom: to generate session and private keys
> /dev/arandom: to generate anything else (such as IV's)
> The primary concern of the first should be to be unpredictable,
> whilst the second should focus on being fast. A question might be
> why do we need /dev/arandom? There are non cryptographic
> uses of random numbers (IV's, some padding data) that have
> different requirements and thus should not depleat the kernel's
> entropy the same way as a key generation. There are also
> non-cryptographic applications, that could use that instead.

Speaking of IVs,
Is there a need in gnutls to have a sequence of N-bit values that
needs to be first and foremost nonrepeating and secondly
unpredictable?  For example, some block modes need different IVs every
time, but don't necessarily need to be unpredictable.  In such cases,
I am considering using a N-bit cipher in CTR mode to create such
nonrepeating sequences.  IIRC the Lion cipher can be scaled to various
bit widths, and so I could create non-repeating sequences. 
Furthermore, one could return the state to the userland process
requesting it and read it back each time they need a number, so the
kernel would not have to allocate resources for maintaining internal
state.

I am considering writing a cross-platform userland library, first in
python then in C, for access to /dev/random devices, so that the
application need not concern itself with "am I running on FreeBSD,
where /dev/random is yarrow, or am I running on Linux, where
/dev/random is a true RNG?"

Thank you for the link to fortuna, I will investigate that further!
--
Security Guru for Hire http://www.lightconsulting.com/~travis/ -><-
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098 0C55 1484



From jas at extundo.com  Wed Mar  1 10:19:14 2006
From: jas at extundo.com (Simon Josefsson)
Date: Wed, 01 Mar 2006 10:19:14 +0100
Subject: [gnutls-dev] Re: alternative /dev/random
In-Reply-To: <c331d99a0602280348h6d988051v47efe53e7e96186f@mail.gmail.com>
	(Nikos Mavrogiannopoulos's message of "Tue, 28 Feb 2006 12:48:59
	+0100")
References: <c331d99a0602280348h6d988051v47efe53e7e96186f@mail.gmail.com>
Message-ID: <jas7j7eed4d.fsf@latte.josefsson.org>

"Nikos Mavrogiannopoulos" <nmav at gnutls.org> writes:

> Thus if your system had one of the previously discussed problems,
> we'd like to suggest you to try this kernel prng implementation
> and discuss it in this list.

In particular, I want to suggest that Debian look into adding this
patch to their kernels.  That would be the first step towards making
GnuTLS and/or libgcrypt use those devices, and would solve the
blocking issue.



From nmav at gnutls.org  Wed Mar  1 10:28:21 2006
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 1 Mar 2006 10:28:21 +0100
Subject: [gnutls-dev] Re: alternative /dev/random
In-Reply-To: <d4f1333a0602281633o7b8ad1c1rb03110795e2ea89d@mail.gmail.com>
References: <c331d99a0602280348h6d988051v47efe53e7e96186f@mail.gmail.com>
	<d4f1333a0602281633o7b8ad1c1rb03110795e2ea89d@mail.gmail.com>
Message-ID: <c331d99a0603010128y6f7a5d52v426caefe8414204d@mail.gmail.com>

On 3/1/06, Travis H. <solinym at gmail.com> wrote:

> Speaking of IVs,
> Is there a need in gnutls to have a sequence of N-bit values that
> needs to be first and foremost nonrepeating and secondly
> unpredictable?
Not really. Ok the CBC IV needs to be non-repeating but a random repeat
isn't catastrophic (it's no good either). We don't use any modes such
as OFB or CFB and I cannot find a usage for such numbers in gnutls
now.

> For example, some block modes need different IVs every
> time, but don't necessarily need to be unpredictable.  In such cases,
> I am considering using a N-bit cipher in CTR mode to create such
> nonrepeating sequences.  IIRC the Lion cipher can be scaled to various
> bit widths, and so I could create non-repeating sequences.
This sounds like a good idea.

> Furthermore, one could return the state to the userland process
> requesting it and read it back each time they need a number, so the
> kernel would not have to allocate resources for maintaining internal
> state.
You will not gain much from that except from complication to use it.
I think the best is to open the device (kernel allocates all required
contexts) and during read produce the outputs.

> I am considering writing a cross-platform userland library, first in
> python then in C, for access to /dev/random devices, so that the
> application need not concern itself with "am I running on FreeBSD,
> where /dev/random is yarrow, or am I running on Linux, where
> /dev/random is a true RNG?"

That would be trully a good idea. Of course you have to define
your semantics, for random numbers, and try to emulate them using each host's
available devices. Otherwise it would be unknown what to expect in
every system. The problem in a library like that would be the emulation
of these devices in systems that don't support them, and then you
have to think about thread safety, forks (that might lead to producing
the same numbers etc)... It sounds like lots of work... :)

regards,
Nikos



From solinym at gmail.com  Fri Mar  3 05:00:52 2006
From: solinym at gmail.com (Travis H.)
Date: Thu, 2 Mar 2006 22:00:52 -0600
Subject: [gnutls-dev] Re: alternative /dev/random
In-Reply-To: <c331d99a0603010128y6f7a5d52v426caefe8414204d@mail.gmail.com>
References: <c331d99a0602280348h6d988051v47efe53e7e96186f@mail.gmail.com>
	<d4f1333a0602281633o7b8ad1c1rb03110795e2ea89d@mail.gmail.com>
	<c331d99a0603010128y6f7a5d52v426caefe8414204d@mail.gmail.com>
Message-ID: <d4f1333a0603022000m5361881bj77fa93866d2f5676@mail.gmail.com>

On 3/1/06, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> That would be trully a good idea. Of course you have to define
> your semantics, for random numbers, and try to emulate them using each host's
> available devices. Otherwise it would be unknown what to expect in
> every system. The problem in a library like that would be the emulation
> of these devices in systems that don't support them, and then you
> have to think about thread safety, forks (that might lead to producing
> the same numbers etc)... It sounds like lots of work... :)

Yes, well, I'd start by simply throwing an exception if the host OS
doesn't support what you requested, but obviously I'd want to emulate
eventually.

Of course, you can always create a PRNG with real random numbers, but
one cannot go the other direction.  So, FreeBSD could not have a
"really random" device.

I think the right solution will be an engineering one, where you make
careful tradeoffs between speed and requirements.  For example, can it
recover from state compromise?  How quickly?  How fast is the PRNG
reseeded?  With what exactly?  Does reading from it affect other
devices (/dev/urandom draining /dev/random too)?  How quickly does it
work?  How quickly _can_ it repeat?  Can it be distinguished from
"real random numbers", and if so, how and with how much data?

This to me is too complex to express with device major and minor
numbers, and when the various OSes try, they will make confusion. 
It's already happening.  Eventually it will shake out, but until the
differences go away (think AT&T vs. BSD) application developers need
something portable.

Plus it sounds like fun work.  I have two HWRNGs now with very little to do :)
--
Security Guru for Hire http://www.lightconsulting.com/~travis/ -><-
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098 0C55 1484



From nmav at gnutls.org  Sat Mar  4 12:31:47 2006
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 4 Mar 2006 12:31:47 +0100
Subject: [gnutls-dev] Re: alternative /dev/random
In-Reply-To: <d4f1333a0603022000m5361881bj77fa93866d2f5676@mail.gmail.com>
References: <c331d99a0602280348h6d988051v47efe53e7e96186f@mail.gmail.com>
	<c331d99a0603010128y6f7a5d52v426caefe8414204d@mail.gmail.com>
	<d4f1333a0603022000m5361881bj77fa93866d2f5676@mail.gmail.com>
Message-ID: <200603041231.47268.nmav@gnutls.org>

On Fri 03 Mar 2006 05:00, Travis H. wrote:

> > That would be trully a good idea. Of course you have to define
> > your semantics, for random numbers, and try to emulate them using
> > each host's available devices. Otherwise it would be unknown what
> > to expect in every system. The problem in a library like that would
> > be the emulation of these devices in systems that don't support
> > them, and then you have to think about thread safety, forks (that
> > might lead to producing the same numbers etc)... It sounds like
> > lots of work... :)
> Yes, well, I'd start by simply throwing an exception if the host OS
> doesn't support what you requested, but obviously I'd want to emulate
> eventually.
> Of course, you can always create a PRNG with real random numbers, but
> one cannot go the other direction.  So, FreeBSD could not have a
> "really random" device.

I wouldn't name /dev/random of Linux a real random device. It does
have some way to count entropy and block if it thinks the entropy is
low, but I wouldn't trust it more than any other decent CPRNG.


-- 
Nikos Mavrogiannopoulos



From jas at extundo.com  Wed Mar  8 17:32:40 2006
From: jas at extundo.com (Simon Josefsson)
Date: Wed, 08 Mar 2006 17:32:40 +0100
Subject: [gnutls-dev] Re: alternative /dev/random
In-Reply-To: <c331d99a0602280348h6d988051v47efe53e7e96186f@mail.gmail.com>
	(Nikos Mavrogiannopoulos's message of "Tue, 28 Feb 2006 12:48:59
	+0100")
References: <c331d99a0602280348h6d988051v47efe53e7e96186f@mail.gmail.com>
Message-ID: <jask6b4dhhz.fsf@latte.josefsson.org>

FYI, a paper on the flawed /dev/random implemention in Linux.

Are the Debian folks reading this thread?  Perhaps someone could
forward our recommendation (i.e., replace the /dev/random device with
something better, such as Jean-Luc's patch below) to them.  That would
solve the problem that GnuTLS-applications block on /dev/random.

Jean-Luc Cooke <jlcooke at certainkey.com> writes:

> I didn't not write this.  I've given up trying to convince people of the
> problems with the Linux RNG long ago.
>
> http://eprint.iacr.org/2006/086
>
> It's worth mentioning that they said using a simpler RNG would have been
> better than using the RNG we have now.  That's almost insulting.
>
> JLC
>
> ps.  My out-of-date Fortuna RNG page: http://jlcooke.ca/random/
>
> -
> Linux-crypto:  cryptography in and on the Linux system
> Archive:       http://mail.nl.linux.org/linux-crypto/



From jas at extundo.com  Wed Mar  8 18:46:28 2006
From: jas at extundo.com (Simon Josefsson)
Date: Wed, 08 Mar 2006 18:46:28 +0100
Subject: [gnutls-dev] Libtasn1 0.3.1
Message-ID: <jasacc0de2z.fsf@latte.josefsson.org>

As several of you have noticed, libtasn1 0.3.0 did not work with
gnutls 1.3.4.  GnuTLS needed two more functions from libtasn1, and
this release export them.  Note that gnutls 1.3.4 will not work with
this release either, but gnutls 1.3.5 will follow shortly that should
work together with this release.

Below is your regular release announcement...

Libtasn1 is a standalone library written in C for manipulating ASN.1
objects including DER/BER encoding and DER/BER decoding.  Libtasn1 is
used by GnuTLS to manipulate X.509 objects and by GNU Shishi to handle
Kerberos V5 packets.

Version 0.3.1
- Support constant size bit strings, as in 'BIT STRING (SIZE(42))'.
  Reported by Cyril Holweck <cyril.holweck at q-free.com>.
- Add two more APIs required by GnuTLS.
- New public APIs:
  asn1_find_node function
  asn1_copy_node

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

If you need help to use Libtasn1, or want to help others, you are
invited to join our help-gnutls mailing list, see:
<http://lists.gnu.org/mailman/listinfo/help-gnutls>.

Homepage:
  http://josefsson.org/libtasn1/

Manual in many formats:
  http://josefsson.org/gnutls/manual/libtasn1/

Here are the compressed sources (1.2MB):
  ftp://ftp.gnutls.org/pub/gnutls/libtasn1/libtasn1-0.3.1.tar.gz
  http://josefsson.org/gnutls/releases/libtasn1/libtasn1-0.3.1.tar.gz

Here are GPG detached signatures using key 0xB565716F:
  ftp://ftp.gnutls.org/pub/gnutls/libtasn1/libtasn1-0.3.1.tar.gz.sig
  http://josefsson.org/gnutls/releases/libtasn1/libtasn1-0.3.1.tar.gz.sig

The software is cryptographically signed by the author using an
OpenPGP key identified by the following information:
  1280R/B565716F 2002-05-05 [expires: 2006-08-14]
  Key fingerprint = 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F

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

Here are the SHA-1 checksums:

2448d76ffabead9ff66e357dd98db6b9181ed783  libtasn1-0.3.1.tar.gz
9b61d6d7e3d6a730d86904dcdd7f578ecaabf868  libtasn1-0.3.1.tar.gz.sig

Enjoy,
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 422 bytes
Desc: not available
URL: </pipermail/attachments/20060308/aeaec2ce/attachment.pgp>

From jas at extundo.com  Wed Mar  8 19:41:30 2006
From: jas at extundo.com (Simon Josefsson)
Date: Wed, 08 Mar 2006 19:41:30 +0100
Subject: [gnutls-dev] GnuTLS 1.3.5
Message-ID: <jas64modbj9.fsf@latte.josefsson.org>

GnuTLS is a modern C library that implement the standard network
security protocol Transport Layer Security (TLS), for use by network
applications.

Noteworthy changes since version 1.3.4:

** Error messages are now translated using GNU Gettext.

** The function gnutls_x509_crt_to_xml now return an internal error.
This means that the code to convert X.509 certificates to XML format
does not work any more.  The reason is that the function called
libtasn1 internal functions.  It seems unclean for libtasn1 to export
the APIs needed here.  Instead it would be better to implement XML
support inside libtasn1 properly.  If you need this functionality
strongly, please consider looking into implementing this suggested
approach instead.  As a workaround, you may also modify lib/x509/xml.c
(change '#if 1' to '#if 0') and build using --with-included-libtasn1.

** Libraries are now built with libtool's -no-undefined.
This helps producing libraries for Windows using mingw32.

** Doc fixes to explain that gnutls_record_send can block.

** Libtasn1 0.3.1 or later is now required.
The include copy has been updated too.

** gnutls-cli can now recognize services and port numbers with the -p option.

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.

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>.

The project page of the library is available at:
  http://www.gnutls.org/
  http://www.gnu.org/software/gnutls/
  http://josefsson.org/gnutls/ (updated fastest)

Here are the compressed sources (3.2MB):
  http://josefsson.org/gnutls/releases/gnutls-1.3.5.tar.bz2
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.3.5.tar.bz2

Here are GPG detached signatures signed using key 0xB565716F:
  http://josefsson.org/gnutls/releases/gnutls-1.3.5.tar.bz2.sig
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.3.5.tar.bz2.sig

The software is cryptographically signed by the author using an
OpenPGP key identified by the following information:
  1280R/B565716F 2002-05-05 [expires: 2006-08-14]
  Key fingerprint = 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F

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

Here are the build reports for various platforms:
  http://josefsson.org/autobuild-logs/gnutls.html

Here are the SHA-1 checksums:

21fa619515cd9997c9d84bd3b0555e86a0a1d44f  gnutls-1.3.5.tar.bz2
0f1d7f03befd78daf7160bffca12a55059f32ec9  gnutls-1.3.5.tar.bz2.sig

Enjoy,
Nikos and Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 422 bytes
Desc: not available
URL: </pipermail/attachments/20060308/2bf413b5/attachment.pgp>

From jas at extundo.com  Wed Mar  8 19:58:35 2006
From: jas at extundo.com (Simon Josefsson)
Date: Wed, 08 Mar 2006 19:58:35 +0100
Subject: [gnutls-dev] Re: GnuTLS 1.3.5
In-Reply-To: <jas64modbj9.fsf@latte.josefsson.org> (Simon Josefsson's message
	of "Wed, 08 Mar 2006 19:41:30 +0100")
References: <jas64modbj9.fsf@latte.josefsson.org>
Message-ID: <jasveuobw6c.fsf@latte.josefsson.org>

Simon Josefsson <jas at extundo.com> writes:

> ** The function gnutls_x509_crt_to_xml now return an internal error.
> This means that the code to convert X.509 certificates to XML format
> does not work any more.  The reason is that the function called
> libtasn1 internal functions.  It seems unclean for libtasn1 to export
> the APIs needed here.  Instead it would be better to implement XML
> support inside libtasn1 properly.  If you need this functionality
> strongly, please consider looking into implementing this suggested
> approach instead.  As a workaround, you may also modify lib/x509/xml.c
> (change '#if 1' to '#if 0') and build using --with-included-libtasn1.

Perhaps we should ask about this on the list, so here goes:

Does anyone use the X.509 XML stuff?

We're inclined to disable it permanently, and maybe even remove it.
The only way to avoid that is to supply us with patches that implement
XML support inside libtasn1 (instead of in GnuTLS), which seem to be
the "correct" solution.  Or, naturally, pay us to do it for you.

Thanks,
Simon



From ametzler at downhill.at.eu.org  Wed Mar  8 20:09:33 2006
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Wed, 8 Mar 2006 20:09:33 +0100
Subject: [gnutls-dev] Re: alternative /dev/random
In-Reply-To: <jask6b4dhhz.fsf@latte.josefsson.org>
References: <c331d99a0602280348h6d988051v47efe53e7e96186f@mail.gmail.com>
	<jask6b4dhhz.fsf@latte.josefsson.org>
Message-ID: <20060308190933.GB3276@downhill.aus.cc>

On 2006-03-08 Simon Josefsson <jas at extundo.com> wrote:
> FYI, a paper on the flawed /dev/random implemention in Linux.

> Are the Debian folks reading this thread? 
[...]

I am (and should have followed up earlier), I'll post a proper
response later this week.

sorry, cu andreas
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.                                (c) Jasper Ffforde



From rkit at mur.at  Thu Mar  9 22:05:53 2006
From: rkit at mur.at (Rupert Kittinger)
Date: Thu, 09 Mar 2006 22:05:53 +0100
Subject: [gnutls-dev] thread safety issue in
	gnutls_certificate_verify_peers2()
Message-ID: <441098B1.1020505@mur.at>


Hi everybody,

I have found an unexpected race condition in using gnutls in an 
multithreaded application.

It is a multithreaded tcp server, where each thread handles its own 
session. It uses x509 certificates and requires client certification.
All threads share the same certificate_credentials structure. I would 
have expected that the credentials structure is read-only and does not 
need explicit locking, but unfortunately...

Under heavy load, the server crashes reproducably in 
gnutls_certificate_verify_peers2(). After some debugging, I found the 
following:

asn1_der_coding() seems to modify its first argument (ASN1_TYPE element) 
when encoding seuences or sets. e.g.


     case TYPE_SEQUENCE_OF: case TYPE_SET_OF:
       if(move!=UP){
	_asn1_ltostr(counter,temp);
	tlen = strlen(temp);
	
	if (tlen > 0)
	   _asn1_set_value(p,temp,tlen+1);
	p=p->down;
         ...

where p seems to point inside the asn1 structure. The program crashes 
when _asn1_set_value() frees the node while another thread is reading 
the same structure and tries to dereference a null pointer.

What is the reason for writing inside the structure? I admit I did not 
tr yto understand the der encoding code in detail, it looks quite 
intimidating :-)

Protecting the call to gnutls_certificate_verify_peers2() is an 
acceptable workaround, but I would suggest fixing this issue inside 
libtasn1. At the very least, there should be a hint inside the 
documentation that credentials should not be shared between threads.
The window of opportunity for this race condition is very short, and I 
have not yet been able to reproduce it on a single-cpu machine :-(

cheers,
Rupert

PS: thanks for all your efforts!


-- 
Rupert Kittinger <rkit at mur.at>
Krenngasse 32
A-8010 Graz
Austria




From n.mavrogiannopoulos at gmail.com  Fri Mar 10 18:24:11 2006
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Fri, 10 Mar 2006 18:24:11 +0100
Subject: [gnutls-dev] thread safety issue in
	gnutls_certificate_verify_peers2()
In-Reply-To: <441098B1.1020505@mur.at>
References: <441098B1.1020505@mur.at>
Message-ID: <200603101824.11974.n.mavrogiannopoulos@gmail.com>

On Thu 09 Mar 2006 22:05, Rupert Kittinger wrote:
> Hi everybody,

> Under heavy load, the server crashes reproducably in
> gnutls_certificate_verify_peers2(). After some debugging, I found the
> following:
> asn1_der_coding() seems to modify its first argument (ASN1_TYPE
> element) when encoding seuences or sets. e.g.
>      case TYPE_SEQUENCE_OF: case TYPE_SET_OF:
>        if(move!=UP){
> 	_asn1_ltostr(counter,temp);
> 	tlen = strlen(temp);
>
> 	if (tlen > 0)
> 	   _asn1_set_value(p,temp,tlen+1);
> 	p=p->down;
>          ...

Ouch! That's really bad. I'll try to take a look during the weekend.
Thanks for reporting it!




From ametzler at downhill.at.eu.org  Sat Mar 11 13:08:14 2006
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sat, 11 Mar 2006 13:08:14 +0100
Subject: [gnutls-dev] Re: alternative /dev/random
In-Reply-To: <jas7j7eed4d.fsf@latte.josefsson.org>
References: <c331d99a0602280348h6d988051v47efe53e7e96186f@mail.gmail.com>
	<jas7j7eed4d.fsf@latte.josefsson.org>
Message-ID: <20060311120814.GA11131@downhill.aus.cc>

On 2006-03-01 Simon Josefsson <jas at extundo.com> wrote:
> "Nikos Mavrogiannopoulos" <nmav at gnutls.org> writes:

> > Thus if your system had one of the previously discussed problems,
> > we'd like to suggest you to try this kernel prng implementation
> > and discuss it in this list.

> In particular, I want to suggest that Debian look into adding this
> patch to their kernels.  That would be the first step towards making
> GnuTLS and/or libgcrypt use those devices, and would solve the
> blocking issue.

Hello,
There is no blocking issue in /current/ exim4 packages. RSA/DSA params
generation is done offline (using cron). And there is zero chance that
blocking issue in Debian stable (sarge) is going to be fixed by
applying a patch to the kernel (which is not approved by lkml).

I am also very reluctant to suggest that Debian's kernels are patched
to use the fortuna PRNG http://jlcooke.ca/random/ by default for a
couple of reasons:

- Debian's kernel team tries to limit divergence from upstream. Every
  single additional patch increases workload.
- I am not qualified to judge the quality of the fortuna RPNG.
- I've read up on the fortuna discussions on LKML. I do not expect to
  see the fortuna patch being accepted, replacing the current
  /dev/(u)random implementation. Theodore Ts'o (the current
  /dev/(u)random maintainer) prefers the current implementation for
  various reasons. The current implentation does not require
  CONFIG_CRYPTO, and "we simply have carefully designed /dev/random to
  minimize its reliance on crypto primitives, since we have so much
  entropy available to us from the hardware. Fortuna, in contrast, has
  the property that if its cryptoprimitives are broken, you might as
  well go home." The general feeling seems to be that the current
  implemtation works, and fortuna is a nice concept but not better
  than the current implementation.

cu andreas
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.                                (c) Jasper Ffforde



From nmav at gnutls.org  Sat Mar 11 13:45:09 2006
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 11 Mar 2006 13:45:09 +0100
Subject: [gnutls-dev] Re: alternative /dev/random
In-Reply-To: <20060311120814.GA11131@downhill.aus.cc>
References: <c331d99a0602280348h6d988051v47efe53e7e96186f@mail.gmail.com>
	<jas7j7eed4d.fsf@latte.josefsson.org>
	<20060311120814.GA11131@downhill.aus.cc>
Message-ID: <200603111345.09449.nmav@gnutls.org>

On Sat 11 Mar 2006 13:08, Andreas Metzler wrote:

>   CONFIG_CRYPTO, and "we simply have carefully designed /dev/random
> to minimize its reliance on crypto primitives, since we have so much
> entropy available to us from the hardware. Fortuna, in contrast, has
> the property that if its cryptoprimitives are broken, you might as
> well go home." The general feeling seems to be that the current

I will only comment on that. This statement is  totally wrong. If SHA1
fails to provide preimage resistance the random generator of the linux
kernel is as good as  /dev/zero. The only advantage of the linux 
generator until some days ago was that nobody except its author
actually knew how it worked and there were no serious studies about it.
This changed some days ago with the paper that discussed the weaknesses
of /dev/random.

regards,
Nikos



From n.mavrogiannopoulos at gmail.com  Mon Mar 13 12:38:14 2006
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Mon, 13 Mar 2006 12:38:14 +0100
Subject: [gnutls-dev] Re: alternative /dev/random
In-Reply-To: <200603111345.09449.nmav@gnutls.org>
References: <c331d99a0602280348h6d988051v47efe53e7e96186f@mail.gmail.com>
	<jas7j7eed4d.fsf@latte.josefsson.org>
	<20060311120814.GA11131@downhill.aus.cc>
	<200603111345.09449.nmav@gnutls.org>
Message-ID: <c331d99a0603130338v57700239l1682a51875076473@mail.gmail.com>

On 3/11/06, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

> >   CONFIG_CRYPTO, and "we simply have carefully designed /dev/random
> > to minimize its reliance on crypto primitives, since we have so much
> > entropy available to us from the hardware. Fortuna, in contrast, has
> > the property that if its cryptoprimitives are broken, you might as
> > well go home." The general feeling seems to be that the current
> I will only comment on that. This statement is  totally wrong. If SHA1
> fails to provide preimage resistance the random generator of the linux
> kernel is as good as  /dev/zero. The only advantage of the linux
> generator until some days ago was that nobody except its author
> actually knew how it worked and there were no serious studies about it.
> This changed some days ago with the paper that discussed the weaknesses
> of /dev/random.

Ok, I got a bit partial here. I don't consider the concepts of
/dev/random and /dev/urandom
to be that bad for a prng generator (although it is not that good
either) and it was
initially revolutionary --I knew of no others system support such concept.
What I consider bad is the unwilliness of the maintainers to consider
alternative
approaches given the weaknesses that have been found so far. Fortuna just
happened to be there, there are many more other options to consider.

regards,
Nikos



From n.mavrogiannopoulos at gmail.com  Mon Mar 13 15:51:53 2006
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Mon, 13 Mar 2006 15:51:53 +0100
Subject: [gnutls-dev] thread safety issue in
	gnutls_certificate_verify_peers2()
In-Reply-To: <441098B1.1020505@mur.at>
References: <441098B1.1020505@mur.at>
Message-ID: <c331d99a0603130651m7f0875a6y160ca187acbfae64@mail.gmail.com>

On 3/9/06, Rupert Kittinger <rkit at mur.at> wrote:

> Hi everybody,
> I have found an unexpected race condition in using gnutls in an
> multithreaded application.

Hello,
 The problem should be corrected in the current cvs of libtasn1 (or gnutls
if you use the included version). I'd appreciate if you could try it and
see if it solves your problem.

regards,
Nikos



From ametzler at downhill.at.eu.org  Mon Mar 13 19:42:59 2006
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Mon, 13 Mar 2006 19:42:59 +0100
Subject: [gnutls-dev] Re: alternative /dev/random
In-Reply-To: <c331d99a0603130338v57700239l1682a51875076473@mail.gmail.com>
References: <c331d99a0602280348h6d988051v47efe53e7e96186f@mail.gmail.com>
	<jas7j7eed4d.fsf@latte.josefsson.org>
	<20060311120814.GA11131@downhill.aus.cc>
	<200603111345.09449.nmav@gnutls.org>
	<c331d99a0603130338v57700239l1682a51875076473@mail.gmail.com>
Message-ID: <20060313184259.GA3799@downhill.aus.cc>

On 2006-03-13 Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> wrote:
[...]
> Ok, I got a bit partial here. I don't consider the concepts of
> /dev/random and /dev/urandom to be that bad for a prng generator
> (although it is not that good either) and it was initially
> revolutionary --I knew of no others system support such concept.
> What I consider bad is the unwilliness of the maintainers to
> consider alternative approaches given the weaknesses that have been
> found so far.
[...]

Hello,
Could you elaborate on which weaknesses you are talking about? (Just
to satisfy my curiosity.)
thanks, cu andreas
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.                                (c) Jasper Ffforde



From nmav at gnutls.org  Mon Mar 13 20:17:29 2006
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 13 Mar 2006 20:17:29 +0100
Subject: [gnutls-dev] Re: alternative /dev/random
In-Reply-To: <20060313184259.GA3799@downhill.aus.cc>
References: <c331d99a0602280348h6d988051v47efe53e7e96186f@mail.gmail.com>
	<c331d99a0603130338v57700239l1682a51875076473@mail.gmail.com>
	<20060313184259.GA3799@downhill.aus.cc>
Message-ID: <200603132017.30067.nmav@gnutls.org>

On Mon 13 Mar 2006 19:42, Andreas Metzler wrote:

> Hello,
> Could you elaborate on which weaknesses you are talking about? (Just
> to satisfy my curiosity.)

I was talking about this paper that was forwards by Simon
some days ago:

http://eprint.iacr.org/2006/086



From wk at gnupg.org  Mon Mar 13 21:30:04 2006
From: wk at gnupg.org (Werner Koch)
Date: Mon, 13 Mar 2006 21:30:04 +0100
Subject: [gnutls-dev] Re: alternative /dev/random
In-Reply-To: <200603132017.30067.nmav@gnutls.org> (Nikos Mavrogiannopoulos's
	message of "Mon, 13 Mar 2006 20:17:29 +0100")
References: <c331d99a0602280348h6d988051v47efe53e7e96186f@mail.gmail.com>
	<c331d99a0603130338v57700239l1682a51875076473@mail.gmail.com>
	<20060313184259.GA3799@downhill.aus.cc>
	<200603132017.30067.nmav@gnutls.org>
Message-ID: <87slpmcckz.fsf@wheatstone.g10code.de>

On Mon, 13 Mar 2006 20:17:29 +0100, Nikos Mavrogiannopoulos said:

> http://eprint.iacr.org/2006/086

It seems that they did not contact Ted to ask for further insight into
the architecture.  I attended a talk in the mid 90ies where he
described /dev/random along with its design goals and problems.
Unfortunately the proceedings are not online (www.linux-kongress.org
has only > 1996).  I should have a paper copy somewhere but moved
several times since then :-(.

Despite from the first analysis of a large pool RNG design, the paper
describes more a problem with the linux development model than with
the original design.  Any new implementation will hamper from the same
problems.


Shalom-Salam,

   Werner





From jas at extundo.com  Wed Mar 15 12:28:18 2006
From: jas at extundo.com (Simon Josefsson)
Date: Wed, 15 Mar 2006 12:28:18 +0100
Subject: [gnutls-dev] Approaching GnuTLS 1.4.0
Message-ID: <87ek14aqwd.fsf@latte.josefsson.org>

We're approaching the release of GnuTLS 1.4.0, the next stable branch.
Please test 1.3.5 as if it were a new stable release, and report any
problems or missing features.

http://josefsson.org/gnutls/releases/gnutls-1.3.5.tar.bz2

/Simon



From rkit at mur.at  Wed Mar 15 19:57:32 2006
From: rkit at mur.at (Rupert Kittinger)
Date: Wed, 15 Mar 2006 19:57:32 +0100
Subject: [gnutls-dev] Approaching GnuTLS 1.4.0
In-Reply-To: <87ek14aqwd.fsf@latte.josefsson.org>
References: <87ek14aqwd.fsf@latte.josefsson.org>
Message-ID: <4418639C.1070007@mur.at>

Simon Josefsson schrieb:
> We're approaching the release of GnuTLS 1.4.0, the next stable branch.
> Please test 1.3.5 as if it were a new stable release, and report any
> problems or missing features.
> 
> http://josefsson.org/gnutls/releases/gnutls-1.3.5.tar.bz2
> 
> /Simon
> 
>

The race condition I reported some days ago is still present 1.3.5. Has 
the fix Nikos put in the cvs head been included?

cheers,

Rupert

-- 
Rupert Kittinger <rkit at mur.at>
Krenngasse 32
A-8010 Graz
Austria




From jas at extundo.com  Wed Mar 15 21:07:34 2006
From: jas at extundo.com (Simon Josefsson)
Date: Wed, 15 Mar 2006 21:07:34 +0100
Subject: [gnutls-dev] Re: Approaching GnuTLS 1.4.0
In-Reply-To: <4418639C.1070007@mur.at> (Rupert Kittinger's message of "Wed, 15
	Mar 2006 19:57:32 +0100")
References: <87ek14aqwd.fsf@latte.josefsson.org> <4418639C.1070007@mur.at>
Message-ID: <87u09za2ux.fsf@latte.josefsson.org>

Rupert Kittinger <rkit at mur.at> writes:

> Simon Josefsson schrieb:
>> We're approaching the release of GnuTLS 1.4.0, the next stable branch.
>> Please test 1.3.5 as if it were a new stable release, and report any
>> problems or missing features.
>> http://josefsson.org/gnutls/releases/gnutls-1.3.5.tar.bz2
>> /Simon
>> 
>>
>
> The race condition I reported some days ago is still present
> 1.3.5. Has the fix Nikos put in the cvs head been included?

Yes, but didn't make it for 1.3.5.  It will be in 1.4.0 though.

You can also try the daily snapshots:

http://josefsson.org/daily/gnutls/
http://josefsson.org/daily/gnutls/gnutls-20060315.tar.gz

/Simon



From jas at extundo.com  Tue Mar 21 18:16:05 2006
From: jas at extundo.com (Simon Josefsson)
Date: Tue, 21 Mar 2006 18:16:05 +0100
Subject: [gnutls-dev] Libtasn1 0.3.2
Message-ID: <873bhbzpka.fsf@latte.josefsson.org>

Libtasn1 is a standalone library written in C for manipulating ASN.1
objects including DER/BER encoding and DER/BER decoding.  Libtasn1 is
used by GnuTLS to manipulate X.509 objects and by GNU Shishi to handle
Kerberos V5 packets.

Version 0.3.2
- Corrected bug in asn1_der_coding() which overwrited some
  data in the original structure.
- The asn1Parser, asn1Coding and asn1Decoding programs are now installed.

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

If you need help to use Libtasn1, or want to help others, you are
invited to join our help-gnutls mailing list, see:
<http://lists.gnu.org/mailman/listinfo/help-gnutls>.

Homepage:
  http://josefsson.org/libtasn1/

Manual in many formats:
  http://josefsson.org/gnutls/manual/libtasn1/

Here are the compressed sources (1.2MB):
  ftp://ftp.gnutls.org/pub/gnutls/libtasn1/libtasn1-0.3.2.tar.gz
  http://josefsson.org/gnutls/releases/libtasn1/libtasn1-0.3.2.tar.gz

Here are GPG detached signatures using key 0xB565716F:
  ftp://ftp.gnutls.org/pub/gnutls/libtasn1/libtasn1-0.3.2.tar.gz.sig
  http://josefsson.org/gnutls/releases/libtasn1/libtasn1-0.3.2.tar.gz.sig

The software is cryptographically signed by the author using an
OpenPGP key identified by the following information:

pub   1280R/B565716F 2002-05-05 [expires: 2006-08-14]
      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: 2006-08-14]
sub   1024R/09CC4670 2006-03-18 [expires: 2007-04-22]
sub   1024R/AABB1F7B 2006-03-18 [expires: 2007-04-22]
sub   1024R/A14C401A 2006-03-18 [expires: 2007-04-22]

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

Note that the software is signed using my sub-key 0xAABB1F7B which is
stored on an OpenPGP smartcard.

Here are the SHA-1 and SHA-224 checksums:

25c228d9a3675b5d763a671d97438009e9a548d3  libtasn1-0.3.2.tar.gz
e1d1e9fe296329789045651a54c64ca7101d0c50  libtasn1-0.3.2.tar.gz.sig
295c8e1d99167b2e67ffd89188e31c373a1f9cee6080ae3adbe2607d  libtasn1-0.3.2.tar.gz
eb346b8fce70b09a90aa9a3949b1baa3149f85fd67a5daa9b5486ee8  libtasn1-0.3.2.tar.gz.sig

Enjoy,
Fabio, Nikos and Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 377 bytes
Desc: not available
URL: </pipermail/attachments/20060321/c8154741/attachment.pgp>

From jas at extundo.com  Tue Mar 21 18:51:35 2006
From: jas at extundo.com (Simon Josefsson)
Date: Tue, 21 Mar 2006 18:51:35 +0100
Subject: [gnutls-dev] GnuTLS 1.4.0 release candidate 1
Message-ID: <87r74vy9co.fsf@latte.josefsson.org>

We expect to release 1.4.0 shortly, and anything you'd like to change
in the software or in the final announcement (which will look much
like the below) should be sent to us within a few days...

GnuTLS is a modern C library that implement the standard network
security protocol Transport Layer Security (TLS), for use by network
applications.

Noteworthy improvements over the 1.2.x branch:

** Support for TLS Inner application (TLS/IA).  This is per
   draft-funk-tls-inner-application-extension-01, and is compatible
   with the recent -02 version too.

** Support for TLS Pre-Shared Key (TLS-PSK) ciphersuites have been added.

** New APIs to access the TLS Pseudo-Random-Function (PRF) and the
   client and server random fields in a session.  This is primarily
   intended for when GnuTLS is used as a component in other
   authentication protocols, such as the EAP mechanism PEAP and TTLS.

** The session resumption data are now system independent.

** GnuTLS is now easier to port to Windows through mingw32.

** Error messages are now translated using GNU Gettext.

** Documentation improvements, including more discussion of the GnuTLS
   internals.

** New function to set a X.509 private key and certificate pairs,
   and/or CRLs, from an PKCS#12 file.

** Build improvements on many platforms, including 64-bit fixes.

...and the general set of cleanups and improvements.

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.

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>.

The project page of the library is available at:
  http://www.gnutls.org/
  http://www.gnu.org/software/gnutls/
  http://josefsson.org/gnutls/ (updated fastest)

Here are the compressed sources (3.2MB):
  http://josefsson.org/gnutls/releases/gnutls-1.4.0rc1.tar.bz2
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.4.0rc1.tar.bz2

Here are GPG detached signatures signed using key 0xB565716F:
  http://josefsson.org/gnutls/releases/gnutls-1.4.0rc1.tar.bz2.sig
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.4.0rc1.tar.bz2.sig

The software is cryptographically signed by the author using an
OpenPGP key identified by the following information:

pub   1280R/B565716F 2002-05-05 [expires: 2006-08-14]
      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: 2006-08-14]
sub   1024R/09CC4670 2006-03-18 [expires: 2007-04-22]
sub   1024R/AABB1F7B 2006-03-18 [expires: 2007-04-22]
sub   1024R/A14C401A 2006-03-18 [expires: 2007-04-22]

Note that the software is signed using my sub-key 0xAABB1F7B which is
stored on an OpenPGP smartcard, see <https://www.fsfe.org/en/card>.

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

Here are the SHA-1 and SHA-224 checksums:

494a3a8bff64947a61225428e03177a0133859f3  gnutls-1.4.0rc1.tar.bz2
bee5396dac88d48e92d636283ee1ee066eac9866  gnutls-1.4.0rc1.tar.bz2.sig
008c38bb7cf4aa5dc8a0b6f9f56008e396637744ed96acbaa47a1bfb  gnutls-1.4.0rc1.tar.bz2
2769e547938e1a5dee23d988e707505879abd1708803a4ad14179f6e  gnutls-1.4.0rc1.tar.bz2.sig

Enjoy,
Nikos and Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 377 bytes
Desc: not available
URL: </pipermail/attachments/20060321/19b0e9aa/attachment.pgp>

From emile-gnutls at e-advies.nl  Tue Mar 21 19:07:04 2006
From: emile-gnutls at e-advies.nl (Emile van Bergen)
Date: Tue, 21 Mar 2006 19:07:04 +0100
Subject: [gnutls-dev] GnuTLS 1.4.0 release candidate 1
In-Reply-To: <87r74vy9co.fsf@latte.josefsson.org>
References: <87r74vy9co.fsf@latte.josefsson.org>
Message-ID: <20060321180703.GC5895@note.evbergen.xs4all.nl>

Hi,

On Tue, Mar 21, 2006 at 06:51:35PM +0100, Simon Josefsson wrote:

> We expect to release 1.4.0 shortly, and anything you'd like to change
> in the software or in the final announcement (which will look much
> like the below) should be sent to us within a few days...

[SNIP]

> ** Support for TLS Inner application (TLS/IA).  This is per
>    draft-funk-tls-inner-application-extension-01, and is compatible
>    with the recent -02 version too.

I have a patch for that with a proposed API change, hope the FSF's
confirmation of the copyright assignment reaches you in time for you to
review it.

> ** New APIs to access the TLS Pseudo-Random-Function (PRF) and the
>    client and server random fields in a session.  This is primarily
>    intended for when GnuTLS is used as a component in other
>    authentication protocols, such as the EAP mechanism PEAP and TTLS.

I also have a patch for that; it's attached. The purpose is to allow you
to use the higher level PRF function (the one that derives from the
TLS MSK and the randoms) for generating IV material, that's supposed to
be dependent on the randoms, but not on the MSK.

This is useful for PEAPv2 etc. Basically, the server_random_first flag
is changed to a 'type' flag that contains the server_random_first flag
and a 'empty_master_secret' flag in bits 0 and 1, respectively.

Of course one could pull the randoms manually and then call the raw PRF,
but this seemed the cleaner way to do it.

Cheers,


Emile.

-- 
E-Advies - Emile van Bergen           emile at e-advies.nl      
tel. +31 (0)78 6136282           http://www.e-advies.nl    
-------------- next part --------------
diff -ur gnutls-1.3.4-evb0/includes/gnutls/gnutls.h.in gnutls-1.3.4-evb1/includes/gnutls/gnutls.h.in
--- gnutls-1.3.4-evb0/includes/gnutls/gnutls.h.in       2006-02-14 12:13:50.000000000 +0100
+++ gnutls-1.3.4-evb1/includes/gnutls/gnutls.h.in       2006-03-17 12:42:22.000000000 +0100
@@ -399,7 +399,7 @@
 
   int gnutls_prf (gnutls_session_t session,
                  size_t label_size, const char *label,
-                 int server_random_first,
+                 int type,
                  size_t extra_size, const char *extra,
                  size_t outsize, char *out);
 
diff -ur gnutls-1.3.4-evb0/lib/gnutls_state.c gnutls-1.3.4-evb1/lib/gnutls_state.c
--- gnutls-1.3.4-evb0/lib/gnutls_state.c        2005-12-16 12:11:39.000000000 +0100
+++ gnutls-1.3.4-evb1/lib/gnutls_state.c        2006-03-17 13:06:31.000000000 +0100
@@ -949,7 +949,10 @@
  * @session: is a #gnutls_session_t structure.
  * @label_size: length of the @label variable.
  * @label: label used in PRF computation, typically a short string.
- * @server_random_first: non-0 if server random field should be first in seed
+ * @type: flags specifying the type of material to derive
+ *        if bit 0 set, server random is put before client random in seed
+ *         if bit 1 set, use an empty secret instead of the TLS master secret;
+ *         useful for deriving IV material
  * @extra_size: length of the @extra variable.
  * @extra: optional extra data to seed the PRF with.
  * @outsize: size of pre-allocated output buffer to hold the output.
@@ -977,10 +980,10 @@
 gnutls_prf (gnutls_session_t session,
            size_t label_size,
            const char *label,
-           int server_random_first,
+           int type,
            size_t extra_size, const char *extra, size_t outsize, char *out)
 {
-  int ret;
+  int ret, server_random_first = (type & 1), no_msk = (type & 2);
   opaque *seed;
   size_t seedsize = 2 * TLS_RANDOM_SIZE + extra_size;
 
@@ -1000,8 +1003,10 @@
 
   memcpy (seed + 2 * TLS_RANDOM_SIZE, extra, extra_size);
 
-  ret = _gnutls_PRF (session->security_parameters.master_secret,
-                    TLS_MASTER_SIZE,
+  ret = _gnutls_PRF (no_msk ? (const opaque *)""  
+                           : session->security_parameters.master_secret,
+                    no_msk ? 0  
+                           : TLS_MASTER_SIZE,
                     label, label_size, seed, seedsize, outsize, out);
 
   gnutls_free (seed);
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: </pipermail/attachments/20060321/597c9de8/attachment.pgp>