Niels Möller | 26 Mar 22:37 2015


Available now, at

There's also a corresponding tag in the repo (except that the suffix
"rc1" on the package version in is not committed).

All testing and proof-reading highly appreciated.



Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
Niels Möller | 25 Mar 23:44 2015

Getting closer to nettle-3.1

I think the remaining items on aren't very urgent,
and can be postponed.

Discussed recently, but not on that list, is mem_equalp (or whatever it
should be called). That's also not very urgent.

I plan to move NETTLE_USE_MINI_GMP from bignum.h to version.h, and drop It should be enough with one configure-generated header
like that. It also has the advantage that version.h actually gets used
during the build. That change touches a couple of files, so I don't want
to check that in tonight.

Anyway, I think it's time to get into final testing. I've done some
tests on freebsd, revealing one real bug (triggered only when compiled
with the ancient gcc version freebsd keeps in /usr/bin). And I've made
some fixes to what gets included by make dist.

I hope to be able to create a nettle-3.1rc1.tar.gz in a day or two.



Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
Nikos Mavrogiannopoulos | 19 Mar 11:01 2015

patch: added missing dist files

nettle-bugs mailing list
Martin Sebor | 16 Mar 21:33 2015

test failures on powerpc64le-redhat-linux

Running Nettle 3.0 tests on a powerpc64le RHEL 7.1 box shows
the two failures below.  The cause is in the second definition
of the HAVE_NATIVE_64_BIT configuration macro:

   $ grep HAVE_NATIVE_64_BIT config.*
   config.h:# define HAVE_NATIVE_64_BIT 1
   config.h:# define HAVE_NATIVE_64_BIT (SIZEOF_LONG * CHAR_BIT >= 64)

The macro relies on the CHAR_BIT macro being defined at the
point of its expansion. Uses of HAVE_NATIVE_64_BIT of the form

   #if !HAVE_NATIVE_64_BIT

in files that don't include <limits.h> (and thus don't have
the CHAR_BIT macro defined) end up compiling the conditional
blocks that are intended to be included only when the target
has no native support for 64 bit arithmetic.  One such file
that comes into play in the failing tests is camellia-absorb.c.
Since powerpc64le obviously does have such support, the code
is unnecessary and, as it turns out, introduces errors.

Once <limits.h> is included all of Nettle's tests pass even
on powerpc64le-redhat-linux.


Encrypt failed:
(Continue reading)

Niels Möller | 14 Mar 08:20 2015


I think there's only one sensitive use of memcmp within nettle, and
that's the tag comparison in ccm_decrypt_message. I've now written a
private function memeql_sec to do that comparison in a more side-channel
silent fashion.

  static int
  memeql_sec (const void *a, const void *b, size_t n)
    volatile const unsigned char *ap = (const unsigned char *) a;
    volatile const unsigned char *bp = (const unsigned char *) b;
    volatile unsigned char d;
    size_t i;
    for (d = i = 0; i < n; i++)
      d |= (ap[i] ^ bp[i]);
    return d == 0;

The idea is to avoid leaking (via timing or memory access patterns) the
location of the first difference. Information that a guess for a forged
MAC tag matches some characters of the correct MAC can be used to attack
the MAC key, in particular for MAC algorithms with linear structure such
as gcm and poly1305 (which is why chacha-poly1305 uses a new poly1305
key for each message, and why one shouldn't use gcm with short
authentication tags).

memeql_sec is a bit similar to

Now, applications using nettle are likely doing a lot of similar
comparisons on hash and hmac digests. So it would be good to make this
function public. But then I'd need to decide on
(Continue reading)

Niels Möller | 26 Feb 11:03 2015

curve25519 and eddsa

I've just pushed some documentation for the curve25519 and eddsa
functions. This raises a few questions on the current interfaces.

1. Should ecc-curves.h really declare nettle_curve25519? Its' not needed
   for any of the documented functions, except for obscurities like
   doing ecdsa (not eddsa) over the curve. It could be moved to
   ecc-internal, or be marked as internal in some other way. Perhaps
   renaming to _nettle_ed25519 would be appropriate.

2. curve25519_mul should be changed to have a void return type (an
   earlier implementation failed for inputs which didn't correspond to
   points on the curve, but instead were points on its twist). But the
   current implementation, using the Montgomery ladder, doesn't care and
   computes a well defined result for all inputs.

3. struct ed25519_private_key and struct ed25519_public_key include
   compile-time constant limb arrays. At least for the public key, this
   will imply an ABI break if/when we switch to a base 2^51
   representations for GF(2^255 - 19). So maybe switch to dynamic
   allocation for struct ed25519_public_key, or both structs?

