24 Nov 15:14 2014

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 libnettle.so" regards, Nikos

_______________________________________________ nettle-bugs mailing list nettle-bugs@... http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

23 Nov 22:58 2014

### issues found while converting from 2.7 to 3.0

Hello, * 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 well. #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)

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 "/home/zaamus/Dependencies/nettle-2.7.1" true 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 "/home/zaamus/Dependencies/nettle-2.7.1/tools" true make[1]: uscita dalla directory "/home/zaamus/Dependencies/nettle-2.7.1/tools" Making check in testsuite make[1]: ingresso nella directory "/home/zaamus/Dependencies/nettle-2.7.1/testsuite" LD_LIBRARY_PATH=../.lib PATH="../.lib:$PATH" srcdir="." \(Continue reading)

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 (https://github.com/agl/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). Regards, /Niels -----8<--- /* cipher-sidechannel-test.c(Continue reading)

26 Oct 09:59 2014

### chacha-poly1305

Hello, 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 incorporated). 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? regards, Nikos [0]. https://tools.ietf.org/html/draft-irtf-cfrg-chacha20-poly1305-02

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 updated http://www.lysator.liu.se/~nisse/nettle/plan.html). 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 __(Continue reading)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 reorganization: * 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. Regards, /Niels

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. Regards, /Niels -- -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

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. Regards, /Niels -- -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

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. Regards, /Niels -- -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

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. */ void ecc_mod (mp_limb_t *rp, mp_size_t rn, mp_size_t mn, const mp_limb_t *bp, mp_size_t bn, -- -- 2.0.0