From nmav at gnutls.org Sat Dec 1 06:39:22 2018 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 01 Dec 2018 06:39:22 +0100 Subject: [gnutls-help] gnutls 3.6.5 Message-ID: Hello, I've just released gnutls 3.6.5. This is a bug fix release on the 3.6.x branch. It fixes several issues related to TLS1.3 support, and addresses a moderate-severity issue related to RSA-encryption ciphersuites. The issue affects usage of gnutls mainly in "cloud" environments which we believe are an essential use case for crypto libs today (see nettle's announcement for more information on the issue [0]). Due to that fix the minimum required version of nettle is 3.4.1. That release marks the 3.6.x as our stable branch, and replaces the 3.5.x branch. The detailed list of changes follows. I'd like to thank everyone who was involved in the release Ander Juaristi, Daiki Ueno, Dmitry Eremin-Solenikov, Simo Sorce, Stefan Berger, Stephan Mueller, Tim R?hsen, Tom Vrancken as well as Niels Mueller for his work on the nettle library which made this release possible. [0]. https://lists.lysator.liu.se/pipermail/nettle-bugs/2018/007363.html Changes ======= * Version 3.6.5 (released 2018-12-01) ** libgnutls: Provide the option of transparent re-handshake/reauthentication when the GNUTLS_AUTO_REAUTH flag is specified in gnutls_init() (#571). ** libgnutls: Added support for TLS 1.3 zero round-trip (0-RTT) mode (#127) ** libgnutls: The priority functions will ignore and not enable TLS1.3 if requested with legacy TLS versions enabled but not TLS1.2. That is because if such a priority string is used in the client side (e.g., TLS1.3+TLS1.0 enabled) servers which do not support TLS1.3 will negotiate TLS1.2 which will be rejected by the client as disabled (#621). ** libgnutls: Change RSA decryption to use a new side-channel silent function. This addresses a security issue where memory access patterns as well as timing on the underlying Nettle rsa-decrypt function could lead to new Bleichenbacher attacks. Side-channel resistant code is slower due to the need to mask access and timings. When used in TLS the new functions cause RSA based handshakes to be between 13% and 28% slower on average (Numbers are indicative, the tests where performed on a relatively modern Intel CPU, results vary depending on the CPU and architecture used). This change makes nettle 3.4.1 the minimum requirement of gnutls (#630). [CVSS: medium] ** libgnutls: gnutls_priority_init() and friends, allow the CTYPE-OPENPGP keyword in the priority string. It is only accepted as legacy option and is ignored. ** libgnutls: Added support for EdDSA under PKCS#11 (#417) ** libgnutls: Added support for AES-CFB8 cipher (#357) ** libgnutls: Added support for AES-CMAC MAC (#351) ** libgnutls: In two previous versions GNUTLS_CIPHER_GOST28147_CPB/CPC/CPD_CFB ciphers have incorrectly used CryptoPro-A S-BOX instead of proper (CryptoPro-B/-C/-D S-BOXes). They are fixed now. ** libgnutls: Added support for GOST key unmasking and unwrapped GOST private keys parsing, as specified in R 50.1.112-2016. ** gnutls-serv: It applies the default settings when no --priority option is given, using gnutls_set_default_priority(). ** p11tool: Fix initialization of security officer's PIN with the --initialize-so-pin option (#561) ** certtool: Add parameter --no-text that prevents certtool from outputting text before PEM-encoded private key, public key, certificate, CRL or CSR. ** API and ABI modifications: GNUTLS_AUTO_REAUTH: Added GNUTLS_CIPHER_AES_128_CFB8: Added GNUTLS_CIPHER_AES_192_CFB8: Added GNUTLS_CIPHER_AES_256_CFB8: Added GNUTLS_MAC_AES_CMAC_128: Added GNUTLS_MAC_AES_CMAC_256: Added gnutls_record_get_max_early_data_size: Added gnutls_record_send_early_data: Added gnutls_record_recv_early_data: Added gnutls_db_check_entry_expire_time: Added gnutls_anti_replay_set_add_function: Added gnutls_anti_replay_init: Added gnutls_anti_replay_deinit: Added gnutls_anti_replay_set_window: Added gnutls_anti_replay_enable: Added gnutls_privkey_decrypt_data2: Added Getting the Software ==================== GnuTLS may be downloaded directly from ;. A list of GnuTLS mirrors can be found at ;. Here are the XZ compressed sources: https://www.gnupg.org/ftp/gcrypt/gnutls/v3.6/gnutls-3.6.5.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: https://www.gnupg.org/ftp/gcrypt/gnutls/v3.6/gnutls-3.6.5.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 alice at librelamp.com Wed Dec 19 02:04:07 2018 From: alice at librelamp.com (Alice Wonder) Date: Tue, 18 Dec 2018 17:04:07 -0800 Subject: [gnutls-help] Utility for public key Message-ID: <47734faa-6389-efaa-42a2-e2c557a91a48@librelamp.com> Hi, new to GnuTLS Using GnuTLS 3.6.5 (built on CentOS 7.6) What I am looking for is a simple utility program to generate public key from private key *without* needing to generate a x.509 certificate. Use case is OpenDKIM on mail servers I figured out easy enough how to use certtool to generate ed25519 private key, but I need to generate public key to stick in the DKIM DNS record. I am guessing there is probably simple C code out there somewhere that can do it, but I didn't see public key export options in certtool man page to do it. RSA private to public would be nice too, I can do that conversion w/ openssl but my openssl is too old for ed25519. I know it probably is too early to use ed25519 dkim signing in the wild, but I want to set up signing from a web host that only ever e-mails me so that I can test validation and make sure my OpenDKIM (built against GnuTLS) validates it properly. Thank you for any suggestions. From alice at librelamp.com Wed Dec 19 02:56:02 2018 From: alice at librelamp.com (Alice Wonder) Date: Tue, 18 Dec 2018 17:56:02 -0800 Subject: [gnutls-help] Utility for public key In-Reply-To: <47734faa-6389-efaa-42a2-e2c557a91a48@librelamp.com> References: <47734faa-6389-efaa-42a2-e2c557a91a48@librelamp.com> Message-ID: <70177d98-0170-1155-e537-c4ac74a20b5b@librelamp.com> On 12/18/18 5:04 PM, Alice Wonder wrote: > Hi, new to GnuTLS > > Using GnuTLS 3.6.5 (built on CentOS 7.6) > > What I am looking for is a simple utility program to generate public key > from private key *without* needing to generate a x.509 certificate. > *snip* Think I found a simple solution in Python, sorry for noise. From alice at librelamp.com Thu Dec 20 01:10:46 2018 From: alice at librelamp.com (Alice Wonder) Date: Wed, 19 Dec 2018 16:10:46 -0800 Subject: [gnutls-help] typo fix in tests [3.6.5] Message-ID: <18313281-6998-1b31-e5b2-b7f87f4f75ac@librelamp.com> sed -i 's|machanisms|mechanisms|g' tests/testpkcs11.sh From nicolas at babelouest.org Fri Dec 21 15:25:29 2018 From: nicolas at babelouest.org (Nicolas Mora) Date: Fri, 21 Dec 2018 09:25:29 -0500 Subject: [gnutls-help] Incompability between gnutls 3.5.8 and 3.6.5 for gnutls_encode_rs_value and gnutls_decode_rs_value Message-ID: <6739c5ad4ff57384d8148ce192d7e7f8@babelouest.org> Hello, Last year I asked a question about encoding and decoding messages with ECDSA using GnuTLS. At that time, the functions to achieve this were present but not exported in GnuTLS 3.5.8. So the solution was to manually export them in my code [1] and it works like a charm for this version of GnuTLS [2]. Unfortunately, it seems that my code no longer works with GnuTLS 3.6. I realized this by building and testing libjwt with gnutls backend under a Debian Stretch (GnuTLS 3.5.8), and a Debian testing (currently GnuTLS 3.6.5). My question is: Are there differences between GnuTLS 3.5.x and 3.6.x on the functions gnutls_encode_rs_value and gnutls_decode_rs_value or in the ECDSA encoding/decoding? And if so, Are there a way to fix my code in order to encode and decode messages with ECDSA algorithm? Thanks in advance for the help. [1] - https://lists.gnupg.org/pipermail/gnutls-help/2017-May/004314.html [2] - https://github.com/benmcollins/libjwt/blob/master/libjwt/jwt-gnutls.c#L25 From nicolas at babelouest.org Fri Dec 21 21:57:51 2018 From: nicolas at babelouest.org (Nicolas Mora) Date: Fri, 21 Dec 2018 15:57:51 -0500 Subject: [gnutls-help] Incompability between gnutls 3.5.8 and 3.6.5 for gnutls_encode_rs_value and gnutls_decode_rs_value In-Reply-To: <6739c5ad4ff57384d8148ce192d7e7f8@babelouest.org> References: <6739c5ad4ff57384d8148ce192d7e7f8@babelouest.org> Message-ID: <10af29931529afa1850e9491a1bde7ee@babelouest.org> Le 2018-12-21 09:25, Nicolas Mora a ?crit?: > > And if so, Are there a way to fix my code in order to encode and > decode messages with ECDSA algorithm? > I made a sample source code to explain my problem: https://gist.github.com/babelouest/ad6ca39e43587bf037b9868e1ac9ad9d This program signs and then verify the signature of a message using SHA256 and ECDSA algorithms. - When using GnuTLS 2.5.8, signing and verifying the message work fine. - When using GnuTLS 3.6.5, signing works, but verifying the message fails. If I use r and s structures with gnutls_decode_rs_value/gnutls_encode_rs_value, the result is the same. I can't figure out what's wrong with my code. Does someone have an idea? /Nicolas