nettle-bugs

nettle-bugs@lists.lysator.liu.se

1 participants
2197 discussions

ANNOUNCE: Nettle-3.5.1
by nisse＠lysator.liu.se 27 Jun '19

27 Jun '19

There was a packaging problem with the Nettle-3.5 release of yesterday, breaking certain x86_64 configurations. 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 corrected release can be downloaded from https://ftp.gnu.org/gnu/nettle/nettle-3.5.1.tar.gz ftp://ftp.gnu.org/gnu/nettle/nettle-3.5.1.tar.gz https://www.lysator.liu.se/~nisse/archive/nettle-3.5.1.tar.gz Regards, /Niels NEWS for the Nettle 3.5.1 release The Nettle-3.5.1 corrects a packaging mistake in Nettle-3.5. The new directory x86_64/sha_ni were missing in the tar file, breaking x86_64 builds with --enable-fat, and producing worse performance than promised for builds with --enable-x86-sha-ni. Also a few unused in-progress assembly files were accidentally included in the tar file. These problems are corrected in Nettle-3.5.1. There are no other changes, and also the library version numbers are unchanged. NEWS for the Nettle 3.5 release This release adds a couple of new features and optimizations, and deletes or deprecates a few obsolete features. It is *not* binary (ABI) compatible with earlier versions. Except for deprecations listed below, it is intended to be fully source-level (API) compatible with Nettle-3.4.1. The shared library names are libnettle.so.7.0 and libhogweed.so.5.0, with sonames libnettle.so.7 and libhogweed.so.5. Changes in behavior: * Nettle's gcm_crypt will now call the underlying block cipher to process more than one block at a time. This is not a change to the documented behavior, but unfortunately breaks assumptions accidentally made in GnuTLS, up to and including version 3.6.1. New features: * Support for CFB8 (Cipher Feedback Mode, processing a single octet per block cipher operation), contributed by Dmitry Eremin-Solenikov. * Support for CMAC (RFC 4493), contributed by Nikos Mavrogiannopoulos. * Support for XTS mode, contributed by Simo Sorce. Optimizations: * Improved performance of the x86_64 AES implementation using the aesni instructions. Gives a large speedup for operations processing multiple blocks at a time (including CTR mode, GCM mode, and CBC decrypt, but *not* CBC encrypt). * Improved performance for CTR mode, for the common case of 16-byte block size. Pass more data at a time to underlying block cipher, and fill the counter blocks more efficiently. Extension to also handle GCM mode efficiently contributed by Nikos Mavrogiannopoulos. * New x86_64 implementation of sha1 and sha256, for processors supporting the sha_ni instructions. Speedup of 3-5 times on affected processors. * Improved parameters for the precomputation of tables used for ecc signatures. Roughly 10%-15% speedup of the ecdsa sign operation using the secp_256r1, secp_384r1 and secp_521r1 curves, and 25% speedup of ed25519 sign operation, benchmarked on x86_64. Table sizes unchanged, around 16 KB per curve. * In ARM fat builds, automatically select Neon implementation of Chacha, where possible. Contributed by Yuriy M. Kaminskiy. Deleted features: * The header file des-compat.h and everything declared therein has been deleted, as announced earlier. This file provided a subset of the old libdes/ssleay/openssl interface for DES and triple-DES. DES is still supported, via the functions declared in des.h. * Functions using the old struct aes_ctx have been marked as deprecated. Use the fixed key size interface instead, e.g., struct aes256_ctx, introduced in Nettle-3.0. * The header file nettle-stdint.h, and corresponding autoconf tests, have been deleted. Nettle now requires that the compiler/libc provides <stdint.h>. Miscellaneous: * Support for big-endian ARM systems, contributed by Michael Weiser. * The programs aesdata, desdata, twofishdata, shadata and gcmdata are no longer built by default. Makefile improvements contributed by Jay Foad. * The "example" program examples/eratosthenes.c has been deleted. * The contents of hash context structs, and the deprecated aes_ctx struct, have been reorganized, to enable later optimizations. -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

1 0

[PATCH 1/3] build: allow overriding the debug flags
by Alon Bar-Lev 26 Jun '19

26 Jun '19

In Gentoo and probably other downstream distributions we let package management to manage the flags Signed-off-by: Alon Bar-Lev <alon.barlev(a)gmail.com> --- configure.ac | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 00d2bf5d..379c021c 100644 --- a/configure.ac +++ b/configure.ac @@ -949,13 +949,16 @@ LIBS="$old_LIBS" AC_SUBST(BENCH_LIBS) +AC_ARG_VAR([GCC_DEBUG_FLAGS], [GCC debug flags]) +test -z "${GCC_DEBUG_FLAGS}" && GCC_DEBUG_FLAGS="-ggdb3" + # Set these flags *last*, or else the test programs won't compile if test x$GCC = xyes ; then # Using -ggdb3 makes (some versions of) Redhat's gcc-2.96 dump core if $CC --version | grep '^2\.96$' 1>/dev/null 2>&1; then true else - CFLAGS="$CFLAGS -ggdb3" + CFLAGS="$CFLAGS ${GCC_DEBUG_FLAGS}" fi # FIXME: It would be better to actually test if this option works and/or is needed. # Or perhaps use -funsigned-char. -- 2.21.0

