nettle-bugs

nettle-bugs@lists.lysator.liu.se

1 participants
2197 discussions

[PATCH v3 0/1] Add Cipher FeedBack mode support
by Dmitry Eremin-Solenikov 04 Jan '18

04 Jan '18

Add CFB mode support. CFB uses segment size = block size. Changes since V2: - Dropped CFB8, isn't widely used. - Simplified cfb_encrypt code. - Dropped code handling IV for last-partial-segment. One should set IV for new message anyway, so there little point in adding additional complexity there. Changes since V1: - Add CFB8 support - Minor corrections in documentation. Dmitry Eremin-Solenikov (1): Add CFB block mode support Makefile.in | 4 +- cfb.c | 165 ++++++++++++++++++++++++++ cfb.h | 87 ++++++++++++++ nettle.texinfo | 106 +++++++++++++++-- testsuite/.gitignore | 1 + testsuite/.test-rules.make | 3 + testsuite/Makefile.in | 2 +- testsuite/cfb-test.c | 287 +++++++++++++++++++++++++++++++++++++++++++++ testsuite/testutils.c | 179 ++++++++++++++++++++++++++++ testsuite/testutils.h | 7 ++ 10 files changed, 829 insertions(+), 12 deletions(-) create mode 100644 cfb.c create mode 100644 cfb.h create mode 100644 testsuite/cfb-test.c -- 2.14.2

3 6

Skein status
by nisse＠lysator.liu.se 01 Jan '18

01 Jan '18

I'm looking at the skein code I wrote a while ago, and I might merge it pretty soon, just need a little cleanup. I'm doing skein256 and skein512 (other variants, in particular, skein512-256, mey be of interest). For skein256, it works quite well with two-way unrolling (by which I mean that each loop iteration performs 8 mixing rounds, adding in subkeys twice). I did an x86_64 assembly version, but I'm not being able to beat C code compiled by gcc, so I think I'll scrap that. Which isn't so surprising, since skein uses only operations that the C compiler knows well, and I'm not trying anything clever with scheduling or register allocation. For skein512, subkeys are accessed with mod 9 indexing, which is challenging to do with high performance, if indexes need to be constructed at runtime. I get pretty good performance with full unrolling (so indices are constant), and I'm afraid we have to do either that, or copy subkeys into an area where they are repeated multiple times. As I think I wrote earlier, skein looks similar in spirit to salsa20 and chacha, but unlike those, it's doesn't fit well with simd instructions. To use simd instructions for skein, one would like to put put 2 64-bit values in one xmm register, but one then needs a way to rotate the two halves with different shift counts, which I haven't found any good way to do. Also the odd number of subkeys (five for skein256, and nine for skein512, with the last subkey being the xor of all the other keys and a magic constant), usued in a rotationg fashion, doesn't fit well with storing keys in simd registers. I'm benchmarking on a intel broadwell cpu (marketing name "core i3-5010U") running at 2.1 GHz. Algorithm mode Mbyte/s cycles/byte cycles/block skein256 update 242.45 8.26 264.33 skein512 update 350.44 5.71 365.75 For comparison, timing for sha1, sha2 and sha3: Algorithm mode Mbyte/s cycles/byte cycles/block sha1 update 326.40 6.14 392.69 openssl sha1 update 560.98 3.57 228.48 sha256 update 156.07 12.83 821.24 sha512 update 252.54 7.93 1015.10 sha3_224 update 161.90 12.37 1781.33 sha3_256 update 152.83 13.10 1782.18 sha3_384 update 117.06 17.11 1779.22 sha3_512 update 80.52 24.87 1790.77 So skein512 is faster than both sha2 and sha3 (and one can also see that for sha1 we currently lose to openssl). skein256 is fastet than sha3, but slightly slower than sha512. So maybe we shouldn't do skein256 at all, but skein512-256 (skein can be used with arbitrary output size). Code size for is 408 bytes for skein256, and 3992 bytes for skein512 (which is completely unrolled). Counting only the main block processing function. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

1 0

ANNOUNCE: Nettle-3.4
by nisse＠lysator.liu.se 19 Nov '17

19 Nov '17

