nettle-bugs

nettle-bugs@lists.lysator.liu.se

2196 discussions

gcm + encrypt_message
by Nikos Mavrogiannopoulos 25 Nov '14

25 Nov '14

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? regards, Nikos

3 2

symbol versioning
by Nikos Mavrogiannopoulos 24 Nov '14

24 Nov '14

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

2 2

FAILs in make check
by braga 10 Nov '14

10 Nov '14

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@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="." \ EMULATOR="" NM="nm" EXEEXT="" \ ../run-tests aes-test arcfour-test arctwo-test blowfish-test cast128-test base16-test base64-test camellia-test des-test des3-test des-compat-test md2-test md4-test md5-test md5-compat-test memxor-test gosthash94-test ripemd160-test salsa20-test sha1-test sha224-test sha256-test sha384-test sha512-test sha3-permute-test sha3-224-test sha3-256-test sha3-384-test sha3-512-test serpent-test twofish-test knuth-lfib-test cbc-test ctr-test gcm-test hmac-test umac-test meta-hash-test meta-cipher-test meta-armor-test buffer-test yarrow-test pbkdf2-test sexp-test sexp-format-test rsa2sexp-test sexp2rsa-test bignum-test random-prime-test pkcs1-test rsa-test rsa-encrypt-test rsa-keygen-test dsa-test dsa-keygen-test ecc-mod-test ecc-modinv-test ecc-redc-test ecc-mul-g-test ecc-mul-a-test ecdsa-sign-test ecdsa-verify-test ecdsa-keygen-test cxx-test sexp-conv-test pkcs1-conv-test symbols-test PASS: aes PASS: arcfour PASS: arctwo PASS: blowfish PASS: cast128 PASS: base16 PASS: base64 PASS: camellia PASS: des PASS: des3 PASS: des-compat PASS: md2 PASS: md4 PASS: md5 PASS: md5-compat PASS: memxor PASS: gosthash94 PASS: ripemd160 PASS: salsa20 PASS: sha1 PASS: sha224 PASS: sha256 PASS: sha384 PASS: sha512 PASS: sha3-permute PASS: sha3-224 PASS: sha3-256 PASS: sha3-384 PASS: sha3-512 PASS: serpent PASS: twofish PASS: knuth-lfib PASS: cbc PASS: ctr PASS: gcm PASS: hmac PASS: umac PASS: meta-hash PASS: meta-cipher PASS: meta-armor PASS: buffer PASS: yarrow PASS: pbkdf2 PASS: sexp PASS: sexp-format PASS: rsa2sexp PASS: sexp2rsa PASS: bignum PASS: random-prime PASS: pkcs1 PASS: rsa PASS: rsa-encrypt PASS: rsa-keygen PASS: dsa PASS: dsa-keygen ./ecc-mod-test: symbol lookup error: ../.lib/libhogweed.so.2: undefined symbol: __gmpz_limbs_read FAIL: ecc-mod ./ecc-modinv-test: symbol lookup error: ../.lib/libhogweed.so.2: undefined symbol: __gmpz_limbs_read FAIL: ecc-modinv ./ecc-redc-test: symbol lookup error: ../.lib/libhogweed.so.2: undefined symbol: __gmpz_limbs_read FAIL: ecc-redc ./ecc-mul-g-test: symbol lookup error: ../.lib/libhogweed.so.2: undefined symbol: __gmpn_cnd_add_n FAIL: ecc-mul-g ./ecc-mul-a-test: symbol lookup error: ../.lib/libhogweed.so.2: undefined symbol: __gmpn_cnd_add_n FAIL: ecc-mul-a ./ecdsa-sign-test: symbol lookup error: ../.lib/libhogweed.so.2: undefined symbol: __gmpz_limbs_modify FAIL: ecdsa-sign ./ecdsa-verify-test: symbol lookup error: ../.lib/libhogweed.so.2: undefined symbol: __gmpz_limbs_read FAIL: ecdsa-verify ./ecdsa-keygen-test: symbol lookup error: ../.lib/libhogweed.so.2: undefined symbol: __gmpn_cnd_add_n FAIL: ecdsa-keygen PASS: cxx PASS: sexp-conv PASS: pkcs1-conv PASS: symbols ==================== 8 of 67 tests failed ==================== make[1]: *** [check] Errore 1 make[1]: uscita dalla directory "/home/zaamus/Dependencies/nettle-2.7.1/testsuite" make: *** [check] Errore 2 I have libgcrypt1.6.2, libgpg-error1.17, m4 macro processor and gmp6.0.0 installed. Library lgmp is correctly found when I compile some random c source. Can you help me? Do you need other information? Thanks, Vittorio -- Vittorio Francesco Braga PhD student in Tor Vergata University of Rome Mobile: +393203753307, Office (PhD room): +390672594868

