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: References: Message-ID: On 2/28/06, Nikos Mavrogiannopoulos 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: (Nikos Mavrogiannopoulos's message of "Tue, 28 Feb 2006 12:48:59 +0100") References: Message-ID: "Nikos Mavrogiannopoulos" 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: References: Message-ID: On 3/1/06, Travis H. 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: References: Message-ID: On 3/1/06, Nikos Mavrogiannopoulos 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: References: 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: (Nikos Mavrogiannopoulos's message of "Tue, 28 Feb 2006 12:48:59 +0100") References: Message-ID: 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 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: 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 . - 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: . 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: 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: 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: . 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: 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: (Simon Josefsson's message of "Wed, 08 Mar 2006 19:41:30 +0100") References: Message-ID: Simon Josefsson 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: References: Message-ID: <20060308190933.GB3276@downhill.aus.cc> On 2006-03-08 Simon Josefsson 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 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: References: Message-ID: <20060311120814.GA11131@downhill.aus.cc> On 2006-03-01 Simon Josefsson wrote: > "Nikos Mavrogiannopoulos" 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: <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: <20060311120814.GA11131@downhill.aus.cc> <200603111345.09449.nmav@gnutls.org> Message-ID: On 3/11/06, Nikos Mavrogiannopoulos 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: On 3/9/06, Rupert Kittinger 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: References: <20060311120814.GA11131@downhill.aus.cc> <200603111345.09449.nmav@gnutls.org> Message-ID: <20060313184259.GA3799@downhill.aus.cc> On 2006-03-13 Nikos Mavrogiannopoulos 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: <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: <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 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 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: . 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 uid Simon Josefsson 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: 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: . 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 uid Simon Josefsson 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 . 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: 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: