nettle-bugs October 2014

nettle-bugs@lists.lysator.liu.se

4 participants
6 discussions

ANNOUNCE: Nettle-3.0
by nisse＠lysator.liu.se 13 Apr '15

13 Apr '15

I'm happy to announce a new version of GNU Nettle, a low-level cryptographics library. The Nettle home page can be found at http://www.lysator.liu.se/~nisse/nettle/. This release is dual licensed as LGPLv3 or later, or GPLv2 or later. See the manual for details. NEWS for the Nettle 3.0 release This is a major release, including several interface changes, and new features, some of which are a bit experimental. Feedback is highly appreciated. It is *not* binary (ABI) compatible with earlier versions. It is mostly source-level (API) compatible, with a couple of incompatibilities noted below. The shared library names are libnettle.so.5.0 and libhogweed.so.3.0, with sonames libnettle.so.5 and libhogweed.so.3. There may be some problems in the new interfaces and new features which really need incompatible fixes. It is likely that there will be an update in the form of a 3.1 release in the not too distant future, with small but incompatible changes, and if that happens, bugfix-only releases 3.0.x are unlikely. Users and applications which desire better API and ABI stability are advised to stay with nettle-2.7.x (latest version is now 2.7.1) until the dust settles. Interface changes: * For the many _set_key functions, it is now consider the normal case to have a fixed key size, with no key_size arguments. _set_key functions with a length parameter are provided only for algorithms with a truly variable keysize, and where it makes sense for backwards compatibility. INCOMPATIBLE CHANGE: cast128_set_key no longer accepts a key size argument. The old function is available under a new name, cast5_set_key. INCOMPATIBLE CHANGE: The function typedef nettle_set_key_func no longer accepts a key size argument. In particular, this affects users of struct nettle_cipher. * The nettle_cipher abstraction (in nettle-meta.h) is restricted to block ciphers only. The encrypt and decrypt functions now take a const argument for the context. INCOMPATIBLE CHANGE: nettle_arcfour, i.e., the nettle_cipher abstraction for the arcfour stream cipher, is deleted. INCOMPATIBLE CHANGE: New type, nettle_cipher_func, for the encrypt and decrypt fields of struct nettle_cipher. * New DSA interface, with a separate struct dsa_param to represent the underlying group, and generalized dsa_sign and dsa_verify functions which don't care about the hash function used. Limited backwards compatibility provided in dsa-compat.h. INCOMPATIBLE CHANGE: Declarations of the old interface, e.g., struct dsa_public_key, dsa_sha1_sign, etc, is moved to dsa-compat.h. INCOMPATIBLE CHANGE: The various key conversion functions, e.g., dsa_keypair_to_sexp, all use the new DSA interface, with no backwards compatible functions. INCOMPATIBLE CHANGE: dsa_generate_keypair also uses the new interface. dsa-compat.h declares a function dsa_compat_generate_keypair, implementing the old interface, and #defines dsa_generate_keypair to refer to this backwards compatible function. * New AES and Camellia interfaces. There are now separate context structs for each key size, e.g., aes128_ctx and camellia256_ctx, and corresponding new functions. The old interface, with struct aes_ctx and struct camellia_ctx, is kept for backwards compatibility, but might be removed in later versions. * The type of most length arguments is changed from unsigned to size_t. The memxor functions have their pointer arguments changed from uint8_t * to void *, for consistency with related libc functions. * For hash functions, the constants *_DATA_SIZE have been renamed to *_BLOCK_SIZE. Old names kept for backwards compatibility. Removed features: * The nettle_next_prime function has been deleted. Applications should use GMP's mpz_nextprime instead. * Deleted the RSAREF compatibility, including the header file rsa-compat.h and everything declared therein. * Also under consideration for removal is des-compat.h and everything declared therein. This implements a subset of the old libdes/ssleay/openssl interface for DES and triple-DES, and it is poorly tested. If anyone uses this interface, please speak up! Otherwise, it will likely be removed in the next release. Bug fixes: * Building with ./configure --disable-static now works. * Use GMP's allocation functions for temporary storage related to bignums, to avoid potentially large stack allocations. * Fixes for shared libraries on M$ Windows. New features: * Support for Poly1305-AES MAC. * Support for the ChaCha stream cipher and EXPERIMENTAL support for the ChaCha-Poly1305 AEAD mode. Specifications are still in flux, and future releases may do incompatible changes to track standardization. Currently uses 256-bit key and 64-bit nonce. * Support for EAX mode. * Support for CCM mode. Contributed by Owen Kirby. * Additional variants of SHA512 with output size of 224 and 256 bits. Contributed by Joachim Strömbergson. * New interface, struct nettle_aead, for mechanisms providing authenticated encryption with associated data (AEAD). * DSA: Support a wider range for the size of q and a wider range for the digest size. Optimizations: * New x86_64 assembly for GCM and MD5. Modest speedups on the order of 10%-20%. Miscellaneous: * SHA3 is now documented as EXPERIMENTAL. Nettle currently implements SHA3 as specified at the time Keccak won the SHA3 competition. However, the final standard specified by NIST is likely to be incompatible, in which case future releases may do incompatible changes to track standardization. * The portability fix for the rotation macros, mentioned in NEWS for 2.7.1, actually didn't make it into that release. It is included now. * cast128_set_key rewritten for clarity, also eliminating a couple of compiler warnings. * New command line tool nettle-pbkdf2. Available at: https://ftp.gnu.org/gnu/nettle/nettle-3.0.tar.gz ftp://ftp.gnu.org/gnu/nettle/nettle-3.0.tar.gz http://www.lysator.liu.se/~nisse/archive/nettle-3.0.tar.gz ftp://ftp.lysator.liu.se/pub/security/lsh/nettle-3.0.tar.gz (soon) Happy hacking, /Niels Möller -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

5 12

OCB mode
by Nikos Mavrogiannopoulos 28 Jan '15

28 Jan '15

Hello, What do you think of having OCB mode in nettle? I particularly like OCB due to it's simplicity and performance comparing to GCM/CCM, but was always patented. However in [0] there is license1 which states: "Under this license, you are authorized to make, use, and distribute open-source software implementations of OCB. This license terminates for you if you sue someone over their open-source software implementation of OCB claiming that you have a patent covering their implementation." What do you think? Should the FSF be consulted on that? regards, Nikos [0]. http://www.cs.ucdavis.edu/~rogaway/ocb/license.htm

4 8

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

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 October 2014