nettle-bugs

nettle-bugs@lists.lysator.liu.se

1 participants
2193 discussions

Nettle 3.7.2 and OS X 10.12.6
by Jeffrey Walton 21 Mar '21

21 Mar '21

$ make check ... ../run-tests aes-test arcfour-test arctwo-test blowfish-test bcrypt-test cast128-test base16-test base64-test camellia-test chacha-test cnd-memcpy-test des-test des3-test md2-test md4-test md5-test md5-compat-test memeql-test memxor-test gosthash94-test ripemd160-test hkdf-test salsa20-test sha1-test sha224-test sha256-test sha384-test sha512-test sha512-224-test sha512-256-test sha3-permute-test sha3-224-test sha3-256-test sha3-384-test sha3-512-test shake256-test streebog-test serpent-test twofish-test version-test knuth-lfib-test cbc-test cfb-test ctr-test gcm-test eax-test ccm-test cmac-test siv-test poly1305-test chacha-poly1305-test hmac-test umac-test meta-hash-test meta-cipher-test meta-aead-test meta-armor-test meta-mac-test buffer-test yarrow-test xts-test pbkdf2-test x86-ibt-test sexp-test sexp-format-test rsa2sexp-test sexp2rsa-test bignum-test random-prime-test pkcs1-test pkcs1-sec-decrypt-test pss-test rsa-sign-tr-test pss-mgf1-test rsa-pss-sign-tr-test rsa-test rsa-encrypt-test rsa-keygen-test rsa-sec-decrypt-test rsa-compute-root-test dsa-test dsa-keygen-test curve25519-dh-test curve448-dh-test ecc-mod-test ecc-modinv-test ecc-redc-test ecc-sqrt-test ecc-dup-test ecc-add-test ecc-mul-g-test ecc-mul-a-test ecdsa-sign-test ecdsa-verify-test ecdsa-keygen-test ecdh-test eddsa-compress-test eddsa-sign-test eddsa-verify-test ed25519-test ed448-test gostdsa-sign-test gostdsa-verify-test gostdsa-keygen-test gostdsa-vko-test cxx-test sexp-conv-test pkcs1-conv-test nettle-pbkdf2-test symbols-test dlopen-test /bin/sh: ../run-tests: Permission denied make[1]: *** [check] Error 126 make: *** [check] Error 2 $ cd testsuite/ $ ../run-tests aes-test -bash: ../run-tests: Permission denied $ ls -Al ../run-tests -rw-r--r-- 1 jwalton staff 2777 Mar 21 04:32 ../run-tests

1 1

[S390x] Optimize SHA functions
by Maamoun TK 21 Mar '21

21 Mar '21

I made a patch that optimizes SHA functions on S390x architecture. the patch implements the optimized cores using cipher instructions that have been added to s390x arch in message security assist extensions. The patch uses the following functions: KIMD-SHA-1, KLMD-SHA-1 (SHA1) KIMD-SHA-256, KLMD-SHA-256 (SHA256) KIMD-SHA-512, KLMD-SHA-512 (SHA512) KIMD-SHA3-224, KLMD-SHA3-224 (SHA3-224) KIMD-SHA3-256, KLMD-SHA3-224 (SHA3-256) KIMD-SHA3-384, KLMD-SHA3-224 (SHA3-384) KIMD-SHA3-512, KLMD-SHA3-224 (SHA3-512) KLMD-SHAKE-256 (SHA3-256-SHAKE) The patch built on top of AES patch of s390x so I can't make a merge request until the previous patch got merged. However, the code can be found in my fork s390x-sha <https://git.lysator.liu.se/mamonet/nettle/-/tree/s390x-sha>. The optimized core can be enabled by either fat build or enabling the corresponding configuration options (MSA, MSA-X1, MSA-X2, MSA-X6). Benchmark of this patch using nettle-benchmark (Tested on z15 5.2GHZ): *---------------------------------------------------------------------------* | Algorithm | C | Hardware-accelerated | | sha1 | 360.69 | 1735.34 | | sha224 | 244.63 | 2179.60 | | sha256 | 244.63 | 2179.74 | | sha384 | 372.57 | 3464.84 | | sha512 | 370.82 | 3463.66 | | sha512-224 | 364.93 | 3382.58 | | sha512-256 | 373.19 | 3463.23 | | sha3-224 | 236.50 | 6859.54 | | sha3-256 | 224.76 | 6656.05 | | sha3-384 | 173.21 | 5818.89 | | sha3-512 | 119.79 | 4693.53 | *---------------------------------------------------------------------------* I have a couple of questions for this patch: Is packing the configuration MSA options in single option is more convenient than spamming the options with MSA extensions? The optimized functions of sha3_update store the state buffer in big-endian order, while C implementation store each 64-bit of state buffer in little-endian order, I see the state buffer is used internally and since both sha3_update and sha3_digest are optimized so both have the same convention I think it's okay to keep it up like that, any opinions here? regards, Mamone