2 10

chacha-poly1305
by Nikos Mavrogiannopoulos 31 Oct '14

31 Oct '14

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

3 8

Side-channel silence
by nisse＠lysator.liu.se 29 Oct '14

29 Oct '14

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 Copyright (C) 2014 Niels MÃ¶ller This file is part of GNU Nettle. GNU Nettle is free software: you can redistribute it and/or modify it under the terms of either: * the GNU Lesser General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. or * the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. or both in parallel, as here. GNU Nettle is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received copies of the GNU General Public License and the GNU Lesser General Public License along with this program. If not, see http://www.gnu.org/licenses/. */ #include "testutils.h" #include "nettle-internal.h" #if !HAVE_VALGRIND_MEMCHECK_H void testmain (void) { SKIP (); } #else /* HAVE_VALGRIND_MEMCHECK_H */ #include <valgrind/memcheck.h> static uint8_t * xalloc_secret (size_t size) { uint8_t *p = xalloc (size); memset (p, 0, size); VALGRIND_MAKE_MEM_UNDEFINED (p, size); return p; } static void test_sc_cipher (const struct nettle_cipher *cipher) { void *ctx; uint8_t *key; uint8_t *src; uint8_t *dst; ctx = xalloc (cipher->context_size); key = xalloc_secret (cipher->key_size); src = xalloc_secret (cipher->block_size); dst = xalloc (cipher->block_size); cipher->set_encrypt_key (ctx, key); cipher->encrypt (ctx, cipher->block_size, dst, src); free (ctx); free (key); free (src); free (dst); } #define DATA_SIZE 32 static void test_sc_aead (const struct nettle_aead *aead) { void *ctx; uint8_t *key; uint8_t *nonce; uint8_t *src; uint8_t *data; uint8_t *dst; uint8_t *digest; ctx = xalloc (aead->context_size); key = xalloc_secret (aead->key_size); nonce = xalloc_secret (aead->nonce_size); src = xalloc_secret (aead->block_size); data = xalloc_secret (DATA_SIZE); dst = xalloc (aead->block_size); digest = xalloc (aead->digest_size); aead->set_encrypt_key (ctx, key); if (aead->set_nonce) aead->set_nonce (ctx, nonce); if (aead->update) aead->update (ctx, DATA_SIZE, data); aead->encrypt (ctx, aead->block_size, dst, src); if (aead->update) aead->digest (ctx, aead->digest_size, digest); free (ctx); free (key); free (nonce); free (src); free (data); free (dst); free (digest); } static const struct nettle_cipher * other_ciphers[] = { &nettle_des, &nettle_des3, &nettle_blowfish128, NULL, }; static const struct nettle_aead * other_aeads[] = { &nettle_arcfour128, &nettle_chacha, &nettle_salsa20, &nettle_salsa20r12, NULL, }; void test_main (void) { unsigned i; const struct nettle_cipher *cipher; const struct nettle_aead *aead; for (i = 0; ((cipher = nettle_ciphers[i])); i++) test_sc_cipher (cipher); for (i = 0; ((cipher = other_ciphers[i])); i++) test_sc_cipher (cipher); for (i = 0; ((aead = nettle_aeads[i])); i++) test_sc_aead (aead); for (i = 0; ((aead = other_aeads[i])); i++) test_sc_aead (aead); } #endif /* HAVE_VALGRIND_MEMCHECK_H */ -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

Fat binaries
by nisse＠lysator.liu.se 22 Oct '14

22 Oct '14

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

2 1

curve25519 progress
by nisse＠lysator.liu.se 22 Oct '14

22 Oct '14

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.

4 18

ecc_curve and ecc_modulo
by nisse＠lysator.liu.se 24 Sep '14

24 Sep '14

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.

1 0

Hashing with EdDSA
by nisse＠lysator.liu.se 09 Sep '14

09 Sep '14

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.

2 4

Simplifying pic vs non-pic object files
by nisse＠lysator.liu.se 03 Sep '14

03 Sep '14

Currently, the nettle Makefile creates two object files for each source file, .o for inclusion in the static library, and .po ("pure object") for the shared library. By default, both are compiled as pic code, but --disable-pic drops the pic flags when compiling the .o files, to get non-pic code into the static library. I'm considering dropping this complication. Just build a single .o file, which is pic by default, and non-pic if --disable-pic is given. To build a non-pic static library, one would configure with "--disable-pic --disable-shared" (since just --disable-pic would produce a shared library with non-pic code, which is highly undesirable). And to produce a static non-pic library and a shared pic library, one would need to use separate build trees. Does that make sense? It would make things simpler, shorten build time, and eliminate the problem of naming two types of object files. One might also have --disable-pic imply --disable-shared (unless explicitly overridden by the user). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

nettle-bugs