nettle-bugs

nettle-bugs@lists.lysator.liu.se

2219 discussions

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

nettle haskell bindings
by Daniel Kahn Gillmor 08 Jan '14

08 Jan '14

hi nettle folks-- The list of language bindings at: http://www.lysator.liu.se/~nisse/nettle/ doesn't mention haskell yet, but Clint Adams' nettle bindings for that language are available here: http://hackage.haskell.org/package/bindings-nettle They're not exhaustive, but probably worth pointing to. Thanks for nettle! --dkg

3 4

Valgrind for side channel testing
by Joachim Strömbergson 07 Jan '14

07 Jan '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aloha! Related to Valgrind - Adam Langley has created ctgrind - a way to use Valgrind to test for timing based side channels: https://github.com/agl/ctgrind Dunno if you have tested it on Nettle Niels or if it is even applicable. Just wanted to mention it. - -- 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/ iEYEARECAAYFAlLKsiQACgkQZoPr8HT30QFmDwCgnt4T0T2WTYHSoO9GPSVAycPE G68An3w4JSe0w1Padn2v6E4TXYhytNXe =VX0C -----END PGP SIGNATURE-----

2 1

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 05 Jan '14

05 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 05 Jan '14

05 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 04 Jan '14

04 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 04 Jan '14

04 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

Jump to page:

2026

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