1 0

ANNOUNCE: Nettle-3.7.2
by nisse＠lysator.liu.se 21 Mar '21

21 Mar '21

I've prepared a new bug-fix release of Nettle, a low-level cryptographics library, to fix a serious bug in the function to verify ECDSA signatures. Implications include an assertion failure, which could be used for denial-of-service, when verifying signatures on the secp_224r1 and secp521_r1 curves. More details in NEWS file below. Upgrading is strongly recomended. The Nettle home page can be found at https://www.lysator.liu.se/~nisse/nettle/, and the manual at https://www.lysator.liu.se/~nisse/nettle/nettle.html. The release can be downloaded from https://ftp.gnu.org/gnu/nettle/nettle-3.7.2.tar.gz ftp://ftp.gnu.org/gnu/nettle/nettle-3.7.2.tar.gz https://www.lysator.liu.se/~nisse/archive/nettle-3.7.2.tar.gz Regards, /Niels NEWS for the Nettle 3.7.2 release This is a bugfix release, fixing a bug in ECDSA signature verification that could lead to a denial of service attack (via an assertion failure) or possibly incorrect results. It also fixes a few related problems where scalars are required to be canonically reduced modulo the ECC group order, but in fact may be slightly larger. Upgrading to the new version is strongly recommended. Even when no assert is triggered in ecdsa_verify, ECC point multiplication may get invalid intermediate values as input, and produce incorrect results. It's trivial to construct alleged signatures that result in invalid intermediate values. It appears difficult to construct an alleged signature that makes the function misbehave in such a way that an invalid signature is accepted as valid, but such attacks can't be ruled out without further analysis. Thanks to Guido Vranken for setting up the fuzzer tests that uncovered this problem. The new version is intended to be fully source and binary compatible with Nettle-3.6. The shared library names are libnettle.so.8.3 and libhogweed.so.6.3, with sonames libnettle.so.8 and libhogweed.so.6. Bug fixes: * Fixed bug in ecdsa_verify, and added a corresponding test case. * Similar fixes to ecc_gostdsa_verify and gostdsa_vko. * Similar fixes to eddsa signatures. The problem is less severe for these curves, because (i) the potentially out or range value is derived from output of a hash function, making it harder for the attacker to to hit the narrow range of problematic values, and (ii) the ecc operations are inherently more robust, and my current understanding is that unless the corresponding assert is hit, the verify operation should complete with a correct result. * Fix to ecdsa_sign, which with a very low probability could return out of range signature values, which would be rejected immediately by a verifier. -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

1 0

ANNOUNCE: Serious bug in Nettle's ecdsa_verify
by nisse＠lysator.liu.se 16 Mar '21

16 Mar '21

I've been made aware of a bug in Nettle's code to verify ECDSA signatures. Certain signatures result in the ecc point multiply function being called with out-of-range scalars, which may give incorrect results, or crash in an assertion failure. It's an old bug, probably since Nettle's initial implementation of ECDSA. I've just pushed fixes for ecdsa_verify, as well as a few other cases of potentially out-of-range scalars, to the master-updates branch. I haven't fully analysed the implications, but I'll describe my current understanding. I think an assertion failure, useful for a denial-of-service attack, is easy on the curves where the bitsize of q, the group order, is not an integral number of words. That's secp224r1, on 64-bit platforms, and secp521r1. Even when it's not possible to trigger an assertion failure, it's easy to produce valid-looking input "signatures" that hit out-of range intermediate scalar values where point multiplication may misbehave. This applies to all the NIST secp* curves as well as the GOST curves. To me, it looks very difficult to make it misbehave in such a way that ecdsa_verify will think an invalid signature is valid, but it might be possible; further analysis is needed. I will not be able to analyze it properly now, if anyone else would like to look into it, I can provide a bit more background. ed25519 and ed448 may be affected too, but it appears a bit harder to find inputs that hit out of range values. And since point operations are inherently more robust on these curves, I think they will produce correct results as long as they don't hit the assert. Advise on how to deal best with this? My current plan is to prepare a 3.7.2 bugfix release (from a new bugfix-only branch, without the new arm64 code). Maybe as soon as tomorrow (Wednesday, european time), or in the weekend. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