I'm happy to announce a new release of GNU Nettle, a low-level cryptographics library. This release includes a couple of bugfixes and new features. Next release is likely to break ABI compatibility, to make that transition easier, applications are encourraged to adopt the new accessor functions introduced in this release. 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.4.tar.gz ftp://ftp.gnu.org/gnu/nettle/nettle-3.4.tar.gz https://www.lysator.liu.se/~nisse/archive/nettle-3.4.tar.gz Happy hacking, /Niels möller NEWS for the Nettle 3.4 release This release fixes bugs and adds a few new features. It also addresses an ABI compatibility issue affecting Nettle-3.1 and later, see below. Bug fixes: * Fixed an improper use of GMP mpn_mul, breaking curve2559 and eddsa on certain platforms. Reported by Sergei Trofimovich. * Fixed memory leak when handling invalid signatures in ecdsa_verify. Fix contributed by Nikos Mavrogiannopoulos. * Fix compilation error with --enable-fat om ARM. Fix contributed by Andreas Schneider. * Reorganized the way certain data items are made available. Short version: Nettle header files now define the symbols nettle_hashes, nettle_ciphers, and nettle_aeads, as preprocessor macros invoking a corresponding accessor function. For backwards ABI compatibility, the symbols are still present in the compiled libraries, and with the same sizes as in nettle-3.3. New features: * Support for RSA-PSS signatures, contributed by Daiki Ueno. * Support for the HKDF key derivation function, defined by RFC 5869. Contributed by Nikos Mavrogiannopoulos. * Support for the Cipher Feedback Mode (CFB), contributed by Dmitry Eremin-Solenikov. * New accessor functions: nettle_get_hashes, nettle_get_ciphers, nettle_get_aeads, nettle_get_secp_192r1, nettle_get_secp_224r1, nettle_get_secp_256r1, nettle_get_secp_384r1, nettle_get_secp_521r1. For source-level compatibility with future versions, applications are encouraged to migrate to using these functions instead of referring to the corresponding data items directly. Miscellaneous: * The base16 and base64 functions now use the type char * for ascii data, rather than uint8_t *. This eliminates the last pointer-signedness warnings when building Nettle. This is a minor API change, and applications may need to be adjusted, but the ABI is unaffected on all platforms I'm aware of. * The contents of the header file nettle/version.h is now architecture independent, except in --enable-mini-gmp configurations. ABI issue: Since the breakage was a bit subtle, let me document it here. The nettle and hogweed libraries export a couple of data symbols, and for some of these, the size was never intended to be part of the ABI. E.g., extern const struct nettle_hash * const nettle_hashes[]; which is an NULL-terminated array. It turns out the sizes nevertheless may leak into the ABI, and that increasing the sizes can break old executables linked with a newer version of the library. When linking a classic non-PIE executable with a shared library, we get ELF relocations of type R_X86_64_COPY for references to data items. These mean that the linker allocates space for the data item in the data segment of executable, at a fixed address determined at link-time, and with size extracted from the version of the .so-file seen when linking. At load time, the run time linker then copies the contents of the symbol from the .so file to that location, and uses the copy instead of the version loaded with the .so-file. And if the data item in the .so file used at load time is larger than the data item seen at link time, it is silently truncated in the process. So when SHA3 hashes were was added to the nettle_hashes array in the nettle-3.3 release, this way of linking produces a truncated array at load time, no longer NULL-terminated. We will get similar problems for planned extensions of the internal struct ecc_curve, and exported data items like extern const struct ecc_curve nettle_secp_256r1; where the ecc_curve struct is only forward declared in the public headers. To prepare, applications should migrate to using the new function nettle_get_secp_256r1, and similarly for the other curves. In some future version, the plan is to add a leading underscore to the name of the actual data items. E.g., nettle_hashes --> _nettle_hashes, breaking the ABI, while keeping the nettle_get_hashes function and the nettle_hashes macro as the supported ways to access it. We will also rename nettle_secp_256r1 --> _nettle_secp_256r1, breaking both ABI and API. Note that data items like nettle_sha256 are *not* affected, since the size and layout of this struct is considered part of the ABI, and R_X86_64_COPY-relocations then work fine. The shared library names are libnettle.so.6.4 and libhogweed.so.4.4, with sonames still libnettle.so.6 and libhogweed.so.4. It is intended to be fully binary compatible with nettle-3.1. -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

1 0

Nettle-3.4 rc2
by nisse＠lysator.liu.se 15 Nov '17

15 Nov '17

Hi, I've prepared a "release candidate" tarball, https://www.lysator.liu.se/~nisse/archive/nettle-3.4rc2.tar.gz All testing appreciated, in particular on non-x86 or non-gnu/linux platforms. If all goes well, I might make the release next weekend. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

2 7

Fix UBSAN issue
by Tim Rühsen 09 Nov '17

