nettle-bugs

nettle-bugs@lists.lysator.liu.se

2196 discussions

[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

[PATCH 0/3] add support for GOST R 34.10 curves
by Dmitry Eremin-Solenikov 12 May '19

12 May '19

Add support for several GOST curves as defined by RFC 4357 and RFC 7836. Names for these curves are taken from TLS Supported Groups registry. -- With best wishes Dmitry

2 11

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