1 0

Status update
by nisse＠lysator.liu.se 07 Mar '21

07 Mar '21

I've haven't had much hacking time since the 3.7.1 bug fix rel1ease. I'm aware of the following recent issues that need review/work: 1. New Arm64 code (don't recall current status off the top of my head). 2. s390x testing. I'd prefer to not run a git checkout on the s390x test machine, but have the ci job make a tarball, ssh it over to the test machine, unpack in a fresh directory for build and test. This needs to be in place before adding s390x specific code. When done, could likely be reused for remote testing on any other platforms of interest, which aren't directly available in the ci system. 3. AES-keywrap merge request, https://git.lysator.liu.se/nettle/nettle/-/merge_requests/19 4. RSA-OAEP merge request. I intend to attend to (3) first, and will not pay much attention to this one at the moment. If anyone else would like to help out with review, maybe have alook at this one? https://git.lysator.liu.se/nettle/nettle/-/merge_requests/20 Anything else? There are other projects that's been on hold for a while, e.g., support for compact representation (aka "point compression") on the NIST curves, that I don't give high priority at the moment. I often get some hacking time on Wednesdays and weekends, but not every week. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

3 6

ANNOUNCE: Nettle-3.7.1
by nisse＠lysator.liu.se 17 Feb '21

17 Feb '21

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I'd like to announce a new release of GNU Nettle, a low-level cryptographics library. This release fixes a few problem in Nettle-3.7, in particular, a bug affecting GnuTLS on powerpc64 platforms. See NEWS entries below. The Nettle home page can be found at https://www.lysator.liu.se/~nisse/nettle/, and the manual at https://www.lysator.liu.se/~nisse/nettle/nettle.html. The release can be downloaded from https://ftp.gnu.org/gnu/nettle/nettle-3.7.1.tar.gz ftp://ftp.gnu.org/gnu/nettle/nettle-3.7.1.tar.gz https://www.lysator.liu.se/~nisse/archive/nettle-3.7.1.tar.gz Happy hacking, /Niels Möller NEWS for the Nettle 3.7.1 release This is primarily a bug fix release, fixing a couple of problems found in Nettle-3.7. The new version is intended to be fully source and binary compatible with Nettle-3.6. The shared library names are libnettle.so.8.2 and libhogweed.so.6.2, with sonames libnettle.so.8 and libhogweed.so.6. Bug fixes: * Fix bug in chacha counter update logic. The problem affected ppc64 and ppc64el, with the new altivec assembly code enabled. Reported by Andreas Metzler, after breakage in GnuTLS tests on ppc64. * Support for big-endian ARM platforms has been restored. Fixes contributed by Michael Weiser. * Fix build problem on OpenBSD/powerpc64, reported by Jasper Lievisse Adriaanse. * Fix corner case bug in ECDSA verify, it would produce incorrect result in the unlikely case of an all-zero message hash. Reported by Guido Vranken. New features: * Support for pbkdf2_hmac_sha384 and pbkdf2_hmac_sha512, contributed by Nicolas Mora. Miscellaneous: * Poorly performing ARM Neon code for doing single-block Salsa20 and Chacha has been deleted. The code to do two or three blocks in parallel, introduced in Nettle-3.7, is unchanged. - -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance. -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEy0li0HDXfX/Li6Nicdjx/zaMZncFAmAtgJMACgkQcdjx/zaM ZnfTEQf+KdzEoCkSHZfOFQ9qreKfY4ZVzxO3Nbh8wBiQYbueUw2X9kNxh+ErL4M7 FL2ovRbE3vLsWft5Y+rWg7wmDPUCwOdVsovURwENB6l+kbynksG+DWhIfg6hcjQ4 qqlhSArW/2UtIlswMj1hfh/g//aUDl0gigZX0C1LmCIlr4IzZvmMk5+9ZsR+9cXT +R/gdh2Hxw/DzMT8yB/J5wP5/5IzA5xkV2LhBKqS538bFEVsE7t+DInEjoUYhmtv st5VuyUxstKxqtp6RB+RfVcWDwpyyMi6/wn8fKfv5UkdVVgOHsXwY2Ls2YG6oKvs XswtEhTV17sYMTlVNtLKm8vOLnLYPA== =E0qp -----END PGP SIGNATURE-----

