nettle-bugs December 2012

nettle-bugs@lists.lysator.liu.se

4 participants
10 discussions

[PATCH] silence more warnings
by Tim Ruehsen 21 Dec '12

21 Dec '12

some little fixes for nettle-hash.c:53:2: warning: ISO C does not allow extra ';' outside of a function [-pedantic] testutils.c:1072:2: warning: ISO C does not allow extra ';' outside of a function [-pedantic] des-compat-test.c:748:14: warning: old-style function definition [-Wold-style-definition] des-compat-test.c:755:17: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] Regards, Tim diff --cc testsuite/des-compat-test.c index 257c343,257c343..4021ee8 --- a/testsuite/des-compat-test.c +++ b/testsuite/des-compat-test.c @@@ -745,14 -745,14 +745,13 @@@ plain[8+4], plain[8+5], plain[8+6], pla return(0); } --static char *pt(p) --const unsigned char *p; ++static char *pt(const unsigned char *p) { static char bufs[10][20]; static int bnum=0; char *ret; int i; -- static char *f="0123456789ABCDEF"; ++ static const char *f="0123456789ABCDEF"; ret= &(bufs[bnum++][0]); bnum%=10; diff --cc testsuite/testutils.c index d77bb7e,d77bb7e..1b0fd88 --- a/testsuite/testutils.c +++ b/testsuite/testutils.c @@@ -1069,7 -1069,7 +1069,7 @@@ test_dsa_key(struct dsa_public_key *pub mpz_powm(t, pub->g, key->x, pub->p); ASSERT(0 == mpz_cmp(t, pub->y)); --}; ++} #endif /* WITH_HOGWEED */ diff --cc tools/nettle-hash.c index 842f9ff,5710216..bd03b18 --- a/tools/nettle-hash.c +++ b/tools/nettle-hash.c @@@ -50,9 -49,9 +50,9 @@@ list_algorithms (void for (i = 0; (alg = nettle_hashes[i]); i++) printf ("%10s %d (%d)\n", alg->name, alg->digest_size, alg->block_size); --}; ++} -static const struct nettle_hash * +static const struct nettle_hash * NONNULL(1) find_algorithm (const char *name) { const struct nettle_hash *alg;

2 1

building without fp
by Nikos Mavrogiannopoulos 16 Dec '12

16 Dec '12

I noticed that trying to build nettle in systems without floating point fails at the shadata, aesdata tools. The attached patch adds a flag (disable-data-targets) to prevent them from being built. regards, Nikos

2 1

Re: [PATCH] build: add --enable-static option
by nisse＠lysator.liu.se 15 Dec '12

15 Dec '12

Alon Bar-Lev <alon.barlev(a)gmail.com> writes: >> Maybe a make install without a previous make all should be supported? > > Usually yes. I just checked the GNU coding standards, and they seem to agree with you. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

Re: [PATCH] build: add --enable-static option
by nisse＠lysator.liu.se 15 Dec '12

15 Dec '12

Alon Bar-Lev <alon.barlev(a)gmail.com> writes: > Working, thanks! Thanks for testing. ---disable-static checked in now. > BTW: > There is an issue with: > $ ./configure > $ make install DESTDIR=/tmp/xxx Skipping make is not currently supported. I.e., you're supposed to do $ ./configure $ make $ make install or even better $ ./configure $ make $ make check && make install Maybe a make install without a previous make all should be supported? Nevertheless, I guess the reported problem is a bug in tools/Makefile.in, the rule $(getopt_OBJS): ( cd .. && $(MAKE) $@ ) Does it work to replace $@ by `basename $@` ? (I haven't thought this through, maybe there's some better way to do it...) Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

Some news for the next year
by nisse＠lysator.liu.se 15 Dec '12

15 Dec '12

