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
Hi,
Am 07.06.2014 um 10:35 schrieb Niels Möller nisse@lysator.liu.se:
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
I have two failing tests on 64 bit Sparc:
Encrypt failed: Input: 0123456789abcdef fedcba9876543210
Output: df51fc645013f77c 25c472e2871f742a
Expected: 6767313854966973 0857065648eabe43
Abort - core dumped FAIL: camellia ... Assert failed: testutils.c:513: MEMEQ(digest->length, buffer, digest->data) Abort - core dumped FAIL: gcm
Sparc 32 bit, i386 32 bit and amd64 64 bit work fine. Byte ordering?
Best regards
— Dago
Dagobert Michelsen dam@opencsw.org writes:
I have two failing tests on 64 bit Sparc:
And it's camellia and gcm, which is plain C code on that platform. The testsuite passes on the machine where I test it:
$ uname -a SunOS bacon 5.10 Generic_147147-26 sun4u sparc SUNW,Sun-Fire-15000
$ ./config.status --version nettle config.status 3.0 configured by /home/nisse/hack/nettle/configure, generated by GNU Autoconf 2.69, with options "'CC=gcc -m64' 'CXX=g++ -m64'"
$ gcc --version gcc (GCC) 3.4.5
Which compiler are you using?
Sparc 32 bit, i386 32 bit and amd64 64 bit work fine. Byte ordering?
Does your config.h define WORDS_BIGENDIAN correctly?
Regards, /Niels
Hi Niels,
Am 10.06.2014 um 10:47 schrieb Niels Möller nisse@lysator.liu.se:
Dagobert Michelsen dam@opencsw.org writes:
I have two failing tests on 64 bit Sparc:
And it's camellia and gcm, which is plain C code on that platform. The testsuite passes on the machine where I test it:
$ uname -a SunOS bacon 5.10 Generic_147147-26 sun4u sparc SUNW,Sun-Fire-15000
$ ./config.status --version nettle config.status 3.0 configured by /home/nisse/hack/nettle/configure, generated by GNU Autoconf 2.69, with options "'CC=gcc -m64' 'CXX=g++ -m64'"
$ gcc --version gcc (GCC) 3.4.5
Which compiler are you using?
This is Sun Studio 12. Sun Studio 12.3 fails also. Optflags are -xO3. Removing optflags leads to the same error. I just tested with GCC 4.9.0 and the testsuite passes. Looks like a compiler-interop issue. Would you think giving Sun Studio a try would be worth it? Maybe different alignment and differing pragmas?
Sparc 32 bit, i386 32 bit and amd64 64 bit work fine. Byte ordering?
Does your config.h define WORDS_BIGENDIAN correctly?
Good question:
/* Define WORDS_BIGENDIAN to 1 if your processor stores words with the most significant byte first (like Motorola and SPARC, unlike Intel). */ #if defined AC_APPLE_UNIVERSAL_BUILD # if defined __BIG_ENDIAN__ # define WORDS_BIGENDIAN 1 # endif #else # ifndef WORDS_BIGENDIAN # define WORDS_BIGENDIAN 1 # endif #endif
I guess that is ok.
Best regards
— Dago
Dagobert Michelsen dam@opencsw.org writes:
This is Sun Studio 12. Sun Studio 12.3 fails also. Optflags are -xO3. Removing optflags leads to the same error. I just tested with GCC 4.9.0 and the testsuite passes.
So then it's either a configuration error, some portability problem in the C code, or a compiler bug. Let's start with the camellia failure. Some things you can try to track it down:
1. Enable all warning options.
2. Check that you get the same settings for HAVE_NATIVE_64_BIT with both compilers. And check for any other differences in config.h between builds.
3. Try compiling camellia-crypt-internal.c using gcc, and copy the object file into your Sun Studio build, to try to isolate the failure to a single source file. (This file seems like the most likely culprit, but it could be elsewhere).
4. Add debug output after key expansion, and between rounds, to see where results start to differ between the working and the non-working build.
Regards, /Niels
On Sat, Jun 7, 2014 at 10:35 AM, Niels Möller nisse@lysator.liu.se wrote:
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/.
Hello, As the ABI broke anyway in 3.0, would it make sense to merge the nettle and hogweed libraries? Hogweed cannot be used without linking to libnettle, thus the advantage of the current split is only to applications that only use libnettle. Nevertheless, I don't think there are such applications. My guess is that the ones that simply need sha1, would avoid linking to nettle and just copy the algorithms they need internally. In any embedded system using nettle+hogweed would require more memory and overhead than having a single library. That is of course not a very significant overhead, but it harms the actual programs it targets to help.
regards, Nikos
On Mon, Jun 16, 2014 at 10:36 AM, Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com wrote:
As the ABI broke anyway in 3.0, would it make sense to merge the nettle and hogweed libraries? Hogweed cannot be used without linking to libnettle, thus the advantage of the current split is only to applications that only use libnettle. Nevertheless, I don't think there are such applications. My guess is that the ones that simply need sha1, would avoid linking to nettle and just copy the algorithms they need internally. In any embedded system using nettle+hogweed would require more memory and overhead than having a single library. That is of course not a very significant overhead, but it harms the actual programs it targets to help.
Also maybe it is time to introduce symbol versioning. As nettle 2.7 will be present for quite some time in desktops it would be good to avoid conflicts between libraries that are linked with nettle-2.7 and programs that are linked with nettle-3.0 (or vice-versa).
regards, Nikos
Date: Mon, 16 Jun 2014 10:36:59 +0200 From: Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com Cc: info-gnu@gnu.org, Nettle Crypto Library nettle-bugs@lists.lysator.liu.se
As the ABI broke anyway in 3.0, would it make sense to merge the nettle and hogweed libraries? Hogweed cannot be used without linking to libnettle, thus the advantage of the current split is only to applications that only use libnettle. Nevertheless, I don't think there are such applications.
Hogweed needs GMP, so if someone doesn't want to depend on it, they cannot build hogweed. Of course, if the merged library will build even when GMP is not present, just without some APIs, that's fine too.
On Mon, 2014-06-16 at 17:57 +0300, Eli Zaretskii wrote:
As the ABI broke anyway in 3.0, would it make sense to merge the nettle and hogweed libraries? Hogweed cannot be used without linking to libnettle, thus the advantage of the current split is only to applications that only use libnettle. Nevertheless, I don't think there are such applications.
Hogweed needs GMP, so if someone doesn't want to depend on it, they cannot build hogweed. Of course, if the merged library will build even when GMP is not present, just without some APIs, that's fine too.
There is a patch to use hogweed even without gmp, and is currently part of the openwrt nettle (2.7.1) package, thus one could avoid that dependency altogether and still have (slow) public key support.
regards, Nikos
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
As the ABI broke anyway in 3.0, would it make sense to merge the nettle and hogweed libraries?
Maybe as a build option, but not for a normal installation.
the advantage of the current split is only to applications that only use libnettle. Nevertheless, I don't think there are such applications. My guess is that the ones that simply need sha1, would avoid linking to nettle and just copy the algorithms they need internally.
But I think those applications should use nettle... Adding a gmp dependency makes that less attractive.
In any embedded system using nettle+hogweed would require more memory and overhead than having a single library.
Could you put some numbers to that overhead? I can't say if it's worth trying to avoid.
Regards, /Niels
On Mon, 2014-06-16 at 19:08 +0200, Niels Möller wrote:
Maybe as a build option, but not for a normal installation.
That would be worse as there will be multiple ABIs and would require tweaking all the applications that use nettle in order to build one way or another. I'd prefer to have things as is if the only alternative is that.
But I think those applications should use nettle... Adding a gmp dependency makes that less attractive.
In any embedded system using nettle+hogweed would require more memory and overhead than having a single library.
Could you put some numbers to that overhead? I can't say if it's worth trying to avoid.
No, but is there a reason for having it in the first place? Are there really applications that need only symmetric crypto support and can afford linking to a shared library but really don't want to have the public key in that shared library? OpenSSL's libcrypto is used in embedded systems without any complain of the kind (and it includes all kind of crypto).
regards, Nikos
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/, and the manual at http://www.lysator.liu.se/~nisse/nettle/nettle.html.
NEWS for the Nettle 3.1 release
This release adds a couple of new features.
The library is mostly source-level compatible with nettle-3.0. It is however not binary compatible, due to the introduction of versioned symbols, and extensions to the base64 context structs. The shared library names are libnettle.so.6.0 and libhogweed.so.4.0, with sonames libnettle.so.6 and libhogweed.so.4.
Bug fixes:
* Fixed a missing include of <limits.h>, which made the camellia implementation fail on all 64-bit non-x86 platforms.
* Eliminate out-of-bounds reads in the C implementation of memxor (related to valgrind's --partial-loads-ok flag).
Interface changes:
* Declarations of many internal functions are moved from ecc.h to ecc-internal.h. The functions are undocumented, and luckily they're apparently also unused by applications, so I don't expect any problems from this change.
New features:
* Support for curve25519 and for EdDSA25519 signatures.
* Support for "fat builds" on x86_64 and arm, where the implementation of certain functions is selected at run-time depending on available cpu features. Configure with --enable-fat to try this out. If it turns out to work well enough, it will likely be enabled by default in later releases.
* Support for building the hogweed library (public key support) using "mini-gmp", a small but slower implementation of a subset of the GMP interfaces. Note that builds using mini-gmp are *not* binary compatible with regular builds, and more likely to leak side-channel information.
One intended use-case is for small embedded applications which need to verify digital signatures.
* The shared libraries are now built with versioned symbols. Should reduce problems in case a program links explicitly to nettle and/or hogweed, and to gnutls, and the program and gnutls expect different versions.
* Support for "URL-safe" base64 encoding and decoding, as specified in RFC 4648. Contributed by Amos Jeffries.
Optimizations:
* New x86_64 implementation of AES, using the "aesni" instructions. Autodetected in fat builds. In non-fat builds, it has to be enabled explicitly with --enable-x86-aesni.
Build system:
* Use the same object files for both static and shared libraries. This eliminates the *.po object files which were confusing to some tools (as well as humans). Like before, PIC code is used by default; to build a non-pic static library, configure with --disable-pic --disable-shared.
Miscellaneous:
* Made type-checking hack in CBC_ENCRYPT and similar macros stricter, to generate warnings if they are used with functions which have a length argument smaller than size_t.
Available at:
https://ftp.gnu.org/gnu/nettle/nettle-3.1.tar.gz ftp://ftp.gnu.org/gnu/nettle/nettle-3.1.tar.gz http://www.lysator.liu.se/~nisse/archive/nettle-3.1.tar.gz ftp://ftp.lysator.liu.se/pub/security/lsh/nettle-3.1.tar.gz (soon)
Happy hacking, /Niels Möller
nisse@lysator.liu.se (Niels Möller) writes:
I'm happy to announce a new version of GNU Nettle, a low-level cryptographics library.
I've now seen my first bug report on nettle-3.1. Seems I got shell quoting wrong in the last-minute fix for w64 and mini-gmp. I've checked in a fix. I'll have to do a nettle-3.1.1 bugfix release in a week or so (I need to test that this fix doesn't break on w64). Any other issues?
Regards, /Niels
nettle-bugs@lists.lysator.liu.se
-
Dagobert Michelsen -
Eli Zaretskii -
Nikos Mavrogiannopoulos -
Nikos Mavrogiannopoulos -
nisse＠lysator.liu.se