From rgerhards at gmail.com Thu Dec 1 17:24:52 2011 From: rgerhards at gmail.com (Rainer Gerhards) Date: Thu, 1 Dec 2011 17:24:52 +0100 Subject: reading private key file Message-ID: Hi all, I am banging my head for quite some while now and hope to find some help here. I am unable to read a private key that I have generated with certtool. I do this $ certtool --generate-privkey --outfile test.key then I call my (test) program and make it try to read/import test.key via these statements: data.size = fread (buffer, 1, sizeof (buffer) - 1, infile); buffer[data.size] = 0; data.data = buffer; r = gnutls_x509_privkey_init(&key); r = gnutls_x509_privkey_import(key, &data, GNUTLS_X509_FMT_PEM); if(1){//r == GNUTLS_E_BASE64_UNEXPECTED_HEADER_ERROR) { fprintf(stderr, "gnutls error %d in privkey_import1: %s\n", r, gnutls_strerror(r)); /* as a non-interactive process, we do not try with password */ r = gnutls_x509_privkey_import_pkcs8 (key, &data, GNUTLS_X509_FMT_PEM, NULL, GNUTLS_PKCS_PLAIN); } if(r != GNUTLS_E_SUCCESS) { fprintf(stderr, "gnutls error %d in privkey_import: %s\n", r, gnutls_strerror(r)); exit(1); } This results in these errors: gnutls error -69 in privkey_import1: ASN1 parser: Error in DER parsing. gnutls error -207 in privkey_import: Base64 unexpected header error. Interestingly, I can read the key file without any problems via openSSL's PEM_read_RSAPrivateKey(). I guess I am doing something pretty basic wrong, but what? Help would be deeply appreciated. Thanks, Rainer From nmav at gnutls.org Thu Dec 1 17:39:17 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 1 Dec 2011 17:39:17 +0100 Subject: reading private key file In-Reply-To: References: Message-ID: On Thu, Dec 1, 2011 at 5:24 PM, Rainer Gerhards wrote: > Hi all, > > I am banging my head for quite some while now and hope to find some > help here. I am unable to read a private key that I have generated > with certtool. > I do this > > $ certtool ?--generate-privkey --outfile test.key > then I call my (test) program and make it try to read/import test.key > via these statements: > > ? ? ? ?data.size = fread (buffer, 1, sizeof (buffer) - 1, infile); > ? ? ? ?buffer[data.size] = 0; > ? ? ? ?data.data = buffer; > ? ? ? ?r = gnutls_x509_privkey_init(&key); I don't know what is wrong with your program, but certtool uses the same idea to load a key (see privkey_info()), so if certtool can read the key so should you (unless you provide bad data, or you didn't call gnutls_global_init()).provide to the function. regards, Nikos From rgerhards at gmail.com Thu Dec 1 17:44:15 2011 From: rgerhards at gmail.com (Rainer Gerhards) Date: Thu, 1 Dec 2011 17:44:15 +0100 Subject: reading private key file In-Reply-To: References: Message-ID: > I don't know what is wrong with your program, but certtool uses the > same idea to load a key (see privkey_info()), so if certtool can read > the key so should you (unless you provide bad data, or you didn't call > gnutls_global_init()).provide to the function. doh! I did not call the init! Shame on me (but, believe me, I got what I deserve...). Thanks for the quick help! Rainer From symack at gmail.com Wed Dec 7 17:09:40 2011 From: symack at gmail.com (Nick Khamis) Date: Wed, 7 Dec 2011 11:09:40 -0500 Subject: GNUTLS 3.0.8 Compilation Error Message-ID: Hello Everyone, I built nettle 2.4 from source, and it is located in /usr/include/nettle however, when trying to build GNUTLS 3.0.8 using: ./congiure or, ./configure --prefix=/usr --with-libnettle-prefix=/usr/include/nettle I am recieving the following error: configure: error: *** *** Libnettle 2.4 was not found. Goggling did not yield much. Thanks in Advance, Nick. From simon at josefsson.org Thu Dec 8 11:22:56 2011 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 08 Dec 2011 11:22:56 +0100 Subject: GNUTLS 3.0.8 Compilation Error In-Reply-To: (Nick Khamis's message of "Wed, 7 Dec 2011 11:09:40 -0500") References: Message-ID: <87fwgvxszj.fsf@latte.josefsson.org> Nick Khamis writes: > Hello Everyone, > > I built nettle 2.4 from source, and it is located in > /usr/include/nettle however, when > trying to build GNUTLS 3.0.8 using: > > ./congiure or, > ./configure --prefix=/usr --with-libnettle-prefix=/usr/include/nettle > > I am recieving the following error: > > configure: error: > *** > *** Libnettle 2.4 was not found. Use --with-libnettle-prefix=/usr (or just try without it). I'm assuming you didn't install libnettle.so under /usr/include/nettle. Also, did you run ldconfig after installing Nettle? /Simon From symack at gmail.com Thu Dec 8 19:03:58 2011 From: symack at gmail.com (Nick Khamis) Date: Thu, 8 Dec 2011 13:03:58 -0500 Subject: GNUTLS 3.0.8 Compilation Error In-Reply-To: <87fwgvxszj.fsf@latte.josefsson.org> References: <87fwgvxszj.fsf@latte.josefsson.org> Message-ID: Hello Simon, Thank you so much for your response. Libnettle is intalled in: /usr/lib/libnettle.a /usr/lib/libnettle.so /usr/lib/libnettle.so.4 /usr/lib/libnettle.so.4.3 After installing nettle, I issue an ldconfig. When trying to compile GNU TLS using the following: ./configure --prefix=/usr or, ./configure --prefix=/usr --with-libnettle-prefix=/usr/lib or, ./configure --prefix=/usr --with-libnettle-prefix=/usr I get the same error. There is no clean, or distclean tasks in GNUTLS? Thanks in Advanace, Nicholas. On Thu, Dec 8, 2011 at 5:22 AM, Simon Josefsson wrote: > Nick Khamis writes: > >> Hello Everyone, >> >> I built nettle 2.4 from source, and it is located in >> /usr/include/nettle however, when >> trying to build GNUTLS 3.0.8 using: >> >> ./congiure or, >> ./configure --prefix=/usr --with-libnettle-prefix=/usr/include/nettle >> >> I am recieving the following error: >> >> configure: error: >> *** >> *** Libnettle 2.4 was not found. > > Use --with-libnettle-prefix=/usr (or just try without it). I'm assuming > you didn't install libnettle.so under /usr/include/nettle. Also, did > you run ldconfig after installing Nettle? > > /Simon From aleksander.kamenik at krediidiinfo.ee Fri Dec 9 12:09:44 2011 From: aleksander.kamenik at krediidiinfo.ee (Kamenik, Aleksander) Date: Fri, 9 Dec 2011 11:09:44 -0000 Subject: view ciphers Message-ID: Hi, With openssl I can check the results of my cipher string: $ openssl ciphers -v 'MEDIUM:-MD5:-RC4:!ADH' DHE-RSA-SEED-SHA SSLv3 Kx=DH Au=RSA Enc=SEED(128) Mac=SHA1 DHE-DSS-SEED-SHA SSLv3 Kx=DH Au=DSS Enc=SEED(128) Mac=SHA1 SEED-SHA SSLv3 Kx=RSA Au=RSA Enc=SEED(128) Mac=SHA1 How do I do something like this with gnutls-cli or some other gnutls tool? Regards, Aleksander Kamenik System Administrator Krediidiinfo AS an Experian Company Phone: +372 665 9649 Email: aleksander at krediidiinfo.ee From nmav at gnutls.org Fri Dec 9 18:59:10 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 09 Dec 2011 18:59:10 +0100 Subject: view ciphers In-Reply-To: References: Message-ID: <4EE24C6E.4040809@gnutls.org> On 12/09/2011 12:09 PM, Kamenik, Aleksander wrote: > Hi, > With openssl I can check the results of my cipher string: > $ openssl ciphers -v 'MEDIUM:-MD5:-RC4:!ADH' > DHE-RSA-SEED-SHA SSLv3 Kx=DH Au=RSA Enc=SEED(128) Mac=SHA1 > DHE-DSS-SEED-SHA SSLv3 Kx=DH Au=DSS Enc=SEED(128) Mac=SHA1 > SEED-SHA SSLv3 Kx=RSA Au=RSA Enc=SEED(128) Mac=SHA1 > How do I do something like this with gnutls-cli or some other gnutls tool? None that I know of. It looks like an interesting functionality though. Noted. regards, Nikos From mrsam at courier-mta.com Sat Dec 10 17:41:42 2011 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sat, 10 Dec 2011 11:41:42 -0500 Subject: Heuristically picking # of bits for =?UTF-8?Q?gnutls=5Fdh=5Fparams=5Fgenerate2?= Message-ID: Does anyone happen to know of a good heuristic to come up with some reasonable number of bits at runtime that I can give to gnutls_dh_params_generate2, and have reasonably odds of coming up with a DH pair in, maybe, 5-10 seconds. I was hacking on some code in a 32 bit guest VM, and I thought that I was corrupting something, because gnutls_dh_params_generate2 was seemingly getting stuck, spinning forever. But it turns out that it was really just very, very slow. I don't think it's the VM itself, it seems to run reasonably well to me. Regular compiles get completed at a fairly reasonable pace. I don't know if it's just that gmp is slow on i686, if something is not right with the rnd generator, or something other reason. I'm just used to my native x86-64 bare metal cranking out a key at a good clip. After feeding 2048 bits to gnutls_dh_params_generate2 it cranks something out in only a few seconds. But, for whatever reason may be, flipping over to an i686 guest VM, and gnutls_dh_params_generate2 runs slow as molasses. I'm clocking a 1024 bit run of gnutls_dh_params_generate2 to take several minutes long, typically. Sometimes I get lucky, and come up with a 1024-bit based parameter in 5-10 seconds. But my last two runs took a minute and a half, and over three minutes, each, and that's typical. With GNUTLS_SEC_PARAM_NORMAL telling me that I should use 3072 bits, that'll probably take a day. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From aleksander.kamenik at krediidiinfo.ee Sat Dec 10 18:17:13 2011 From: aleksander.kamenik at krediidiinfo.ee (Kamenik, Aleksander) Date: Sat, 10 Dec 2011 17:17:13 -0000 Subject: Heuristically picking # of bits forgnutls_dh_params_generate2 In-Reply-To: References: Message-ID: Not enough entropry maybe, it's usually quite low on VMs. Input devices and network traffic should/might help. cat /proc/sys/kernel/random/entropy_avail to check, compare that with the host OS. Regards, Aleksander Kamenik System Administrator Krediidiinfo AS an Experian Company Phone: +372 665 9649 Email: aleksander at krediidiinfo.ee > -----Original Message----- > From: help-gnutls-bounces+aleksander.kamenik=krediidiinfo.ee at gnu.org > [mailto:help-gnutls-bounces+aleksander.kamenik=krediidiinfo.ee at gnu.org] > On Behalf Of Sam Varshavchik > Sent: Saturday, December 10, 2011 6:42 PM > To: help-gnutls at gnu.org > Subject: Heuristically picking # of bits forgnutls_dh_params_generate2 > > Does anyone happen to know of a good heuristic to come up with some > reasonable number of bits at runtime that I can give to > gnutls_dh_params_generate2, and have reasonably odds of coming up with > a DH pair in, maybe, 5-10 seconds. > > I was hacking on some code in a 32 bit guest VM, and I thought that I > was corrupting something, because gnutls_dh_params_generate2 was > seemingly getting stuck, spinning forever. But it turns out that it was > really just very, very slow. > > I don't think it's the VM itself, it seems to run reasonably well to > me. > Regular compiles get completed at a fairly reasonable pace. I don't > know if it's just that gmp is slow on i686, if something is not right > with the rnd generator, or something other reason. I'm just used to my > native x86-64 bare metal cranking out a key at a good clip. After > feeding 2048 bits to > gnutls_dh_params_generate2 it cranks something out in only a few > seconds. > > But, for whatever reason may be, flipping over to an i686 guest VM, and > gnutls_dh_params_generate2 runs slow as molasses. I'm clocking a 1024 > bit run of gnutls_dh_params_generate2 to take several minutes long, > typically. > Sometimes I get lucky, and come up with a 1024-bit based parameter in > 5-10 seconds. But my last two runs took a minute and a half, and over > three minutes, each, and that's typical. With GNUTLS_SEC_PARAM_NORMAL > telling me that I should use 3072 bits, that'll probably take a day. > From mrsam at courier-mta.com Sat Dec 10 20:47:29 2011 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sat, 10 Dec 2011 14:47:29 -0500 Subject: Heuristically picking # of bits =?UTF-8?Q?forgnutls=5Fdh=5Fparams=5Fgenerate2?= References: Message-ID: Kamenik, Aleksander writes: > Not enough entropry maybe, it's usually quite low on VMs. Input devices and > network traffic should/might help. > > cat /proc/sys/kernel/random/entropy_avail to check, compare that with the > host OS. Thanks, but this is not Linux, and entropy is not the issue here. > Regards, > > Aleksander Kamenik > System Administrator > Krediidiinfo AS > an Experian Company > Phone: +372 665 9649 > Email: aleksander at krediidiinfo.ee > > > > -----Original Message----- > > From: help-gnutls-bounces+aleksander.kamenik=krediidiinfo.ee at gnu.org > > [mailto:help-gnutls-bounces+aleksander.kamenik=krediidiinfo.ee at gnu.org] > > On Behalf Of Sam Varshavchik > > Sent: Saturday, December 10, 2011 6:42 PM > > To: help-gnutls at gnu.org > > Subject: Heuristically picking # of bits forgnutls_dh_params_generate2 > > > > Does anyone happen to know of a good heuristic to come up with some > > reasonable number of bits at runtime that I can give to > > gnutls_dh_params_generate2, and have reasonably odds of coming up with > > a DH pair in, maybe, 5-10 seconds. > > > > I was hacking on some code in a 32 bit guest VM, and I thought that I > > was corrupting something, because gnutls_dh_params_generate2 was > > seemingly getting stuck, spinning forever. But it turns out that it was > > really just very, very slow. > > > > I don't think it's the VM itself, it seems to run reasonably well to > > me. > > Regular compiles get completed at a fairly reasonable pace. I don't > > know if it's just that gmp is slow on i686, if something is not right > > with the rnd generator, or something other reason. I'm just used to my > > native x86-64 bare metal cranking out a key at a good clip. After > > feeding 2048 bits to > > gnutls_dh_params_generate2 it cranks something out in only a few > > seconds. > > > > But, for whatever reason may be, flipping over to an i686 guest VM, and > > gnutls_dh_params_generate2 runs slow as molasses. I'm clocking a 1024 > > bit run of gnutls_dh_params_generate2 to take several minutes long, > > typically. > > Sometimes I get lucky, and come up with a 1024-bit based parameter in > > 5-10 seconds. But my last two runs took a minute and a half, and over > > three minutes, each, and that's typical. With GNUTLS_SEC_PARAM_NORMAL > > telling me that I should use 3072 bits, that'll probably take a day. > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From nmav at gnutls.org Sun Dec 11 14:27:42 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 11 Dec 2011 14:27:42 +0100 Subject: view ciphers In-Reply-To: <4EE24C6E.4040809@gnutls.org> References: <4EE24C6E.4040809@gnutls.org> Message-ID: <4EE4AFCE.5050701@gnutls.org> On 12/09/2011 06:59 PM, Nikos Mavrogiannopoulos wrote: > On 12/09/2011 12:09 PM, Kamenik, Aleksander wrote: >> Hi, >> With openssl I can check the results of my cipher string: >> $ openssl ciphers -v 'MEDIUM:-MD5:-RC4:!ADH' >> DHE-RSA-SEED-SHA SSLv3 Kx=DH Au=RSA Enc=SEED(128) Mac=SHA1 >> DHE-DSS-SEED-SHA SSLv3 Kx=DH Au=DSS Enc=SEED(128) Mac=SHA1 >> SEED-SHA SSLv3 Kx=RSA Au=RSA Enc=SEED(128) Mac=SHA1 >> How do I do something like this with gnutls-cli or some other gnutls tool? The repository's gnutls-cli can do the following: $ gnutls-cli --priority "NORMAL:-RSA" -l and will list the ciphersuites of the given priority string. regards, Nikos From nmav at gnutls.org Sun Dec 11 14:39:33 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 11 Dec 2011 14:39:33 +0100 Subject: Heuristically picking # of bits for gnutls_dh_params_generate2 In-Reply-To: References: Message-ID: <4EE4B295.70907@gnutls.org> On 12/10/2011 05:41 PM, Sam Varshavchik wrote: > Does anyone happen to know of a good heuristic to come up with some > reasonable number of bits at runtime that I can give to > gnutls_dh_params_generate2, and have reasonably odds of coming up > with a DH pair in, maybe, 5-10 seconds. gnutls with libgcrypt used a faster algorithm than the algorithm used in gnutls 3.x for DH parameter generation. However the 3.x version requires stronger properties on the primes. > I was hacking on some code in a 32 bit guest VM, and I thought that I > was corrupting something, because gnutls_dh_params_generate2 was > seemingly getting stuck, spinning forever. But it turns out that it > was really just very, very slow. Indeed. However you don't really need to do this at an application's run-time. You can use either the included parameters in gnutls (using certtool --get-dh-params), or if you have requirement for random ones, then use certtool --generate-dh-params on the background. > But, for whatever reason may be, flipping over to an i686 guest VM, > and gnutls_dh_params_generate2 runs slow as molasses. I'm clocking a > 1024 bit run of gnutls_dh_params_generate2 to take several minutes > long, typically. Sometimes I get lucky, and come up with a 1024-bit > based parameter in 5-10 seconds. But my last two runs took a minute > and a half, and over three minutes, each, and that's typical. With > GNUTLS_SEC_PARAM_NORMAL telling me that I should use 3072 bits, > that'll probably take a day. You can always use weaker options to optimize generation but in that case it might be wiser to do regeneration often (every week or month). regards, Nikos From tzz at lifelogs.com Tue Dec 13 18:54:12 2011 From: tzz at lifelogs.com (Ted Zlatanov) Date: Tue, 13 Dec 2011 11:54:12 -0600 Subject: gnutls 3.0.5 References: <4EA9A771.7060203@gnutls.org> <87r51wx4ci.fsf@lifelogs.com> Message-ID: <87pqfs8iij.fsf@lifelogs.com> On Sat, 29 Oct 2011 01:42:30 +0200 Nikos Mavrogiannopoulos wrote: NM> 2011/10/28 Ted Zlatanov : NM> ?I've just released gnutls 3.0.5. It is a bug-fix release on the current NM> stable branch. >> Thanks, Nikos. ?Simon Josefsson's Windows DLL builds haven't been >> updated since 2.10.x (July 2010). ?Can the GnuTLS project provide these >> builds for 3.x or will Simon remain their provider? NM> I cannot provide win32 builds. If however there is someone who can NM> provide win32 builds for the releases, he's welcome to join us. Hi Nikos, I would do it but don't know much about making the build with free tools. Is there a recipe I can follow? I did not see instructions in the package. Once I have a recipe I can set up a BuildBot. Thanks Ted From nmav at gnutls.org Tue Dec 13 22:34:13 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 13 Dec 2011 22:34:13 +0100 Subject: gnutls 3.0.5 In-Reply-To: <87pqfs8iij.fsf@lifelogs.com> References: <4EA9A771.7060203@gnutls.org> <87r51wx4ci.fsf@lifelogs.com> <87pqfs8iij.fsf@lifelogs.com> Message-ID: <4EE7C4D5.4080808@gnutls.org> On 12/13/2011 06:54 PM, Ted Zlatanov wrote: > NM> I cannot provide win32 builds. If however there is someone who > can NM> provide win32 builds for the releases, he's welcome to join > us. > > Hi Nikos, > I would do it but don't know much about making the build with free > tools. Is there a recipe I can follow? I did not see instructions > in the package. Once I have a recipe I can set up a BuildBot. Hello Ted, Thanks! You can use mingw64: http://mingw-w64.sourceforge.net/ or mingw32: http://www.mingw.org to build from linux or windows. I'd suppose that using something like ./configure --build=i586-pc-mingw32 && make should be enough. You'll also need to compile dependencies, such as libnettle as shared libraries. The old instructions for using the library are at http://josefsson.org/gnutls4win/README.html but I don't know if they are helpful since they refer to an old gnutls library with libgcrypt. If that works let me know! regards, Nikos From nmav at gnutls.org Tue Dec 13 23:23:52 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 13 Dec 2011 23:23:52 +0100 Subject: gnutls 3.0.9 Message-ID: <4EE7D078.6090007@gnutls.org> Hello, I've just released gnutls 3.0.9. This release optimizes several parts of gnutls, more prominent being optimizations in Diffie-Hellman and elliptic curve Diffie-Hellman key exchange. Moreover servers can now enforce their priority for ciphersuites. * Version 3.0.9 (released 2011-12-13) ** certtool: Added new parameter --dh-info. ** certtool: -l option was overloaded so if combined with --priority it will only list the ciphersuites that are enabled by the given priority string. ** libgnutls: Added new priority string %SERVER_PRECEDENCE, which changes the ciphersuite selection procedure. If specified the server priorities will be used for selection instead of the client's. ** libgnutls: Optimizations in Diffie-Hellman parameters generation and key exchange. ** libgnutls: When session tickets are negotiated and used in a session, a server will not store that session data into its cache. ** libgnutls: Added the SECP192R1 curve. ** libgnutls: Added gnutls_priority_get_cipher_suite_index() to allow listing the ciphersuites enabled in a priority structure. It outputs an index to be used in gnutls_get_cipher_suite_info(). ** libgnutls: Optimizations in the elliptic curve code --timing attacks resistant code is only used in ECDSA private key operations. ** doc: man pages for API functions generation was fixed and are now added again in the distribution. ** API and ABI modifications: GNUTLS_ECC_CURVE_SECP192R1: New curve definition gnutls_priority_get_cipher_suite_index: Added Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly >From . The list of GNU mirrors can be found at and a list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.9.tar.xz http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.9.tar.xz ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.9.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.9.tar.xz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.9.tar.xz.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.9.tar.xz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From michael at weiser.dinsnail.net Sat Dec 17 21:36:11 2011 From: michael at weiser.dinsnail.net (Michael Weiser) Date: Sat, 17 Dec 2011 21:36:11 +0100 Subject: gnutls-3.0.9, PSK and SECURE256 Message-ID: <20111217203611.GB17411@weiser.dinsnail.net> Hello list, Hi Nikos, my home-grown stunnel-lookalike uses gnutls and PSK. I run it with the following ciphersuite priority specification: SECURE256:+ECDHE-PSK:+DHE-PSK:+PSK. After upgrading to gnutls-3.0.9 it no longer works. This seems to be due to the fact that PSK ciphersuites use AES128 at most. Up until 3.0.9 they used to belong to SECURE256 but now got removed. So in order to be able to use PSK I have to switch to SECURE128. I don't want to debate the reason for removing AES128 from SECURE256. Obviously the security level with SECURE128 is just as high (or low) as before. Rather I wonder, why PSK isn't used in conjunction with AES256? -- Thanks for any insights, Micha From nmav at gnutls.org Sun Dec 18 19:25:08 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 18 Dec 2011 19:25:08 +0100 Subject: gnutls-3.0.9, PSK and SECURE256 In-Reply-To: <20111217203611.GB17411@weiser.dinsnail.net> References: <20111217203611.GB17411@weiser.dinsnail.net> Message-ID: <4EEE3004.1040604@gnutls.org> On 12/17/2011 09:36 PM, Michael Weiser wrote: > Hello list, Hi Nikos, my home-grown stunnel-lookalike uses gnutls > and PSK. I run it with the following ciphersuite priority > specification: SECURE256:+ECDHE-PSK:+DHE-PSK:+PSK. After upgrading to > gnutls-3.0.9 it no longer works. This seems to be due to the fact > that PSK ciphersuites use AES128 at most. Up until 3.0.9 they used to > belong to SECURE256 but now got removed. So in order to be able to > use PSK I have to switch to SECURE128. > I don't want to debate the reason for removing AES128 from SECURE256. > Obviously the security level with SECURE128 is just as high (or low) > as before. Rather I wonder, why PSK isn't used in conjunction with > AES256? There is very little point to use SECURE256. This is really an insane security level that has to be supported by public keys of equivalent level (e.g. for DHE in your case) that are of a size that probably would make the handshake extremely slow. However, for the situation you describe the issue isn't AES-256 but the fact that the PSK ciphersuites (in rfc4279) are defined using SHA-1, which isn't available any more in the 256-bit security level. regards, Nikos From michael at weiser.dinsnail.net Sun Dec 18 23:04:17 2011 From: michael at weiser.dinsnail.net (Michael Weiser) Date: Sun, 18 Dec 2011 23:04:17 +0100 Subject: gnutls-3.0.9, PSK and SECURE256 In-Reply-To: <4EEE3004.1040604@gnutls.org> References: <20111217203611.GB17411@weiser.dinsnail.net> <4EEE3004.1040604@gnutls.org> Message-ID: <20111218220417.GB32106@weiser.dinsnail.net> Hi Nikos, On Sun, Dec 18, 2011 at 07:25:08PM +0100, Nikos Mavrogiannopoulos wrote: > > I don't want to debate the reason for removing AES128 from SECURE256. > > Obviously the security level with SECURE128 is just as high (or low) > > as before. Rather I wonder, why PSK isn't used in conjunction with > > AES256? > There is very little point to use SECURE256. This is really an insane > security level that has to be supported by public keys of equivalent > level (e.g. for DHE in your case) that are of a size that probably > would make the handshake extremely slow. > However, for the situation you describe the issue isn't AES-256 but the > fact that the PSK ciphersuites (in rfc4279) are defined using SHA-1, which > isn't available any more in the 256-bit security level. Will this be the case for the foreseeable future or is something better/more secure/fancier/faster already coming? Should I contemplate moving away from PSK in favour of public key authentication in order to get a stronger hashing algorithm? BTW: My program currently ends up using ECDHE_PSK_AES_128_CBC_SHA256. Isn't SHA256 actually SHA-2, not SHA-1? -- Thanks, Micha From nmav at gnutls.org Mon Dec 19 01:30:26 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 19 Dec 2011 01:30:26 +0100 Subject: gnutls-3.0.9, PSK and SECURE256 In-Reply-To: <20111218220417.GB32106@weiser.dinsnail.net> References: <20111217203611.GB17411@weiser.dinsnail.net> <4EEE3004.1040604@gnutls.org> <20111218220417.GB32106@weiser.dinsnail.net> Message-ID: <4EEE85A2.807@gnutls.org> On 12/18/2011 11:04 PM, Michael Weiser wrote: >>> I don't want to debate the reason for removing AES128 from SECURE256. >>> Obviously the security level with SECURE128 is just as high (or low) >>> as before. Rather I wonder, why PSK isn't used in conjunction with >>> AES256? >> There is very little point to use SECURE256. This is really an insane >> security level that has to be supported by public keys of equivalent >> level (e.g. for DHE in your case) that are of a size that probably >> would make the handshake extremely slow. > >> However, for the situation you describe the issue isn't AES-256 but the >> fact that the PSK ciphersuites (in rfc4279) are defined using SHA-1, which >> isn't available any more in the 256-bit security level. > Will this be the case for the foreseeable future or is something > better/more secure/fancier/faster already coming? There are ciphersuites for PSK with AES-GCM support in rfc5487 that were not included/enabled in gnutls. I've enabled them in the repository so this may suit your needs. AES-GCM might be slower than SHA1 though, unless you have certain CPUs that optimize it. > Should I contemplate moving away from PSK in favour of public key > authentication in order to get a stronger hashing algorithm? No. Although gnutls tries to keep a uniform security level with the SECUREXXX priority strings, the security of the MAC is only significant for the period of the connection (as opposed to the security of the cipher which is significant for the period that the data need to be kept secure). That's why their security level shouldn't be treated the same. Maybe we should introduce asymmetric SECUREXXX variants to reflect that. > BTW: My program currently ends up using ECDHE_PSK_AES_128_CBC_SHA256. > Isn't SHA256 actually SHA-2, not SHA-1? Thanks for letting me know. It seems that ECDHE_PSK_AES_256_CBC_SHA256 should also have been available, but due to a bug it wasn't. I've fixed that. regards, Nikos From mzxnet at hotmail.com Mon Dec 19 12:42:39 2011 From: mzxnet at hotmail.com (mzx) Date: Mon, 19 Dec 2011 11:42:39 +0000 Subject: ./configure can't find libnettle 2.4 In-Reply-To: References: Message-ID: hello there, simply configure: error: *** *** Libnettle 2.4 was not found. I compiled nettle v2.4 with --prefix=$HOME and installed. But ./configure could not find it even with --with-libnettle-prefix=$HOME or --with-libnettle-prefix=$HOME/lib I found this question asked by someone 2 weeks ago and still not solution presented. Hope somebody will help me. ps. about libnettle in my box: libnettle.so and libnettle.a are stored in $HOME/lib, *.h in $HOME/include/nettle Regards, mzx -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Mon Dec 19 13:57:25 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 19 Dec 2011 13:57:25 +0100 Subject: ./configure can't find libnettle 2.4 In-Reply-To: References: Message-ID: 2011/12/19 mzx : > hello there, > simply > configure: error: > ? *** > ? *** Libnettle 2.4 was not found. > I compiled nettle v2.4 with --prefix=$HOME and installed. But ./configure > could not find it even with? --with-libnettle-prefix=$HOME or If your $HOME contains "include" and "lib" directories that should have worked (I use it quite successfully). Check your config.log on details of the failure in your system. regards, Nikos From nmav at gnutls.org Mon Dec 19 19:16:51 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 19 Dec 2011 19:16:51 +0100 Subject: a TLS packet with unexpected length received In-Reply-To: <1324309103.45261.YahooMailNeo@web112708.mail.gq1.yahoo.com> References: <1324309103.45261.YahooMailNeo@web112708.mail.gq1.yahoo.com> Message-ID: <4EEF7F93.6080309@gnutls.org> On 12/19/2011 04:38 PM, Barsan Liviu wrote: > Hello, > > We are using SipSimpleClient, a Python based SIP client to implement > our Skype like client for chat and audio. This SipSimpleClient uses > gnutls for TLS encryption. When integrating this python based > SipSimpleClient into our ObjectiveC project on Mac, and trying to > communicate with the server (which also has gnutls installed) we > receive the error from the Subject of this mail. By debugging with > Eclipse-PyDev, we found that gnutls_handshake() method give us this > error. We have 2.12.14 gnutls running on Debian Squeeze on server > and same version on Mac for client. It is interesting that when this > SipSimpleClient is run from the command line(not integrated into > ObjectiveC), then this error does not appear and session is realized > between client-server. Can somebody tell us what we can do? How to > avoid this error, maybe with a gnutls update? Please use the mailing list for sending questions. Most probably you do something different in the command line application than the other application and the only one who can verify that is you. As a last resort I'd suggest that you check what are the exchanged network packets. Compare the successful run with the packets from the failed run. The differences would show you the issue. regards, Nikos From michael at weiser.dinsnail.net Mon Dec 19 19:39:21 2011 From: michael at weiser.dinsnail.net (Michael Weiser) Date: Mon, 19 Dec 2011 19:39:21 +0100 Subject: gnutls-3.0.9, PSK and SECURE256 In-Reply-To: <4EEE85A2.807@gnutls.org> References: <20111217203611.GB17411@weiser.dinsnail.net> <4EEE3004.1040604@gnutls.org> <20111218220417.GB32106@weiser.dinsnail.net> <4EEE85A2.807@gnutls.org> Message-ID: <20111219183921.GA8423@weiser.dinsnail.net> Hi Nikos, On Mon, Dec 19, 2011 at 01:30:26AM +0100, Nikos Mavrogiannopoulos wrote: > not included/enabled in gnutls. I've enabled them in the repository > so this may suit your needs. AES-GCM might be slower than SHA1 though, > unless you have certain CPUs that optimize it. > > BTW: My program currently ends up using ECDHE_PSK_AES_128_CBC_SHA256. > > Isn't SHA256 actually SHA-2, not SHA-1? > Thanks for letting me know. It seems that ECDHE_PSK_AES_256_CBC_SHA256 > should also have been available, but due to a bug it wasn't. I've fixed that. Thanks. I'll give it a whirl as soon as possible. -- Thanks, Micha From n.mavrogiannopoulos at gmail.com Fri Dec 30 23:55:26 2011 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Sat, 31 Dec 2011 00:55:26 +0200 Subject: gnutls for win32 Message-ID: Hello all and best wishes for new year, I've put pre-built win32 dlls and the other gnutls applications for 3.0.9 in [0]. I've managed to automate the procedure, so it could be that next releases (at least the major ones) will have the corresponding windows dlls released as well. regards, Nikos [0]. http://homes.esat.kuleuven.be/~nikos/gnutls-win32/ From tzz at lifelogs.com Sat Dec 31 14:46:55 2011 From: tzz at lifelogs.com (Ted Zlatanov) Date: Sat, 31 Dec 2011 08:46:55 -0500 Subject: gnutls for win32 References: Message-ID: <87aa68dfao.fsf@lifelogs.com> On Sat, 31 Dec 2011 00:55:26 +0200 Nikos Mavrogiannopoulos wrote: NM> Hello all and best wishes for new year, NM> I've put pre-built win32 dlls and the other gnutls applications for NM> 3.0.9 in [0]. I've managed to automate the procedure, so it could be NM> that next releases (at least the major ones) will have the NM> corresponding windows dlls released as well. NM> [0]. http://homes.esat.kuleuven.be/~nikos/gnutls-win32/ Great news! That lets GNU Emacs use the latest GnuTLS on all the supported platforms. Currently we're in a feature freeze for the Emacs pretest, but after the next Emacs release we'll make GnuTLS 3.x required. That also lets us ensure that we're not fighting old, already-fixed bugs. Could the W32 releases go on the official GnuTLS site so we can point to them in the GNU Emacs installation notes? And could you, when able, publish the build script so developers can make their own W32 builds? Thanks Ted