nettle-bugs April 2013

nettle-bugs@lists.lysator.liu.se

10 participants
20 discussions

[PATCH 1/5] Don't include OPT_ASM_SOURCES twice in hogweed_PURE_OBJS
by Martin Storsjö 24 Aug '14

24 Aug '14

OPT_ASM_SOURCES is already included via hogweed_OBJS. This avoids build errors about duplicate symbols in the shared library. --- Makefile.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.in b/Makefile.in index 1ec807b..2db76c5 100644 --- a/Makefile.in +++ b/Makefile.in @@ -180,7 +180,7 @@ nettle_OBJS = $(nettle_SOURCES:.c=.$(OBJEXT)) $(LIBOBJS) nettle_PURE_OBJS = $(nettle_OBJS:.$(OBJEXT)=.p$(OBJEXT)) hogweed_OBJS = $(hogweed_SOURCES:.c=.$(OBJEXT)) $(OPT_ASM_SOURCES:.asm=.$(OBJEXT)) -hogweed_PURE_OBJS = $(hogweed_OBJS:.$(OBJEXT)=.p$(OBJEXT)) $(OPT_ASM_SOURCES:.asm=.p$(OBJEXT)) +hogweed_PURE_OBJS = $(hogweed_OBJS:.$(OBJEXT)=.p$(OBJEXT)) libnettle.a: $(nettle_OBJS) -rm -f $@ -- 1.7.9.4

5 29

Release plans
by nisse＠lysator.liu.se 22 Jan '14

22 Jan '14

I have updated the release plans, at http://www.lysator.liu.se/~nisse/nettle/plan.html. I aim to get a release out within a month or two. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

3 26

raspberry pi
by nisse＠lysator.liu.se 30 Apr '13

30 Apr '13