1 0

Arcfour status
by nisse＠lysator.liu.se 14 Feb '21

14 Feb '21

I've had a report (from Matthew Kempe) about another problem with the openssl benchmarking code. It fails on FreeBSD, because there (and possible in other environments too) openssl has been configured without RC4 (aka arcfour) support. I'm considering just deleting code to benchmark openssl arcfour; I don't plan any improvements of Nettle's arcfour performance, and I would be surprised if the openssl people do. I do intend to keep arcfour support in Nettle for the foreseeable future, to support old protocols and applications. But I'm thinking that maybe the arcfour assembly code could be deleted? Nettle currently includes arcfour assembly implementations for x86 (32-bit) and sparc (both 32-bit and 64-bit), which as far as I remember gave a modest speedup when added. But the code hasn't been tuned or benchmarked recently. And we have nothing for more relevant platforms. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

2 1

GnuTLS testsuite error on ppc64 after nettle upgrade
by Andreas Metzler 10 Feb '21

10 Feb '21

Hello, Upgrading nettle from 3.6 to 3.7 triggers a GnuTLS 3.7.0 testsuite error on both ppc64 and ppc64el: (sid_ppc64el-dchroot)ametzler@plummer:~/GNUTLS/gnutls28-3.7.0/b4deb/tests$ ./min i-record-2 testing aes-cbc testing aes-cbc-sha256 testing aes-gcm testing aes-ccm testing aes-ccm-8 testing null-sha1 testing arcfour-sha1 testing arcfour-md5 testing chacha20-poly1305 testing tls13-chacha20-poly1305 server:330: client: Error: An unexpected TLS packet was received. Running the same binary dynamically (with LD_LIBRARY_PATH setting) linked against nettle 3.6 succeeds. --verbose logs are huge (5-7 MB xz-compressed), I have uploaded them to https://people.debian.org/~ametzler/tmp/ cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'

4 10

Bug fix release Nettle-3.7.1 ?
by nisse＠lysator.liu.se 10 Feb '21

10 Feb '21

Hi, I think the chacha bug is a severe enough regression to warrant a bugfix release pretty soon. I'll aim to get it out in a week from now. I think it should be fine to do a 3.7.1 release from the master branch, rather than cherry-picking selected bugfixes. I've looked through git history and ChangeLog since the release one and a half month ago, and I think this is a accurate summary for the NEWS file: Bug fixes: * Fix bug in chacha counter update logic. The problem affected ppc64 and ppc64el, with the new altivec assembly code enabled. Reported by Andreas Metzler, after breakage in GnuTLS tests on ppc64. * Support for big-endian ARM platforms has been restored. Fixes contributed by Michael Weiser. * Fix build problem on OpenBSD/powerpc64, reported by Jasper Lievisse Adriaanse. * Fix corner case bug in ECDSA verify, it would produce incorrect result in the unlikely case of an all-zero message hash. Reported by Guido Vranken. New features: * Support for pbkdf2_hmac_sha384 and pbkdf2_hmac_sha512, contributed by Nicolas Mora. Miscellaneous: * Poorly performing ARM Neon code for doing single-block Salsa20 and Chacha has been deleted. The code to do two or three blocks in parallel, introduced in Nettle-3.7, is unchanged. Sonames will be unchanged. libnettle.so should get an incremented minor number, for the addition of the new pbkdf2 function. I don't think libhogweed.so strictly needs an incremented minor number, but maybe it's less confusing to increment it anyway. Anything I'm missing? Any easy in-progress changes that should also get into the release? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

1 0

Re: Release of Nettle-3.7?
by nisse＠lysator.liu.se 06 Feb '21

06 Feb '21

Michael Weiser <michael(a)weiser.dinsnail.net> writes: > Porting over the basic > IF_[LB]E mechanism from chacha-core-internal was easy and fixed up the > first of the three interleaved blocks right away. For the other two I am > still in the process of wrapping my head around how the interleaving > works and how it would need some adjustment for BE. The 3-way functions don't do anything fancy, just each of the three blocks represented in separate registers, and same instruction sequence as for the 1-way version, duplicated threee times and interleaved. The 2-way version (for ARM, that's salsa only) tries to be a bit more clever, with registers representing either odd or even words from both blocks. Not sure how endianness affects the code to move words around. Byte swapping should go close to the final stores, but after the addition of the initial state. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

3 16

← Newer
1
...
7
8
9
10
11
12
13
...
220
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

nettle-bugs