Florian Weimer | 2 Sep 16:05 2015

RSA-CRT hardening

I strongly suggest to implement RSA-CRT hardening, by checking that RSA
signature have not been miscomputed accidentally:


We did not see any key leaks which could be attributed to Nettle, but I
think the added verification is still a reasonable precaution.


Florian Weimer / Red Hat Product Security
nettle-bugs mailing list
nettle-bugs <at> lists.lysator.liu.se
Nikos Mavrogiannopoulos | 12 Aug 16:18 2015

[PATCH] sha3 update

The attached two patches update SHA3 to the final published version.
nettle-bugs mailing list
Nikos Mavrogiannopoulos | 7 Aug 10:49 2015


It seems that as of today SHA-3 is finalized as a standard algorithm.

andy lawrence | 29 Jul 09:41 2015

Helping out


I am interested in helping out with the development of Nettle. Are there
any small projects I could undertake to get started?

Best wishes,

Andrew Lawrence
Simon Josefsson | 1 Jul 22:46 2015


Can Nettle compute the SHAKE128/SHAKE256 variant of SHA-3?  What do you
think about adding APIs for them?

nettle-bugs mailing list
Mark H Weaver | 21 Jun 16:17 2015

dlopen nettle-3.1 built with --enable-fat leads to SIGSEGV

The following test program leads to SIGSEGV in 'get_x86_features' while
loading libnettle.so from nettle-3.1 built with --enable-fat:

--8<---------------cut here---------------start------------->8---
#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>

int main (int argc, char *argv[])
  void *handle;

  handle = dlopen ("libnettle.so", RTLD_NOW);
  if (!handle)
      fprintf (stderr, "%s\n", dlerror ());
      exit (EXIT_FAILURE);
  dlclose (handle);
  exit (EXIT_SUCCESS);
--8<---------------cut here---------------end--------------->8---

Here's the backtrace:

--8<---------------cut here---------------start------------->8---
#0  0x0000000000009006 in ?? ()
#1  0x00007ffff73f6a37 in get_x86_features (features=<synthetic pointer>) at fat-x86_64.c:94
#2  fat_init () at fat-x86_64.c:133
#3  0x00007ffff7412475 in nettle_memxor_resolve () at fat-x86_64.c:185
(Continue reading)

Tomáš Chvátal | 3 Jun 13:33 2015

Two issues found by Address sanitizer

Hello everybody,

we at suse ran address sanitizer against libnettle and found two bugs [1][2].

The first one is easy to fix (simple off by one) and thus we already have the 
patch (see attachment 0001-...).

The second one is about memory leaks, and it would be better if someone more 
aware of the source took a look wether and how to fix it.



[1] https://bugzilla.suse.com/show_bug.cgi?id=928328
[2] https://bugzilla.suse.com/show_bug.cgi?id=929109

PS: I am not subscribed so keep me in CC please.
nettle-bugs mailing list
Niels Möller | 2 May 10:47 2015

nettle-3.1 transition and symbol versions

Now we see some transition problems,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784009, and it's going
to also hit other distributions than debian.

Would it make sense to issue a nettle-2.7.2, which is nettle-2.7.1 +
symbol versions? There's at least one bugfix which could be backported
if we do another 2.7.x:

2014-06-30  Niels Möller  <nisse@...>

	* camellia-absorb.c: Include <limits.h>, needed for correct use of
	HAVE_NATIVE_64_BIT. Reported and debugged by Magnus Holmgren.



Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
Elliot Saba | 1 May 17:09 2015

Version API

Hello there, I saw the recent addition of the version #define's, which are
great, but a runtime function that I can call to find out libnettle's API
is essential for dynamic bindings.

I maintain the Julia language bindings for Nettle
<https://github.com/staticfloat/Nettle.jl> which loads the dynamic library
and generates methods to use Nettle's cryptographic functions on the fly.
This process does not use header files, it's similar to Python's ctypes
functionality, and thus knowing which API version we're dealing with by
only using the dynamic library itself is necessary.  Most other projects
have some method or other for determining this, as you guys have already
discussed, but simply placing the information into a header file is not
sufficient for this use case.

Is this something it would be possible to support?

Niels Möller | 24 Apr 22:21 2015

ANNOUNCE: Nettle-3.1.1

I've made another release of GNU Nettle, a low-level
cryptographics library, to fix bugs reported for Nettle 3.1.

The Nettle home page can be found at
http://www.lysator.liu.se/~nisse/nettle/, and the manual at

NEWS for the Nettle 3.1.1 release

	This release fixes a couple of non-critical bugs.

	Bug fixes:

	* By accident, nettle-3.1 disabled the assembly code for the
	  secp_224r1 and secp_521r1 elliptic curves on all x86_64
	  configurations, making signature operations on those curves
	  10%-30% slower. This code is now re-enabled.

	* The x86_64 assembly implementation of gcm hashing has been
          fixed to work with the Sun/Oracle assembler.

	The shared library names are libnettle.so.6.1 and
	libhogweed.so.4.1, with sonames still libnettle.so.6 and
	libhogweed.so.4. It is intended to be fully binary compatible
	with nettle-3.1.

Available at:

(Continue reading)

Niels Möller | 22 Apr 19:00 2015

Re: bug against .short value

dongsheng zhang <dongsheng.zhang@...> writes:

> Solaris doesn't take .short value, but instead only takes .value value.
> We thus cannot compile the following file:
> nettle-3.1/x86_64/gcm-hash8.asm

I've checked in a fix. Can you try to check out


and test if it solves the problem? You need to run the script
./.boostrap before configure and make.



Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.