The first item is a personal one. From January 7, I'll start working for Southpole Consulting AB, a small Sockholm-based consulting company mainly doing embedded (GNU/)Linux development. Second item is more directly related to Nettle. I will get funding from Internetfonden, for "Adapting GNU Nettle for embedded systems". This will mean two things: Support for elliptic curve signatures (and possibly some other ECC-related things), and optimizations for the ARM architecture. The funding is for 420 hours of work, most of which will be spent during the spring, and the project will be carried out under the umbrella of Southpole Consulting. A question for the list: Which variants of the ARM family are most important for Nettle applications? I'm not yet very familiar with the ARM world, but the following are some alternatives for testing and benchmarking: * The current most high-end processor, Cortex-A15, where an affordable development system seems to be a recent "chromebook". Not sure exactly which model, but I guess it's this one: http://www.amazon.co.uk/Samsung-Chromebook-Wifi-Latest-Model/dp/B009RF0AQ8/… * The previous "most high-end" processor, Cortex-A9. An affordable development system is the PandaBoard. http://www.omappedia.com/wiki/PandaBoard_FAQ * The Raspberry Pi computer, featuring an older (obsolete?) ARM1176JFZ, "ARMv6" architecture. http://www.raspberrypi.org/faqs * The low-end Cortex-M0, competing with less than $1 microcontrollers. Also "ARMv6" architecture. An affordable development system seems to be LPCXPRESSO board. http://www.embeddedartists.com/products/lpcxpresso/lpc11U14_xpr.php And if anybody here has some interesting ARM hardware to donate to the project, this is the right time. Best regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

3 5

Re: [PATCH] Probe for archiver tool
by nisse＠lysator.liu.se 15 Dec '12

15 Dec '12

Comitted now. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

Re: [PATCH] build: add --enable-static option
by nisse＠lysator.liu.se 15 Dec '12

15 Dec '12

Alon Bar-Lev <alon.barlev(a)gmail.com> writes: > Gentoo bug#405525, support not installing static libraries. Can you check if the following, simpler, patch to Makefile.in does the job (still depends on IF_STATIC, from configure, of course)? It will use the install-static and uninstall-static targets unconditionally, but they won't do anything when LIBTARGETS is empty. Regards, /Niels diff --git a/Makefile.in b/Makefile.in index c63465c..d6be465 100644 --- a/Makefile.in +++ b/Makefile.in @@ -20,8 +20,8 @@ include config.make PRE_CPPFLAGS = -I. # FIXME: Add configuration of LIBEXT? -LIBTARGETS = libnettle.a @IF_HOGWEED@ libhogweed.a -SHLIBTARGETS = $(LIBNETTLE_FORLINK) @IF_HOGWEED@ $(LIBHOGWEED_FORLINK) +LIBTARGETS = @IF_STATIC@ libnettle.a @IF_HOGWEED@ libhogweed.a +SHLIBTARGETS = @IF_SHARED@ $(LIBNETTLE_FORLINK) @IF_HOGWEED@ $(LIBHOGWEED_FORLINK) getopt_SOURCES = getopt.c getopt1.c getopt_TARGETS = $(getopt_SOURCES:.c=.$(OBJEXT)) @@ -32,7 +32,7 @@ internal_TARGETS = $(internal_SOURCES:.c=.$(OBJEXT)) TARGETS = aesdata$(EXEEXT) desdata$(EXEEXT) twofishdata$(EXEEXT) \ shadata$(EXEEXT) gcmdata$(EXEEXT) \ $(getopt_TARGETS) $(internal_TARGETS) \ - $(LIBTARGETS) @IF_SHARED@ $(SHLIBTARGETS) + $(LIBTARGETS) $(SHLIBTARGETS) IMPLICIT_TARGETS = @IF_DLL@ $(LIBNETTLE_FILE) $(LIBHOGWEED_FILE) DOCTARGETS = @IF_DOCUMENTATION@ nettle.info nettle.html nettle.pdf -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

Re: [PATCH] build: add --enable-static option
by nisse＠lysator.liu.se 15 Dec '12

15 Dec '12

