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 …
[View More]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.gzftp://ftp.gnu.org/gnu/nettle/nettle-3.0.tar.gzhttp://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.
[View Less]
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."
…
[View More]What do you think? Should the FSF be consulted on that?
regards,
Nikos
[0]. http://www.cs.ucdavis.edu/~rogaway/ocb/license.htm
[View Less]
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-…
[View More]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.
[View Less]
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 …
[View More]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.
[View Less]
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 …
[View More]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.
[View Less]