nettle-bugs

nettle-bugs@lists.lysator.liu.se

1 participants
2193 discussions

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

Support for via quadcore SHA512 hw acceleration‏
by Shaun Murphy 21 Apr '13

21 Apr '13

The limited literature for the newer VIA QuadCore E-Series embedded platform says that it now supports "Secure Hash Algorithm: SHA-1, SHA-256, SHA-384, SHA-512" but I'm not seeing any acceleration for SHA512 in the kernel modules or nettle / gnutls. I would appreciate some pointers on what I need to do to access that SHA512 acceleration in nettle. Here's my setup:Via Artigo A1250 Ubuntu 12.04 x86_64Gnutls - built from git Nettle - built from 2.6 source Kernel modules: padlock_aes, padlock_sha Here's my dmesg output for the loaded modules:[ 2.345061] padlock_aes: Using VIA PadLock ACE for AES algorithm.[ 2.364105] padlock_sha: Using VIA PadLock ACE for SHA1/SHA256 algorithms. gnutls Benchmark Soft Ciphers:Checking SHA1 (16kb payload)... Processed 464.73 MB in 5.00 secs: 92.95 MB/secChecking SHA256 (16kb payload)... Processed 180.04 MB in 5.00 secs: 36.01 MB/secChecking SHA512 (16kb payload)... Processed 267.39 MB in 5.00 secs: 53.48 MB/sec gnutls Benchmark Ciphers:Checking SHA1 (16kb payload)... Processed 1.51 GB in 5.00 secs: 0.30 GB/secChecking SHA256 (16kb payload)... Processed 1.30 GB in 5.00 secs: 0.26 GB/secChecking SHA512 (16kb payload)... Processed 267.45 MB in 5.00 secs: 53.49 MB/sec The SHA256 numbers are great but I really need SHA512 for my application. Thank you.

2 1

[PATCH] Fix a typo in a comment
by Martin Storsjö 18 Apr '13

18 Apr '13

--- aclocal.m4 | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/aclocal.m4 b/aclocal.m4 index 0d24fc2..98b399b 100644 --- a/aclocal.m4 +++ b/aclocal.m4 @@ -610,8 +610,8 @@ AC_SUBST(EXEEXT_FOR_BUILD,$gmp_cv_prog_exeext_for_build) dnl NETTLE_CHECK_ARM_NEON dnl --------------------- -dnl Check if ARM Neon instructinos should be used. -dnl Obeys enable_arn_neon, which should be set earlier. +dnl Check if ARM Neon instructions should be used. +dnl Obeys enable_arm_neon, which should be set earlier. AC_DEFUN([NETTLE_CHECK_ARM_NEON], [if test "$enable_arm_neon" = auto ; then if test "$cross_compiling" = yes ; then -- 1.7.9.4

1 0

rename of salsa20r12
by Nikos Mavrogiannopoulos 17 Apr '13

17 Apr '13

The attached patch renames the salsa20r12_crypt function to estream_salsa20_crypt(), and adds it in the benchmarks. What is missing is an equivalent of x86_64/salsa20-crypt.asm for the estream variant. regards, Nikos

2 4

Micro optimizations of the umac context structs
by nisse＠lysator.liu.se 16 Apr '13

16 Apr '13

Speaking of umac, I'm also looking at the umac context structs, for potential micro optimizations and fixes before it becomes a part of the ABI. Some fields, like nonce_length, index, and (for umac32 and umac64) nonce_low, fit in 16 or even 8 bits. So it might make sense to make them adjacent. And on the other hand, the umac block count is currently unsigned, and will wraparound after 2*32 blocks or 2^42 bytes. Other hash functions typically support data sizes up to 2^64 (except sha512 which uses a 128-bit coutner, which seems gross overkill). For umac, the block counter is only needed to keep track of when to switch to different layer 2 hashing, and to keep track of odd and even blocks for poly128. So it could probably be made to work with only 16 bits and some saturation logic. But extending it to 64 bits seems simpler. It would also be nice if we could force 16-byte alignment for the l1_key array (this is important for assembly routines), which would them imply 16-byte alignment for the complete context struct. Could help x86 sse2 assembly. And could help also on ARM, but I'm not sure if the system (primarily linker and malloc) really makes 16-byte alignment possible there. And it would also be good to get a reasonably large alignment for the block buffer. In gcc, there's __attribute__ ((aligned (16))), but since this gets part of the ABI, we can't use it in public headers unless we can specify the same alignment for *all* reasonable compilers for the given architecture. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 5

Internal vs installed headers
by nisse＠lysator.liu.se 16 Apr '13

16 Apr '13

I'm considering moving some macros from macros.h (installad as <nettle/macros.h>) to nettle-internal.h (not installed). Only the various READ, WRITE and ROTL macros seem generally useful. Comments? I'm also looking at the current umac.h. It could be split into umac.h and umac-internal.h, but I'm not sure that's needed; the "internal" definitions are reasonably clean and seem unlikely to cause problems. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 3

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