From aqQ439g8u at softhome.com Sun Jul 30 02:42:23 2006 From: aqQ439g8u at softhome.com (aqQ439g8u at softhome.com) Date: 30 Jul 06 2:42:23 PM Subject: [Help-gnutls] Build A Professional Web Site Today Message-ID: <60mPFocavvqThn9D> This is a News Announcement, not a Subscription, so take advantage now! ----------------Visit us at: www.advancewebcreations.com-------------------- Want to improve your companies reach and performance? Create or strengthen your web site's internet presence today with our new Web Builder Program! Since 1994, Advanced Web Creations has been committed to successfully transitioning both existing and start-up companies over the internet. Due to the popular demand, we now offer custom designs starting at $499.00 so you can receive all of the benefits of a professional Web shop - at an affordable price. Select from over 50 designs and customize one to suit your needs and portray your company as a leader in the industry. Upon successfully creating and purchasing your design package, your web site will be available within 2 business days for your review. Here's what the packages include:  A professionally designed Web site consisting of 5 to 11 pages (Example pages could include Home, Company Description, Products, and Contact Us.)  Free registration of custom Web address for one year.  5 to 11 stock images for your web site to help establish the site theme.  Free submission of the web site to the top 25 search engines to ensure search capabilities.  A customized email form to allow user inquiries such as "Contact Requests."  3 months of free consulting and support which includes minor changes to the web site.  Current "Date" displayed along with custom "Drop Down" navigation menu.  Site will be expandable for viewing in different resolution sizes. Ex: 800 x 600 or 1024 x 768  Custom rollover images for navigation.  A copy of all files used to create the web site.  Hosting options are available upon request. Please visit us at www.advancewebcreations.com/builder.htm or contact us at the number listed below for full details. If you are in need of a more professional solution simply discuss your project with one of our consultants to receive a free proposal. We look forward to hearing from you. Advanced Web Creations 17171 Roscoe Blvd Northridge, CA 91325 Phone: 818 708 2841 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ This mailing is done by an independent marketing co. We apologize if this message has reached you in error. Save the Planet, Save the Trees! Advertise via Email. No wasted paper! Delete with one simple keystroke! Less refuse in our Dumps! This is the new way of the new millennium To be removed please email optmeoutnow at aol.com with the word "remove" in the subject line. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ From mario.lenz at gmx.net Wed Jul 5 19:34:38 2006 From: mario.lenz at gmx.net (Mario Lenz) Date: Wed, 05 Jul 2006 19:34:38 +0200 Subject: [Help-gnutls] GnuTLS + GnuPG Message-ID: <1152120878.4336.22.camel@mario> Hi! I'm new to this mailing list and just wanted to ask a question. (Please don't hit me if it's a dumb one, but I just don't get it. I neither found anything on the web.) Well, I'm playing around with GnuTLS a little bit just to find out more about C programming and secure network connections. Well, I wanted to write a small program like an echo server with OpenPGP authentication. But I dont't even get gnutls-serv to work! I used a test key: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.3 (GNU/Linux) mIsERKvW5QEEALF5CLpZ8LdKsfhIBT8wbR/4S95TsQRI8VCNljcuP85pYeGA2yO8 qgT/mkq9IPSL/jiMufTnz7FCR20lC2RXkh50c0Gohj5fVgMXeRKP8fex0AKRkOdX Y6E1cMTbVzdzm3EEN4L1AmqzLlpZ1rS/Up2UavqnAKoV7CbN924hpou3AAYptDJN YXJpbyBUZXN0ICh3aXRob3V0IGEgcGFzc3BocmFzZSkgPG1hcmlvQHRlc3QubmV0 Poi2BBMBAgAgBQJEq9blAhsvBgsJCAcDAgQVAggDBBYCAwECHgECF4AACgkQ7I2d IshvCJtj4wQApqVJ6VMjoc4SnUn4j+bWwVW8pHu09C27Jl0UvPuAGB4M6sfJy/5P fv16FC/gbhXf7T4hZEJrV7TBiwBUt4fk8mpwMrv+8Y3GMQmWbvoGhjoMF1chSJmY 8/+T7f7Er++LtPh3fn0sT0qxYgCp5cQPbc4nAg0RpVc6TxCAFFyYRFI= =xVNR -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP PRIVATE KEY BLOCK----- Version: GnuPG v1.4.3 (GNU/Linux) lQHWBESr1uUBBACxeQi6WfC3SrH4SAU/MG0f+EveU7EESPFQjZY3Lj/OaWHhgNsj vKoE/5pKvSD0i/44jLn058+xQkdtJQtkV5IedHNBqIY+X1YDF3kSj/H3sdACkZDn V2OhNXDE21c3c5txBDeC9QJqsy5aWda0v1KdlGr6pwCqFewmzfduIaaLtwAGKQAD /ib1GuQ5NNcQZYFtd8kwF/RJPFyCwvRz6gtwQDGThKPxq1b20nH9tO5dkkJbd5/T zaiCyylFnfs0AzDvJ/bOijhFD8seJsp8J0xWVVsEIuEeHgUDs/mQhP9bv9acCCfl YfPRtGsE+1Fjvet6mbCKx/lx8uVU/ayoqfaD/TJIE+CRAgDFEGoo/sO9AaXTuVeM BSeElAr/3HWDrCwlAPwrzCSsCmh9OBmgcIWpQ1YIo/I7UQ9o3EBU9NtH8uiafQXp jjuDAgDmjKv2LBkXaHNIrKqbv7IyQW7ynQDsBD8ZIkxagl0H70AEkJ494BzuNH4/ IUjvVh3PH8IHwRGUuhQTFWa22jS9Af4/liWSrX9feQKMDrxuway0NkcYxY1eiXhA Uf0pPrNxF66nTuCHiejSHhomO78mZYxSaYrPcUstwKVvI5GImDK/nAG0Mk1hcmlv IFRlc3QgKHdpdGhvdXQgYSBwYXNzcGhyYXNlKSA8bWFyaW9AdGVzdC5uZXQ+iLYE EwECACAFAkSr1uUCGy8GCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRDsjZ0iyG8I m2PjBACmpUnpUyOhzhKdSfiP5tbBVbyke7T0LbsmXRS8+4AYHgzqx8nL/k9+/XoU L+BuFd/tPiFkQmtXtMGLAFS3h+TyanAyu/7xjcYxCZZu+gaGOgwXVyFImZjz/5Pt /sSv74u0+Hd+fSxPSrFiAKnlxA9tzicCDRGlVzpPEIAUXJhEUg== =n5xc -----END PGP PRIVATE KEY BLOCK----- and tried the files src/openpgp/pub.asc and src/openpgp/sec.asc, but it didn't work. starting: gnutls-serv --echo --pgpkeyfile $PRIVKEY --pgpcertfile $PUBKEY (PRIVKEY and PUBKEY beeing the keys I included in this mail or the ones under src/openpgp/) Then gnutls-cli -p 5556 localhost gives me "Error: Could not negotiate a supported cipher suite." on the server side. I tried it with several combinations of --kx and all those parameters on both the client and the server side. Thanks in advance Mario From nmav at gnutls.org Wed Jul 5 21:40:28 2006 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 5 Jul 2006 21:40:28 +0200 Subject: [Help-gnutls] GnuTLS + GnuPG In-Reply-To: <1152120878.4336.22.camel@mario> References: <1152120878.4336.22.camel@mario> Message-ID: <200607052140.29220.nmav@gnutls.org> On Wed 05 Jul 2006 19:34, Mario Lenz wrote: > Hi! > > I'm new to this mailing list and just wanted to ask a question. > (Please don't hit me if it's a dumb one, but I just don't get it. I > neither found anything on the web.) > Well, I'm playing around with GnuTLS a little bit just to find out > more about C programming and secure network connections. Well, I > wanted to write a small program like an echo server with OpenPGP > authentication. But I dont't even get gnutls-serv to work! I used a > test key: Yes it's true :) I've found a bug in gnutls-serv. If you compile from source replace the USE_OPENPGP ifdefs with ENABLE_OPENPGP. If this doesn't fix your problem, just report again. regards, Nikos From jeremiah.foster at theclickstore.se Thu Jul 6 10:15:26 2006 From: jeremiah.foster at theclickstore.se (Jeremiah Foster) Date: Thu, 06 Jul 2006 10:15:26 +0200 Subject: [Help-gnutls] Previous bug in Debian regarding entropy Gnu-TLS, Exim-4.60, 2.4 kernel Message-ID: <1152173726.3185.15.camel@localhost.localdomain> Hello! I have been lurking on this list a bit and would like to pose the following question. Is the TLS entropy bug in debian solved? To be specific, there was an issue with exim hanging when TLS could not find enough entropy to create a secure connection. This caused problems, but mostly with older kernels. I had been stuck on just such a machine and complained to the exim package maintainers at debian who stated that they needed help with GNUTLS but they were having trouble finding someone with the knowledge required. That bug appears to be active, or maybe it should be called a "known issue," as that is what the debian people call it. Here is a link to the description of the issue, http://wiki.debian.org/PkgExim4KnownBugsInSarge My understanding is that GnuTLS does not generate enough entropy to satisfy exim's requirements. Can this issue be addressed? Jeremiah From jas at extundo.com Thu Jul 6 15:37:43 2006 From: jas at extundo.com (Simon Josefsson) Date: Thu, 06 Jul 2006 15:37:43 +0200 Subject: [Help-gnutls] Re: Previous bug in Debian regarding entropy Gnu-TLS, Exim-4.60, 2.4 kernel In-Reply-To: <1152173726.3185.15.camel@localhost.localdomain> (Jeremiah Foster's message of "Thu, 06 Jul 2006 10:15:26 +0200") References: <1152173726.3185.15.camel@localhost.localdomain> Message-ID: <87odw2q2fs.fsf@latte.josefsson.org> Jeremiah Foster writes: > Hello! > > I have been lurking on this list a bit and would like to pose the > following question. Is the TLS entropy bug in debian solved? > > To be specific, there was an issue with exim hanging when TLS could not > find enough entropy to create a secure connection. This caused problems, > but mostly with older kernels. I had been stuck on just such a machine > and complained to the exim package maintainers at debian who stated that > they needed help with GNUTLS but they were having trouble finding > someone with the knowledge required. > > That bug appears to be active, or maybe it should be called a "known > issue," as that is what the debian people call it. Here is a link to the > description of the issue, > > http://wiki.debian.org/PkgExim4KnownBugsInSarge > > My understanding is that GnuTLS does not generate enough entropy to > satisfy exim's requirements. Can this issue be addressed? I'd love to help on this, but IIRC, the earlier reports were so vague that there wasn't much to work on. One problem was generation of DH or RSA parameters, but the proper solution to that is to generate it in an external process in a cron job every day or similar. Then an exhausted entropy pool shouldn't hang exim. If an exhausted entropy pool really is the problem, then using better /dev/*random devices in Linux is the proper solution. I think it has been established that the current Linux /dev/*random devices are very inefficient and have security problems. There are better alternatives out there too, maybe Debian could try them. However, I'm not sure this is actually the origin of the problems. Measuring the amount of entropy required for every TLS session in exim might be interesting. In any case, that entropy should come from /dev/urandom and not cause hangs. /Simon From nmav at gnutls.org Thu Jul 6 15:56:05 2006 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 6 Jul 2006 15:56:05 +0200 Subject: [Help-gnutls] Re: Previous bug in Debian regarding entropy Gnu-TLS, Exim-4.60, 2.4 kernel In-Reply-To: <87odw2q2fs.fsf@latte.josefsson.org> References: <1152173726.3185.15.camel@localhost.localdomain> <87odw2q2fs.fsf@latte.josefsson.org> Message-ID: <200607061556.05984.nmav@gnutls.org> On Thu 06 Jul 2006 15:37, Simon Josefsson wrote: > > That bug appears to be active, or maybe it should be called a > > "known issue," as that is what the debian people call it. Here is a > > link to the description of the issue, > > http://wiki.debian.org/PkgExim4KnownBugsInSarge > > My understanding is that GnuTLS does not generate enough entropy to > > satisfy exim's requirements. Can this issue be addressed? > > I'd love to help on this, but IIRC, the earlier reports were so vague > that there wasn't much to work on. > One problem was generation of DH or RSA parameters, but the proper > solution to that is to generate it in an external process in a cron > job every day or similar. Then an exhausted entropy pool shouldn't > hang exim. This was a problem in exim, which generated those parameters during a connection. But as far as I know this has been solved in debian. The parameters are now generated off-line with certtool. regards, Nikos From jas at extundo.com Thu Jul 6 16:08:21 2006 From: jas at extundo.com (Simon Josefsson) Date: Thu, 06 Jul 2006 16:08:21 +0200 Subject: [Help-gnutls] Re: Previous bug in Debian regarding entropy Gnu-TLS, Exim-4.60, 2.4 kernel In-Reply-To: <200607061556.05984.nmav@gnutls.org> (Nikos Mavrogiannopoulos's message of "Thu, 6 Jul 2006 15:56:05 +0200") References: <1152173726.3185.15.camel@localhost.localdomain> <87odw2q2fs.fsf@latte.josefsson.org> <200607061556.05984.nmav@gnutls.org> Message-ID: <87bqs2q10q.fsf@latte.josefsson.org> Nikos Mavrogiannopoulos writes: > On Thu 06 Jul 2006 15:37, Simon Josefsson wrote: > >> > That bug appears to be active, or maybe it should be called a >> > "known issue," as that is what the debian people call it. Here is a >> > link to the description of the issue, >> > http://wiki.debian.org/PkgExim4KnownBugsInSarge >> > My understanding is that GnuTLS does not generate enough entropy to >> > satisfy exim's requirements. Can this issue be addressed? >> >> I'd love to help on this, but IIRC, the earlier reports were so vague >> that there wasn't much to work on. >> One problem was generation of DH or RSA parameters, but the proper >> solution to that is to generate it in an external process in a cron >> job every day or similar. Then an exhausted entropy pool shouldn't >> hang exim. > > This was a problem in exim, which generated those parameters during a > connection. But as far as I know this has been solved in debian. The > parameters are now generated off-line with certtool. Then presumably the issue can be solved by back-porting the fix to Debian sarge. /Simon From fweimer at bfk.de Thu Jul 6 16:10:26 2006 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 06 Jul 2006 16:10:26 +0200 Subject: [Help-gnutls] Re: Previous bug in Debian regarding entropy Gnu-TLS, Exim-4.60, 2.4 kernel In-Reply-To: <200607061556.05984.nmav@gnutls.org> (Nikos Mavrogiannopoulos's message of "Thu, 6 Jul 2006 15:56:05 +0200") References: <1152173726.3185.15.camel@localhost.localdomain> <87odw2q2fs.fsf@latte.josefsson.org> <200607061556.05984.nmav@gnutls.org> Message-ID: <82zmfmddt9.fsf@mid.bfk.de> * Nikos Mavrogiannopoulos: > This was a problem in exim, which generated those parameters during a > connection. But as far as I know this has been solved in debian. The > parameters are now generated off-line with certtool. This only works if certtool is actually installed, which is not the default. 8-( But the problem has been solved in principle. Just more polishing is needed. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Durlacher Allee 47 tel: +49-721-96201-1 D-76131 Karlsruhe fax: +49-721-96201-99 From jeremiah.foster at theclickstore.se Thu Jul 6 16:16:10 2006 From: jeremiah.foster at theclickstore.se (Jeremiah Foster) Date: Thu, 06 Jul 2006 16:16:10 +0200 Subject: [Help-gnutls] Re: Previous bug in Debian regarding entropy Gnu-TLS, Exim-4.60, 2.4 kernel In-Reply-To: <87odw2q2fs.fsf@latte.josefsson.org> References: <1152173726.3185.15.camel@localhost.localdomain> <87odw2q2fs.fsf@latte.josefsson.org> Message-ID: <1152195370.3185.66.camel@localhost.localdomain> On Thu, 2006-07-06 at 15:37 +0200, Simon Josefsson wrote: > Jeremiah Foster writes: > > To be specific, there was an issue with exim hanging when TLS could not > > find enough entropy to create a secure connection. This caused problems, > > but mostly with older kernels. I had been stuck on just such a machine > > and complained to the exim package maintainers at debian who stated that > > they needed help with GNUTLS but they were having trouble finding > > someone with the knowledge required. > > > > That bug appears to be active, or maybe it should be called a "known > > issue," as that is what the debian people call it. Here is a link to the > > description of the issue, > > > > http://wiki.debian.org/PkgExim4KnownBugsInSarge > > > > My understanding is that GnuTLS does not generate enough entropy to > > satisfy exim's requirements. Can this issue be addressed? > > I'd love to help on this, but IIRC, the earlier reports were so vague > that there wasn't much to work on. > > One problem was generation of DH or RSA parameters, but the proper > solution to that is to generate it in an external process in a cron > job every day or similar. Then an exhausted entropy pool shouldn't > hang exim. > > If an exhausted entropy pool really is the problem, then using better > /dev/*random devices in Linux is the proper solution. I think it has > been established that the current Linux /dev/*random devices are very > inefficient and have security problems. There are better alternatives > out there too, maybe Debian could try them. However, I'm not sure > this is actually the origin of the problems. I think there is a cron shell script fix provided on the debian exim web site, and I have heard that /dev/urandom is somewhat more secure on linux than /dev/random, but that the security and efficiency issues are as you say, that is problematic. > Measuring the amount of entropy required for every TLS session in exim > might be interesting. In any case, that entropy should come from > /dev/urandom and not cause hangs. A bit over my head unfortunately, but I will post this suggestion to the debian-exim mailing list when the issues comes up again. Thanks! Jeremiah From nmav at gnutls.org Thu Jul 6 16:37:03 2006 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 6 Jul 2006 16:37:03 +0200 Subject: [Help-gnutls] Re: Previous bug in Debian regarding entropy Gnu-TLS, Exim-4.60, 2.4 kernel In-Reply-To: <1152195370.3185.66.camel@localhost.localdomain> References: <1152173726.3185.15.camel@localhost.localdomain> <87odw2q2fs.fsf@latte.josefsson.org> <1152195370.3185.66.camel@localhost.localdomain> Message-ID: <200607061637.04200.nmav@gnutls.org> On Thu 06 Jul 2006 16:16, Jeremiah Foster wrote: > I think there is a cron shell script fix provided on the debian exim > web site, and I have heard that /dev/urandom is somewhat more secure > on linux than /dev/random, but that the security and efficiency > issues are as you say, that is problematic. This is a common misunderstanding. /dev/urandom and /dev/random are the same random generator. The only difference is that /dev/random blocks when it thinks there is no entry available. And according to the author it is more "secure". However there is no evidence to support that claim (and currently there is only evidence to the contrary). There are more efficient CPRNGs such as the yarrow (freebsd) which are better studied than the Linux' and considered secure. regards, Nikos From jas at extundo.com Thu Jul 6 16:42:30 2006 From: jas at extundo.com (Simon Josefsson) Date: Thu, 06 Jul 2006 16:42:30 +0200 Subject: [Help-gnutls] Re: Previous bug in Debian regarding entropy Gnu-TLS, Exim-4.60, 2.4 kernel In-Reply-To: <1152195370.3185.66.camel@localhost.localdomain> (Jeremiah Foster's message of "Thu, 06 Jul 2006 16:16:10 +0200") References: <1152173726.3185.15.camel@localhost.localdomain> <87odw2q2fs.fsf@latte.josefsson.org> <1152195370.3185.66.camel@localhost.localdomain> Message-ID: <873bdepzft.fsf@latte.josefsson.org> Jeremiah Foster writes: > I think there is a cron shell script fix provided on the debian exim web > site It should probably be packaged, it seems to be the proper solution. Also, exim probably shouldn't use the file if it is stale, i.e. if it is too old. The parameters should be rebuilt once a day or so. > and I have heard that /dev/urandom is somewhat more secure on > linux than /dev/random, but that the security and efficiency issues > are as you say, that is problematic. /dev/random blocks when no more entropy is available, /dev/urandom doesn't block. The data is the same if the entropy pool is not empty, if the entropy pool is empty, the /dev/urandom data will be less good. However, it seems both devices aren't state-of-the-art (P)RNG's, so the output shouldn't be trusted too much; libgcrypt does additional mixing, which is sadly probably necessary. /Simon From nmav at gnutls.org Thu Jul 6 18:54:38 2006 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 6 Jul 2006 18:54:38 +0200 Subject: [Help-gnutls] Re: Previous bug in Debian regarding entropy Gnu-TLS, Exim-4.60, 2.4 kernel In-Reply-To: <873bdepzft.fsf@latte.josefsson.org> References: <1152173726.3185.15.camel@localhost.localdomain> <1152195370.3185.66.camel@localhost.localdomain> <873bdepzft.fsf@latte.josefsson.org> Message-ID: <200607061854.38623.nmav@gnutls.org> On Thu 06 Jul 2006 16:42, Simon Josefsson wrote: > It should probably be packaged, it seems to be the proper solution. > Also, exim probably shouldn't use the file if it is stale, i.e. if it > is too old. The parameters should be rebuilt once a day or so. Indeed. The RSA parameters are quite short 512 bits so they need quite frequent regeneration. The DH parameters could be there for months or so (if they are over 1024 bits). regards, Nikos From fweimer at bfk.de Fri Jul 7 09:12:16 2006 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 07 Jul 2006 09:12:16 +0200 Subject: [Help-gnutls] Re: Previous bug in Debian regarding entropy Gnu-TLS, Exim-4.60, 2.4 kernel In-Reply-To: <200607061854.38623.nmav@gnutls.org> (Nikos Mavrogiannopoulos's message of "Thu, 6 Jul 2006 18:54:38 +0200") References: <1152173726.3185.15.camel@localhost.localdomain> <1152195370.3185.66.camel@localhost.localdomain> <873bdepzft.fsf@latte.josefsson.org> <200607061854.38623.nmav@gnutls.org> Message-ID: <82ac7ldh2n.fsf@mid.bfk.de> * Nikos Mavrogiannopoulos: > Indeed. The RSA parameters are quite short 512 bits so they need quite > frequent regeneration. I would be surprised if RSA_EXPORT support is needed at all. I don't see it in my mail server logs, and don't you need a special server certificate to enable it anyway? > The DH parameters could be there for months or so (if they are over > 1024 bits). And they don't need to be based on bits from /dev/random. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Durlacher Allee 47 tel: +49-721-96201-1 D-76131 Karlsruhe fax: +49-721-96201-99 From mario.lenz at gmx.net Fri Jul 7 16:34:51 2006 From: mario.lenz at gmx.net (Mario Lenz) Date: Fri, 07 Jul 2006 16:34:51 +0200 Subject: [Help-gnutls] GnuTLS + GnuPG In-Reply-To: <200607052140.29220.nmav@gnutls.org> References: <1152120878.4336.22.camel@mario> <200607052140.29220.nmav@gnutls.org> Message-ID: <1152282892.4130.3.camel@mario> Hi! > Yes it's true :) I've found a bug in gnutls-serv. If you compile from > source replace the USE_OPENPGP ifdefs with ENABLE_OPENPGP. > > If this doesn't fix your problem, just report again. Now everything breaks down. gnutls-serv reads my key now, but look: I change to directory gnutls-1.4.0/src and start "./gnutls-serv --echo --pgpkeyfile /path/to/keys/privkey --pgpcertfile /path/to/keys/pubkey" Then I change (in another terminal window) to the same directory and start "/gnutls-cli -p 5556 --xml localhost". This gives me a segmentation fault. Something's not working in function _gnutls_send_server_certificate_request in lib/gnutls_kx.c: "session->internals.auth_struct->gnutls_generate_server_certificate_request (session, &data);" fails. If I delete "if (session->internals.resumed == RESUME_FALSE) ret = _gnutls_send_server_certificate_request (session, AGAIN (STATE5));" (function _gnutls_handshake_server in file lib/gnutls_handshake.c, look for "case STATE5:") everything works. I'd have to dive pretty deep into the code from here on if you don't have any suggestions. > regards, > Nikos greez Mario From nmav at gnutls.org Sat Jul 8 14:55:43 2006 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 8 Jul 2006 14:55:43 +0200 Subject: [Help-gnutls] GnuTLS + GnuPG In-Reply-To: <1152282892.4130.3.camel@mario> References: <1152120878.4336.22.camel@mario> <200607052140.29220.nmav@gnutls.org> <1152282892.4130.3.camel@mario> Message-ID: <200607081455.44039.nmav@gnutls.org> On 7/7/06, Mario Lenz wrote: > Hi! > > > Yes it's true :) I've found a bug in gnutls-serv. If you compile from > > source replace the USE_OPENPGP ifdefs with ENABLE_OPENPGP. > > If this doesn't fix your problem, just report again. > Now everything breaks down. gnutls-serv reads my key now, but look: Ah, this is a bug introduced in the latest release. It was already fixed, but there was no release since then. You can use the cvs version for now which fixes the bug. regards, Nikos From nmav at gnutls.org Sat Jul 8 15:02:17 2006 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 8 Jul 2006 15:02:17 +0200 Subject: [Help-gnutls] Re: Previous bug in Debian regarding entropy Gnu-TLS, Exim-4.60, 2.4 kernel In-Reply-To: <82ac7ldh2n.fsf@mid.bfk.de> References: <1152173726.3185.15.camel@localhost.localdomain> <200607061854.38623.nmav@gnutls.org> <82ac7ldh2n.fsf@mid.bfk.de> Message-ID: <200607081502.17549.nmav@gnutls.org> On Fri 07 Jul 2006 09:12, Florian Weimer wrote: > > Indeed. The RSA parameters are quite short 512 bits so they need > > quite frequent regeneration. > I would be surprised if RSA_EXPORT support is needed at all. I don't > see it in my mail server logs, and don't you need a special server > certificate to enable it anyway? The only requirement is for the server certificate to be able to be used for signing. > > The DH parameters could be there for months or so (if they are over > > 1024 bits). > And they don't need to be based on bits from /dev/random. Indeed. But in the versions of linux used, they depleted the same pool, thus again /dev/random was blocked. regards, Nikos From jas at extundo.com Sat Jul 8 20:24:19 2006 From: jas at extundo.com (Simon Josefsson) Date: Sat, 08 Jul 2006 20:24:19 +0200 Subject: [Help-gnutls] Re: GnuTLS + GnuPG In-Reply-To: <200607081455.44039.nmav@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sat, 8 Jul 2006 14:55:43 +0200") References: <1152120878.4336.22.camel@mario> <200607052140.29220.nmav@gnutls.org> <1152282892.4130.3.camel@mario> <200607081455.44039.nmav@gnutls.org> Message-ID: <87irm8ymy4.fsf@latte.josefsson.org> Nikos Mavrogiannopoulos writes: > On 7/7/06, Mario Lenz wrote: >> Hi! >> >> > Yes it's true :) I've found a bug in gnutls-serv. If you compile > from >> > source replace the USE_OPENPGP ifdefs with ENABLE_OPENPGP. >> > If this doesn't fix your problem, just report again. > >> Now everything breaks down. gnutls-serv reads my key now, but look: > > Ah, this is a bug introduced in the latest release. It was already > fixed, but there was no release since then. You can use the cvs > version for now which fixes the bug. And for those who hesitate to build from CVS, I'd like to promote the daily snapshots more, see: http://josefsson.org/daily/gnutls/ (CVS trunk, currently 1.5) http://josefsson.org/daily/gnutls-1.2/ http://josefsson.org/daily/gnutls-1.4/ They build like regular releases, and for the 1.2 and 1.4 branches, they should be as stable as real releases on the respective branch. /Simon From mario.lenz at gmx.net Mon Jul 10 20:15:16 2006 From: mario.lenz at gmx.net (Mario Lenz) Date: Mon, 10 Jul 2006 20:15:16 +0200 Subject: [Help-gnutls] gnutls-cli can't open OpenPGP key Message-ID: <1152555316.4165.8.camel@mario> Hi! There seems to be a bug in src/cli.c in line 265. It should read "data = load_file (pgp_keyfile);" instead of "data = load_file (x509_keyfile);". Another thing: gnutls_openpgp_privkey_import in libextra/openpgp/privkey.c ignores the format parameter. cu Mario From jas at extundo.com Mon Jul 10 23:09:00 2006 From: jas at extundo.com (Simon Josefsson) Date: Mon, 10 Jul 2006 23:09:00 +0200 Subject: [Help-gnutls] Re: gnutls-cli can't open OpenPGP key In-Reply-To: <1152555316.4165.8.camel@mario> (Mario Lenz's message of "Mon, 10 Jul 2006 20:15:16 +0200") References: <1152555316.4165.8.camel@mario> Message-ID: <87k66ltbf7.fsf@latte.josefsson.org> Mario Lenz writes: > Hi! > > There seems to be a bug in src/cli.c in line 265. It should read "data = > load_file (pgp_keyfile);" instead of "data = load_file (x509_keyfile);". Hi! Thanks for the report. I've installed this. > Another thing: gnutls_openpgp_privkey_import in > libextra/openpgp/privkey.c ignores the format parameter. Yes, but it should support both BASE64 and RAW keys anyway. Doesn't it? /Simon From fweimer at bfk.de Wed Jul 12 12:51:15 2006 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 12 Jul 2006 12:51:15 +0200 Subject: [Help-gnutls] Re: Previous bug in Debian regarding entropy Gnu-TLS, Exim-4.60, 2.4 kernel In-Reply-To: <200607081502.17549.nmav@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sat, 8 Jul 2006 15:02:17 +0200") References: <1152173726.3185.15.camel@localhost.localdomain> <200607061854.38623.nmav@gnutls.org> <82ac7ldh2n.fsf@mid.bfk.de> <200607081502.17549.nmav@gnutls.org> Message-ID: <821wsrayfw.fsf@mid.bfk.de> * Nikos Mavrogiannopoulos: >> I would be surprised if RSA_EXPORT support is needed at all. I don't >> see it in my mail server logs, and don't you need a special server >> certificate to enable it anyway? > > The only requirement is for the server certificate to be able to be used > for signing. I don't think this is correct; the certificate issuer must come from certain well-known CAs which allow upgrading to a better security level. If you don't need interoperability with crippled clients, you'd use RSA instead of RSA_EXPORT in the first place. > Indeed. But in the versions of linux used, they depleted the same pool, > thus again /dev/random was blocked. But on a typical GNU/Linux system, no periodic tasks read from /dev/random, so it doesn't matter if the pool has been depleted or not. And the process which generates the key parameters for Exim would not block, either. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Durlacher Allee 47 tel: +49-721-96201-1 D-76131 Karlsruhe fax: +49-721-96201-99 From fweimer at bfk.de Wed Jul 12 13:21:17 2006 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 12 Jul 2006 13:21:17 +0200 Subject: [Help-gnutls] Peer certificates not signed by any CA In-Reply-To: <200606220121.37984.n.mavrogiannopoulos@gmail.com> (Nikos Mavrogiannopoulos's message of "Thu, 22 Jun 2006 01:21:37 +0200") References: <20060613083128.GA7946@mx00.int.bfk.de> <20060613125134.GA2698@mx00.int.bfk.de> <20060613142835.GA26436@mx00.int.bfk.de> <200606220121.37984.n.mavrogiannopoulos@gmail.com> Message-ID: <82sll79ihe.fsf@mid.bfk.de> * Nikos Mavrogiannopoulos: >> May I assume that the first certificate returned by >> gnutls_certifcate_get_peers contains public key material which >> actually corresponds to the private key material which was used to >> establish the ssession? > No. That would be the last certificate in the chain. Ah, thanks. >> By the way, gnutls_certificate_client_set_retrieve_function is not a >> well-designed interface. The callback function lacks a closure >> parameter. > What do you mean by closure parameter? Most libraries provide a void * argument which can be used to pass user data to the callback function. For an example, see libpcap and pcap_loop. >> Even worse, it is hard to fake it because >> gnutls_certificate_client_set_retrieve_function is called with a >> credentials structure, and the callback is called with a session >> structure. Extremely annoying. > But you want to know the session in the callback (to obtain information > about the current session). The session is the caller of the callback. I might also need a database handle to fetch data that is used to verify the client certificate, or to locate the function that should be called. Currently, I put the data I need into the transport data structure and call gnutls_transport_get_ptr in the verification callback function, but this is rather hackish. It seems that gnutls_certificate_verify_peers2 sometimes returns 0 even though no matching certificate chain has been provided. Shall we discuss details on this mailing list or somewhere else? -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Durlacher Allee 47 tel: +49-721-96201-1 D-76131 Karlsruhe fax: +49-721-96201-99 From jas at extundo.com Wed Jul 12 13:45:52 2006 From: jas at extundo.com (Simon Josefsson) Date: Wed, 12 Jul 2006 13:45:52 +0200 Subject: [Help-gnutls] Re: Peer certificates not signed by any CA In-Reply-To: <82sll79ihe.fsf@mid.bfk.de> (Florian Weimer's message of "Wed, 12 Jul 2006 13:21:17 +0200") References: <20060613083128.GA7946@mx00.int.bfk.de> <20060613125134.GA2698@mx00.int.bfk.de> <20060613142835.GA26436@mx00.int.bfk.de> <200606220121.37984.n.mavrogiannopoulos@gmail.com> <82sll79ihe.fsf@mid.bfk.de> Message-ID: <87ac7foxlb.fsf@latte.josefsson.org> Florian Weimer writes: > It seems that gnutls_certificate_verify_peers2 sometimes returns 0 > even though no matching certificate chain has been provided. Oh, interesting. > Shall we discuss details on this mailing list or somewhere else? Maybe gnutls-dev at gnupg.org is more appropriate. /Simon From jas at extundo.com Fri Jul 14 12:27:56 2006 From: jas at extundo.com (Simon Josefsson) Date: Fri, 14 Jul 2006 12:27:56 +0200 Subject: [Help-gnutls] GnuTLS 1.4.1 Message-ID: <87irm0wker.fsf@latte.josefsson.org> I am happy to announce GnuTLS 1.4.1, a bugfix release on the stable 1.4 branch. This version is what we recommend for those who need a stable version of GnuTLS. We've had problems with the ftp.gnutls.org server lately, and I couldn't upload this release to it. Hence, this release is only available from my server below. We're looking into moving the ftp server to ftp.gnu.org instead. 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 1.4.0: ** Replaced inactive ifdefs to enable openpgp support in test programs. ** Fixed bug in OpenPGP authentication handshake. ** Fixed typographical in man pages. ** Build fixes of the manual. ** Added Swedish translation. ** API and ABI modifications: No changes since last version. 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. All manual formats are available from: http://www.gnutls.org/manual/ Direct link to the most popular formats: http://www.gnutls.org/manual/gnutls.html - HTML format http://www.gnutls.org/manual/gnutls.pdf - PDF format http://www.gnutls.org/reference/ch01.html - API Reference, GTK-DOC HTML 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.9MB): http://josefsson.org/gnutls/releases/gnutls-1.4.1.tar.bz2 Here are GPG detached signatures signed using key 0xB565716F: http://josefsson.org/gnutls/releases/gnutls-1.4.1.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] 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: 25d183fef21abbcaab0afe6b5809893aa70b577d gnutls-1.4.1.tar.bz2 65547a50e5b3e2158d46972d4eee882d3a404338 gnutls-1.4.1.tar.bz2.sig 1bc91d0abfb5ae847cc06ae2df841ff39682b2574c6dba0cf80e1f0e gnutls-1.4.1.tar.bz2 afadd68e1b75b241a96364c4436b00ea2a8eeca156cd9fe1da775bf5 gnutls-1.4.1.tar.bz2.sig Enjoy, Nikos and Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From mario.lenz at gmx.net Tue Jul 18 22:22:12 2006 From: mario.lenz at gmx.net (Mario Lenz) Date: Tue, 18 Jul 2006 22:22:12 +0200 Subject: [Help-gnutls] Client OpenPGP verification fails Message-ID: <1153254133.13947.35.camel@mario> Hi! I've been trying not only to verify the server, but also the client. I have this problem with one of the daily 1.5.0 snapshots as well as with the 1.4.1 version. To make sure it wasn't my mistake, I tried to use gnutls-serv and gnutls-cli from src: cd libgnutls-1.4.1/src ./gnutls-serv --echo --pgpkeyfile /path/to/privkey --pgpcertfile /path/to/pubkey --dhparams params.pem I found params.pem in the src directory. Output: Error in handshake Error: A TLS packet with unexpected length was received. gnutls-cli: cd libgnutls-1.4.1/src ./gnutls-cli --xml --pgpkeyfile /path/to/otherprivkey --pgpcertfile /path/to/otherpubkey -p 5556 localhost ends with: *** Fatal error: GnuTLS internal error. *** Handshake has failed GNUTLS ERROR: GnuTLS internal error. If I dont't tell the client to use keys to identify, everything works. I've tried to find the error, but it's com- pli- ca- ted. If you want me to run it again in debug mode and mail the output, please tell me what level (-d ?) you would prefer. greez Mario PS gnutls_certificate_set_openpgp_key_mem doesn't work either, but the problem seems to be in libopencdk. Does anyone know if this is a general OpenCDK problem or one that's specific to Debian Etch? From mario.lenz at gmx.net Wed Jul 19 20:47:36 2006 From: mario.lenz at gmx.net (Mario Lenz) Date: Wed, 19 Jul 2006 18:47:36 +0000 (UTC) Subject: [Help-gnutls] Re: Client OpenPGP verification fails References: <1153254133.13947.35.camel@mario> Message-ID: > PS > gnutls_certificate_set_openpgp_key_mem doesn't work either, but the > problem seems to be in libopencdk. Does anyone know if this is a general > OpenCDK problem or one that's specific to Debian Etch? Sorry, forget about this. I've made a stupid mistake and- after correcting it- gnutls_certificate_set_openpgp_key_mem works. Sorry :-/ I'm still not any further with the main Problem. Mario From mario.lenz at gmx.net Sun Jul 23 12:49:55 2006 From: mario.lenz at gmx.net (Mario Lenz) Date: Sun, 23 Jul 2006 10:49:55 +0000 (UTC) Subject: [Help-gnutls] Client OpenPGP verification fails (update) References: <1153254133.13947.35.camel@mario> Message-ID: Hi! _gnutls_openpgp_key_to_gcert() in libextra/gnutls_openpgp.c calls gnutls_openpgp_key_export() with the parameter GNUTLS_OPENPGP_FMT_RAW. gnutls_openpgp_key_export() in libextra/openpgp/pgp.c only handles GNUTLS_OPENPGP_FMT_BASE64. greez Mario From nmav at gnutls.org Tue Jul 25 15:47:23 2006 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 25 Jul 2006 15:47:23 +0200 Subject: [Help-gnutls] Client OpenPGP verification fails (update) In-Reply-To: References: <1153254133.13947.35.camel@mario> Message-ID: <200607251547.24345.nmav@gnutls.org> On Sun 23 Jul 2006 12:49, Mario Lenz wrote: > Hi! > > _gnutls_openpgp_key_to_gcert() in libextra/gnutls_openpgp.c calls > gnutls_openpgp_key_export() with the parameter > GNUTLS_OPENPGP_FMT_RAW. gnutls_openpgp_key_export() in > libextra/openpgp/pgp.c only handles GNUTLS_OPENPGP_FMT_BASE64. Are you sure? I didn't test it but it seems that the first call to cdk_kbnode_write_to_mem() does the work... regards, Nikos From mario.lenz at gmx.net Tue Jul 25 19:56:48 2006 From: mario.lenz at gmx.net (Mario Lenz) Date: Tue, 25 Jul 2006 19:56:48 +0200 Subject: [Help-gnutls] Client OpenPGP verification fails (update) In-Reply-To: <200607251547.24345.nmav@gnutls.org> References: <1153254133.13947.35.camel@mario> <200607251547.24345.nmav@gnutls.org> Message-ID: <1153850209.4355.22.camel@mario> Hi! > Are you sure? I didn't test it but it seems that the first call to > cdk_kbnode_write_to_mem() does the work... (I'm talking about 1.4.1 here. I think I'll have some time next week to have a look at 1.5.0.) Well, the function gnutls_openpgp_key_export looks like this: /* call cdk_kbnode_write_to_mem() and handle return value */ if (format == GNUTLS_OPENPGP_FMT_BASE64) { /* code */ } return 0; I inserted "printf("gnutls_openpgp_key_export format == GNUTLS_OPENPGP_FMT_BASE64\n");" at the beginning of the if block and "printf("gnutls_openpgp_key_export format != GNUTLS_OPENPGP_FMT_BASE64 \n");" just befor the return and I can see that the if isn't processed. OK, this might be correct and there's nothing to do when the format isn't GNUTLS_OPENPGP_FMT_BASE64. You should know better than me :-) But then there's another problem in libextra/gnutls_openpgp.c. Please have a look at _gnutls_openpgp_key_to_gcert: ret = gnutls_openpgp_key_export (cert, GNUTLS_OPENPGP_FMT_RAW, NULL, &der_size); if (ret != GNUTLS_E_SHORT_MEMORY_BUFFER) { gnutls_assert (); return ret; } The function always dies, except when there's a specific error. cu Mario From nmav at gnutls.org Tue Jul 25 20:17:37 2006 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 25 Jul 2006 20:17:37 +0200 Subject: [Help-gnutls] Client OpenPGP verification fails (update) In-Reply-To: <1153850209.4355.22.camel@mario> References: <1153254133.13947.35.camel@mario> <200607251547.24345.nmav@gnutls.org> <1153850209.4355.22.camel@mario> Message-ID: <200607252017.38245.nmav@gnutls.org> On Tue 25 Jul 2006 19:56, Mario Lenz wrote: > Hi! > > > Are you sure? I didn't test it but it seems that the first call to > > cdk_kbnode_write_to_mem() does the work... > > (I'm talking about 1.4.1 here. I think I'll have some time next week > to have a look at 1.5.0.) I think the openpgp part is the same since 1.0.x. Hasn't really changed. > Well, the function gnutls_openpgp_key_export looks like this: > > /* call cdk_kbnode_write_to_mem() and handle return value */ This should be doing the convertion to raw encoding. Then it proceeds if only if conversion to base64 is needed. > But then there's another problem in libextra/gnutls_openpgp.c. Please > have a look at _gnutls_openpgp_key_to_gcert: > > ret = gnutls_openpgp_key_export (cert, GNUTLS_OPENPGP_FMT_RAW, NULL, > &der_size); > if (ret != GNUTLS_E_SHORT_MEMORY_BUFFER) > { > gnutls_assert (); > return ret; > } This should be correct since decoding should fail (check that the output pointer is NULL so there is no place to copy the output). That call is there to get the size of the exported key only. > The function always dies, except when there's a specific error. You're not really supposed to call this function directly! :) But anyway did you notice failures in this function? regards, Nikos From mario.lenz at gmx.net Tue Jul 25 23:41:15 2006 From: mario.lenz at gmx.net (Mario Lenz) Date: Tue, 25 Jul 2006 23:41:15 +0200 Subject: [Help-gnutls] Client OpenPGP verification fails (update) In-Reply-To: <200607252017.38245.nmav@gnutls.org> References: <1153254133.13947.35.camel@mario> <200607251547.24345.nmav@gnutls.org> <1153850209.4355.22.camel@mario> <200607252017.38245.nmav@gnutls.org> Message-ID: <1153863676.4355.46.camel@mario> Hi! > You're not really supposed to call this function directly! :) I don't. I just follow the programm and try to find out what's wrong. I found some stuff that seemed weird to me, and so I posted it. But I was wrong. Sorry for that :-/ OK, next try: cert->subject_pk_algorithm in _gnutls_tls_sign_hdata (lib/gnutls_sig.c) is unknown, so the function returns GNUTLS_E_INTERNAL_ERROR. But I'm getting tired (it's nearly midnight and I have to get up at 6 in the morning). I'm not at home for some days, but I'll have a look at it when I'm back. cu Mario From nmav at gnutls.org Wed Jul 26 16:02:13 2006 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 26 Jul 2006 16:02:13 +0200 Subject: [Help-gnutls] Client OpenPGP verification fails (update) In-Reply-To: <1153863676.4355.46.camel@mario> References: <1153254133.13947.35.camel@mario> <200607252017.38245.nmav@gnutls.org> <1153863676.4355.46.camel@mario> Message-ID: <200607261602.14817.nmav@gnutls.org> On Tue 25 Jul 2006 23:41, Mario Lenz wrote: > Hi! > > > You're not really supposed to call this function directly! :) > > I don't. I just follow the programm and try to find out what's wrong. > I found some stuff that seemed weird to me, and so I posted it. But I > was wrong. Sorry for that :-/ Don't feel sorry, it's nice to know somebody is checking our (old now) code. > OK, next try: cert->subject_pk_algorithm in _gnutls_tls_sign_hdata > (lib/gnutls_sig.c) is unknown, so the function returns > GNUTLS_E_INTERNAL_ERROR. Why is subject_pk_algorithm unknown? For openpgp keys it should be set in openpgp_pk_to_gnutls_cert(). regards, Nikos PS. for these questions you might want to use the gnutls-dev ML. From regit at inl.fr Sat Jul 29 11:47:00 2006 From: regit at inl.fr (Eric Leblond) Date: Sat, 29 Jul 2006 11:47:00 +0200 Subject: [Help-gnutls] gnutls_handshake() is slow and is a big lock Message-ID: <1154166420.8178.10.camel@localhost> Hi, After a long benchmark week, we found some slowness in our program (NuFW : http://www;nufw.org). The main point is that gnutls_handshake() is "slow". Slow means : * ~200ms on an AMD 2GHz * ~500 ms on an IBM PowerPC with 4 CPU bicore !? The weirdest thing is that it takes only about 30ms on a laptop (Intel Celeron 1.6Ghz) For that test, we use the same clients and only switch the server target, thus time comes from the server. We dig into gnutls code, and we found *the* function which takes so much time. At the server site, the function is: _gnutls_pkcs1_rsa_decrypt() -- lib/auth_rsa.c Another *BAD* point is that the handshake doesn't look to be possible on multiple threads whereas server code uses a lot of thread. So, any idea to explain why _gnutls_pkcs1_rsa_decrypt() is so slow on my computer and really faster on another one? And do you think that gnutls_handshake() can be used in two different threads at the same time? We tried different gnutls and gcrypt versions. I'm using last version of gcrypt and gnutls on my computer. (gnutls 1.2.2 and gnutls 1.4). -- Victor Stinner and Eric Leblond From jas at extundo.com Sat Jul 29 13:50:06 2006 From: jas at extundo.com (Simon Josefsson) Date: Sat, 29 Jul 2006 13:50:06 +0200 Subject: [Help-gnutls] Re: gnutls_handshake() is slow and is a big lock In-Reply-To: <1154166420.8178.10.camel@localhost> (Eric Leblond's message of "Sat, 29 Jul 2006 11:47:00 +0200") References: <1154166420.8178.10.camel@localhost> Message-ID: <87mzas6369.fsf@latte.josefsson.org> Eric Leblond writes: > Hi, > > After a long benchmark week, we found some slowness in our program > (NuFW : http://www;nufw.org). Hi! Cool. I don't think we have really spent much time on optimizing GnuTLS, so your efforts are great. > The main point is that gnutls_handshake() is "slow". Slow means : > * ~200ms on an AMD 2GHz > * ~500 ms on an IBM PowerPC with 4 CPU bicore !? > The weirdest thing is that it takes only about 30ms on a laptop (Intel > Celeron 1.6Ghz) Maybe some thread or locking issue. > For that test, we use the same clients and only switch the server > target, thus time comes from the server. > > We dig into gnutls code, and we found *the* function which takes so much > time. At the server site, the function is: > _gnutls_pkcs1_rsa_decrypt() -- lib/auth_rsa.c Can you tell whether the majority of that time is spent in gcry_pk_decrypt or somewhere else? I have been working on an abstract crypto layer between GnuTLS and gcrypt, to simplify adding specialized routines for a particular algorithm, or even hardware accelerators. Hashing and symmetric operations have already been finished, but unfortunately I ran out of spare time for the MPI/PK part. > Another *BAD* point is that the handshake doesn't look to be possible on > multiple threads whereas server code uses a lot of thread. I'm not sure I follow here. Why doesn't this work? You shouldn't use the same gnutls_session from several threads at the same time, but presumably, you have one thread for each gnutls_session don't you? I haven't tried it, but I think it should work. > So, any idea to explain why _gnutls_pkcs1_rsa_decrypt() is so slow on my > computer and really faster on another one? Hm. Libgcrypt seem to need strong randomness for blinding purposes, maybe this is what stalls everything? Try disabling blinding in libgcrypt and try again. I.e., insert 'flags |= PUBKEY_FLAG_NO_BLINDING;' into cipher/rsa.c at the top of _gcry_rsa_decrypt(). > And do you think that gnutls_handshake() can be used in two > different threads at the same time? If you use different gnutls_session objects in each thread, I think this should work. But I haven't tested it. Maybe you need extra copies of other structures too, used by the gnutls_session. Hope this helps, Simon From nmav at gnutls.org Sat Jul 29 14:03:21 2006 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 29 Jul 2006 14:03:21 +0200 Subject: [Help-gnutls] Re: gnutls_handshake() is slow and is a big lock In-Reply-To: <87mzas6369.fsf@latte.josefsson.org> References: <1154166420.8178.10.camel@localhost> <87mzas6369.fsf@latte.josefsson.org> Message-ID: <200607291403.22746.nmav@gnutls.org> On Sat 29 Jul 2006 13:50, Simon Josefsson wrote: > > And do you think that gnutls_handshake() can be used in two > > different threads at the same time? > If you use different gnutls_session objects in each thread, I think > this should work. But I haven't tested it. Maybe you need extra > copies of other structures too, used by the gnutls_session. Yes, if a gnutls_session object is only accessed by a single thread it works (of course the locks for libgcrypt need to be set up). The hydra web server (http://hydra.hellug.gr) uses gnutls and works pretty much ok. regards, Nikos From regit at inl.fr Sat Jul 29 14:14:30 2006 From: regit at inl.fr (Eric Leblond) Date: Sat, 29 Jul 2006 14:14:30 +0200 Subject: [Help-gnutls] Re: gnutls_handshake() is slow and is a big lock In-Reply-To: <87mzas6369.fsf@latte.josefsson.org> References: <1154166420.8178.10.camel@localhost> <87mzas6369.fsf@latte.josefsson.org> Message-ID: <1154175270.8178.33.camel@localhost> Le samedi 29 juillet 2006 ? 13:50 +0200, Simon Josefsson a ?crit : > Eric Leblond writes: > > > Hi, > > > > After a long benchmark week, we found some slowness in our program > > (NuFW : http://www;nufw.org). > > Hi! Cool. I don't think we have really spent much time on optimizing > GnuTLS, so your efforts are great. > > > The main point is that gnutls_handshake() is "slow". Slow means : > > * ~200ms on an AMD 2GHz > > * ~500 ms on an IBM PowerPC with 4 CPU bicore !? > > The weirdest thing is that it takes only about 30ms on a laptop (Intel > > Celeron 1.6Ghz) > > Maybe some thread or locking issue. > > > For that test, we use the same clients and only switch the server > > target, thus time comes from the server. > > > > We dig into gnutls code, and we found *the* function which takes so much > > time. At the server site, the function is: > > _gnutls_pkcs1_rsa_decrypt() -- lib/auth_rsa.c > > Can you tell whether the majority of that time is spent in > gcry_pk_decrypt or somewhere else? > > I have been working on an abstract crypto layer between GnuTLS and > gcrypt, to simplify adding specialized routines for a particular > algorithm, or even hardware accelerators. Hashing and symmetric > operations have already been finished, but unfortunately I ran out of > spare time for the MPI/PK part. > > > Another *BAD* point is that the handshake doesn't look to be possible on > > multiple threads whereas server code uses a lot of thread. > > I'm not sure I follow here. Why doesn't this work? You shouldn't use > the same gnutls_session from several threads at the same time, but > presumably, you have one thread for each gnutls_session don't you? Yes this is it, one thread per gnutls_handshake. > I > haven't tried it, but I think it should work. No sadly, it seems there's a lot in gcrypt and all gets serialized. > > > So, any idea to explain why _gnutls_pkcs1_rsa_decrypt() is so slow on my > > computer and really faster on another one? > > Hm. Libgcrypt seem to need strong randomness for blinding purposes, > maybe this is what stalls everything? > > Try disabling blinding in libgcrypt and try again. I.e., insert > 'flags |= PUBKEY_FLAG_NO_BLINDING;' into cipher/rsa.c at the top of > _gcry_rsa_decrypt(). Ok, I'm giving a try to this. > > > And do you think that gnutls_handshake() can be used in two > > different threads at the same time? > > If you use different gnutls_session objects in each thread, I think > this should work. But I haven't tested it. Maybe you need extra > copies of other structures too, used by the gnutls_session. > > Hope this helps, > Simon From regit at inl.fr Sat Jul 29 14:17:26 2006 From: regit at inl.fr (Eric Leblond) Date: Sat, 29 Jul 2006 14:17:26 +0200 Subject: [Help-gnutls] Re: gnutls_handshake() is slow and is a big lock In-Reply-To: <200607291403.22746.nmav@gnutls.org> References: <1154166420.8178.10.camel@localhost> <87mzas6369.fsf@latte.josefsson.org> <200607291403.22746.nmav@gnutls.org> Message-ID: <1154175446.8178.35.camel@localhost> Le samedi 29 juillet 2006 ? 14:03 +0200, Nikos Mavrogiannopoulos a ?crit : > On Sat 29 Jul 2006 13:50, Simon Josefsson wrote: > > > > And do you think that gnutls_handshake() can be used in two > > > different threads at the same time? > > If you use different gnutls_session objects in each thread, I think > > this should work. But I haven't tested it. Maybe you need extra > > copies of other structures too, used by the gnutls_session. > > Yes, if a gnutls_session object is only accessed by a single thread it > works (of course the locks for libgcrypt need to be set up). The hydra > web server (http://hydra.hellug.gr) uses gnutls and works pretty much > ok. Our test have shown that this work well in streaming mode but not during handshake. regards Eric From jas at extundo.com Sat Jul 29 14:23:34 2006 From: jas at extundo.com (Simon Josefsson) Date: Sat, 29 Jul 2006 14:23:34 +0200 Subject: [Help-gnutls] Re: gnutls_handshake() is slow and is a big lock In-Reply-To: <1154175270.8178.33.camel@localhost> (Eric Leblond's message of "Sat, 29 Jul 2006 14:14:30 +0200") References: <1154166420.8178.10.camel@localhost> <87mzas6369.fsf@latte.josefsson.org> <1154175270.8178.33.camel@localhost> Message-ID: <87bqr861mh.fsf@latte.josefsson.org> Eric Leblond writes: >> I haven't tried it, but I think it should work. > > No sadly, it seems there's a lot in gcrypt and all gets serialized. Ouch. Which lock is this? I agree that locks in libgcrypt are bad, we should try to remove them, or provide a way to replace libgcrypt with thread-safer and lock-free alternatives (of which there are several). /Simon From regit at inl.fr Sat Jul 29 14:27:07 2006 From: regit at inl.fr (Eric Leblond) Date: Sat, 29 Jul 2006 14:27:07 +0200 Subject: [Help-gnutls] GNUTLS vs OpenSSL Message-ID: <1154176027.8178.46.camel@localhost> Hi, We have done some comparison between GNUTLS and openssl during our benchmark of NuFW. We have only had a switch to one part of the code and thus it only display a trend and not a performance comparison. We measure performance of a complex system (NuFW) not directly the performance of transfert. On Intel Centrino 1.6GHz, openssl outperfoms GNUTLS with a ratio of 15%. On quadri processor PowerPC 1.8GHz (ppc64 architecture) and quadri processor XEON 3GHz (x86_64 architecture), GNUTLS outperforms openssl with a ratio of 15%. Thus, it seems that results depends heavily on the architecture. BR, Eric From nmav at gnutls.org Sat Jul 29 14:28:00 2006 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 29 Jul 2006 14:28:00 +0200 Subject: [Help-gnutls] Re: gnutls_handshake() is slow and is a big lock In-Reply-To: <1154175446.8178.35.camel@localhost> References: <1154166420.8178.10.camel@localhost> <200607291403.22746.nmav@gnutls.org> <1154175446.8178.35.camel@localhost> Message-ID: <200607291428.01880.nmav@gnutls.org> On Sat 29 Jul 2006 14:17, Eric Leblond wrote: > Le samedi 29 juillet 2006 ? 14:03 +0200, Nikos Mavrogiannopoulos a > > ?crit : > > On Sat 29 Jul 2006 13:50, Simon Josefsson wrote: > > > > And do you think that gnutls_handshake() can be used in two > > > > different threads at the same time? > > > > > > If you use different gnutls_session objects in each thread, I > > > think this should work. But I haven't tested it. Maybe you need > > > extra copies of other structures too, used by the gnutls_session. > > > > Yes, if a gnutls_session object is only accessed by a single thread > > it works (of course the locks for libgcrypt need to be set up). The > > hydra web server (http://hydra.hellug.gr) uses gnutls and works > > pretty much ok. > > Our test have shown that this work well in streaming mode but not > during handshake. Do you change the credential structures during handshakes? They have to be initialized and stay fixed during any handshakes. From regit at inl.fr Sat Jul 29 14:34:22 2006 From: regit at inl.fr (Eric Leblond) Date: Sat, 29 Jul 2006 14:34:22 +0200 Subject: [Help-gnutls] Re: gnutls_handshake() is slow and is a big lock In-Reply-To: <87bqr861mh.fsf@latte.josefsson.org> References: <1154166420.8178.10.camel@localhost> <87mzas6369.fsf@latte.josefsson.org> <1154175270.8178.33.camel@localhost> <87bqr861mh.fsf@latte.josefsson.org> Message-ID: <1154176462.8178.52.camel@localhost> Le samedi 29 juillet 2006 ? 14:23 +0200, Simon Josefsson a ?crit : > Eric Leblond writes: > > >> I haven't tried it, but I think it should work. > > > > No sadly, it seems there's a lot in gcrypt and all gets serialized. > > Ouch. Which lock is this? We do not had the time to point it but on our our quadri processors test platform (thanks to our partner for giving acces to it ;-)) with a thread per gnutls_handshake we clearly manage to see that handshakes finish at regular interval. This indicates that there is now use of multithreading at all. Thus there is a lock. > I agree that locks in libgcrypt are bad, > we should try to remove them, or provide a way to replace libgcrypt > with thread-safer and lock-free alternatives (of which there are > several). Yes it is clearly on important point. > > /Simon From jas at extundo.com Sat Jul 29 14:50:52 2006 From: jas at extundo.com (Simon Josefsson) Date: Sat, 29 Jul 2006 14:50:52 +0200 Subject: [Help-gnutls] Re: GNUTLS vs OpenSSL In-Reply-To: <1154176027.8178.46.camel@localhost> (Eric Leblond's message of "Sat, 29 Jul 2006 14:27:07 +0200") References: <1154176027.8178.46.camel@localhost> Message-ID: <87y7uc4lsj.fsf@latte.josefsson.org> Eric Leblond writes: > Hi, > > We have done some comparison between GNUTLS and openssl during our > benchmark of NuFW. > > We have only had a switch to one part of the code and thus it only > display a trend and not a performance comparison. We measure performance > of a complex system (NuFW) not directly the performance of transfert. > > On Intel Centrino 1.6GHz, openssl outperfoms GNUTLS with a ratio of 15%. > > On quadri processor PowerPC 1.8GHz (ppc64 architecture) and quadri > processor XEON 3GHz (x86_64 architecture), GNUTLS outperforms openssl > with a ratio of 15%. > > Thus, it seems that results depends heavily on the architecture. Did one of the numbers lack a zero or something? Otherwise, it doesn't seem like the results depend on the architecture at all. /Simon From jas at extundo.com Sat Jul 29 14:52:11 2006 From: jas at extundo.com (Simon Josefsson) Date: Sat, 29 Jul 2006 14:52:11 +0200 Subject: [Help-gnutls] Re: GNUTLS vs OpenSSL In-Reply-To: <87y7uc4lsj.fsf@latte.josefsson.org> (Simon Josefsson's message of "Sat, 29 Jul 2006 14:50:52 +0200") References: <1154176027.8178.46.camel@localhost> <87y7uc4lsj.fsf@latte.josefsson.org> Message-ID: <87u0504lqc.fsf@latte.josefsson.org> Simon Josefsson writes: > Eric Leblond writes: > >> Hi, >> >> We have done some comparison between GNUTLS and openssl during our >> benchmark of NuFW. >> >> We have only had a switch to one part of the code and thus it only >> display a trend and not a performance comparison. We measure performance >> of a complex system (NuFW) not directly the performance of transfert. >> >> On Intel Centrino 1.6GHz, openssl outperfoms GNUTLS with a ratio of 15%. >> >> On quadri processor PowerPC 1.8GHz (ppc64 architecture) and quadri >> processor XEON 3GHz (x86_64 architecture), GNUTLS outperforms openssl >> with a ratio of 15%. >> >> Thus, it seems that results depends heavily on the architecture. > > Did one of the numbers lack a zero or something? Otherwise, it > doesn't seem like the results depend on the architecture at all. Oops, I didn't notice that GnuTLS was faster by the same amount on some platforms. Never mind. /Simon From regit at inl.fr Sat Jul 29 15:46:14 2006 From: regit at inl.fr (Eric Leblond) Date: Sat, 29 Jul 2006 15:46:14 +0200 Subject: [Help-gnutls] Re: gnutls_handshake() is slow and is a big lock In-Reply-To: <87mzas6369.fsf@latte.josefsson.org> References: <1154166420.8178.10.camel@localhost> <87mzas6369.fsf@latte.josefsson.org> Message-ID: <1154180774.8178.55.camel@localhost> Le samedi 29 juillet 2006 ? 13:50 +0200, Simon Josefsson a ?crit : > Eric Leblond writes: > Hm. Libgcrypt seem to need strong randomness for blinding purposes, > maybe this is what stalls everything? > > Try disabling blinding in libgcrypt and try again. I.e., insert > 'flags |= PUBKEY_FLAG_NO_BLINDING;' into cipher/rsa.c at the top of > _gcry_rsa_decrypt(). Hmmm, it did not change a lot of thing. The only thing I saw is that minimum time with that is less than without. But globaly performance are the same. BR, > > > And do you think that gnutls_handshake() can be used in two > > different threads at the same time? > > If you use different gnutls_session objects in each thread, I think > this should work. But I haven't tested it. Maybe you need extra > copies of other structures too, used by the gnutls_session. > > Hope this helps, > Simon From regit at inl.fr Sat Jul 29 15:51:51 2006 From: regit at inl.fr (Eric Leblond) Date: Sat, 29 Jul 2006 15:51:51 +0200 Subject: [Help-gnutls] Re: gnutls_handshake() is slow and is a big lock In-Reply-To: <200607291428.01880.nmav@gnutls.org> References: <1154166420.8178.10.camel@localhost> <200607291403.22746.nmav@gnutls.org> <1154175446.8178.35.camel@localhost> <200607291428.01880.nmav@gnutls.org> Message-ID: <1154181111.8178.58.camel@localhost> Le samedi 29 juillet 2006 ? 14:28 +0200, Nikos Mavrogiannopoulos a ?crit : > On Sat 29 Jul 2006 14:17, Eric Leblond wrote: > > Le samedi 29 juillet 2006 ? 14:03 +0200, Nikos Mavrogiannopoulos a > > > > If you use different gnutls_session objects in each thread, I > > > > think this should work. But I haven't tested it. Maybe you need > > > > extra copies of other structures too, used by the gnutls_session. > > > > > > Yes, if a gnutls_session object is only accessed by a single thread > > > it works (of course the locks for libgcrypt need to be set up). The > > > hydra web server (http://hydra.hellug.gr) uses gnutls and works > > > pretty much ok. > > > > Our test have shown that this work well in streaming mode but not > > during handshake. > > Do you change the credential structures during handshakes? They have to > be initialized and stay fixed during any handshakes. No they are fixed on the server. You can check the source of the server at : http://nufw.org/doxygen/nuauth_2tls_8c-source.html#l00209 BR, Eric From bradh at frogmouth.net Mon Jul 31 10:23:07 2006 From: bradh at frogmouth.net (Brad Hards) Date: Mon, 31 Jul 2006 18:23:07 +1000 Subject: [Help-gnutls] GNUTLS vs OpenSSL In-Reply-To: <1154176027.8178.46.camel@localhost> References: <1154176027.8178.46.camel@localhost> Message-ID: <200607311823.12706.bradh@frogmouth.net> On Saturday 29 July 2006 22:27, Eric Leblond wrote: > Hi, > > We have done some comparison between GNUTLS and openssl during our > benchmark of NuFW. > > We have only had a switch to one part of the code and thus it only > display a trend and not a performance comparison. We measure performance > of a complex system (NuFW) not directly the performance of transfert. Are you building each system with or without assembler optimisations? Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From regit at inl.fr Mon Jul 31 13:45:40 2006 From: regit at inl.fr (Regit) Date: Mon, 31 Jul 2006 13:45:40 +0200 Subject: [Help-gnutls] GNUTLS vs OpenSSL In-Reply-To: <200607311823.12706.bradh@frogmouth.net> References: <1154176027.8178.46.camel@localhost> <200607311823.12706.bradh@frogmouth.net> Message-ID: <1154346340.20716.2.camel@localhost.localdomain> Le lundi 31 juillet 2006 ? 18:23 +1000, Brad Hards a ?crit : > On Saturday 29 July 2006 22:27, Eric Leblond wrote: > > Hi, > > > > We have done some comparison between GNUTLS and openssl during our > > benchmark of NuFW. > > > > We have only had a switch to one part of the code and thus it only > > display a trend and not a performance comparison. We measure performance > > of a complex system (NuFW) not directly the performance of transfert. > Are you building each system with or without assembler optimisations? There is no assembler optimisation on PPC64 and X86_64 for gnutls. The openssl used was the one of the distro (RHEL4 in this case). I don't know about assembler optimisation of openssl on this platform. BR, From nilanjans at condornetworks.com Mon Jul 31 17:27:27 2006 From: nilanjans at condornetworks.com (Nilanjan Sarkar) Date: Mon, 31 Jul 2006 20:57:27 +0530 Subject: [Help-gnutls] Need help Message-ID: <001401c6b4b5$d64b30d0$4001a8c0@nilanjan> Hi, We integrated our code with gnuTLS. In load, I am getting Signal 6 from gnuTLS, with error "_gcry_ath_mutex_lock: Assertion `*lock == ((ath_mutex_t) 0)' failed." . Can anybody please help me? Thanks in advance. Regards, Nilanjan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rks at mur.at Mon Jul 31 21:28:10 2006 From: rks at mur.at (Rupert Kittinger-Sereinig) Date: Mon, 31 Jul 2006 21:28:10 +0200 Subject: [Help-gnutls] Need help In-Reply-To: <001401c6b4b5$d64b30d0$4001a8c0@nilanjan> References: <001401c6b4b5$d64b30d0$4001a8c0@nilanjan> Message-ID: <44CE59CA.60907@mur.at> Nilanjan Sarkar schrieb: > Hi, > > We integrated our code with gnuTLS. In load, I am getting Signal 6 from > gnuTLS, with error "_gcry_ath_mutex_lock: Assertion `*lock == > ((ath_mutex_t) 0)' failed." . > > Can anybody please help me? > > Thanks in advance. > Regards, > Nilanjan sounds like libgcrypt has not been initialized: http://www.gnu.org/software/gnutls/manual/html_node/Multi_002dthreaded-applications.html#Multi_002dthreaded-applications regards, Rupert -- Rupert Kittinger-Sereinig Krenngasse 32 A-8010 Graz Austria