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?

Nikos Mavrogiannopoulos | 24 Nov 14:06 2014

symbol versioning

The attached patch will add symbol versioning in nettle. That would
mean that software linked against nettle 3.x will be able to
interoperate with libraries that are linked on a previous version of
nettle (and vice versa).

You could check the new symbol names with "readelf -Ws"

nettle-bugs mailing list
Nikos Mavrogiannopoulos | 23 Nov 22:58 2014

issues found while converting from 2.7 to 3.0


* gcm.h:

The GCM_SET_KEY macro uses key both as input and to access a ctx
element, and thus requires the last parameter to be called "key" as

#define GCM_SET_KEY(ctx, set_key, encrypt, key)                 \
  do {                                                          \
    (set_key)(&(ctx)->cipher, (key));                           \
    if (0) (encrypt)(&(ctx)->cipher, 0, (void *)0, (void *)0);  \
    gcm_set_key(&(ctx)->key, &(ctx)->cipher,                    \
                (nettle_cipher_func *) (encrypt));              \
  } while (0)

* cbc.h:
cbc_encrypt and decrypt use const void* as first parameter. That is, it
cannot be wrapped over a function that works for cbc_encrypt as well as
gcm_aes_encrypt (the latter doesn't use const). Without casts that is.

Overall, what I didn't like it that the new cipher API required more
code to wrap around it.

* macros.h:
The MD_INCR(ctx) macro is now only applicable for sha512.

* nettle-types.h:
There is still nettle_crypt_func which is identical to
nettle_cipher_func. Is that intentional? I was wondering what was its
(Continue reading)

braga | 9 Nov 09:46 2014

FAILs in make check

Dear nettle community

I am triyng to install nettle2.7.1 (because I want to install gnutls-cli 
but it doesn't support nettle3.0) on my

Ubuntu 12.04
i686 architecture

but I always get this result on

make check

zaamus <at> zaamuspc:~/Dependencies/nettle-2.7.1$ make check
make check-here
make[1]: ingresso nella directory 
make[1]: uscita dalla directory "/home/zaamus/Dependencies/nettle-2.7.1"
set -e; for d in tools testsuite examples; do \
	  echo "Making check in $d" ; (cd $d && make check); done
Making check in tools
make[1]: ingresso nella directory 
make[1]: uscita dalla directory 
Making check in testsuite
make[1]: ingresso nella directory 
LD_LIBRARY_PATH=../.lib PATH="../.lib:$PATH" srcdir="." \
(Continue reading)

Niels Möller | 29 Oct 14:17 2014

Side-channel silence

I've written a simple program to setup valgrind to check for bad uses of
secret data. Maybe you have heard of Adam Langley's ctgrind
(, but it seems to work fine to use plain
valgrind and mark the secret data with VALGRIND_MAKE_MEM_UNDEFINED.

Non-silent algorithms include aes, camellia, cast128, twofish, arctwo, des,
blowfish, gcm (the hashing), arcfour. Almost anything using sboxes.

Silent algorithms include serpent (sboxes, but with nice bit-slicing
instead of tables), salsa20, chacha, poly1305.

Not sure if and how this testing could be added to a plain

  make check EMULATOR='$(VALGRIND)'

As for AES, an implementations using the aesni instructions ought to be
side-channel silent. And if one is concerned about side channel attacks
on AES, but too conservative to jump to salsa20 or chacha, serpent might
be a good alternative.

(I'll be doing a short talk on side-channel attacks on Southpole's 15
year anniversary party on November 7, so that's why I'm looking into
this now).


/* cipher-sidechannel-test.c

(Continue reading)

Nikos Mavrogiannopoulos | 26 Oct 09:59 2014


 I was checking what is required for the chacha-poly1305 implementation
to be kept up to date with the current draft [0], on Last-Call. My
understanding is that the current implementation:
1. Is missing support for 96-bit nonce Chacha (could be solved by adding
a chacha_set_nonce96 function)
2. Misses the optimization which you proposed to CFRG (and was

It seems however, that if nettle is changed for the latter (i.e., to pad
AAD), then using chacha_poly1305_update() becomes tricky. It could only
be called once. Would in that case make sense to rename it to
chacha_poly1305_set_aad() rather than update?