4. There's no function to generate eddsa key pairs. To generate a
   private key, use a random 32-octet string. To get the corresponding
   public key, one can call ed25519_set_private_key, and copy the pub
   element of the struct. This needs some additional documentation or
   maybe some additional function.


(Continue reading)

Niels Möller | 28 Jan 21:35 2015

nettle-3.1 loose ends

Looking at, the most
important things are done. I think documentation is the only item left
which is both important and requires several hours of work.

* Versioned symbols. I think this is complete, I just have forgotten to
  merge that branch.

* Base64 with other alphabets. A patch was posted to the list some month
  ago, I had some comments, and then it seems to have stalled. If it's
  desirable to break the ABI to implement it, 3.1 may be the last chance
  for some years time.

* OCB mode. Is it a good idea to try to get this into the release? I
  don't think patents are a problem, but I've mailed sflc, and it would
  be nice to get their opinion too. Needs not just the code, but also
  test cases and documentation.

* Also OFB mode has been requested, used by openpgp, iirc.

Anything else I've missed? And which of the above items are important?

There are a lot of things that could be better optimized, including the
curve25519 code and the aesni code, but I don't think the release should
be delayed for that.



Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
(Continue reading)

Niels Möller | 26 Jan 09:35 2015

ecc.h vs ecc-internal.h

I'm about to remove a lot of the internal declarations from ecc.h, and
move the ones which still are needed to ecc-internal.h. Problem is that
most of these functions work only with particular curve types, and are
typically installed in function pointers in struct ecc_curve. If they
really are needed as public functions, they must be reimplemented to
jump via the appropriate function pointer.

And some, like most or all of the corresponding itch functions, are not
even defined anywhere anymore (replaced by macros in ecc-internal.h, and
fields in struct ecc_curve).

ecc_size_j is a borderline case, not sure if it should be public (if so,
it should probably be renamed, and not mean "convert to jacobian
coordinates", but "convert to whatever internal representation is
appropriate for the curve".

And everything below ecc_size_j in ecc.h should be removed.

Any objections? Any function applications are relying on?



Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
Martin Storsjö | 24 Jan 13:22 2015

[PATCH 1/2] arm: Add .arch directives for armv6

This allows building these files as part of a fat build, even if
the assembler by default targets a lower architecture version.
 arm/v6/aes-decrypt-internal.asm | 2 ++
 arm/v6/aes-encrypt-internal.asm | 2 ++
 arm/v6/sha1-compress.asm        | 1 +
 arm/v6/sha256-compress.asm      | 1 +
 4 files changed, 6 insertions(+)

diff --git a/arm/v6/aes-decrypt-internal.asm b/arm/v6/aes-decrypt-internal.asm
index 28d8f6f..3eab3eb 100644
--- a/arm/v6/aes-decrypt-internal.asm
+++ b/arm/v6/aes-decrypt-internal.asm
 <at>  <at>  -30,6 +30,8  <at>  <at>  ifelse(<
    not, see

+	.arch armv6

 define(<PARAM_ROUNDS>, <r0>)
diff --git a/arm/v6/aes-encrypt-internal.asm b/arm/v6/aes-encrypt-internal.asm
index f7f4769..e4fa25d 100644
--- a/arm/v6/aes-encrypt-internal.asm
+++ b/arm/v6/aes-encrypt-internal.asm
 <at>  <at>  -30,6 +30,8  <at>  <at>  ifelse(<
    not, see

(Continue reading)

Niels Möller | 11 Jan 15:27 2015

Intel aes instructions

I've just pushed new aes code using intel's aesni instructions.

It gave a speedup of almost 10 times on the haswell machine where I
tested it (and in addition, it should avoid sidechannel leaks in those
functions). Clearly, this will be more useful after adding support for
fat binaries, detecting presence of these instructions at runtime. For
now, it has to be enabled explicitly with the configure argument

I have one question, on how to enable support for these instructions in
the assembler. For now I added a pseudo-op

	.arch bdver2

and that seems to work, but it's a bit too specific for my taste. I
would have preferred something like .arch generic64,aes, but I couldn't
get that to work. So what's the right way to do this?

I haven't played with the corresponding arch flags to gcc, but I'd
prefer do declare within the .asm file itself which instruction set it
is intended for.

Feedback on the actual assembler code is also appreciated, of course.
It's pretty basic, a dozen lines, no unrolling or other cleverness.

(Continue reading)

Nikos Mavrogiannopoulos | 16 Dec 13:02 2014

[Fwd: [gnutls-help] Generating DH Parameters larger than 3072 bits]

 It seems that by switching gnutls to nettle 2.7.x for DSA (and DH) key
generation the forwarded issues occur. Would it be possible to have a
2.7.x release with the attached patch? That would allow gnutls 3.3.x
generate arbitrary DH parameters.


nettle-bugs mailing list