I finally got a Raspberry Pi setup. Took almost 20 minutes to compile nettle, and the configure script figured out not to use neon instructions. It passes the testsuite. Benchmark for the public key functions: name size sign/ms verify/ms rsa 1024 0.1073 1.9099 rsa 2048 0.0167 0.5539 dsa 1024 0.1992 0.1014 ecdsa 192 0.5297 0.1922 ecdsa 224 0.3623 0.1354 ecdsa 256 0.2621 0.0971 ecdsa 384 0.1125 0.0391 ecdsa 521 0.0551 0.0190 So 3 to 5 times slower than the pandaboard (although that's not a completely fair comparison, since the raspberry pi is using gmp-5.0.5, not the gmp bleeding edge). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

Problems when compiling 32bit version on 64bit host (multilib)
by Florian Pritz 27 Apr '13

27 Apr '13

Hi, I'm compiling nettle for the Arch Linux multilib repository (32bit libraries for a 64bit system so people can run skype and wine without needing a chroot). Looks like the new ecc code doesn't properly handle integer type sizes. Here[1] is the output of make, make check along with the PKGBUILD used to build this and a sample of the generated ecc-*.h files. [1]: http://flo.server-speed.net/tmp/lib32-nettle/ Can I fix that by setting some env variable or does it need code changes? If you need any more files, please tell me.

2 2

ANNOUNCE: Nettle-2.7
by nisse＠lysator.liu.se 24 Apr '13

24 Apr '13

I'm happy to annnounce 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/. NEWS for the 2.7 release 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. http://ftp.gnu.org/gnu/nettle/nettle-2.7.tar.gz ftp://ftp.gnu.org/gnu/nettle/nettle-2.7.tar.gz http://www.lysator.liu.se/~nisse/archive/nettle-2.7.tar.gz ftp://ftp.lysator.liu.se/pub/security/lsh/nettle-2.7.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.

1 0

nettle-2.7 release candidate
by nisse＠lysator.liu.se 24 Apr '13

24 Apr '13

I've generated a release candidate, available at http://www.lysator.liu.se/~nisse/archive/nettle-2.7rc1.tar.gz Testing appreciated. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 9

[PATCH 1/2] sha: Add the missing W64_EXIT epilogue macro
by Martin Storsjö 23 Apr '13

23 Apr '13

--- x86_64/sha256-compress.asm | 1 + x86_64/sha512-compress.asm | 1 + 2 files changed, 2 insertions(+) diff --git a/x86_64/sha256-compress.asm b/x86_64/sha256-compress.asm index 6bfb7a7..385654c 100644 --- a/x86_64/sha256-compress.asm +++ b/x86_64/sha256-compress.asm @@ -192,5 +192,6 @@ PROLOGUE(_nettle_sha256_compress) mov 112(%rsp),%r15 add $120, %rsp + W64_EXIT(3, 0) ret EPILOGUE(_nettle_sha256_compress) diff --git a/x86_64/sha512-compress.asm b/x86_64/sha512-compress.asm index 21df82a..663e68e 100644 --- a/x86_64/sha512-compress.asm +++ b/x86_64/sha512-compress.asm @@ -192,5 +192,6 @@ PROLOGUE(_nettle_sha512_compress) mov 176(%rsp),%r15 add $184, %rsp + W64_EXIT(3, 0) ret EPILOGUE(_nettle_sha512_compress) -- 1.7.9.5

1 1

[PATCH 1/2] Use movdqu instead of movdqa for saving xmm registers
by Martin Storsjö 23 Apr '13

23 Apr '13

The stack is not guaranteed to be 16-byte aligned on win64. --- x86_64/machine.m4 | 40 ++++++++++++++++++++-------------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/x86_64/machine.m4 b/x86_64/machine.m4 index dc23dde..d5d5b37 100644 --- a/x86_64/machine.m4 +++ b/x86_64/machine.m4 @@ -71,34 +71,34 @@ define(<W64_ENTRY>, < ifelse(W64_ABI,yes,[ ifelse(eval($2 > 6), 1, [ sub [$]eval(8 + 16*($2 - 6)), %rsp - movdqa %xmm6, 0(%rsp) + movdqu %xmm6, 0(%rsp) ]) ifelse(eval($2 > 7), 1, [ - movdqa %xmm7, 16(%rsp) + movdqu %xmm7, 16(%rsp) ]) ifelse(eval($2 > 8), 1, [ - movdqa %xmm8, 32(%rsp) + movdqu %xmm8, 32(%rsp) ]) ifelse(eval($2 > 9), 1, [ - movdqa %xmm9, 48(%rsp) + movdqu %xmm9, 48(%rsp) ]) ifelse(eval($2 > 10), 1, [ - movdqa %xmm10, 64(%rsp) + movdqu %xmm10, 64(%rsp) ]) ifelse(eval($2 > 11), 1, [ - movdqa %xmm11, 80(%rsp) + movdqu %xmm11, 80(%rsp) ]) ifelse(eval($2 > 12), 1, [ - movdqa %xmm12, 96(%rsp) + movdqu %xmm12, 96(%rsp) ]) ifelse(eval($2 > 13), 1, [ - movdqa %xmm13, 112(%rsp) + movdqu %xmm13, 112(%rsp) ]) ifelse(eval($2 > 14), 1, [ - movdqa %xmm14, 128(%rsp) + movdqu %xmm14, 128(%rsp) ]) ifelse(eval($2 > 15), 1, [ - movdqa %xmm15, 144(%rsp) + movdqu %xmm15, 144(%rsp) ]) ifelse(eval($1 >= 1), 1, [ push %rdi @@ -133,34 +133,34 @@ define(<W64_EXIT>, < pop %rdi ]) ifelse(eval($2 > 15), 1, [ - movdqa 144(%rsp), %xmm15 + movdqu 144(%rsp), %xmm15 ]) ifelse(eval($2 > 14), 1, [ - movdqa 128(%rsp), %xmm14 + movdqu 128(%rsp), %xmm14 ]) ifelse(eval($2 > 13), 1, [ - movdqa 112(%rsp), %xmm13 + movdqu 112(%rsp), %xmm13 ]) ifelse(eval($2 > 12), 1, [ - movdqa 96(%rsp), %xmm12 + movdqu 96(%rsp), %xmm12 ]) ifelse(eval($2 > 11), 1, [ - movdqa 80(%rsp), %xmm11 + movdqu 80(%rsp), %xmm11 ]) ifelse(eval($2 > 10), 1, [ - movdqa 64(%rsp), %xmm10 + movdqu 64(%rsp), %xmm10 ]) ifelse(eval($2 > 9), 1, [ - movdqa 48(%rsp), %xmm9 + movdqu 48(%rsp), %xmm9 ]) ifelse(eval($2 > 8), 1, [ - movdqa 32(%rsp), %xmm8 + movdqu 32(%rsp), %xmm8 ]) ifelse(eval($2 > 7), 1, [ - movdqa 16(%rsp), %xmm7 + movdqu 16(%rsp), %xmm7 ]) ifelse(eval($2 > 6), 1, [ - movdqa 0(%rsp), %xmm6 + movdqu 0(%rsp), %xmm6 add [$]eval(8 + 16*($2 - 6)), %rsp ]) ]) -- 1.7.9.5

1 1

[PATCH 1/2] Consistently use EXEEXT_FOR_BUILD
by Martin Storsjö 23 Apr '13

23 Apr '13

This fixes cross building for cases where EXEEXT differs from EXEEXT_FOR_BUILD, such as when building for windows from unix. --- Makefile.in | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/Makefile.in b/Makefile.in index c96e3a3..cbc001c 100644 --- a/Makefile.in +++ b/Makefile.in @@ -31,8 +31,9 @@ getopt_TARGETS = $(getopt_SOURCES:.c=.$(OBJEXT)) internal_SOURCES = nettle-internal.c internal_TARGETS = $(internal_SOURCES:.c=.$(OBJEXT)) -TARGETS = aesdata$(EXEEXT) desdata$(EXEEXT) twofishdata$(EXEEXT) \ - shadata$(EXEEXT) gcmdata$(EXEEXT) \ +TARGETS = aesdata$(EXEEXT_FOR_BUILD) desdata$(EXEEXT_FOR_BUILD) \ + twofishdata$(EXEEXT_FOR_BUILD) shadata$(EXEEXT_FOR_BUILD) \ + gcmdata$(EXEEXT_FOR_BUILD) \ $(getopt_TARGETS) $(internal_TARGETS) \ $(LIBTARGETS) $(SHLIBTARGETS) IMPLICIT_TARGETS = @IF_DLL@ $(LIBNETTLE_FILE) $(LIBHOGWEED_FILE) @@ -273,7 +274,7 @@ des.$(OBJEXT): des.c des.h $(des_headers) # k = 7, c = 6, 320 entries, ~15 KB # k = 9, c = 7, 512 entries, ~24 KB ecc-192.h: eccdata.stamp - ./eccdata$(EXEEXT) 192 7 6 $(GMP_NUMB_BITS) > $@T && mv $@T $@ + ./eccdata$(EXEEXT_FOR_BUILD) 192 7 6 $(GMP_NUMB_BITS) > $@T && mv $@T $@ # Some possible choices for 224: # k = 18, c = 4, 64 entries, ~4 KB # k = 24, c = 6, 128 entries, ~8 KB @@ -281,7 +282,7 @@ ecc-192.h: eccdata.stamp # k = 8, c = 6, 320 entries, ~20 KB # k = 10, c = 7, 512 entries, ~32 KB ecc-224.h: eccdata.stamp - ./eccdata$(EXEEXT) 224 12 6 $(GMP_NUMB_BITS) > $@T && mv $@T $@ + ./eccdata$(EXEEXT_FOR_BUILD) 224 12 6 $(GMP_NUMB_BITS) > $@T && mv $@T $@ # Some possible choices for 256: # k = 20, c = 4, 64 entries, ~4 KB # k = 27, c = 6, 128 entries, ~8 KB @@ -289,7 +290,7 @@ ecc-224.h: eccdata.stamp # k = 9, c = 6, 320 entries, ~20 KB # k = 12, c = 7, 512 entries, ~32 KB ecc-256.h: eccdata.stamp - ./eccdata$(EXEEXT) 256 14 6 $(GMP_NUMB_BITS) > $@T && mv $@T $@ + ./eccdata$(EXEEXT_FOR_BUILD) 256 14 6 $(GMP_NUMB_BITS) > $@T && mv $@T $@ # Some possible choices for 384: # k = 31, c = 4, 64 entries, ~6 KB # k = 41, c = 6, 128 entries, ~12 KB @@ -297,7 +298,7 @@ ecc-256.h: eccdata.stamp # k = 14, c = 6, 320 entries, ~30 KB # k = 18, c = 7, 512 entries, ~48 KB ecc-384.h: eccdata.stamp - ./eccdata$(EXEEXT) 384 41 6 $(GMP_NUMB_BITS) > $@T && mv $@T $@ + ./eccdata$(EXEEXT_FOR_BUILD) 384 41 6 $(GMP_NUMB_BITS) > $@T && mv $@T $@ # Some possible choices for 521: # k = 42, c = 4, 64 entries, ~9 KB # k = 56, c = 6, 128 entries, ~18 KB @@ -305,10 +306,10 @@ ecc-384.h: eccdata.stamp # k = 19, c = 6, 320 entries, ~44 KB # k = 24, c = 7, 512 entries, ~70 KB ecc-521.h: eccdata.stamp - ./eccdata$(EXEEXT) 521 56 6 $(GMP_NUMB_BITS) > $@T && mv $@T $@ + ./eccdata$(EXEEXT_FOR_BUILD) 521 56 6 $(GMP_NUMB_BITS) > $@T && mv $@T $@ eccdata.stamp: eccdata.c - $(MAKE) eccdata$(EXEEXT) + $(MAKE) eccdata$(EXEEXT_FOR_BUILD) echo stamp > eccdata.stamp ecc-192.$(OBJEXT): ecc-192.h @@ -575,7 +576,7 @@ distcheck: dist clean-here: -rm -f $(TARGETS) $(IMPLICIT_TARGETS) *.$(OBJEXT) *.p$(OBJEXT) *.s \ ecc-192.h ecc-224.h ecc-256.h ecc-384.h ecc-521.h \ - eccdata$(EXEEXT) eccdata.stamp + eccdata$(EXEEXT_FOR_BUILD) eccdata.stamp -rm -rf .lib distclean-here: clean-here -- 1.7.9.4

1 1

ARM/NEON optimizations
by Martin Storsjö 21 Apr '13

21 Apr '13

Hi, Before the upcoming(?) release, it might be good to tweak the way the NEON optimizations are enabled. Currently, as far as I've seen, they're enabled as soon as you target ARMv7, even if not all ARMv7 CPUs have NEON. I've seen that you've discussed this on the GMP list a few times as well. For static detection in configure, one way is to check whether the assembler can do the neon instructions without actually adding the ".fpu neon" line. If this succeeds, the compiler/assembler is configured with -mfpu=neon, and we can freely use neon instructions wherever. Since there's AFAIK no runtime detection for anything else in nettle so far (nor any state or global variables), I guess you're not going to add it anytime soon - for that case, detecting it statically in configure based on the target configuration is probably good enough. Anyway, for reference on the topic of runtime detection (which is necessary e.g. on Android ARMv7, which explicitly supports a number of ARMv7 devices without NEON), there's a number of ways of doing it. One way that was mentioned on the gmp mailing list was using getauxval from glibc. This obviously isn't available on non-glibc platforms such as Android (or other platforms as well). On general linux, one pretty straightforward way is to parse /proc/self/auxv (which is pretty well structured), the other is parsing /proc/cpuinfo (which requires a little bit more code to parse). The Android NDK comes with a small support library that detects cpu extensions - previously it used to parse /proc/self/auxv, but in recent Android versions this file isn't accessible within release mode processes, so now it parses /proc/cpuinfo. See http://git.libav.org/?p=libav.git;a=blob;f=libavutil/arm/cpu.c or https://android.googlesource.com/platform/ndk/+/a92ba07e8abf397e74285e90d08… for examples on how to parse these files. A third option is to allow the caller to set it, so the caller can use whatever runtime detection that is available on the app level and configure the library accordingly. But this both goes against the design of nettle, and additionally isn't too useful when nettle in many cases is used indirectly via a number of other libraries, and the calling app might not even know much about what lower level libraries are used. // Martin

3 6

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 April 2013