nettle-bugs December 2013

nettle-bugs@lists.lysator.liu.se

9 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

dsa_generate_keypair
by Nikos Mavrogiannopoulos 28 Mar '14

28 Mar '14

Hello, I tried to switch gnutls to use dsa_generate_keypair() to generate primes for the DH key exchange, but unfortunately this interface has the strict DSS checks for q_bits. Would it be possible to have a dh_generate_keypair() that does the exact same thing without the q_bits and p_bits limitations? regards, Nikos

4 21

brainpool curves
by Nikos Mavrogiannopoulos 02 Feb '14

02 Feb '14

Hello, There has been lately an attempt to avoid the NIST's curves due to suspicions about their generation. One of them are the brainpool curves at: http://tools.ietf.org/html/rfc5639 which seem to be sponsored by the German BSI. Having them in nettle would be a good thing (the same authors are working on standardizing these curves in TLS and PKIX). regards, Nikos

5 7

Status of Poly1305 and use of AES-NI in Poly1305, UMAC?
by Joachim Strömbergson 22 Jan '14

22 Jan '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aloha! What is the status of Poly1305 in Nettle, i.e. is the branch ready to be merged into master or when might that happen? I have to admit that I haven't studied how UMAC and Poly1305 uses (in what phase) the block cipher. Would they gain any substantial performance if they could use AES-NI when available? - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. ======================================================================== Joachim Strömbergson Secworks AB joachim(a)secworks.se ======================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlKo3KQACgkQZoPr8HT30QH6gwCg5Ry4e20cHvqpd8MzuFNkzhC3 fisAn0olck6OFNqh6FHkvd9Kx/YKD7mn =Zn5G -----END PGP SIGNATURE-----

3 8

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

memxor3 could lead to invalid mem accesses
by Nikos Mavrogiannopoulos 16 Jan '14

16 Jan '14

Hello and best wishes for new year, I was debugging an invalid memory access in gnutls and realized that the issue is in memxor3 of nettle (2.7.x branch). I have not yet a fix for that, but the attached patch modifies the memxor-test.c to reproduce the issue. regards, Nikos $ valgrind ./memxor-test [...] ==26108== Invalid read of size 8 ==26108== at 0x4E817BD: memxor3 (memxor.s:137) ==26108== by 0x4029D8: test_main (memxor-test.c:157) ==26108== by 0x4024C6: main (testutils.c:204) ==26108== Address 0x5094498 is 104 bytes inside a block of size 111 alloc'd ==26108== at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==26108== by 0x402909: test_main (memxor-test.c:152) ==26108== by 0x4024C6: main (testutils.c:204) ==26108== ==26108==

3 9

Request to release new version of nettle to support new architecture ppc64le
by rajesh 04 Jan '14

04 Jan '14

