From nmav at gnutls.org Thu May 2 21:25:57 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 2 May 2013 22:25:57 +0300 Subject: [gnutls-help] Connecting Apache with client certificates In-Reply-To: References: Message-ID: On Mon, Feb 11, 2013 at 5:44 PM, Fr?d?ric Dreier wrote: > Hi, > I try since some hours deploy a webdav server using apache under ubuntu 12.4 > using client certificates. > I already setup apache+webdav and I can access it through firefox using the > client certificate. > Now I want to use davfs2 which use gnutls but it exits with an gnutls error > (handshake failed, no details) Hello, Sorry for the late reply, it seems several posts were held by the mailing list and I missed them. > |<2>| ASSERT: gnutls_handshake.c:2833 > *** Fatal error: GnuTLS internal error. > Using "openssl client -connect ..." I am able to connect apache with the > client certificate and execute a GET request. > I only found one post refering to unimplemented SHA512 in gnutls. Is that > the reason? Not really. The issue looks like a bug in old gnutls versions. Should you use a recent gnutls versions you wouldn't have the issue. regards, Nikos From nmav at gnutls.org Thu May 2 21:29:39 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 2 May 2013 22:29:39 +0300 Subject: [gnutls-help] about SSL VPN In-Reply-To: <003301ce34ce$17f9fe90$47edfbb0$@com.tw> References: <003301ce34ce$17f9fe90$47edfbb0$@com.tw> Message-ID: On Tue, Apr 9, 2013 at 5:58 AM, Austin wrote: > Hello, > I want to find library (SSL VPN) for my company. > Could any products support SSL VPN which the function like openVPN? The term SSL VPN is often used by marketing departments to describe totally different technologies. The closest protocol to that term is CISCO's SSL VPN and there is the openconnect client and server implementations at: http://www.infradead.org/ocserv/ http://www.infradead.org/openconnect/ regards, Nikos From nmav at gnutls.org Thu May 2 21:30:23 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 2 May 2013 22:30:23 +0300 Subject: [gnutls-help] can't find libnettle In-Reply-To: References: Message-ID: On Thu, Apr 11, 2013 at 8:24 PM, Shahar Barak wrote: > Hi, > When I run ./configure I get the following error: > checking for libnettle... no > configure: error: > *** > *** Libnettle 2.5 was not found. Note that you must compile nettle with > gmp support. > Even though I have libnettle. It is in: > /usr/local/lib/libnettle.a You should check config.log for the actual error. regards, Nikos From nmav at gnutls.org Thu May 2 21:31:40 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 2 May 2013 22:31:40 +0300 Subject: [gnutls-help] Signature scheme for RSA signatures using gnutls_x509_crt_sign2 In-Reply-To: <516D4FD1.50902@sirrix.com> References: <516D4FD1.50902@sirrix.com> Message-ID: On Tue, Apr 16, 2013 at 4:19 PM, Ren? Korthaus wrote: > Hi, > I need to know which signature scheme for RSA signatures from PKCS#1 > v2.1 is used when signing a certificate using gnutls_x509_crt_sign2. > Unfortunately, I couldn't find an answer through source code analysis. > From the Google Summer of Code page (http://gnutls.org/soc.html) it > seems that RSASSA-PSS is not yet supported and RSASSA-PKCS1-V1_5 is > currently used. Is this information still accurate? Hello, Only RSASSA-PKCS1-V1_5 is supported. Since this is the version used in all TLS versions there isn't much of an incentive to change that. regards, Nikos From frederic.dreier at gmail.com Thu May 2 23:38:11 2013 From: frederic.dreier at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Dreier?=) Date: Thu, 2 May 2013 23:38:11 +0200 Subject: [gnutls-help] Connecting Apache with client certificates In-Reply-To: References: Message-ID: Hi, Actually you answer me the 12 feb already :-) and you were right: updating gnutls solved this problem. Best regards, Frederic 2013/5/2 Nikos Mavrogiannopoulos > On Mon, Feb 11, 2013 at 5:44 PM, Fr?d?ric Dreier > wrote: > > Hi, > > I try since some hours deploy a webdav server using apache under ubuntu > 12.4 > > using client certificates. > > I already setup apache+webdav and I can access it through firefox using > the > > client certificate. > > Now I want to use davfs2 which use gnutls but it exits with an gnutls > error > > (handshake failed, no details) > > Hello, > Sorry for the late reply, it seems several posts were held by the > mailing list and I missed them. > > > |<2>| ASSERT: gnutls_handshake.c:2833 > > *** Fatal error: GnuTLS internal error. > > Using "openssl client -connect ..." I am able to connect apache with the > > client certificate and execute a GET request. > > I only found one post refering to unimplemented SHA512 in gnutls. Is that > > the reason? > > Not really. The issue looks like a bug in old gnutls versions. Should > you use a recent gnutls versions you wouldn't have the issue. > > regards, > Nikos > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Fri May 10 11:45:42 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 10 May 2013 11:45:42 +0200 Subject: [gnutls-help] gnutls 3.1.11 Message-ID: <20130510114542.35c76788@aspire.lan> Hello, I've just released gnutls 3.1.11. This release adds new features and fixed bugs on the current stable branch. * Version 3.1.11 (released 2013-05-10) ** libgnutls: Added priority string VERS-DTLS-ALL. ** libgnutls: When in compatibility mode allow for a wrong version in the RSA PMS. ** libgnutls: Corrected issues in DTLS heartbeat parsing. Reported by Joke de Buhr. ** libgnutls: Heartbeat support is enabled by default. ** libgnutls: Added GNUTLS_PRIVKEY_SIGN_FLAG_TLS1_RSA which allows gnutls_privkey_sign_hash() to operate as with gnutls_privkey_sign_raw_data(). This makes it consistent with verification with GNUTLS_PUBKEY_VERIFY_FLAG_TLS1_RSA flag. ** libgnutls: Fixes in unknown DN string printing. Issues reported and patches by Stef Walter. ** certtool: When generating certificates the default answer for marking the key for signing and encryption is yes. ** API and ABI modifications: gnutls_certificate_set_x509_key_mem2: Added gnutls_certificate_set_x509_key_file2: Added gnutls_sign_algorithm_get_client: Added GNUTLS_PRIVKEY_SIGN_FLAG_TLS1_RSA: Added Getting the Software ==================== GnuTLS may be downloaded directly from . A list of GnuTLS mirrors can be found at . Here are the XZ and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.11.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.11.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.11.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.11.tar.lz.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 nmav at gnutls.org Fri May 10 18:38:45 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 10 May 2013 18:38:45 +0200 Subject: [gnutls-help] gnutls 3.2.0 Message-ID: <20130510183845.222dd931@aspire.lan> Hello, I've just released gnutls 3.2.0. This release significantly improves the performance of gnutls in two ways. The new elliptic curve implementation of nettle 2.7 is used which improves performance by a factor of 2 (thanks to Niels Moeller), and on the ciphersuite level the (currently) private ciphersuites with Salsa20 and UMAC-96 are defined, giving a performance boost compared to any ARCFOUR or AES based ciphersuites. The new ciphersuites also provide a solution to the recent attacks in TLS that compromise the security of CBC-based ciphersuites and ARCFOUR. Note that since these are private --i.e., gnutls-specific-- ciphersuites they are not enabled by default. In addition on this release all support for the so-called EXPORT ciphersuites is dropped. * Version 3.2.0 (released 2013-05-10) ** libgnutls: Use nettle's elliptic curve implementation. ** libgnutls: Added Salsa20 cipher ** libgnutls: Added UMAC-96 and UMAC-128 ** libgnutls: Added ciphersuites involving Salsa20 and UMAC-96. As they are not standardized they are defined using private ciphersuite numbers. ** libgnutls: Added support for DTLS 1.2. ** libgnutls: Added support for the Application Layer Protocol Negotiation (ALPN) extension. ** libgnutls: Removed support for the RSA-EXPORT ciphersuites. ** libgnutls: Avoid linking to librt (that also avoids unnecessary linking to pthreads if p11-kit isn't used). ** API and ABI modifications: gnutls_cipher_get_iv_size: Added gnutls_hmac_set_nonce: Added gnutls_mac_get_nonce_size: Added Getting the Software ==================== GnuTLS may be downloaded directly from . A list of GnuTLS mirrors can be found at . Here are the XZ and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.0.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.0.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.0.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.0.tar.lz.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 bry8star at yahoo.com Wed May 22 02:06:14 2013 From: bry8star at yahoo.com (Bry8 Star) Date: Tue, 21 May 2013 17:06:14 -0700 Subject: [gnutls-help] Which CA Management Software Are Based On Last Stable GnuTLS Message-ID: <519C0BF6.2070508@yahoo.com> Hi, Which CA Management software are based on last stable release of GnuTLS ? gnoMint was last released on Aug, 2010. http://gnomint.sf.net/ Its missing many many newer features which exist today. Want to create+use+support : newer algorithms, ciphers, etc based certs, OCSP, DANE (DNSSEC) authentication, more bits, etc. Last stable GnuTLS supports DANE (DNSSEC) protocols. And want to know, which CA Mgmt softwr can verify and indicate IF a Cert's/Key's authenticity (and chain of Cert's authenticity) was checked/done/passed more correctly OR not, ... (by obtaining cert's/key's hash/checksum or full cert from domain-name's owner approved/declared DNS records, like: TLSA, CERT, etc, using DANE (DNSSEC) and other PKIX protocols/standards). Thanks in advance, -- Bright Star (Bry8Star). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Fri May 24 00:58:29 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 23 May 2013 18:58:29 -0400 Subject: [gnutls-help] Which CA Management Software Are Based On Last Stable GnuTLS In-Reply-To: <519C0BF6.2070508@yahoo.com> References: <519C0BF6.2070508@yahoo.com> Message-ID: <519E9F15.6000200@fifthhorseman.net> On 05/21/2013 08:06 PM, Bry8 Star wrote: > Which CA Management software are based on last stable release of > GnuTLS ? i'm not aware of any that have been built explicitly against gnutls 3.2.0. > gnoMint was last released on Aug, 2010. > http://gnomint.sf.net/ > > Its missing many many newer features which exist today. > > Want to create+use+support : newer algorithms, ciphers, etc based > certs, OCSP, DANE (DNSSEC) authentication, more bits, etc. If you like the basic interface of gnomint already but want to see these features added to it, it sounds to me like patching gnomint would be the right direction to take. I imagine the original authors of gnomint would welcome patches! I am personally interested in seeing a dual-stack CA management tool, one which produces concurrent X.509 and OpenPGP certificates using the same key material, but i don't have time to work on it right now :( --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From viric at viric.name Fri May 17 23:00:14 2013 From: viric at viric.name (=?iso-8859-1?Q?Llu=EDs?= Batlle i Rossell) Date: Fri, 17 May 2013 23:00:14 +0200 Subject: [gnutls-help] Problem with https://archive.org Message-ID: <20130517210014.GU5577@vicerveza.homeunix.net> Hello, I tried gnutls 3.1 and 3.2.0 on https://archive.org (with wget and gnutls-cli), and both give me: Connecting to www.archive.org|207.241.224.2|:443... connected. GnuTLS: Could not negotiate a supported cipher suite. Unable to establish SSL connection. Enabling "EXPORT" in --priority (a friend helped me with that), made gnutls choose: |<3>| HSK[0x7a9ec0]: Selected cipher suite: RSA_AES_128_CBC_SHA1 But with openssl all just works, and chooses: TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA Any idea? Regards, Llu?s. From nmav at gnutls.org Wed May 29 21:13:00 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 29 May 2013 21:13:00 +0200 Subject: [gnutls-help] Problem with https://archive.org In-Reply-To: <20130517210014.GU5577@vicerveza.homeunix.net> References: <20130517210014.GU5577@vicerveza.homeunix.net> Message-ID: <51A6533C.3060903@gnutls.org> On 05/17/2013 11:00 PM, Llu?s Batlle i Rossell wrote: > Hello, > > I tried gnutls 3.1 and 3.2.0 on https://archive.org (with wget and gnutls-cli), > and both give me: > Connecting to www.archive.org|207.241.224.2|:443... connected. > GnuTLS: Could not negotiate a supported cipher suite. > Unable to establish SSL connection. > Enabling "EXPORT" in --priority (a friend helped me with that), made gnutls > choose: > |<3>| HSK[0x7a9ec0]: Selected cipher suite: RSA_AES_128_CBC_SHA1 Interesting. This server negotiates C0.13 (which is ECDHE-RSA-AES256-SHA), and selects SSL 3.0. This ciphersuite is only defined for TLS 1.0 or later and that's why gnutls rejects it and closes the connection. This was a bug of a particular openssl version on Debian. If this is a widespread issue we may try to work it around in gnutls and allow elliptic curves even in SSL 3.0. regards, Nikos From dkg at fifthhorseman.net Wed May 29 23:47:57 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 29 May 2013 17:47:57 -0400 Subject: [gnutls-help] Problem with https://archive.org In-Reply-To: <51A6533C.3060903@gnutls.org> References: <20130517210014.GU5577@vicerveza.homeunix.net> <51A6533C.3060903@gnutls.org> Message-ID: <51A6778D.4070705@fifthhorseman.net> On 05/29/2013 03:13 PM, Nikos Mavrogiannopoulos wrote: > Interesting. This server negotiates C0.13 (which is > ECDHE-RSA-AES256-SHA), and selects SSL 3.0. This ciphersuite is only > defined for TLS 1.0 or later and that's why gnutls rejects it and closes > the connection. > > This was a bug of a particular openssl version on Debian. > > If this is a widespread issue we may try to work it around in gnutls and > allow elliptic curves even in SSL 3.0. I've just forwarded this exchange to info at archive.org; i'm hoping someone there can get back to to me about what they're running and whether it's a vendor issue or a configuration issue. It looks like their setup also *can't* negotiate TLS 1.0, which seems pretty broken to me these days. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From marco.maggi-ipsu at poste.it Thu May 30 12:39:01 2013 From: marco.maggi-ipsu at poste.it (Marco Maggi) Date: Thu, 30 May 2013 12:39:01 +0200 Subject: [gnutls-help] on finding nettle under /usr/local rather than under /usr (GNU+Linux 64-bit system) Message-ID: <87obbslpkq.fsf@governatore.luna> Ciao, I am trying to install Gnutls 3.2.0 on a GNU+Linux 64-bit system with Slackware's Nettle 2.5 installed under "/usr" and my own installation of Nettle 2.7.1 under "/usr/local". I can do: $ /sbin/ldconfig -p | grep nettle libnettle.so.4 (libc6,x86-64) => /usr/local/lib/libnettle.so.4 libnettle.so.4 (libc6,x86-64) => /usr/lib64/libnettle.so.4 libnettle.so (libc6,x86-64) => /usr/local/lib/libnettle.so libnettle.so (libc6,x86-64) => /usr/lib64/libnettle.so so I would expect Gnutls's building infrastructure to find the correct version, but instead it does not happen. I can also do: $ pkg-config nettle --libs -L/usr/local/lib -lnettle $ pkg-config nettle --cflags -I/usr/local/include $ pkg-config libtasn1 --libs -L/usr/local/lib -ltasn1 $ pkg-config libtasn1 --cflags -I/usr/local/include If I just do: $ ./configure the build starts and it seems to find the right Nettle: $ grep nettle config.log configure:8886: checking whether to use nettle configure:9384: checking for libnettle configure:9406: gcc -std=gnu99 -o conftest -g -O2 -L/usr/local/lib conftest.c /usr/local/lib/libnettle.so /usr/local/lib/libhogweed.so -lgmp -Wl,-rpath -Wl,/usr/local/lib >&5 configure:9423: checking how to link with libnettle configure:9425: result: /usr/local/lib/libnettle.so /usr/local/lib/libhogweed.so -lgmp -Wl,-rpath -Wl,/usr/local/lib config.status:3259: creating lib/nettle/Makefile ac_cv_libnettle=yes LIBNETTLE='/usr/local/lib/libnettle.so /usr/local/lib/libhogweed.so -lgmp -Wl,-rpath -Wl,/usr/local/lib' LTLIBNETTLE='-L/usr/local/lib -lnettle -L/usr/local/lib -lhogweed -lgmp -R/usr/local/lib' but then "make" will fail because the old Nettle does not have the needed functions ("nettle_umac_*", "nettle_ecc_*", etc.); and after building fails I see: $ ldd lib/.libs/libgnutls.so linux-vdso.so.1 (0x00007fff1730b000) libz.so.1 => /usr/lib64/libz.so.1 (0x00007ff2c771d000) libp11-kit.so.0 => /usr/lib64/libp11-kit.so.0 (0x00007ff2c750b000) libtasn1.so.6 => /usr/local/lib/libtasn1.so.6 (0x00007ff2c72f8000) libnettle.so.4 => /usr/lib64/libnettle.so.4 (0x00007ff2c70d3000) libhogweed.so.2 => /usr/lib64/libhogweed.so.2 (0x00007ff2c6ec0000) libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x00007ff2c6c54000) libc.so.6 => /lib64/libc.so.6 (0x00007ff2c6867000) libdl.so.2 => /lib64/libdl.so.2 (0x00007ff2c6662000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ff2c6446000) /lib64/ld-linux-x86-64.so.2 (0x00007ff2c7c3a000) so libtasn1 is correctly found but Nettle... I dunno. The same happens if I do: $ ./configure LDFLAGS=-L/usr/local/lib If I do: $ ./configure --with-libnettle-prefix=/usr/local ... checking whether to use nettle... yes checking for libnettle... no configure: error: *** *** Libnettle 2.7 was not found. Note that you must compile nettle with gmp support. and: $ grep nettle config.log config.log:7: $ ./configure --with-libnettle-prefix=/usr/local config.log:595:configure:8886: checking whether to use nettle config.log:597:configure:9384: checking for libnettle config.log:598:configure:9406: gcc -std=gnu99 -o conftest -g -O2 conftest.c -lnettle -lhogweed -lgmp >&5 config.log:600:/home/marco/var/build/lib/gnutls-3.2.0/conftest.c:35: undefined reference to `nettle_umac96_set_nonce' config.log:634:| #include config.log:638:| nettle_umac96_set_nonce (0,0,0) config.log:645: *** Libnettle 2.7 was not found. Note that you must compile nettle with gmp support. config.log:713:ac_cv_libnettle=no and I see that "/usr/local/lib" is not used. It seems to me that the distributed "configure.ac" file is not the one used to generate "configure"; is this weird? I need some help. TIA -- "Now feel the funk blast!" Rage Against the Machine - "Calm like a bomb" From petr at yarpen.cz Thu May 30 15:16:13 2013 From: petr at yarpen.cz (Petr Vanek) Date: Thu, 30 May 2013 15:16:13 +0200 Subject: [gnutls-help] openpgp and gnutls_privkey_import_openpgp Message-ID: <51A7511D.6040406@yarpen.cz> hi all, what is proper use of gnutls_privkey_import_openpgp, please? I have a playground application to examine gnutls as a potential backend for new Qore language module and I'm getting crashes in nettle when I try to decrypt data. Is there any public implementation of this functionality I can look into? Any hints? thanks, petr vanek selfcompiled gnutls-3.2.0, nettle-2.7; OS used: opensuse 12.3. gnutls_global_init() is called in main(), also: gnutls_global_set_log_level(9); gnutls_global_set_log_function(log_func); // log_func is basically printf("LOG> %d: %s", level, msg); test_decrypt(273): 0 GNUTLS_E_SUCCESS = Success. <-- result of res = gnutls_privkey_init(&privkey); test_decrypt(276): 0 GNUTLS_E_SUCCESS = Success. <-- res = gnutls_openpgp_privkey_init(&pgppriv); LOG> 2: ASSERT: stream.c:1035 test_decrypt(284): 0 GNUTLS_E_SUCCESS = Success. <-- res = gnutls_openpgp_privkey_import(pgppriv, &data, GNUTLS_OPENPGP_FMT_BASE64, "n/a for now", 0); // the ASCII armored key is in data LOG> 2: ASSERT: privkey.c:1249 LOG> 2: ASSERT: privkey.c:1249 test_decrypt(287): 0 GNUTLS_E_SUCCESS = Success. <-- res = gnutls_privkey_import_openpgp(privkey, pgppriv, 0); LOG> 2: ASSERT: privkey.c:1249 <-- calling of res = gnutls_privkey_decrypt_data(privkey, 0, &ciphertext, &plaintext); LOG> 9: Decrypting using master PGP key LOG> 2: ASSERT: privkey.c:1249 LOG> 2: ASSERT: pubkey.c:291 LOG> 2: ASSERT: pgp.c:1228 LOG> 2: ASSERT: privkey.c:838 Program received signal SIGSEGV, Segmentation fault. wrap_nettle_mpi_clear (a=0x0) at mpi.c:220 220 memset(TOMPZ(a)[0]._mp_d, 0, TOMPZ(a)[0]._mp_alloc*sizeof(mp_limb_t)); (gdb) bt #0 wrap_nettle_mpi_clear (a=0x0) at mpi.c:220 #1 0x00007ffff7b078e7 in gnutls_pk_params_clear (p=p at entry=0x7fffffffdb60) at gnutls_pk.c:223 #2 0x00007ffff7b8551e in _gnutls_openpgp_privkey_get_mpis ( pkey=pkey at entry=0x60dbd0, keyid=keyid at entry=0x0, params=params at entry=0x7fffffffdb60) at privkey.c:856 #3 0x00007ffff7b868db in _gnutls_openpgp_privkey_decrypt_data (key=0x60dbd0, flags=, ciphertext=0x7fffffffdc40, plaintext=0x7fffffffdc50) at privkey.c:1449 #4 0x00000000004022c9 in test_decrypt (bn=0x62c310) at ../qore-gnutls/main.cpp:295 #5 0x0000000000401f94 in test_encrypt () at ../qore-gnutls/main.cpp:252 #6 0x000000000040240f in main () at ../qore-gnutls/main.cpp:375 the code is: #define QERRCHECK(err) \ printf("%s(%d): %d %s = %s\n", __FUNCTION__, __LINE__, res, gnutls_strerror_name(res), gnutls_strerror(res)); \ if ((err) != 0) { \ printf("ERROR: %s\n", gnutls_error_is_fatal((res)) ? "FATAL" : "regular"); \ return; \ } void test_decrypt(BinaryNode *bn) { int res; gnutls_privkey_t privkey; gnutls_openpgp_privkey_t pgppriv; res = gnutls_privkey_init(&privkey); QERRCHECK(res); res = gnutls_openpgp_privkey_init(&pgppriv); QERRCHECK(res); gnutls_datum_t data; data.data = (unsigned char*)privkeyTxt; data.size = sizeof(privkeyTxt); res = gnutls_openpgp_privkey_import(pgppriv, &data, GNUTLS_OPENPGP_FMT_BASE64, "n/a for now", 0); QERRCHECK(res); res = gnutls_privkey_import_openpgp(privkey, pgppriv, 0); QERRCHECK(res); //gnutls_privkey_set_pin_function(privkey, test_decrypt_callback, NULL); // TODO: context data gnutls_datum_t plaintext; gnutls_datum_t ciphertext; ciphertext.data = (unsigned char*)bn->getPtr(); ciphertext.size = bn->size(); res = gnutls_privkey_decrypt_data(privkey, 0, &ciphertext, &plaintext); QERRCHECK(res); gnutls_openpgp_privkey_deinit(pgppriv); gnutls_privkey_deinit(privkey); } From nmav at gnutls.org Fri May 31 10:27:39 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 31 May 2013 10:27:39 +0200 Subject: [gnutls-help] on finding nettle under /usr/local rather than under /usr (GNU+Linux 64-bit system) In-Reply-To: <87obbslpkq.fsf@governatore.luna> References: <87obbslpkq.fsf@governatore.luna> Message-ID: On Thu, May 30, 2013 at 12:39 PM, Marco Maggi wrote: > Ciao, > I am trying to install Gnutls 3.2.0 on a GNU+Linux 64-bit > system with Slackware's Nettle 2.5 installed under "/usr" > and my own installation of Nettle 2.7.1 under "/usr/local". > I can do: > $ ./configure > the build starts and it seems to find the right Nettle: > $ grep nettle config.log > configure:8886: checking whether to use nettle > configure:9384: checking for libnettle > configure:9406: gcc -std=gnu99 -o conftest -g -O2 -L/usr/local/lib conftest.c /usr/local/lib/libnettle.so /usr/local/lib/libhogweed.so -lgmp -Wl,-rpath -Wl,/usr/local/lib >&5 > configure:9423: checking how to link with libnettle > configure:9425: result: /usr/local/lib/libnettle.so /usr/local/lib/libhogweed.so -lgmp -Wl,-rpath -Wl,/usr/local/lib > config.status:3259: creating lib/nettle/Makefile > ac_cv_libnettle=yes > LIBNETTLE='/usr/local/lib/libnettle.so /usr/local/lib/libhogweed.so -lgmp -Wl,-rpath -Wl,/usr/local/lib' > LTLIBNETTLE='-L/usr/local/lib -lnettle -L/usr/local/lib -lhogweed -lgmp -R/usr/local/lib' > but then "make" will fail because the old Nettle does not > have the needed functions ("nettle_umac_*", "nettle_ecc_*", > etc.); and after building fails I see: Hello, Does the linking fails or compilation? If it is the latter a quick hack is to configure using CFLAGS=-I/usr/local/include The proper fix is for gnutls to use pkg-config to detect nettle (which I plan to do on the next release). regards, Nikos From nmav at gnutls.org Fri May 31 10:44:31 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 31 May 2013 10:44:31 +0200 Subject: [gnutls-help] openpgp and gnutls_privkey_import_openpgp In-Reply-To: <51A7511D.6040406@yarpen.cz> References: <51A7511D.6040406@yarpen.cz> Message-ID: On Thu, May 30, 2013 at 3:16 PM, Petr Vanek wrote: > hi all, > what is proper use of gnutls_privkey_import_openpgp, please? > I have a playground application to examine gnutls as a potential backend > for new Qore language module and I'm getting crashes in nettle when I > try to decrypt data. It seems that you triggered a bug on deinitialization of parameters. The attached patch should fix the crash, but will not make your use case work. The crash happens prior to error reporting because for some reason no keys could be extracted from the openpgp key you specified (what kind of key was that?). > Is there any public implementation of this functionality I can look into? Any hints? In general I'd suggest to prefer the X.509 functionality than the openpgp one which is often behind in terms of functionality and testing. regards, Nikos -------------- next part -------------- diff --git a/lib/gnutls_pk.c b/lib/gnutls_pk.c index 7a04b76..1984005 100644 --- a/lib/gnutls_pk.c +++ b/lib/gnutls_pk.c @@ -220,7 +220,8 @@ gnutls_pk_params_clear (gnutls_pk_params_st * p) unsigned int i; for (i = 0; i < p->params_nr; i++) { - _gnutls_mpi_clear (p->params[i]); + if (p->params[i] != NULL) + _gnutls_mpi_clear (p->params[i]); } } From petr at yarpen.cz Fri May 31 11:31:19 2013 From: petr at yarpen.cz (Petr Vanek) Date: Fri, 31 May 2013 11:31:19 +0200 Subject: [gnutls-help] openpgp and gnutls_privkey_import_openpgp In-Reply-To: References: <51A7511D.6040406@yarpen.cz> Message-ID: <51A86DE7.6090506@yarpen.cz> On 05/31/2013 10:44 AM, Nikos Mavrogiannopoulos wrote: > On Thu, May 30, 2013 at 3:16 PM, Petr Vanek wrote: >> hi all, >> what is proper use of gnutls_privkey_import_openpgp, please? >> I have a playground application to examine gnutls as a potential backend >> for new Qore language module and I'm getting crashes in nettle when I >> try to decrypt data. > It seems that you triggered a bug on deinitialization of parameters. > The attached patch should fix the crash, but will not make your use > case work. The crash happens prior to error reporting because for some > reason no keys could be extracted from the openpgp key you specified > (what kind of key was that?). it's a testing key generated by gpg itself. Pub and priv ASCII exports attached (it's safe it's really testing only key). Is there any way how to verify the key, please? Anyway - thanks for crash fix. Now I'm getting GNUTLS_E_INVALID_REQUEST error. LOG> 2: ASSERT: privkey.c:1220 LOG> 9: Decrypting using master PGP key LOG> 2: ASSERT: privkey.c:1220 LOG> 2: ASSERT: pubkey.c:287 LOG> 2: ASSERT: pgp.c:1181 LOG> 2: ASSERT: privkey.c:812 LOG> 2: ASSERT: privkey.c:1425 test_decrypt(303): -50 GNUTLS_E_INVALID_REQUEST = The request is invalid. ERROR: FATAL >> Is there any public implementation of this functionality I can look into? Any hints? > In general I'd suggest to prefer the X.509 functionality than the > openpgp one which is often behind in terms of functionality and > testing. yes, I bet it's a good advice. Unfortunately I'm in the project where I cannot change technologies and openpgp is used there by a 3rd party. thanks, petr -------------- next part -------------- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.19 (GNU/Linux) mQENBFGcmlQBCADDKesnW2oreCuub5jlW8HhoFPxUYtrCVUw8UKhsrBC1LNvWpcZ utJBg8kDnj1bCm4mEL54ZfHrDZT4OjM8v8z8nJoK2Iq/a6+wesjd0b8C4E2vhRRq 9na5hplAp0ol6Oy0xTbV79vU8HiN5Enc/OWYAimwZgHcBkpJ67UwWKz69Z3QJADq gf77bF3hxy1gsOrzXTueTl6yCNWIJTXdwx4wYBqfPk9aZPZRrDkPt1L6U5takNcG 2tBJk/1b4jmpCzC+XXGWzwfX5YxdOrptvlLErrvtdAyVd0ipFQPJgqbmsjgCGMJu 8l1eZMOpmy0zMf41Q2Pcv4LYUmOAllbAsn43ABEBAAG0LFBldHIgVmFuZWsgPHBl dHIudmFuZWtAcW9yZXRlY2hub2xvZ2llcy5jb20+iQE/BBMBAgApBQJRnJpUAhsD BQkB4TOABwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQd0BLvRtVBU9rsgf/ a7DV8CFuOz42HxzuAet6XzzQqShixhRMABxoTphYVf/OsGLe3Z6MfanNaA9Msfmo /TTtWp/0BKXPBImXUCP1lNmufz9Qysvys9rUwSUu/MiWrLIgHbYCjP+ZjuYLLfaN 3z6y1DnnbK5WSHMAglsqH6IDB8VMc7XwcTUBXfez0R/GF6Qr/g3Dmnh0ZwPtkI5I SxhFIsS/8LukmRUwNirLhgnbLGs8CIIJppr63dNfB1VsFs4a68FrFGy4Df80+mtW 7AuJ6pycyGvwziSOsmlnDbsyynsPsSHXz6wCLDXOFpBKoSyrEoaT+6aMMhJKo0VB igxzbYa4A2WFNS2fpQxo1LkBDQRRnJpUAQgA4J/bl1xmwolEg3upJLhkmhmebuav uB19zKAo6lUIjRx2jIoNfmy31BJRizmuUAdSsxw4UFIlFJm4IX2BxMHPYmPHXxxX CTuf2A5G2xOV8y2FZ/Spal5MfRXNLgqrb2263TDPsc9HkJoY7Ly/7CgLCXsSHNIv UQeiVGbhiNgJE/17KhLN9aDS8qx4+DrxCmXqYCOin2JOehsM1xYo4nC25Gr6Mntp RJS52jqdGmzh3BOo3+prNkUSycCxF0Eux3Vk+Gu7u0zp9DK+wZKVSXE3gPEmeJ41 fHZcvOH6mvd3y67pfm5o9XXs0SjJC+mYSbXr1WS8Lde8BpM61cQLVjfR8wARAQAB iQElBBgBAgAPBQJRnJpUAhsMBQkB4TOAAAoJEHdAS70bVQVPhEIIAIr9j/ISoXDL wFhwii7nn/D01GHtpsvp3if1LGt0ehPMcjDwYykYHkL/BG5T7vF4yr0c4NP9qUp2 etr5XCbvwuPYC4Rj3Ypy3nFlfBGCth1hL8Y5toLFdXwEGiBZW6xt6t2WOLRGmNRh Bb1RaYsqUy86TiYCkrSMHCJ37+89dhbXnIlDnuL1l1H0vW76oLCv28r2dUzcPaGr +IqekJogWRDA0ERR8DrCb0JOIxA4q+qRe1CiyTYFme8HC6J66xhywQmmBj6E0Im1 aCTir3GS48OtCkITCA7RTQ75n2oVpjAI/wDuFcAXxmfSvfcWUg+VdUgjO0PqaivP ROtAdTwkHLM= =vT3/ -----END PGP PUBLIC KEY BLOCK----- -------------- next part -------------- -----BEGIN PGP PRIVATE KEY BLOCK----- Version: GnuPG v2.0.19 (GNU/Linux) lQO+BFGcmlQBCADDKesnW2oreCuub5jlW8HhoFPxUYtrCVUw8UKhsrBC1LNvWpcZ utJBg8kDnj1bCm4mEL54ZfHrDZT4OjM8v8z8nJoK2Iq/a6+wesjd0b8C4E2vhRRq 9na5hplAp0ol6Oy0xTbV79vU8HiN5Enc/OWYAimwZgHcBkpJ67UwWKz69Z3QJADq gf77bF3hxy1gsOrzXTueTl6yCNWIJTXdwx4wYBqfPk9aZPZRrDkPt1L6U5takNcG 2tBJk/1b4jmpCzC+XXGWzwfX5YxdOrptvlLErrvtdAyVd0ipFQPJgqbmsjgCGMJu 8l1eZMOpmy0zMf41Q2Pcv4LYUmOAllbAsn43ABEBAAH+AwMCAWmlWlAPXDbbolxI A3HoByJKJqToMjreG2J+zUaP3+PNVCd6yCpHXhQIvE7uxamdXQAJShOssTQL8J5u WH+2R7G/Xa0tg+bugqWgTQLkFrtP1Awmx3c03zu/mabmxl0B0MFXEo1mvfaI+YM+ R1YIrQqqV8N80/T7GM+O4wG2pcHlSmNQoLxYRYp5nyTw9s+IL6g1+PliwHBYoYD2 p2YY31GBZPHHhJ5cYSgelZeZAsAFuxMitJPj9nM9kt0RuMReSkoiMzbR7NxAjFBT 1RUWX1A2qgUg+SqvZA13FFFiviQ+A5Tq8vbk5Su9UY++tXr5AimXOOMmOIRdFJM3 KuyAXmAhkpPoEIk1pecTcqDOMQXFj+Tdn38girieNnyl8MSQ7b/AdtpSIkJ3bpBb KWDUjz4+D346C3pr9HGnMkQWn/yYTCY0vuRrpJ5cdfUEwbeNYko3pgxF4G+ebsmy ZtdbdX1CyEvfTRqxsWRd4M36JE1GmAwpREvWyLpR6AujiUBFINqElMuzYFG1buVK FDe7RAxi0/E3K8MrcGhAXaLq/FGlk+iYyxxdPwD2wtW4aFN022qzQVWBBZTElGZ8 L95mla5kD9oB/QiVBfjLbvVBOgBS4VBzRfL5/kcEk5S/HyjSt9RV4U6KEeA4Wg9h fM6R94RVvZ0won9ihuLqLaOMzwXQrvjFyuV9bl6ufi3o1jDzmEkN6Y8iGfyCCFbs ZvA40eLuG5w6ebrzavDcV6eD2eL0a9DcL3VvWJiAOmOO+HHGCy3R77IiHZCYiM4r +VFBMGE0+U08x0RouuxkShQH8MQ+S0R92xdfc98jNzoV5y2E+8kde2dtyKEFFiDW umRaijwb+aqiTFQBnzo3jHhePFM6YGfJP6q8WmJP5aTAL0Wnk+dPpgAFdpIlH0qs YrQsUGV0ciBWYW5layA8cGV0ci52YW5la0Bxb3JldGVjaG5vbG9naWVzLmNvbT6J AT8EEwECACkFAlGcmlQCGwMFCQHhM4AHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIX gAAKCRB3QEu9G1UFT2uyB/9rsNXwIW47PjYfHO4B63pfPNCpKGLGFEwAHGhOmFhV /86wYt7dnox9qc1oD0yx+aj9NO1an/QEpc8EiZdQI/WU2a5/P1DKy/Kz2tTBJS78 yJassiAdtgKM/5mO5gst9o3fPrLUOedsrlZIcwCCWyofogMHxUxztfBxNQFd97PR H8YXpCv+DcOaeHRnA+2QjkhLGEUixL/wu6SZFTA2KsuGCdssazwIggmmmvrd018H VWwWzhrrwWsUbLgN/zT6a1bsC4nqnJzIa/DOJI6yaWcNuzLKew+xIdfPrAIsNc4W kEqhLKsShpP7powyEkqjRUGKDHNthrgDZYU1LZ+lDGjUnQO+BFGcmlQBCADgn9uX XGbCiUSDe6kkuGSaGZ5u5q+4HX3MoCjqVQiNHHaMig1+bLfUElGLOa5QB1KzHDhQ UiUUmbghfYHEwc9iY8dfHFcJO5/YDkbbE5XzLYVn9KlqXkx9Fc0uCqtvbbrdMM+x z0eQmhjsvL/sKAsJexIc0i9RB6JUZuGI2AkT/XsqEs31oNLyrHj4OvEKZepgI6Kf Yk56GwzXFijicLbkavoye2lElLnaOp0abOHcE6jf6ms2RRLJwLEXQS7HdWT4a7u7 TOn0Mr7BkpVJcTeA8SZ4njV8dly84fqa93fLrul+bmj1dezRKMkL6ZhJtevVZLwt 17wGkzrVxAtWN9HzABEBAAH+AwMCAWmlWlAPXDbbs9/t2a6uqdMENiC5byUR6elK URWWu8CZPYZKC8PR9WeUQuTkKVTspsP7jElXv5H/nIqKYl0dQO8unzNK8y9OWSDe sqz9jpA5FesSPA3z48PL8egpnLKCBk9xuCNzjbtBXFZ0qHqfp3eCiYw2j+WL8vu9 KmsK9ZtgNmVMJxdytl+CvX2J0WFMtJo71cFv0yJb3cf6NbfCSYXIL9kkdzffr5xn K2VJgywWfikBd1Null3aM0C4GT5m77+iCbZ/stoLNmIEduN4Ht+k7H5rN5KMp7z2 ExZ5cTQ3yes/IIBCgaNE3OMIRLA+rA2rRE/bRMqF6VCwc89M5xkgnBhG2IHL3YSQ 9sy9I3xWxOPFd4QVgKRpHcUWktLgsVg1Wk4fij2hW0K8RyThKYZxPwVRaUF38l78 xkHW/L7qLRz9S45Kyhq93XXlGwffxkzA1FP8qiarpIO5gUhrC8JNSZQc57DQJClN +La9NC8yy0Lg6na6K2gPrzIEqdDjbKvqwSwx3syQYVgFguLox9GQGT0tedoKcbBJ h2e7TicT92jApxcRT+d7deigfVx2fjF/QiXOZpI0xlnuLE8t0M0Mav63yUKhU5xh E7poCrE8JOqnISfBuxlF7kHjUY+ghI1YUr9uSMTBG7eoFXEiJ0/6UaS7Cd73F9wf 2HQA3pSquh8Al5yO4QNNzp1r10hddYRaV1r5g9hzNZT+YgUTVW1oY+ANTOfM1SIZ h1tsdNfT40H0toYEnHna2hSJk0McK5G87BxAwZj6/nF9hmUoIkQAq88tCKB/XGSz FGeYIwiDJxu+2a9SfbjcEiyqKQSapjrmlkNnE6pYR+QfXL+jv9oXdNDAmXma+/cb mKD8Xp28Nk/rvvQimhhRca7mJh1nXKx7NNFyqHn4N03lrYkBJQQYAQIADwUCUZya VAIbDAUJAeEzgAAKCRB3QEu9G1UFT4RCCACK/Y/yEqFwy8BYcIou55/w9NRh7abL 6d4n9SxrdHoTzHIw8GMpGB5C/wRuU+7xeMq9HODT/alKdnra+Vwm78Lj2AuEY92K ct5xZXwRgrYdYS/GObaCxXV8BBogWVusberdlji0RpjUYQW9UWmLKlMvOk4mApK0 jBwid+/vPXYW15yJQ57i9ZdR9L1u+qCwr9vK9nVM3D2hq/iKnpCaIFkQwNBEUfA6 wm9CTiMQOKvqkXtQosk2BZnvBwuieusYcsEJpgY+hNCJtWgk4q9xkuPDrQpCEwgO 0U0O+Z9qFaYwCP8A7hXAF8Zn0r33FlIPlXVIIztD6morz0TrQHU8JByz =jJ6i -----END PGP PRIVATE KEY BLOCK----- From nmav at gnutls.org Fri May 31 11:53:28 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 31 May 2013 11:53:28 +0200 Subject: [gnutls-help] openpgp and gnutls_privkey_import_openpgp In-Reply-To: <51A86DE7.6090506@yarpen.cz> References: <51A7511D.6040406@yarpen.cz> <51A86DE7.6090506@yarpen.cz> Message-ID: On Fri, May 31, 2013 at 11:31 AM, Petr Vanek wrote: > it's a testing key generated by gpg itself. Pub and priv ASCII exports > attached (it's safe it's really testing only key). > Is there any way how to verify the key, please? > Anyway - thanks for crash fix. Now I'm getting GNUTLS_E_INVALID_REQUEST > error. I think then the issue is that this is an encrypted key. Encrypted openpgp keys are not supported. You need to export it without a password in order to use it with the gnutls functions. regards, Nikos From petr at yarpen.cz Fri May 31 12:12:40 2013 From: petr at yarpen.cz (Petr Vanek) Date: Fri, 31 May 2013 12:12:40 +0200 Subject: [gnutls-help] openpgp and gnutls_privkey_import_openpgp In-Reply-To: References: <51A7511D.6040406@yarpen.cz> <51A86DE7.6090506@yarpen.cz> Message-ID: <51A87798.10905@yarpen.cz> On 05/31/2013 11:53 AM, Nikos Mavrogiannopoulos wrote: > On Fri, May 31, 2013 at 11:31 AM, Petr Vanek wrote: > >> it's a testing key generated by gpg itself. Pub and priv ASCII exports >> attached (it's safe it's really testing only key). >> Is there any way how to verify the key, please? >> Anyway - thanks for crash fix. Now I'm getting GNUTLS_E_INVALID_REQUEST >> error. > I think then the issue is that this is an encrypted key. Encrypted > openpgp keys are not supported. You need to export it without a > password in order to use it with the gnutls functions. ah thanks! It works when I remove a password from the priv key by gpg. Nikos, just a question - how hard would be to add this (password protected key parsing) feature to gnutls? Where is the place where to start investigation: gnutls or nettle? thanks, p. From marco.maggi-ipsu at poste.it Fri May 31 13:03:23 2013 From: marco.maggi-ipsu at poste.it (Marco Maggi) Date: Fri, 31 May 2013 13:03:23 +0200 Subject: [gnutls-help] on finding nettle under /usr/local rather than under /usr (GNU+Linux 64-bit system) In-Reply-To: marco.maggi-ipsu@poste.it (Nikos Mavrogiannopoulos's message of "Fri, 31 May 2013 10:27:39 +0200") References: <87obbslpkq.fsf@governatore.luna> Message-ID: <87li6vqumc.fsf@governatore.luna> Nikos Mavrogiannopoulos wrote: > Does the linking fails or compilation? If it is the latter a quick > hack is to configure using CFLAGS=-I/usr/local/include It works with neither: $ ./configure \ CPPFLAGS='-I/usr/local/include' \ LDFLAGS='-L/usr/local/lib' nor: $ ./configure \ CFLAGS='-I/usr/local/include -L/usr/local/lib' I always get: Making all in crywrap make[4]: Entering directory `/home/marco/var/build/lib/gnutls-3.2.0/src/crywrap' CCLD crywrap ../../lib/.libs/libgnutls.so: undefined reference to `nettle_umac96_set_key' ../../lib/.libs/libgnutls.so: undefined reference to `nettle_secp_224r1' ../../lib/.libs/libgnutls.so: undefined reference to `nettle_ecc_point_get' ../../lib/.libs/libgnutls.so: undefined reference to `nettle_ecdsa_generate_keypair' ... collect2: error: ld returned 1 exit status make[4]: *** [crywrap] Error 1 make[4]: Leaving directory `/home/marco/var/build/lib/gnutls-3.2.0/src/crywrap' and: $ ldd lib/.libs/libgnutls.so linux-vdso.so.1 (0x00007fff2f7b6000) libz.so.1 => /usr/lib64/libz.so.1 (0x00007f4aadb21000) libp11-kit.so.0 => /usr/lib64/libp11-kit.so.0 (0x00007f4aad90f000) libtasn1.so.6 => /usr/local/lib/libtasn1.so.6 (0x00007f4aad6fc000) libnettle.so.4 => /usr/lib64/libnettle.so.4 (0x00007f4aad4d7000) libhogweed.so.2 => /usr/lib64/libhogweed.so.2 (0x00007f4aad2c4000) libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x00007f4aad058000) libc.so.6 => /lib64/libc.so.6 (0x00007f4aacc6a000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f4aaca65000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f4aac849000) /lib64/ld-linux-x86-64.so.2 (0x00007f4aae044000) -- Marco Maggi From nmav at gnutls.org Fri May 31 13:15:19 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 31 May 2013 13:15:19 +0200 Subject: [gnutls-help] openpgp and gnutls_privkey_import_openpgp In-Reply-To: <51A87798.10905@yarpen.cz> References: <51A7511D.6040406@yarpen.cz> <51A86DE7.6090506@yarpen.cz> <51A87798.10905@yarpen.cz> Message-ID: On Fri, May 31, 2013 at 12:12 PM, Petr Vanek wrote: >> I think then the issue is that this is an encrypted key. Encrypted >> openpgp keys are not supported. You need to export it without a >> password in order to use it with the gnutls functions. > ah thanks! > It works when I remove a password from the priv key by gpg. > Nikos, just a question - how hard would be to add this (password > protected key parsing) feature to gnutls? Where is the place where to > start investigation: gnutls or nettle? You should start from gnutls_openpgp_privkey_import(). Adding support for password-protected files would require you possibly to modify the opencdk/ part of the library, and possibly implement CFB mode of decryption (that one would be best handled in nettle). Overall it shouldn't be much of work. regards, Nikos From nmav at gnutls.org Fri May 31 13:16:28 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 31 May 2013 13:16:28 +0200 Subject: [gnutls-help] on finding nettle under /usr/local rather than under /usr (GNU+Linux 64-bit system) In-Reply-To: <87li6vqumc.fsf@governatore.luna> References: <87obbslpkq.fsf@governatore.luna> <87li6vqumc.fsf@governatore.luna> Message-ID: On Fri, May 31, 2013 at 1:03 PM, Marco Maggi wrote: > Nikos Mavrogiannopoulos wrote: >> Does the linking fails or compilation? If it is the latter a quick >> hack is to configure using CFLAGS=-I/usr/local/include > $ ldd lib/.libs/libgnutls.so > linux-vdso.so.1 (0x00007fff2f7b6000) > libnettle.so.4 => /usr/lib64/libnettle.so.4 (0x00007f4aad4d7000) > libhogweed.so.2 => /usr/lib64/libhogweed.so.2 (0x00007f4aad2c4000) That's pretty strange. Did you run ldconfig on your system (and does its configuration include /usr/local/lib)? I'd expect that the latest library would be used. regards, Nikos From viric at viric.name Wed May 29 22:17:28 2013 From: viric at viric.name (=?iso-8859-1?Q?Llu=EDs?= Batlle i Rossell) Date: Wed, 29 May 2013 22:17:28 +0200 Subject: [gnutls-help] Problem with https://archive.org In-Reply-To: <51A6533C.3060903@gnutls.org> References: <20130517210014.GU5577@vicerveza.homeunix.net> <51A6533C.3060903@gnutls.org> Message-ID: <20130529201728.GR6512@vicerveza.homeunix.net> On Wed, May 29, 2013 at 09:13:00PM +0200, Nikos Mavrogiannopoulos wrote: > On 05/17/2013 11:00 PM, Llu?s Batlle i Rossell wrote: > > I tried gnutls 3.1 and 3.2.0 on https://archive.org (with wget and gnutls-cli), > > and both give me: > > Connecting to www.archive.org|207.241.224.2|:443... connected. > > GnuTLS: Could not negotiate a supported cipher suite. > > Unable to establish SSL connection. > > Enabling "EXPORT" in --priority (a friend helped me with that), made gnutls > > choose: > > |<3>| HSK[0x7a9ec0]: Selected cipher suite: RSA_AES_128_CBC_SHA1 > > Interesting. This server negotiates C0.13 (which is > ECDHE-RSA-AES256-SHA), and selects SSL 3.0. This ciphersuite is only > defined for TLS 1.0 or later and that's why gnutls rejects it and closes > the connection. > > This was a bug of a particular openssl version on Debian. > > If this is a widespread issue we may try to work it around in gnutls and > allow elliptic curves even in SSL 3.0. Thank you for the analysis! Is there anything I can do (env vars, config files) to tweak that gnutls behaviour so it could connect with a reasonable ciphersuite? Regards, Llu?s.