09 Nov '17

Nothing with a real impact, just to silence sanitizers. From OSS-Fuzz: SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /src/libfuzzer/FuzzerSHA1.cpp:132:14 in sec-tabselect.c:58:24: runtime error: negation of 1 cannot be represented in type 'mp_limb_t' (aka 'unsigned long') Patch attached. With Best Regards, Tim

2 5

Release plan?
by nisse＠lysator.liu.se 09 Nov '17

09 Nov '17

There are several unfinished projects, curve448, gost cryptos, skein,... But there are also a few new features completed since the nettle-3.3 release: rsa-pss, and hkdf. And a couple of bugfixes. And we have the ABI problems which are only half way fixed, and which I think are pretty important. So I'm thinking, maybe we should try to fix the ABI issue and get in shape for release, and not try to get more new features in 3.4? To get minimal ABI breakage, I also suspect we would need a release branch where I revert recent changes that grow the size of struct ecc_curve; my idea is to introduce functions returning pointers to the instances of this struct. But as long as applications are using the data symbols directly as advertised in ecc-curves.h, executables with R_X86_64_COPY relocations will break, in the same way as arrays like nettle_hashes. What do you think? See https://www.lysator.liu.se/~nisse/nettle/plan.html for current list. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

3 12

[PATCH 0/5] Improve GOST R 34.11-94 hash function support
by Dmitry Eremin-Solenikov 25 Oct '17

25 Oct '17

This in an excerpt from previously sent patch set [PATCH 00/13] GOST cipher/MAC/hash algorithms support This patch series concentrates on gosthash94 support. It adds gosthash94cp -- GOST R 34.11-94 variant using more popular S-Box and implements HMAC and PBKDF2 interfaes for GOST hashing algorithms. References: - GOST R 34.11-94: RFC 5831 https://tools.ietf.org/html/rfc5831 - GOST 28147-89: RFC 5830 https://tools.ietf.org/html/rfc5830 - S-Boxes: RFC 4357 https://tools.ietf.org/html/rfc4357 Dmitry Eremin-Solenikov (5): Add GOST R 34.11 to nettle_hashes Start separating GOST 28147-89 from GOST R 34.11-94 Add support for GOSTHASH94CP: GOST R 34.11-94 hash with CryptoPro S-box Add HMAC functions for GOSTHASH94 and GOSTHASH94CP Add PBKDF2 support for gosthash94cp Makefile.in | 8 +- examples/nettle-benchmark.c | 1 + gost28147.c | 607 ++++++++++++++++++++++++++++++++++++++++++++ gost28147.h | 66 +++++ gosthash94-meta.c | 3 + gosthash94.c | 321 +++++------------------ gosthash94.h | 13 + hmac-gosthash94.c | 79 ++++++ hmac.h | 37 +++ nettle-meta-hashes.c | 2 + nettle-meta.h | 1 + nettle.texinfo | 41 ++- pbkdf2-hmac-gosthash94.c | 54 ++++ pbkdf2.h | 7 + testsuite/gosthash94-test.c | 12 + testsuite/hmac-test.c | 14 + testsuite/meta-hash-test.c | 2 + testsuite/pbkdf2-test.c | 24 ++ 18 files changed, 1033 insertions(+), 259 deletions(-) create mode 100644 gost28147.c create mode 100644 gost28147.h create mode 100644 hmac-gosthash94.c create mode 100644 pbkdf2-hmac-gosthash94.c -- 2.13.2

1 6

[PATCH 0/6] Secp256k1 curve support
by Dmitry Eremin-Solenikov 16 Oct '17

16 Oct '17

This is the set of patches to add secp256k1 support. They apply on top of curve448 patches, because they reuse ecc->dup field added in that patchset. Dmitry Eremin-Solenikov (6): ecc: use dup fiels for all the curves eccdata: use 'a' coefficient eccdata: switch to using curve name instead of just bits ecc: include coefficient 'a' into the ecc_curve struct ecdsa-keygen-test: make use of ecc->a ecc: support secp256k1 curve Makefile.in | 26 ++++++---- ecc-192.c | 1 + ecc-224.c | 1 + ecc-25519.c | 1 + ecc-256.c | 1 + ecc-384.c | 1 + ecc-521.c | 1 + ecc-curve.h | 1 + ecc-dup-jj-0.c | 108 ++++++++++++++++++++++++++++++++++++++++++ ecc-internal.h | 11 ++++- ecc-mul-a.c | 6 +-- ecc-mul-g.c | 2 +- eccdata.c | 103 +++++++++++++++++++++++++++++----------- testsuite/ecc-add-test.c | 2 +- testsuite/ecc-dup-test.c | 2 +- testsuite/ecdsa-keygen-test.c | 5 +- testsuite/testutils.c | 12 ++++- 17 files changed, 238 insertions(+), 46 deletions(-) create mode 100644 ecc-dup-jj-0.c -- 2.14.2

