NEWS for the Nettle 3.5.1 release
The Nettle-3.5.1 corrects a packaging mistake in Nettle-3.5.
The new directory x86_64/sha_ni were missing in the tar file,
breaking x86_64 builds with --enable-fat, and producing worse
performance than promised for builds with --enable-x86-sha-ni.
Also a few unused in-progress assembly files were accidentally
included in the tar file.
These problems are corrected in Nettle-3.5.1. There are no
other changes, and also the library version numbers are
unchanged.
NEWS for the Nettle 3.5 release
This release adds a couple of new features and optimizations,
and deletes or deprecates a few obsolete features. It is *not*
binary (ABI) compatible with earlier versions. Except for
deprecations listed below, it is intended to be fully
source-level (API) compatible with Nettle-3.4.1.
The shared library names are libnettle.so.7.0 and
libhogweed.so.5.0, with sonames libnettle.so.7 and
libhogweed.so.5.
Changes in behavior:
* Nettle's gcm_crypt will now call the underlying block cipher
to process more than one block at a time. This is not a
change to the documented behavior, but unfortunately breaks
assumptions accidentally made in GnuTLS, up to and including
version 3.6.1.
New features:
* Support for CFB8 (Cipher Feedback Mode, processing a single
octet per block cipher operation), contributed by Dmitry
Eremin-Solenikov.
* Support for CMAC (RFC 4493), contributed by Nikos
Mavrogiannopoulos.
* Support for XTS mode, contributed by Simo Sorce.
Optimizations:
* Improved performance of the x86_64 AES implementation using
the aesni instructions. Gives a large speedup for operations
processing multiple blocks at a time (including CTR mode,
GCM mode, and CBC decrypt, but *not* CBC encrypt).
* Improved performance for CTR mode, for the common case of
16-byte block size. Pass more data at a time to underlying
block cipher, and fill the counter blocks more efficiently.
Extension to also handle GCM mode efficiently contributed
by Nikos Mavrogiannopoulos.
* New x86_64 implementation of sha1 and sha256, for processors
supporting the sha_ni instructions. Speedup of 3-5 times on
affected processors.
* Improved parameters for the precomputation of tables used
for ecc signatures. Roughly 10%-15% speedup of the ecdsa
sign operation using the secp_256r1, secp_384r1 and
secp_521r1 curves, and 25% speedup of ed25519 sign
operation, benchmarked on x86_64. Table sizes unchanged,
around 16 KB per curve.
* In ARM fat builds, automatically select Neon implementation
of Chacha, where possible. Contributed by Yuriy M.
Kaminskiy.
Deleted features:
* The header file des-compat.h and everything declared therein
has been deleted, as announced earlier. This file provided a
subset of the old libdes/ssleay/openssl interface for DES
and triple-DES. DES is still supported, via the functions
declared in des.h.
* Functions using the old struct aes_ctx have been marked as
deprecated. Use the fixed key size interface instead, e.g.,
struct aes256_ctx, introduced in Nettle-3.0.
* The header file nettle-stdint.h, and corresponding autoconf
tests, have been deleted. Nettle now requires that the
compiler/libc provides <stdint.h>.
Miscellaneous:
* Support for big-endian ARM systems, contributed by Michael
Weiser.
* The programs aesdata, desdata, twofishdata, shadata and
gcmdata are no longer built by default. Makefile
improvements contributed by Jay Foad.
* The "example" program examples/eratosthenes.c has been
deleted.
* The contents of hash context structs, and the deprecated
aes_ctx struct, have been reorganized, to enable later
optimizations.
The shared library names are libnettle.so.7.0 and
libhogweed.so.5.0.
NEWS for the Nettle 3.1.1 release
This release fixes a couple of non-critical bugs.
Bug fixes:
* By accident, nettle-3.1 disabled the assembly code for the
secp_224r1 and secp_521r1 elliptic curves on all x86_64
configurations, making signature operations on those curves
10%-30% slower. This code is now re-enabled.
* The x86_64 assembly implementation of gcm hashing has been
fixed to work with the Sun/Oracle assembler.
The shared library names are libnettle.so.6.1 and
libhogweed.so.4.1, with sonames still libnettle.so.6 and
libhogweed.so.4. It is intended to be fully binary compatible
with nettle-3.1.
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.
This release includes an implementation of elliptic curve
cryptography (ECC) and optimizations for the ARM architecture.
This work was done at the offices of South Pole AB, and
generously funded by the .SE Internet Fund.
Bug fixes:
* Fixed a bug in the buffer handling for incremental SHA3
hashing, with a possible buffer overflow. Patch by Edgar
E. Iglesias.
New features:
* Support for ECDSA signatures. Elliptic curve operations over
the following curves: secp192r1, secp224r1, secp256r1,
secp384r1 and secp521r1, including x86_64 and ARM assembly
for the most important primitives.
* Support for UMAC, including x86_64 and ARM assembly.
* Support for 12-round salsa20, "salsa20r12", as specified by
eSTREAM. Contributed by Nikos Mavrogiannopoulos.
Optimizations:
* ARM assembly code for several additional algorithms,
including AES, Salsa20, and the SHA family of hash
functions.
* x86_64 assembly for SHA256, SHA512, and SHA3. (SHA3 assembly
was included in the 2.6 release, but disabled due to poor
performance on some AMD processors. Hopefully, that
performance problem is fixed now).
The ARM code was tested and benchmarked on Cortex-A9. Some of
the functions use "neon" instructions. The configure script
decides if neon instructions can be used, and the command line
options --enable-arm-neon and --disable-arm-neon can be used
to override its choice. Feedback appreciated.
The libraries are intended to be binary compatible with
nettle-2.2 and later. The shared library names are
libnettle.so.4.6 and libhogweed.so.2.4, with sonames still
libnettle.so.4 and libhogweed.so.2.
NEWS for the 2.2 release
Licensing change:
* Relicensed as LGPL v2.1 or later (user's option).
* Replaced blowfish and serpent implementation. New code is
based on the LGPLed code in libgcrypt.
New features:
* Support for Galois/Counter Mode (GCM).
* New interface for enumerating (most) available algorithms,
contributed by Daniel Kahn Gillmor.
* New tool nettle-hash. Can generate hash digests using any
supported hash function, with output compatible with md5sum
and friends from GNU coreutils. Checking (like md5sum -c)
not yet implemented.
Bug fixes:
* The old serpent code had a byte order bug (introduced by
yours truly about ten years ago). New serpent implementation
does not interoperate with earlier versions of nettle.
* Fixed ABI-dependent libdir default for Linux-based systems
which do not follow the Linux File Hierarchy Standard, e.g.,
Debian GNU/Linux.
Optimizations:
* x86_64 implemention of serpent.
* x86_64 implemention of camellia.
* Optimized memxor using word rather than byte operations.
Both generic C and x86_64 assembler.
* Eliminated a memcpy for in-place CBC decrypt.
Miscellaneous:
* In command line tools, no longer support -? for requesting
help, since using it without shell quoting is a dangerous
habit. Use long option --help instead.
The shared library names are libnettle.so.4.1 and
libhogweed.so.2.1, with sonames libnettle.so.4 and
libhogweed.so.2.
or less any context: In crypto toolkits for object-oriented languages
(C++, Python, Pike, ...), in applications like LSH or GNUPG, or even in
kernel space. In most contexts, you need more than the basic
cryptographic algorithms, you also need some way to keep track of available
algorithms, their properties and variants. You often have some algorithm
selection process, often dictated by a protocol you want to implement.
And as the requirements of applications differ in subtle and not so
subtle ways, an API that fits one application well can be a pain to use
in a different context. And that is why there are so many different
cryptographic libraries around.
Nettle tries to avoid this problem by doing one thing, the low-level
crypto stuff, and providing a simple but general interface to it.
In particular, Nettle doesn't do algorithm selection. It doesn't do
memory allocation. It doesn't do any I/O.
The idea is that one can build several application and context specific
interfaces on top of Nettle, and share the code, test cases, benchmarks,
documentation, etc. Examples are the Nettle module for the Pike
language, and LSH, which both use an object-oriented abstraction on top
of the library.