4 20

nettle-3.5rc1
by nisse＠lysator.liu.se 15 Jun '19

15 Jun '19

Hi, I've been talking about release for quite some time, without getting to it. I think the current state is pretty good, and I'd like to get the release out before summer vacations. I know there are several very desirable features being worked on, and I'm very happy about that, but release line has to be drawn somewhere. So I've prepared a nettle-3.5rc1 tarball, https://www.lysator.liu.se/~nisse/archive/nettle-3.5rc1.tar.gz, and there's a corresponding "nettle_3.5rc1" tag in the repository. I'll run tests on some of the gmp and gcc test machines. I think I'll get coverage for x86_64, mips, arm, power, maybe sparc. These machines mainly free operating systems, gnu/linux or freebsd. Help with testing on additional systems is highly appreciated, in particular testingon android and on any proprietary OS:es of interest. Please also review the NEWS file, if there's anything NEWS-worthy that I have missed, speak up. Or if there are some additional improvements that really ought to get into the 3.5 release. I aim to have the release happen in a week or two. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

1 0

[PATCH] Fix some typos in the documentation
by Wim Lewis 15 Jun '19

15 Jun '19

--- nettle.texinfo | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/nettle.texinfo b/nettle.texinfo index 2a934f6b..52adaa94 100644 --- a/nettle.texinfo +++ b/nettle.texinfo @@ -396,7 +396,7 @@ the later version may define a new library symbol, and let header files redefine an old API name as an alias for the new symbol. If the later version ensures that the old symbol is still defined in the library, this change is backwards compatible: A program compiled using headers -from the older version can be successfulyl linked with either version of +from the older version can be successfully linked with either version of the library. But if you compile the same program using headers from the later version of the library, and attempt to link with the older version, you'll get an undefined reference to the new symbol. @@ -2320,7 +2320,7 @@ Expands to @end example @end deffn -@deffn Macro CFB8_SET_IV(@var{ctx}, @var{iv}) +@deffn Macro CFB8_SET_IV (@var{ctx}, @var{iv}) First argument is a pointer to a context struct as defined by @code{CFB8_CTX}, and the second is a pointer to an initialization vector that is copied into that context. @@ -2468,7 +2468,7 @@ Holds state corresponding to the AES-256 block cipher. @deftypefunx void xts_aes128_set_decrypt_key (struct xts_aes128_key *@var{ctx}, const uint8_t *@var{key}) @deftypefunx void xts_aes256_set_decrypt_key (struct xts_aes256_key *@var{ctx}, const uint8_t *@var{key}) Initializes the encryption or decryption key for the AES block cipher. The -lenght of the key must be double the size of the key for the corresponding +length of the key must be double the size of the key for the corresponding cipher (256 bits for AES-128 and 512 bits for AES-256). One of these functions must be called before any of the other functions. @end deftypefun @@ -2572,7 +2572,7 @@ more adventurous alternative, in particular if performance is important. @comment node-name, next, previous, up @subsection EAX -The @acronym{EAX} mode is an @acronym{AEAD} mode whichcombines +The @acronym{EAX} mode is an @acronym{AEAD} mode which combines @acronym{CTR} mode encryption, @xref{CTR}, with a message authentication based on @acronym{CBC}, @xref{CBC}. The implementation in Nettle is restricted to ciphers with a block size of 128 bits (16 octets). @@ -2682,7 +2682,7 @@ Process message data for encryption or decryption. @end deffn @deffn Macro EAX_DIGEST (@var{ctx}, @var{encrypt}, @var{length}, @var{digest}) -Extract te authentication tag for the message. +Extract the authentication tag for the message. @end deffn @@ -2882,7 +2882,7 @@ Context structs, defined using @code{GCM_CTX}. @end deftp @deftp {Context struct} {struct gcm_aes_ctx} -Alternative context struct, usign the old @acronym{AES} interface. +Alternative context struct, using the old @acronym{AES} interface. @end deftp @deftypefun void gcm_aes128_set_key (struct gcm_aes128_ctx *@var{ctx}, const uint8_t *@var{key}) @@ -3038,8 +3038,8 @@ initial counter of @code{IC+1}. @acronym{CCM} mode decryption operates similarly, except that the ciphertext and @acronym{MAC} are first decrypted using CTR mode to -retreive the plaintext and authentication tag. The authentication tag -can then be recalucated from the authenticated data and plantext, and +retrieve the plaintext and authentication tag. The authentication tag +can then be recalculated from the authenticated data and plaintext, and compared to the value in the message to check for authenticity. @subsubsection General @acronym{CCM} interface @@ -4531,7 +4531,7 @@ Calls @code{mpz_clear} on all numbers in the struct. @end deftypefun @deftypefun int dsa_generate_params (struct dsa_params *@var{params}, void *@var{random_ctx}, nettle_random_func *@var{random}, void *@var{progress_ctx}, nettle_progress_func *@var{progress}, unsigned @var{p_bits}, unsigned @var{q_bits}) -Generates paramaters of a new group. The @var{params} struct should be +Generates parameters of a new group. The @var{params} struct should be initialized before you call this function. @var{random_ctx} and @var{random} is a randomness generator. @@ -4574,8 +4574,8 @@ signature, and call @code{dsa_signature_clear} when you are finished with it. @end deftypefun -Keys are represented as bignums, of type @code{mpz_t}. A public keys -represent a group element, and is of the same size as @code{p}, while a +Keys are represented as bignums, of type @code{mpz_t}. A public key +represents a group element, and is of the same size as @code{p}, while a private key is an exponent, of the same size as @code{q}. @deftypefun int dsa_sign (const struct dsa_params *@var{params}, const mpz_t @var{x}, void *@var{random_ctx}, nettle_random_func *@var{random}, size_t @var{digest_size}, const uint8_t *@var{digest}, struct dsa_signature *@var{signature}) -- 2.19.1