Alon Bar-Lev <alon.barlev(a)gmail.com> writes: Thanks. I have one comment on the patch. > --- a/Makefile.in > +++ b/Makefile.in > @@ -21,7 +21,11 @@ include config.make > PRE_CPPFLAGS = -I. > # FIXME: Add configuration of LIBEXT? > LIBTARGETS = libnettle.a @IF_HOGWEED@ libhogweed.a > -SHLIBTARGETS = $(LIBNETTLE_FORLINK) @IF_HOGWEED@ $(LIBHOGWEED_FORLINK) > +@IF_STATIC@INSTALL_LIBTARGETS = install-static > +@IF_STATIC@UNINSTALL_LIBTARGETS = uninstall-static > +@IF_SHARED@SHLIBTARGETS = $(LIBNETTLE_FORLINK) @IF_HOGWEED@ $(LIBHOGWEED_FORLINK) > +@IF_SHARED@INSTALL_SHLIBTARGETS = install-shared-nettle @IF_HOGWEED@ install-shared-hogweed > +@IF_SHARED@UNINSTALL_SHLIBTARGETS = uninstall-shared I think I'd prefer to make the definitions unconditional, but with conditional values. E.g. UNINSTALL_SHLIBTARGETS = @IF_SHARED@ uninstall-shared rather than @IF_SHARED@UNINSTALL_SHLIBTARGETS = uninstall-shared Is there any reason that won't work? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

sha3 optimization
by nisse＠lysator.liu.se 13 Dec '12

13 Dec '12

I've spent the evening on optimizing sha3. I've written a first basic x86_64 implementation of sha3_permute, using 128-bit sse2 operations where practical, which gave a 30% speedup. And after working with the algorithm for a bit, I realized that it's fairly easy to reduce the number of passes each round makes over the data. So I tried that in the C implementation, and it gave a 20% speedup there. So now when I understand the algorithm better, I guess I'll have to rewrite the x86_64 implementation to reduce the number of passes there too. Still pretty slow, with sha3-256 at 32 cycles per byte at best. Which is far behind the claimed performance of 6-7 cycles/byte on x86_64 (close to the performance of sha1). I guess I should also have a look at that code (or does aybody on the list know which tricks are relevant?). The internal state is a 5x5 matrix of 64-bit words. If represented using 128-bit xmm registers, each row fits in two xmm registers and one regular 64-bit register. The steps which seem hardest to fit with 128-bit instructions is the permutation and rotation steps, which appear to want to treat 64-bit words individually. The current code (both C and assembly) keeps the state in memory, using double buffering, and doesn't try to fit more than one row at a time in registers. Keeping more of the state in registers is highly desirable. See http://git.lysator.liu.se/nettle/nettle/blobs/master/sha3-permute.c and http://git.lysator.liu.se/nettle/nettle/blobs/master/x86_64/sha3-permute.asm Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 2

SHA2 renaming
by nisse＠lysator.liu.se 03 Dec '12

03 Dec '12

With support for SHA3, it seems clear that nettle's naming for sha2 functions was a mistake. It should be "sha2_256", rather than "sha256". This is my current plan. Step 1 is as backwards compatible as practical, while step 2, to be taken at some later time, drops backwards compatibility. Step 1: * Split sha.h into sha1.h and sha2.h, and use the new names in sha2.h. Except for the name mangling, e.g., #define sha2_256_init nettle_sha256_init not #define sha2_256_init nettle_sha2_256_init in order to maintain ABI compatibility. * Keep sha.h for backwards compatibility. Have it include sha1.h and sha2.h, and use #define to make old names aliases for the new names. * Do a thorough rename in the implementation; use new names for all internal use of sha2, rename files, etc. * For all other interfaces where a sha2 function shows up in a name, e.g., hmac_sha256_set_key, and DSA_SHA256_MIN_P_BITS, rename for consistency and use #defines to make old names aliases. * For nettle_hash, make the new name of the struct an alias for the old, e.g., #define nettle_sha2_256 nettle_sha256 but for now do *not* change the contents of the name. I.e., nettle_sha2_256.name will still contain the string "sha256", not "sha2_256". Step 2: * Delete sha.h, and the other compatibility aliases defined elsewhere. * Do the rename also on library symbols, i.e., nettle_sha256_init -> nettle_sha2_256_init. * Change the value of the name fields of the nettle_hash objects. As far as I see, Step 1 maintains reasonably complete API and ABI compatibility. The only subtlety I'm aware of is C++ ABI compatibility for code *using* nettle, where I think struct sha256_ctx; vs struct sha2_256_ctx; #define sha256_ctx sha2_256_ctx would give different name mangling of C++ functions using arguments of this type (and not declared extern "C"). I think that is a problem that I'm going to ignore. Or do you think it is important enough to make the aliases for the struct tags the other way around? Comments? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

3 8

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 December 2012