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
Eli Zaretskii | 12 Dec 17:02 2014

Potential bug in nettle-benchmark.c

This was flagged by GCC:

  nettle-benchmark.c: In function 'time_cipher':
  nettle-benchmark.c:504:29: warning: argument to 'sizeof' in 'memset' call is the same expression as the
destination; did you mean to provide an explicit length? [-Wsizeof-pointer-memaccess]
	   memset(iv, 0, sizeof(iv));
  nettle-benchmark.c:520:29: warning: argument to 'sizeof' in 'memset' call is the same expression as the
destination; did you mean to provide an explicit length? [-Wsizeof-pointer-memaccess]
	   memset(iv, 0, sizeof(iv));
  nettle-benchmark.c:537:29: warning: argument to 'sizeof' in 'memset' call is the same expression as the
destination; did you mean to provide an explicit length? [-Wsizeof-pointer-memaccess]
	   memset(iv, 0, sizeof(iv));

Here's a suggested patch:

--- examples/nettle-benchmark.c~0	2013-05-28 17:21:54.000000000 +0300
+++ examples/nettle-benchmark.c	2014-12-12 17:58:10.670625000 +0200
 <at>  <at>  -501,7 +501,7  <at>  <at>  time_cipher(const struct nettle_cipher *
 	info.block_size = cipher->block_size;
 	info.iv = iv;

-        memset(iv, 0, sizeof(iv));
+        memset(iv, 0, sizeof(*iv));

         cipher->set_encrypt_key(ctx, cipher->key_size, key);

 <at>  <at>  -517,7 +517,7  <at>  <at>  time_cipher(const struct nettle_cipher *
(Continue reading)

Amos Jeffries | 11 Dec 11:53 2014

Please add base-64 URL-safe alphabet

RFC 4648 ( standardizes two
Base-64 alphabets. Nettle currently only supports the traditional
base-64 alphabet from section 4.

There is growing use amongst new protocol definitions and extensions,
particularly in the HTTP area for the URL-safe extension alphabet
instead of the classical Base-64 alphabet.

The attached patch implements a proposed API/ABI extension adding
support for RFC 4648 section 5 "Base 64 Encoding with URL and Filename
Safe Alphabet"

External code simply calls the init() function relevant to the
alphabet it is needing to encode/decode with. The library internally
uses the context to select which lookup table to use for later base64
function calls.

The base64_encode_raw() and base64_encode_group() functions which do
not use contexts are left untouched for now.

Amos Jeffries
Treehouse Networks Ltd.
diff --git a/base64-decode.c b/base64-decode.c
index f622baa..fbaf54f 100644
--- a/base64-decode.c
+++ b/base64-decode.c
 <at>  <at>  -43,7 +43,7  <at>  <at> 
(Continue reading)

Nikos Mavrogiannopoulos | 6 Dec 09:30 2014

function casts

It seems that in the GCM macros nettle uses casts to functions. That is
pretty dangerous with the changes of parameters in functions in nettle
3. The issue is the compiler will not warn for serious errors such as
different function type. An example macro is GCM_ENCRYPT.

#define GCM_ENCRYPT(ctx, encrypt, length, dst, src)                   \
  (0 ? (encrypt)(&(ctx)->cipher, 0, (void *)0, (void *)0)             \
     : gcm_encrypt(&(ctx)->gcm, &(ctx)->key, &(ctx)->cipher,          \
                   (nettle_cipher_func *) (encrypt),                  \
                   (length), (dst), (src)))

I don't think that nettle should be casting functions. The issue seems
to be present in ctr, eax and cbc modes as well.

Nikos Mavrogiannopoulos | 5 Dec 23:57 2014

patch: define API version number

 This patch adds a definition in nettle-meta.h with nettle's version
number. That way applications can be easily modified to support both the
2.7 and the 3.x API. I didn't add for hogweed because it didn't seem to
make sense, the API version is fully determined by nettle only.


nettle-bugs mailing list
Nikos Mavrogiannopoulos | 24 Nov 15:14 2014

gcm + encrypt_message

I am trying to figure out how to wrap around CCM and GCM, and it seems
like a hard task. They are totally incompatible. Would it make sense
instead of have an equivalent of ccm_decrypt_message() in gcm as well,
and make that the AEAD API?