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?


Niels Möller | 22 Oct 10:03 2014

Fat binaries

I think I will leave the curve25519 and eddsa code for now, even though
there are several important optimizations left to do (see the just

I think it's getting time to do fat binaries. To make progress, I think
it's best to start with something simple, relying on
__attribute__((constructor) and/or __attribute__(ifunc ...)).

For the case of memxor (where on x86_64, the fat binary mechanism needs
to select between sse2 and non-sse2 code), I'm also considering some

 * Use smaller assembly routines doing one case each, and let the main
   entry point always be C code which can sort out the different cases
   and handle bytes at the beginning and end of the buffer.

 * Fix the cases where the current current code reads a few bytes
   outside of input buffers (but luckily without crossing word
   boundaries, iirc).

 * Add some internal entry points, for cases where alignment is known by
   the caller.

I think some additional overhead is acceptable for the cases of small
badly aligned buffers, if one can gain cleaner or more efficient
handling of the other cases.


(Continue reading)

Niels Möller | 24 Sep 21:10 2014

ecc_curve and ecc_modulo

I just pushed some reorganization of the ecc code. It introduces an
internal struct ecc_modulo, which keeps the data and function pointers
needed for modulo p (or modulo q) arithmetic.

Immediate benefit was that a couple of wrapper functions could be
deleted. E.g, ecc_generic_modp and ecc_generic_modq both called ecc_mod,
but with different constants taken from different fields of struct
ecc_curve). Now, one can instead call ecc_mod (&ecc->p, ...) and
ecc_mod(&ecc->q, ...), respectively.

I also added an invert function pointer, and wrote a specialized modp
invert function for curve25519, which gives a nice little speedup. The
code can be shared with sqrt, since the main part of the addition chain
is the same for p-2 = 2^{255} - 21 (for invert) and (p-5)/8 = 2^{252} -
3 (for sqrt). Similar functions for the secp curves also make sense, at
least for the mod p inversion; modq is less structured.

The plan is to expand struct ecc_modulo with add, mul and sqr function
pointers, to make it possible to have a different internal
representation. In particular, using radix-51 for curve25519 modp
arithmetic, on 64-bit machines.



Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
Niels Möller | 31 Aug 21:12 2014

Hashing with EdDSA

I'm looking into EdDSA. According to the paper, signing of a message M,
using private key (a, k), corresponding to public key A, is essentially

  r = H(k | M),    with k the second half of the private key
  R = rB,          with B the specified generator of the curve,
  S = ((r + H(R | A | M) a) mod l, l is the curve order

with some rules to encode R, A, S as strings. H is typically sha-512.

If M is the original, arbitrarily long, message to be signed, this
breaks the common structure that you can first compute a message digest,
and then apply the secret key to produce a signature. But this doesn't
work above, because the complete message has to be hashed twice, first
with the secret prefix k, next with the prefix R | A, and any hashing
without the private key available is useless. And even worse, one has to
buffer the complete message because the prefix of the second hash
depends on the output of the first hash.

Or should M itself be a digest of the message to be signed? That will
enable a more main-stream signature interface, where the inputs to the
signature function are the private key and the short message digest.



Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
Niels Möller | 29 Jul 16:51 2014

curve25519 progress

I've now pushed some crude code (on the curve25519 branch) which agrees
with the test vectors in draft-josefsson-tls-curve25519-05.

It uses the equivalent Edwards curve for the internal operations. For
scalar multiplication of the fix generator, it uses Pippenger's
algorithm and tables very similar to the other curves, just with
different point operations and no special caes (since the Edwards
operations are "complete"). At the end, the x-coordinate of the
corresponding point on the Montgomery-form curve25519 is computed.

For scalar multiplication of an arbitrary point (with only x coordinate
provided), I first have to compute the y-coordinate using
Shanks-Tonelli (this could be used to implement "point compression") also
for other curves). Then transform to a point on the Edwards curve, using
homogeneneous/projective coordinates. Then the actual scalar multiply is
currently done with the binary algorithm; I have code for window-based
scalar multiply, but it needs a bit more debugging. All this is very
similar to the other corves, but without special cases.



Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
Daniel Kahn Gillmor | 11 Jul 19:27 2014

[PATCH] fix typo in ecc-mod.c

 ecc-mod.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ecc-mod.c b/ecc-mod.c
index 7876d02..3301506 100644
--- a/ecc-mod.c
+++ b/ecc-mod.c
 <at>  <at>  -40,7 +40,7  <at>  <at> 
 #include "ecc-internal.h"

 /* Computes r mod m, where m is of size mn. bp holds B^mn mod m, as mn
-   limbs, but the upper mn - bn libms are zero. */
+   limbs, but the upper mn - bn limbs are zero. */
 ecc_mod (mp_limb_t *rp, mp_size_t rn, mp_size_t mn,
 	 const mp_limb_t *bp, mp_size_t bn,