nettle-bugs

nettle-bugs@lists.lysator.liu.se

2191 discussions

web page bug
by Simon Josefsson 21 Oct '10

21 Oct '10

The web page says: descend into the src/nettle directory for a standard ./configure && make there. I guess it should be: descend into the nettle directory for a standard ./configure && make there. Thanks, Simon

2 1

Configuration and MinGW-w64 Compatibility
by Hoyt, David 24 Sep '10

24 Sep '10

Hello, I'm preparing for future gnutls integration which says in the next stable release, it'll be using nettle by default. I'm working on Windows builds and the 2.1 release has several problems. I'm not entirely familiar with the autotools, so I don't know exactly where the problem lies - but it generates shared library names in the unix/linux style (e.g. libnettle.so.4) instead of Windows-style: libnettle-4.dll. I can simply rename the dll and it'll work, but it's a pain and not in line with most other open source projects. Also, when I use --enabled-shared --disable-static, my configure options are not respected. That is, it builds a static lib as well as the (incorrectly named) shared library. A .dll.a lib file is not created. When I use typical configure options such as --prefix= --libexecdir= --bindir= --libdir= --includedir=, they're not honored. e.g. I specified a different bindir for the shared libs, yet they still ended up in the --libdir directory. This may result from the use of an older autotools/libtool setup, but I'm unsure. I'm building natively using GCC 4.5.1 (x86, 32-bit) from the MinGW-w64 folks on Windows 7 64-bit. Thanks, - David Hoyt

2 5

Patch for configure.ac
by Hoyt, David 17 Sep '10

17 Sep '10

I tried to send the following w/ an attachment, but it got bounced. So here it is w/ the attachment inlined: The attached patch for configure.ac allowed for a normal compile w/ mingw-w64 w/ --enabled-shared. It's really only a stopgap since you would need to do something more intelligent when you detect --enable-shared and then dynamically adjust hogweed's link options. Do you think it would be possible to add libtool and pkg-config support? Thanks, - David Hoyt --- configure.ac Sun Jul 25 12:30:13 2010 +++ configure.ac Thu Sep 16 12:48:51 2010 @@ -233,6 +233,19 @@ SHLIBCFLAGS="$CCPIC" case "$host_os" in + mingw32*) + LIBNETTLE_FORLINK='libnettle-$(LIBNETTLE_MAJOR)-$(LIBNETTLE_MINOR).dll' + LIBNETTLE_SONAME='' + LIBNETTLE_FILE='libnettle.dll.a' + LIBNETTLE_LINK='$(CC) $(LDFLAGS) -shared -Wl,--out-implib=$(LIBNETTLE_FILE) -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--whole-archive' + LIBNETTLE_LIBS='-Wl,--no-whole-archive $(LIBS)' + + LIBHOGWEED_FORLINK='libhogweed-$(LIBHOGWEED_MAJOR)-$(LIBHOGWEED_MINOR).dll' + LIBHOGWEED_SONAME='' + LIBHOGWEED_FILE='libhogweed.dll.a' + LIBHOGWEED_LINK='$(CC) $(LDFLAGS) -shared -Wl,--out-implib=$(LIBHOGWEED_FILE) -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--whole-archive' + LIBHOGWEED_LIBS='-Wl,--no-whole-archive $(LIBS) libnettle.dll.a' + ;; cygwin*) LIBNETTLE_FORLINK='cygnettle-$(LIBNETTLE_MAJOR)-$(LIBNETTLE_MINOR).dll' LIBNETTLE_SONAME=''

2 4

LGPL Configuration
by Hoyt, David 17 Sep '10

17 Sep '10

As a feature request, it'd be useful to have an additional configure flag "--enable-gpl" like the FFmpeg folks use that allows GPL algorithms to be built. Otherwise, by default, LGPL algorithms/code only is allowed in shared libraries. Right now I have to play around with makefiles to remove GPL-only algorithms (as per the included manual) such as serpent and blowfish. Thanks, - David Hoyt

2 2

Hogweed and Nettle Dependencies
by Hoyt, David 17 Sep '10

17 Sep '10

Should libhogweed have a dependency on libnettle if I'm compiling each as shared libraries? Or should I be linking against nettle's static library and thus have duplicate functions in each? Thanks, - David Hoyt

3 3

ANNOUNCE: Nettle-2.1
by nisse＠lysator.liu.se 31 Jul '10

31 Jul '10