1 6

[PATCH v2 0/2] Add Cipher FeedBack mode support
by Dmitry Eremin-Solenikov 05 Oct '17

05 Oct '17

Add support for CFB and CFB8 modes support. CFB uses segment size = block size, CFB8 uses 8-bit segments. Changes since V1: - Add CFB8 support - Minor corrections in documentation. Dmitry Eremin-Solenikov (2): Add CFB block mode support Add CFB8 - Cipher Feedback 8-bit block cipher mode Makefile.in | 4 +- cfb.c | 257 +++++++++++++++++++++++++++++ cfb.h | 122 ++++++++++++++ nettle.texinfo | 188 ++++++++++++++++++++-- testsuite/.gitignore | 1 + testsuite/.test-rules.make | 3 + testsuite/Makefile.in | 2 +- testsuite/cfb-test.c | 390 +++++++++++++++++++++++++++++++++++++++++++++ testsuite/testutils.c | 357 +++++++++++++++++++++++++++++++++++++++++ testsuite/testutils.h | 14 ++ 10 files changed, 1326 insertions(+), 12 deletions(-) create mode 100644 cfb.c create mode 100644 cfb.h create mode 100644 testsuite/cfb-test.c -- 2.14.1

2 10

Cannot build nettle with local GMP on CentOS 6
by Robert Paprocki 01 Oct '17

01 Oct '17

Hello, I have compiled Nettle 3.3 with GMP 6.1.2 on a variety of systems (various Ubuntu/Debian distros, CentOS 7, Alpine) with success: ##### build GMP # pwd /tmp/gmp-6.1.2 # ./configure && make [...snip...] # find . -name "*.so" ./.libs/libgmp.so ###### build nettle # pwd /tmp/nettle-3.3 # CPPFLAGS="-I../gmp-6.1.2/" LDFLAGS="-L../gmp-6.1.2/.libs" ./configure && make Again this works as expected on a variety of systems, except for CentOS 6 (using the centos:6 docker image). On CentOS 6 nettle configure fails with the following: checking for GMP limb size... configure: error: in `/tmp/nettle-3.3': configure: error: cannot find value of GMP_NUMB_BITS Full configure output: https://pastebin.com/9s3nfA8G Oddly enough, if I install GMP (via 'make install') to a default search path, configure/make works as expected. Additionally, if I define LD_LIBRARY_PATH to the GMP lib build path (/tmp/gmp-6.1.2/.libs), the configure process works as expected, but we then encounter further errors when building (during the hogweed build process): gcc -I.. -I.. -I../gmp-6.1.2/ -DHAVE_CONFIG_H -g -O2 -ggdb3 -Wno-pointer-sign -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wnested-externs -MT pkcs1-conv.o -MD -MP -MF pkcs1-conv.o.d -c pkcs1-conv.c && true In file included from ../rsa.h:38, from pkcs1-conv.c:47: ../bignum.h:54:18: error: gmp.h: No such file or directory Which is very odd because we gmp.h definitely does exist (our gcc call has the following: -I../gmp-6.1.2/): # file ../gmp-6.1.2/gmp.h ../gmp-6.1.2/gmp.h: ASCII C program text FWIW, the gcc/m4 versions on CentOS 6 are fairly old: [root@56de37e1bc78 nettle-3.3]# gcc --version gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18) [root@56de37e1bc78 nettle-3.3]# m4 --version m4 (GNU M4) 1.4.13 I tried upgrading GCC to 4.8 with no change; trying to update m4 was more than I wanted to chew off as it involved a libc change. Has anyone run into this behavior before? I wonder if this is potentially a bug with m4, but I'm not quite sure where to look at this point. Again we can work around our problem by installing GMP to a system dir (/usr/local/lib), but would like to avoid this if we can. One other thing I noted is that when running 'make install' in this environment, gmp installs to /usr/local/lib while nettle installs to /usr/local/lib64. Not sure if this is meaningful, or indicative of a compiler/configure flag that needs be adjusted for CentOS specifically (or any other

2 1

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