Hi We are adding support for new ppc64le (IBM powerPC Little Endian) architecture. I was looking at the package nettle from the latest release tarball ( http://www.lysator.liu.se/~nisse/archive/nettle-2.7.1.tar.gz ) and also from the git source (git://git.lysator.liu.se/nettle/nettle.git) and it failed to build the package on ppc64le machine because of outdated config.guess. since currently available config.guess does not have support for ppc64le it fails to guess correct build type. Latest config.guess with ppc64le support is available at : http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.gues… I verified building the package with latest config.guess mentioned above and it built fine in ppc64le platform. I would also like to inform that all make check test cases successfully passed in the new platform ppc64le. Would it be possible to spin up a newer version of nettle for the distros to pick up from the upstream release tarball, which would support ppc64le. Please do let me know if you will be picking up the patches from upstream or you would require local patches to be provided. I can send out the patches to you. I can help to validate the new release of the package works well by compiling on ppc64le machine. Appreciate your response Thanks and Regards Rajeshkumar S Linux Technology Centre, IBM

2 2

acoustic cryptanalysis
by Nikos Mavrogiannopoulos 19 Dec '13

19 Dec '13

Hello, It seems that some guys managed to "listen" gnupg private keys. While some parts of the attack are gnupg specific, similar attacks could apply in nettle as well (and I guess every implementation that does RSA decryption). This could affect TLS sessions where the server is decrypting client provided ciphertext. I see on their mitigation section that "ciphertext normalization", i.e., c=c%n, avoids their key recovery attack, so given that there is no harm to have this step anyway, it would be nice to have it in nettle as well (patch attached). http://www.cs.tau.ac.il/~tromer/acoustic/ regards, Nikos

2 2

arm-neon/v6 auto-detection
by Nikos Mavrogiannopoulos 18 Dec '13

18 Dec '13

Hello, As it is now the ARM-neon and v6 optimizations are enabled when nettle is compiled on the exact system it is supposed to run. This is very unlikely to happen in some scenarios, as applications intended to run on an arm mobile (eg [0]) cannot know in advance the target. That is a petty because nettle is pretty unique in having support for assembly in ARMv6 or neon. A solution to that issue would be to have a nettle library constructor that runs the equivalent of cpuid in ARM, and stores it to a global variable. Then each assembly module (e.g., aes-arm) will jump to the correct implementation detected at runtime. This requires no global initialization functions or anything like that. In the systems where library constructors are not available (i.e., static linking), the cost would be running the oldest arm assembly version (unless the constructor is called explicitly). This is similar to what openssl is doing already (with the exception that they use a global initialization function instead of a constructor). To me that seems quite a simple way to improve the current situation. regards, Nikos [0]. https://github.com/cernekee/ics-openconnect

4 10

Building nettle in OSX
by Joachim Strömbergson 18 Dec '13

18 Dec '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aloha! (Sorry for this stupid question.) I'm trying to get nettle to build in OSX but are having some problems. If i simply do the bootstrap-configure-make I get problems in the assembly phase: <quote> /Applications/Xcode.app/Contents/Developer/usr/bin/make all-here gcc -I. -DHAVE_CONFIG_H -g -O2 -ggdb3 -Wall -W -Wmissing-prototypes - -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith - -Wbad-function-cast -Wnested-externs -fPIC -MT gcm-hash8.o -MD -MP -MF gcm-hash8.o.d -fPIC -c gcm-hash8.s gcm-hash8.s:220:18: error: unexpected token in '.section' directive .section .rodata ^ gcm-hash8.s:224:1: error: unknown directive .hword 0x0000,0xc201,0x8403,0x4602,0x0807,0xca06,0x8c04,0x4e05 ^ gcm-hash8.s:225:1: error: unknown directive .hword 0x100e,0xd20f,0x940d,0x560c,0x1809,0xda08,0x9c0a,0x5e0b ^ .... </quote> Googling I found some other people having problems: https://gist.github.com/morgant/1753095 Turning of assembly (--disable-assembler to configure) I get through the compilation, assembly, but linking fails (similarly the link above): <quote> Undefined symbols for architecture x86_64: "__nettle_aes_decrypt", referenced from: _nettle_aes_decrypt in aes-decrypt.po _nettle_aes128_decrypt in aes-decrypt.po _nettle_aes192_decrypt in aes-decrypt.po _nettle_aes256_decrypt in aes-decrypt.po "__nettle_aes_encrypt", referenced from: _nettle_aes_encrypt in aes-encrypt.po _nettle_aes128_encrypt in aes-encrypt.po _nettle_aes192_encrypt in aes-encrypt.po _nettle_aes256_encrypt in aes-encrypt.po (maybe you meant: __nettle_aes_encrypt_table) ... </quote> This is on OSX 10.9 with gcc being a wrapper around clang: Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) Target: x86_64-apple-darwin13.0.0 Thread model: posix and as being: Apple Inc version cctools-846.2.4, GNU assembler version 1.38 and ld being: @(#)PROGRAM:ld PROJECT:ld64-224.1 configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 armv6m armv7m armv7em LTO support using: LLVM version 3.3svn, from Apple Clang 5.0 (build 500.2.79) Anybody succeeding and building nettle on OSX and if so how. Being able to use the optimized assembler versions would also be good. - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. ======================================================================== Joachim Strömbergson Secworks AB joachim(a)secworks.se ======================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlKq4ZcACgkQZoPr8HT30QEy2QCffi/BpWVuYyNKV5oqFLvDlLg0 CeAAoK0VLGcek5vHcUXkMG9QPHgypl2z =a0RI -----END PGP SIGNATURE-----

3 16

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 2013