nettle-bugs

nettle-bugs@lists.lysator.liu.se

2196 discussions

Nits: Sorted sources in Makefile.in
by Joachim Strömbergson 05 Jan '14

05 Jan '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aloha! (Don't know if this is anything you want to fix Niels.) While working on the integration of chacha into Nettle i noticed that the source files listed in Makefile.in are alphabetically sorted. At least almost. Here is a patch that sorts the nettle_SOURCES. - -- 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/ iEYEARECAAYFAlLJISIACgkQZoPr8HT30QFgTgCgmJ8OlJlK15if2x3eYPABuVHu fhcAn2wVaUIl60cpD8aTpdEHKbUsClIe =fyP1 -----END PGP SIGNATURE-----

1 0

Improved valgrind testing
by nisse＠lysator.liu.se 04 Jan '14

04 Jan '14

I've now added a configure test for valgrind/memcheck.h, and I've added code to testsuite/memxor-test.c to use valgrind client requests to tell it the start and end of the src and dst areas. I've also added the flag --partial-loads-ok=yes to the VALGRIND variable in testsuite/Makefile.in. I usually run valgrind with the invocation make check EMULATOR='$(VALGRIND)' Without that flag, I get tons of warnings for both x86_64/memxor.asm and memxor.c. It would make sense to add similar client requests to more testcases. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

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

Minor nits/comments on sha256.c
by Joachim Strömbergson 03 Jan '14

03 Jan '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aloha! I took a look at the code in sha256.c and have a couple of small comments. (1) The K table is not zero extended. This just makes the table look weird: K[64] = { 0x428a2f98UL, 0x71374491UL, 0xb5c0fbcfUL, 0xe9b5dba5UL, 0x3956c25bUL, 0x59f111f1UL, 0x923f82a4UL, 0xab1c5ed5UL, 0xd807aa98UL, 0x12835b01UL, 0x243185beUL, 0x550c7dc3UL, 0x72be5d74UL, 0x80deb1feUL, 0x9bdc06a7UL, 0xc19bf174UL, 0xe49b69c1UL, 0xefbe4786UL, 0xfc19dc6UL, 0x240ca1ccUL, 0x2de92c6fUL, 0x4a7484aaUL, 0x5cb0a9dcUL, 0x76f988daUL, 0x983e5152UL, 0xa831c66dUL, 0xb00327c8UL, 0xbf597fc7UL, 0xc6e00bf3UL, 0xd5a79147UL, 0x6ca6351UL, 0x14292967UL, 0x27b70a85UL, 0x2e1b2138UL, 0x4d2c6dfcUL, 0x53380d13UL, 0x650a7354UL, 0x766a0abbUL, 0x81c2c92eUL, 0x92722c85UL, 0xa2bfe8a1UL, 0xa81a664bUL, 0xc24b8b70UL, 0xc76c51a3UL, 0xd192e819UL, 0xd6990624UL, 0xf40e3585UL, 0x106aa070UL, 0x19a4c116UL, 0x1e376c08UL, 0x2748774cUL, 0x34b0bcb5UL, 0x391c0cb3UL, 0x4ed8aa4aUL, 0x5b9cca4fUL, 0x682e6ff3UL, 0x748f82eeUL, 0x78a5636fUL, 0x84c87814UL, 0x8cc70208UL, 0x90befffaUL, 0xa4506cebUL, 0xbef9a3f7UL, 0xc67178f2UL, }; I would suggest zero extending the table to get the same textual width of all elements. (2) Pretty cool that you actually generate the constants from the FIPS 180 specification! Good verification. (3) The SHA-224 H0-table refers to the _SHA256_DIGEST_LENGTH. This imho should be a separate define _SHA224_DIGEST_LENGTH. Yes, it is the same length in practice but it looks weird esp since the generated digest for SHA-224 is in fact not the same even though the internal diget state vector H is the same length as SHA-256. (4) I'll think I'm going to ask on the SHA-3 maillist (hosted by NIST) if John Kelsey & Co can provide an explanation for the H0-constants used in SHA-224 and SHA-1 in the same way as for SHA-256, SHA-512 etc. It really is a bit peculiar that they don't. - -- 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/ iEYEARECAAYFAlLG28UACgkQZoPr8HT30QFslACgobq4tXi1dzRao/QIu4/tEUPG ev0An2Mul1IqawWz1mRAQq26i8UNeizX =NxwW -----END PGP SIGNATURE-----

2 4

Regarding the nettle release plan page
by Joachim Strömbergson 03 Jan '14

03 Jan '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aloha! Really good with the release plan page for Nettle: http://www.lysator.liu.se/~nisse/nettle/plan.html A few (bikeshed) comments etc. (1) I would suggest not using colors as distinguisher for what is done (green), what is critical for the release (red) and what is nice to have (grayish). I would instead suggest having subsections with explicit headers stating this instead (done, important, nice to have). Colors are harder to parse and esp red-green is bad when dealing with a lot of male individuals. (2) How about putting up an estimated release schedule at the top of the page. For example such as: - - 2014-01-xx: Feature freeze for 2.8 (branch date) - - 2014-02-xx: Testing and bug fix completed. - - 2014-03-xx: 2.8 RC1 - - 2014-04-xx: 2.8 Released (label date) (I have no idea what release schedule you in fact have in mind - if it is 4 days, 4 weeks of 4 months to do the release.) (3) I'll try and work on the chacha support files the next weeks. (4) I'm prepared to do the darwin testing on OSX 10.9.x - -- 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/ iEYEARECAAYFAlLG110ACgkQZoPr8HT30QGbXACgpU2K0VxrKfQkZUoUVXfdLEed CVgAn0UF6IpAEf8+waGIocrp50NH/El/ =rwsu -----END PGP SIGNATURE-----

2 1

Using side-channel silent GMP functions
by nisse＠lysator.liu.se 03 Jan '14

03 Jan '14

For the next release of GMP, there will be some new public functions for side-channel silent computations, as part of the low-level "mpn" interface. I think it would make sense to rewrite the RSA and DSA private key operations to use side-channel silent functions. This might require further interface changes; I haven't really looked into it yet, so I don't know to which degree backwards compatibility can be kept. I also don't yet know if it's practical to make use of the new functions optional, or if it will make the latest GMP a strict requirement (unless Nettle's public key support is completely disabled). What do you think? Relatedly, I've updated the release plan on http://www.lysator.liu.se/~nisse/nettle/plan.html. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 1

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

Mentioning of .bootstrap in INSTALL?
by Joachim Strömbergson 17 Dec '13

17 Dec '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aloha! Cloned nettle and noticed that INSTALL states: "Briefly, the shell commands `./configure; make; make install' should configure, build, and install this package." But at least in the repo there is only a config.ac and you need to run the .bootstrap shell script in order to invoke autoconf and autoheaders in order to get the configure script. Shouldn't INSTALL mention this? - -- 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/ iEYEARECAAYFAlKq2LgACgkQZoPr8HT30QEIbACfWjUuo8IAbigziPGwnw4Pbmx5 P8cAni2UtPVOqH52XlBlZmmsGnRfNz7L =ioBH -----END PGP SIGNATURE-----

2 4

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