nettle-bugs March 2021

nettle-bugs@lists.lysator.liu.se

6 participants
18 discussions

[AArch64] Fat build support for GCM optimization and syntax improvements
by Maamoun TK 22 Mar '21

22 Mar '21

I made a merge request #21 <https://git.lysator.liu.se/nettle/nettle/-/merge_requests/21> that adds fat build support for GCM implementation on arm64, the patch also updates the README file to stay on par with the other architectures and use m4 macros in gcm-hash.asm (patch provided by Niels Möller), in addition to add documentation comments. regards, Mamone

2 1

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

22 Mar '21

And it looks like examples are not quite working either: $ make check ... ==================== All 110 tests passed ==================== Making check in examples TEST_SHLIB_DIR="/Users/jwalton/Build-Scripts/nettle-3.7.2/.lib" \ srcdir="." EMULATOR="" EXEEXT="" \ ".."/run-tests rsa-sign-test rsa-verify-test rsa-encrypt-test Opening `testkey' failed: No such file or directory Invalid key FAIL: rsa-sign Opening `testkey' failed: No such file or directory Invalid key FAIL: rsa-verify Opening `testkey.pub' failed: No such file or directory Invalid key FAIL: rsa-encrypt =================== 3 of 3 tests failed =================== make[1]: *** [check] Error 1 make: *** [check] Error 2 $ find . -name testkey.pub $ find . -name testkey $ Examples have been breaking the build for years. Why are examples even built during 'make check'? Can they be moved to their own recipe so users can get on with their work? Jeff

2 1

Nettle 3.7.2 and OS X 10.5
by Jeffrey Walton 22 Mar '21

22 Mar '21

Hi Everyone, I'm testing Nettle 3.7.2 on a PowerMac with OS X 10.5 . I added -maltivec to CFLAGS and CXXFLAGS. I enabled Altivec builds with --enable-power-altivec and --enable-fat. Auditing the dylib it appears Altivec was not engaged: $ otool -tV /usr/local/lib/libnettle.dylib | grep perm 0001f124 b _nettle_sha3_permute _nettle_sha3_permute: 000204ec bl _nettle_sha3_permute I think there's something a bit sideways here. Jeff

2 1

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

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 March 2021