nettle-bugs

nettle-bugs@lists.lysator.liu.se

2 participants
2203 discussions

Re: RSA/DSA - Save and Load key
by nisse＠lysator.liu.se 25 Nov '10

25 Nov '10

[ Repost from an off-list discussion, since this may be of more general interest. /Niels ] Jeffrey Walton <noloader(a)gmail.com> writes: > I did not see rsa_public_key_save, rsa_public_key_load, > rsa_private_key_save, and rsa_private_key_load. How does one save and > or load a public or private key? That depends on which keyformat you want. The most general (and most primitive) way is to access the bignums in the public and private key structs directly, using functions like mpz_set_str/mpz_get_str or mpz_import/mpz_export. Don't forget to call rsa_public_key_prepare and rsa_private_key_prepare after setting these fields. There are some helper functions, rsa_keypair_to_sexp and rsa_keypair_from_sexp for conversion to and from spki/sexp format. And there's rsa_keypair_from_der for reading keys in pkcs#1 format (but appearantly none for the other direction). These functions are unfortunately all undocumented, which is due in part to lazyness, in part to the fact that I'm not sure the interfaces are right (although for these particular functions, I see nothing obviously wrong, except perhaps the names). There are at least some examples, examples/rsa-keygen.c calls rsa_keypair_to_sexp, examples/read_rsa_key.c calls rsa_keypair_from_sexp, and tools/pkcs1-conv.c calls rsa_keypair_from_der. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

Re: DES
by nisse＠lysator.liu.se 24 Nov '10

24 Nov '10

Simon Josefsson <simon(a)josefsson.org> writes: > I wrote a DES implementation a long time ago, [...] but if there are > license concerns with the current one, it could be an alternative. The code by Dana L. How is licensed as LGPL version 2 (or later). I don't think there's license problem (see descore.README in the nettle dist). That's one of the nice features with free software: that the code comes with a license which let you use and redistribute it, without any requirement to first get in contact with the author. But I expect that if one decided to try to get a copyright assignment for the current DES code, that would be a bit difficult. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

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

Jump to page:

2025

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