nettle-bugs

nettle-bugs@lists.lysator.liu.se

2191 discussions

Add check for ECC at point 0
by Simo Sorce 02 Jul '19

02 Jul '19

While reviewing FIPS requirements for public key checks in Ephemeral Diffie-Hellman key exchanges it came out that FIPS requires checks that the public key point is not the (0, 0) coordinate and nettle is not doing it (only checks that neither point is negative. Add this check as we never want to allow this point in any case. Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc

4 11

siv and cmac
by nisse＠lysator.liu.se 02 Jul '19

02 Jul '19

I think the siv code could benefit from a funtion to create a cmac digest in one step, without the update/digest split and the intermediate buffer. That would be something like cmac128_message(const struct cmac128_key *key, const void *cipher, nettle_crypt_func *encrypt, size_t digest_length, uint8_t *digest, size_t message_length, const uint8_t *message); Then the key need to be taken out from the cmac128_ctx. I'm trying that out, on the branch cmac-layout. Patch below. What do you think? Regards, /Niels commit 9b41e3b82b567abb68c1b7fc3b1e6b1a4ed87b26 Author: Niels Möller <nisse(a)lysator.liu.se> Date: 2019-06-01 10:30:29 +0200 New struct cmac128_key. diff --git a/ChangeLog b/ChangeLog index 53cdc41d..a7a4355f 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2019-06-01 Niels Möller <nisse(a)lysator.liu.se> + + * cmac.h (struct cmac128_key): New struct. + * cmac.h (struct cmac128_ctx): Use struct cmac128_key. + * cmac.c (cmac128_set_key, cmac128_digest): Update accordingly. + 2019-05-12 Niels Möller <nisse(a)lysator.liu.se> Delete old libdes/openssl compatibility interface. diff --git a/cmac.c b/cmac.c index ed3b5eb8..07d805f3 100644 --- a/cmac.c +++ b/cmac.c @@ -83,8 +83,8 @@ cmac128_set_key(struct cmac128_ctx *ctx, const void *cipher, /* step 1 - generate subkeys k1 and k2 */ encrypt(cipher, 16, L->b, const_zero); - block_mulx(&ctx->K1, L); - block_mulx(&ctx->K2, &ctx->K1); + block_mulx(&ctx->key.K1, L); + block_mulx(&ctx->key.K2, &ctx->key.K1); } #define MIN(x,y) ((x)<(y)?(x):(y)) @@ -148,11 +148,11 @@ cmac128_digest(struct cmac128_ctx *ctx, const void *cipher, if (ctx->index < 16) { ctx->block.b[ctx->index] = 0x80; - memxor(ctx->block.b, ctx->K2.b, 16); + memxor(ctx->block.b, ctx->key.K2.b, 16); } else { - memxor(ctx->block.b, ctx->K1.b, 16); + memxor(ctx->block.b, ctx->key.K1.b, 16); } memxor3(Y.b, ctx->block.b, ctx->X.b, 16); diff --git a/cmac.h b/cmac.h index 6d107982..9d972ea5 100644 --- a/cmac.h +++ b/cmac.h @@ -55,18 +55,22 @@ extern "C" { #define cmac_aes256_update nettle_cmac_aes256_update #define cmac_aes256_digest nettle_cmac_aes256_digest -struct cmac128_ctx +struct cmac128_key { - /* Key */ union nettle_block16 K1; union nettle_block16 K2; +}; + +struct cmac128_ctx +{ + struct cmac128_key key; /* MAC state */ union nettle_block16 X; /* Block buffer */ - union nettle_block16 block; size_t index; + union nettle_block16 block; }; void -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

3 4

[PATCH 00/14] HMAC implementation rework
by Dmitry Eremin-Solenikov 02 Jul '19

02 Jul '19

This is my current attempt to rework hash/HMAC internal API to use separate block buffer from main hash state and thus decrease HMAC context data size by removing byte buffer duplication. Unfortunately this breaks GnuTLS accelerated implementations. Patch for GnuTLS will be provided, if this approach is going to be accepted to Nettle. The following changes since commit ee5d62898cf070f08beedc410a8d7c418588bd95: Fixes for Nettle 3.5.1 (2019-06-26 21:51:36 +0200) are available in the Git repository at: https://gitlab.com/GostCrypt/nettle.git gitlab/hmac-3 for you to fetch changes up to dda00a07d26dbdb6647186c778febe870c30cafc: hmac-sha512/hmac-sha384: use new hmac and hash split state/buffer interface (2019-07-02 16:21:48 +0300) ---------------------------------------------------------------- Dmitry Eremin-Solenikov (14): sha512-224,-256: use _NETTLE_HASH_US instead of hand-coding structure definitions hash: start separating state and block contexts macros: add interface for working with separate hash state and buffer md5: split context into hash state and byte buffer hmac: add interface for working with separate hash state and buffer hmac-md5: use new hmac and hash split state/buffer interface ripemd160: split context into hash state and byte buffer hmac-ripemd160: use new hmac and hash split state/buffer interface sha1: split context into hash state and byte buffer hmac-sha1: use new hmac and hash split state/buffer interface sha256/sha224: split context into hash state and byte buffer hmac-sha256/hmac-sha224: use new hmac and hash split state/buffer interface sha512/sha384: split context into hash state and byte buffer hmac-sha512/hmac-sha384: use new hmac and hash split state/buffer interface hmac-md5.c | 6 +-- hmac-ripemd160.c | 6 +-- hmac-sha1.c | 6 +-- hmac-sha224.c | 4 +- hmac-sha256.c | 6 +-- hmac-sha384.c | 4 +- hmac-sha512.c | 6 +-- hmac.c | 62 ++++++++++++++++++++++++++ hmac.h | 37 +++++++++++++--- macros.h | 66 ++++++++++++++++++++++++++++ md5-meta.c | 3 ++ md5.c | 52 ++++++++++++++++------ md5.h | 29 ++++++++++-- nettle-meta.h | 56 ++++++++++++++++++++++++ nettle-types.h | 15 +++++++ ripemd160-meta.c | 3 ++ ripemd160.c | 50 ++++++++++++++++----- ripemd160.h | 29 ++++++++++-- sha1-meta.c | 3 ++ sha1.c | 56 +++++++++++++++++------- sha1.h | 29 ++++++++++-- sha2.h | 87 +++++++++++++++++++++++++++++++++--- sha224-meta.c | 3 ++ sha256-meta.c | 3 ++ sha256.c | 76 +++++++++++++++++++++++++------- sha384-meta.c | 3 ++ sha512-224-meta.c | 12 +---- sha512-256-meta.c | 12 +---- sha512-meta.c | 3 ++ sha512.c | 129 +++++++++++++++++++++++++++++++++++++++--------------- 30 files changed, 701 insertions(+), 155 deletions(-)

1 14

Changes after 3.5.1
by Dmitry Eremin-Solenikov 02 Jul '19

02 Jul '19

Hello, I have several patch series that were sitting in my local gost tree. Most of them were posted to this mailing list for review with little to no feedback. For now they are incorporated into GnuTLS for testing and maturing. I'd like to understand, how should I proceed if I'd like to get them included into nettle to spare GnuTLS from having more and more crypto code. - CMAC-64 support (together with CMAC-TDES for testing). - Changes to GOST R 34.11-94 (gosthash94) code - GOST 28147-89/Magma 64-bit cipher (depend on gosthash94 changes) - Additional cipher modes required for full GOST 28147-89 support - Streebog hash algorithm (GOST R 34.11-2012) - Several GOST curves (2 for now, other require changes to ecc backend) - GOST ECC-based digital signature scheme - GOST ECC-based key agreement - small chunks of additional support code -- With best wishes Dmitry

2 2

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

Jump to page:

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