I'm happy to announce a new version of GNU Nettle, a low-level cryptographic library. NEWS for the 2.1 release *Important*: this release breaks source and binary compatibility for the digital signature functions, and for the DES and BLOWFISH ciphers which have weak keys. Incompatible changes: * The functions rsa_md5_sign, rsa_sha1_sign and rsa_sha256_sign, and the corresponding _digest variants, now have a return value which callers should check. The functions return failure if the key is too small for the type of signature. * The functions dsa_sign and dsa_verify are renamed to dsa_sha1_sign and dsa_sha1_verify. The _-digest variants are renamed similarly. These functions now have a return value which callers should check, and they return failure if the number q is not of the appropriate size. * The return value from des_set_key, des3_set_key and blowfish_set_key now indicates whether or not the given key is weak. But in either case, the key setup is done, and applications that don't care about weak keys can ignore the return value. The incompatible part of this change is that enum des_error and enum blowfish_error has been deleted, and so has the status attribute in struct des_ctx, struct des3_ctx, and struct blowfish_ctx. The shared library names are libnettle.so.4.0 and libhogweed.so.2.0, with sonames libnettle.so.4 and libhogweed.so.2. Other changes: * Support for the Camellia block cipher, including an assembler implementation for x86_32. * New function aes_invert_key, useful for applications that need both encryption and decryption using the same AES key. * des_set_key and des3_set_key no longer check the key parity bits. Parity bits are silently ignored. A new function des_check_parity is provided, for applications that care about the DES parity bits. * Support for sha224, sha384 and sha512. * Support for digital signatures using rsa-sha512 and dsa-sha256. Due to lack of official test vectors and interop testing, this support should be considered somewhat experimental. * Key generation for RSA and DSA changed to use Maurer's algorithm to generate provably prime numbers (as usual, the mathematical proof does not guaranteee that the implementation is bug free). * x86_64 assembler implementation actually included in the distribution (was accidentally left out in nettle-2.0). * Configure script now detects if the compiler uses a 32-bit or 64-bit ABI on x86_64 (prevously did this for sparc only). Also sets the default location for installing libraries (libdir) depending on system type and the ABI used. * Added the nettle and gmp libraries as dependencies when linking shared library libhogweed.so. On systems using shared libraries where such dependencies work (in particular, ELF systems), it is sufficient to link applications with -lhogweed. For static linking -lhogweed -lnettle -lgmp is still required. * The program pkcs1-conv is extended to also handle dsa keys. Contributed by Magnus Holmgren. * Slightly improved sha1 performance on x86. Available at http://www.lysator.liu.se/~nisse/archive/nettle-2.1.tar.gz ftp://ftp.lysator.liu.se/pub/security/lsh/nettle-2.1.tar.gz -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

plans for other SHA-2 digests?
by Daniel Kahn Gillmor 26 Mar '10

26 Mar '10

Hi Nettle folks-- >From the documentation i could find, it looks like the strongest digest libnettle supports is SHA256. Are there plans to add support for SHA512 or other members of the SHA-2 family? (i suppose the same question holds for the primitives in libhogweed that include a digest operation, such as RSA signing) Thanks for offering this tool, --dkg PS i tried to send this message earlier, PGP/MIME-signed, but it appears to have been bounced from the mailing list with a message of: The message's content type was not explicitly allowed My resend here is unsigned, but it would be nice to be able to send signed mails to the list!

2 9

RSA-SHA512 interface problem
by nisse＠lysator.liu.se 24 Mar '10

24 Mar '10

I just realized that supporting RSA with SHA-512 leads to an interface problem. For RSA keys to work with PKCS#1 signatures, the modulo n has to be large enough. Up to now, I have used two defines, RSA_MINIMUM_N_OCTETS and RSA_MINIMUM_N_BITS, which are determined so that pkcs#1 works with *all* supported hash function. The rsa_public_key_prepare and rsa_private_key_prepare functions check that n is large enough and returns a success/failure value. Then no other rsa functions are expected to ever fail due to n being too small. With sha256, the minimum was 62 octets or 489 bits. But for sha512, the minimum is 94 octets or 745 bits. So if I just bump the RSA_MINIMUM_N_* accordingly, support for 512 bits RSA keys disappears. (And for comparison, with md5, the minimum is 353 bits). I really hope noone still uses 512 bit RSA for anything important, but I nevertheless don't think it's appropriate to just drop support for it. Some applications may have modest security requirements where small keys are somehow appropriate, and then there are legacy applications and old keys. It should still be *possible* to verify signatures made many years ago, using 512-bit RSA, even though they can no longer be considered very secure. I haven't figured out yet how I want to handle this, and I see no solution without its own problems. Some alternatives: * Discontinue the RSA_MINIMUM_N_*, or use some reasonable value which isn't large enough for rsa-sha512. Let signature functions abort if they encounter a too small key. Possibly define new hash-specific constants, RSA_<hash>_MINIMUM_N_BITS or so. * Add some argument to the rsa_*_key_prepare functions to say what the key is to be used for, so that it can check if the key is large enough. I don't quite like this; it's against the spirit of the rest of the Nettle interface. * Introduce a return value for the signing functions, to let them return a success/failure indication. This is analogous to the rsa_encrypt function, which checks if the key size is large enough for the current message size. If we do this, is the return value from the rsa_*_key_prepare functions still useful? I think it's less of a problem with public key operations, since signature verification and rsa decryption have a return value and for too small keys they can easily return fail for all messages. The problem is the signing functions. No matter how the problem is solved, it will break backwards compatibility in some way. Suggestions? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 2

