nettle-bugs

nettle-bugs@lists.lysator.liu.se

1 participants
2200 discussions

[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

umac
by nisse＠lysator.liu.se 12 Apr '13

12 Apr '13

I have now read the UMAC spec (RFC 4418) a bit more carefully. I haven't yet read Niko's code (or any other code, for that matter). Some thoughts: o I don't like the way endian conversion is done in the spec. I'd prefer to think about the various functions as operating on arrays of 32-bit words, and implementation should use integer types of the right size to get correct alignment etc. o The "NH" function looks like a candidate for for assembly implementation. I don't know if there's anything else in the algorithm which really is performance critical? (And here we get a contradiction to point (1), it may be best for performance to have the NH function get the unaligned byte array as input, do be able to use assembly tricks when reading it into integers. Anyway, we should really avoid byte arrays in the internal interfaces between L1/L2/L3). o *Maybe* optimization of the L2 and L3 hashes will be important. Profiling is needed, I guess, and they should be optimized *after* L1/NH. o Since I have been work with side-channel silence recently, it seems natural to try to make the POLY function silent, On the other hand, I'm not sure what the threats are. If the MAC is applied to a secret message, we may leak some information about the message, I guess? o I think we ought to handle large messages correctly, which means we need the POLY function also over the 128-bit prime. Performance is not terribly important, at least not initially. o I'm not sure exactly how the building blocks fit together, but we should strive for pipelining. When we have the first message block M_1, apply L1 to that block, then apply L2 and L3 to the output as soon as possible. And for the larger tag lengths, also try to make that looping inside the loop processing the sequence of message blocks, so we can discard M_1 before starting to work on the next block M_2. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

3 20

Building on AIX 6.1
by Perry Smith 10 Apr '13

10 Apr '13

Hi Guys, I got libnettle to build on AIX 6.1 but I had to edit the Makefile.in and the configure.ac file. Editing the configure.ac is fine. But I had to change the make rules so the shared library depended upon nettle_OBJS instead of nettle_PURE_OBJS. I *think* (but I'm not sure) that the .po suffix confuses the linker. It appears as if it was just ignoring all the .po files. I'm happy to post my diffs but they may not help much. I've never seen "pure" objects before. Is this really a useful concept? Thank you, Perry

2 4

Re: [PATCH] sha3: Correct _sha3_update for incremental hashing
by nisse＠lysator.liu.se 06 Apr '13

06 Apr '13

edgar.iglesias(a)gmail.com writes: > diff --git a/sha3.c b/sha3.c > index d7aec46..21e7beb 100644 > --- a/sha3.c > +++ b/sha3.c > @@ -61,7 +61,7 @@ _sha3_update (struct sha3_state *state, > if (pos > 0) > { > unsigned left = block_size - pos; > - if (length < pos) > + if (length < left) > { > memcpy (block + pos, data, length); > return pos + length; Thanks, checked in now. Unfortunately, testutils.c:test_hash doesn't exercise this logic. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

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