2 1

[PATCH 0/3] Add support for deterministic DSA/ECDSA (RFC 6979)
by Daiki Ueno 13 Jun '19

13 Jun '19

From: Daiki Ueno <dueno(a)redhat.com> This series adds a variant of DSA/ECDSA signing functions that doesn't require random source to generate signature. The construction of the random parameter k is implemented according to RFC 6979, which will be part of FIPS 186-5: https://csrc.nist.gov/CSRC/media/Presentations/NIST-Status-Update-on-Ellipt… The motivation behind this is to make it easier to check the DSA/ECDSA functionality in the circumstances where no proper random sources are available, e.g., in the libary self-tests at early boot stage. Daiki Ueno (3): dsa: Add a function to find k deterministically ecdsa: Add support for deterministic signature generation dsa: Add support for deterministic signature generation Makefile.in | 6 +- dsa-compute-k.c | 169 ++++++++++++++++++++++ dsa-compute-k.h | 63 ++++++++ dsa-sign-deterministic.c | 107 ++++++++++++++ dsa.h | 12 ++ ecdsa-sign-deterministic.c | 78 ++++++++++ ecdsa.h | 11 ++ testsuite/.gitignore | 2 + testsuite/.test-rules.make | 6 + testsuite/Makefile.in | 4 +- testsuite/dsa-compute-k-test.c | 85 +++++++++++ testsuite/dsa-test.c | 148 ++++++++++++++++++- testsuite/ecdsa-sign-deterministic-test.c | 164 +++++++++++++++++++++ 13 files changed, 851 insertions(+), 4 deletions(-) create mode 100644 dsa-compute-k.c create mode 100644 dsa-compute-k.h create mode 100644 dsa-sign-deterministic.c create mode 100644 ecdsa-sign-deterministic.c create mode 100644 testsuite/dsa-compute-k-test.c create mode 100644 testsuite/ecdsa-sign-deterministic-test.c -- 2.20.1

1 3

[PATCH 0/3] Add support for deterministic DSA/ECDSA (RFC 6979)
by Daiki Ueno 13 Jun '19

13 Jun '19

1 0

curve448 branch
by Dmitry Eremin-Solenikov 09 Jun '19

09 Jun '19

Hello, Niels, Daiki, do you have plans to update/merge curve448 branch? I'd benefit from generalized Edwards curves support, which is part of that branch. -- With best wishes Dmitry

3 10

[PATCH v2 0/4] CMAC-64 and 3DES-CMAC support
by Dmitry Eremin-Solenikov 07 Jun '19

07 Jun '19

Add support for CMAC-64 and (in particular) for 3DES-CMAC. CMAC-64 is used for GOST ciphersuites in TLS and 3DES-CMAC is an easy reference to test generic CMAC-64 code. Changes since previous version: - adapt to follow changed CMAC-128 interface - expand documentation to cover CMAC-64

1 4

Does SHA-1 switch to accelerated automatically?
by Jeffrey Walton 03 Jun '19

03 Jun '19

Hi Everyone, Re: https://www.lysator.liu.se/~nisse/nettle/nettle.html#SHA1 Does SHA-1 switch to hardware acceleration for x86 and ARMv8 automatically? Or is a different call required? Jeff

2 4

Re: ecc_modulo.reduce (was Re: Curve point decompression)
by Wim Lewis 26 May '19

26 May '19

(Background: I'd been confused by not getting the results I expected from ecc_mod_sqr(), etc., and wrote to Niels Möller to ask about it) On Saturday, May 25, 2019 1:15:27 AM PDT, Niels Möller wrote: > The thing is, ->reduce will be either a mod operation or a montgomery > redc operation, depending on what seemed most efficient for the > particular curve. So here you get a result equal to c^2 2^{-256} (mod > p). Ahh! That makes more sense. (I had glossed over the references to Montgomery multiplication, probably because I had it confused with Karatsuba multiplication.) Now that I look for it, I see the conditional conversion to Montgomery representation in routines like ecc_a_to_j() and ecc_j_to_a(). Thanks, Wim.

1 0

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