nettle bindings for higher-level languages
by Daniel Kahn Gillmor 23 Mar '10

23 Mar '10

I was wondering if there is a catalog somewhere of bindings that exist for nettle for higher-level languages. in particular, i'm interested in perl and python, but i'd be curious to know about the status of other languages as well. Is this documented somewhere? Is there a list of higher-level languages that the nettle author(s) would like to see prioritized? Regards, --dkg

2 2

GNU Nettle cryptographic library
by nisse＠lysator.liu.se 30 Jun '09

30 Jun '09

Nettle-2.0 was released June 8. Since then, Nettle has been dubbed a GNU package, and I'm therefore reannouncing this release here. The original announcement is included below. Future releases will be distributed at ftp.gnu.org, but unfortunately, I haven't been able to set that up before summer vacations (and I leave my signing keys at home). What is Nettle? A quote from the introduction in the Nettle Manual: Nettle is a cryptographic library that is designed to fit easily in more 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. Nettle is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation. See the file COPYING for details. Most, but not all, of Nettle can also be used under the terms of the GNU Lesser General Public License; please read the Copyright section of the manual if you want to exercise this option. The Nettle home page is http://www.lysator.liu.se/~nisse/nettle/. Happy hacking, /Niels Möller Original announcement: NEWS for the 2.0 release This release breaks binary compatibility by splitting the library into two. Some other smaller changes that are not backwards compatible are also done at the same time. * The nettle library is split into two libraries, libnettle and libhogweed. libnettle contains the symmetric crypto algorithms that don't depend on GMP, while libhogweed contains the public key algorithms that depend on GMP. Using a single library worked fine with static linking, but not with dynamic linking. Consider an application that uses nettle and which doesn't use any public key cryptography. If this application is linked dynamically to nettle, it would have to be linked also with GMP if and only if public key support was enabled when the nettle library was installed. The library names are libnettle.so.3.0 and libhogweed.so.1.0, with sonames libnettle.so.3 and libhogweed.so.1. * Function typedefs have been changed to non-pointer types. E.g, the typedef void (nettle_hash_init_func *)(void *ctx); of previous versions is replaced by typedef void (nettle_hash_init_func)(void *ctx); This makes it possible to use the type when declaring functions, like nettle_hash_init_func foo_hash_init; void foo_hash_init(void *ctx) { ... } * Changes to the yarrow256 interface. The automatic seed file generation, and the seed_file member in struct yarrow256_ctx, has been removed. To generate a new seed file, use yarrow256_random. The function yarrow256_force_reseed has been replaced by the two functions yarrow256_fast_reseed and yarrow256_slow_reseed, which were previously static. This interface change makes it easier to mix in the current content of the seed file before overwriting it with newly generated data. Other changes: * Nettle manual now contributed to the public domain, to enable remixing into documentation of programs that use Nettle. * The sexp-conv program preserves comments when using the advanced syntax for output. Optionally locks the output file. * The base64 decoder recognizes ASCII FF (form feed) and VT (vertical tab) as white space. * New x86_64 implementations of AES and SHA1. On a 2.2 GHz opteron, SHA1 was benchmarked at 250 MByte/s, and AES-128 at 110 MByte/s. * Performance of AES increased by 20-30% on x86. * New programs in the examples directory: erathostenes and next-prime. Available at http://www.lysator.liu.se/~nisse/archive/nettle-2.0.tar.gz ftp://ftp.lysator.liu.se/pub/security/lsh/nettle-2.0.tar.gz as usual. Regards, /Niels

1 0

Jump to page:

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