nettle-bugs

nettle-bugs@lists.lysator.liu.se

2196 discussions

rsa keygen replicability
by Daniel Kahn Gillmor 13 Jun '11

13 Jun '11

Hi Nettle folks-- I'm wondering if there's an expectation of repeatable RSA key generation across different versions of libnettle. In particular, assuming a statically-seeded PRNG (e.g. seeding with a fixed number of bytes from /dev/zero), should I be able to call rsa_generate_keypair() and have it return a predictable result, even across versions of libnettle? Obviously, replicability is *not* what you'd want for production; but for testing, it can be a very handy feature. Right now, i'm trying with a statically-seeded yarrow256_ctx PRNG against version 2.0 of nettle, and seeing a different key returned from rsa_generate_keypair() that i see with version 2.1 of nettle. Should this variation be expected? has the use of random numbers (or other parts of the algorithm) changed significantly for rsa_generate_keypair() between releases? --dkg

2 3

Re: patch to fix build of nettle on gcc-2.95 architectures
by nisse＠lysator.liu.se 08 Jun '11

08 Jun '11

"Sebastian Reitenbach" <sebastia(a)l00-bugdead-prods.de> writes: > I found nettle not compiling on openbsd sparc architecture which uses > gcc-2.95 as default compiler. Attached little patch against nettle-2.1 > fixes the compilation problem for me. Thanks, checked in now. Nettle is not supposed to rely on c99 features. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 1

memory leak fix
by Nikos Mavrogiannopoulos 21 May '11

21 May '11

The attached patch fixes a memory leak in DSA key generation. regards, Nikos

2 1

Re: Fwd: Problem with nettle 2.1 and gnutls 2.12.3 on Solaris
by nisse＠lysator.liu.se 06 May '11

06 May '11

Dagobert Michelsen <dam(a)baltic-online.de> writes: >> I am trying to compile gnutls 2.12.3 with libnettle 2.1 and get the >> following errors. From the output I assume an incompatibility between >> different gnulib inclusions. For the record, nettle does not use gnulib. It uses AX_CREATE_STDINT_H, iirc I copied that from autoconf-archive, long ago. >> "/opt/csw/include/nettle/nettle-stdint.h", line 237: identifier redeclared: gl_int_fast8_t >> current : signed char >> previous: long : "./../gl/stdint.h", line 241 This is puzzling. On Solaris, nettle-stdint.h is expected to contain /* generated using gnu compiler gcc (GCC) 3.4.5 */ #define _STDINT_HAVE_STDINT_H 1 /* ................... shortcircuit part ........................... */ #if defined HAVE_STDINT_H || defined _STDINT_HAVE_STDINT_H #include <stdint.h> #else ... lots of irrelevant stuff... #endif And there seems to be a /usr/include/stdint.h on the system I look, so I don't think it's a gcc-specific include file. What does your nettle-stdin.h look like? If it is different, something went wrong at configure time when nettle was installed.. And what is "./../gl/stdint.h", that's from gnulib? nettle-stdint.h does not refer gl_int_fast8_t as far as I can see, so I guess there's a #define int_fast8_t gl_int_fast8_t somewhere. The failures seem to all be related to the various *_fast_*_t type, where the spec leaves a lot of room for the implementation. So if different packages defines these them selves, it's not very surprising that they might have different ideas about what they should be. But in the Solaris case, the right thing is most likely to use the definitions from /usr/include/stdint.h, and *no* others. I haven't looked at gnulib, but I *hope* it has some short-circuit code like in nettle-stdint.h, to fall back to the system's stdint.h or inttypes.h if one of them exists and works. /Niels PS. Sorry the nettle-bugs list is members only, if you want to reply and are not on that list, please use my personal address instead of nettle-bugs(a)lists.lysator.liu.se. -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

Re: Serpent
by nisse＠lysator.liu.se 16 Apr '11

16 Apr '11

Simon Josefsson <simon(a)josefsson.org> writes: > nisse(a)lysator.liu.se (Niels Möller) writes: > >> Maybe you can try adding some of the testvectors at >> http://www.cs.technion.ac.il/~biham/Reports/Serpent/ to nettle and >> libgcrypt, and see what happens? (On the nettle side, I'll try to give >> that a reasonably high priority). > > As you noted privately, they fail in nettle but work in libgcrypt. A while ago, the email masquerading setup was broken on the machine where I write email. Because of this, the invalid adress nettle-bugs(a)lysator.liu.se has appeared in headers of some of my emails, and then copied into replies to those. The correct address is nettle-bugs(a)lists.lysator.liu.se. > According to Eli's page and the AES submission paper, there is Serpent-0 > and Serpent-1 and the paper discuss (page 22-23) that the key schedule > has changed. Do you think nettle's implementation is serpent-0, or is it just broken? I'm puzzled, because I'm fairly sure I got the test vectors from serpent's submission package (I could try to double check that), which if I understand correctly ought to be serpent-1. I vaguely remember I had some difficulty understanding the organization of the test data, though. And I'm sorry if you have wasted some time debugging fully correct key scheduling. > I updated the wikipedia article on this: > http://en.wikipedia.org/wiki/Serpent_%28cipher%29 Hmm, I can't find any mention of serpent-0 there? > Still, I'm not sure it is worth the time to fix Serpent in Nettle. I > suggest to remove it, that will save some code size as well. It's clearly no use to keep the current broken implementation. But I think it would be nice to have serpent, for a couple of reasons: * It's generally good to have a couple of ciphers with aes-compatible key and block sizes. Besides aes/rijndael and serpent, there's twofish and camellia. * I'm not sure what performance one can get out of serpent compared to aes, in particular on 64-bit processors. AES doesn't fit well with 64-bit operations, camellia is better in that respect but includes some awkward operations (current 64-bit code could perhaps be improved abit using larger tables). * I'd prefer to not remove existing features. If you have a half-done port of libgrypt's serpent code, maybe you or I could finish it? I'll start by looking into the test vectors, I'd like to figure out where nettle's came from, and I'd like to have a serpent-test.c including correct test vectors, even if we end up removing all other serpent code. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

5 11

Re: different lib directories for gnutls and nettle
by nisse＠lysator.liu.se 14 Apr '11

14 Apr '11

Brian Gough <bjg(a)gnu.org> writes: > Nettle should work better with other GNU packages if it follows the > GNU standards, as the assumption of lib/ as a default is a common one > in other configure scripts. I don't change the default lightly, but I still think it's the right thing to do when 1. The user has not provided --libdir explicitly. 2. One is building on a multi-abi system, which is a case where the autoconf default doesn't even try to do the right thing. 3. The autoconf default is known to be wrong. > For comparison the GMP library has ABI detection via configure but > keeps the library directory as lib/ by default. I'm reasonably familiar with the gmp configure script. It's true that it currently always uses lib/ as the default, regardless of ABI, but it's ABI related hacks can also cause other nasty surprises. So it's a good example to exhibit the complexity of the problem, but it's not currently solving it. As for linux on x86_64, it appears that debian (and derivatives, I imagine) put 64-bit libraries in lib/, while the distributions with roots in redhat (at least rhel 5 and fedora 14) and gentoo follow the fhs conventions and put 32-bit libraries in lib/. So to do the right thing, configure has to distinguish between these two cases. What a mess (but just the type of mess configure.ac is intended to help sort out). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 1

Re: different lib directories for gnutls and nettle
by nisse＠lysator.liu.se 12 Apr '11

12 Apr '11

Brian Gough <bjg(a)gnu.org> writes: > I don't know what is the correct interpretation of the FHS, but by > default all other autoconf'ed and GNU packages always use > libdir=$prefix/lib (with the --libdir option allowing it to be > overridden if someone wants to use lib64 or whatever). And the default is broken for multi-abi systems, since it means that a plain ./configure && make && make install may well overwrite a working library in /usr/local/lib with a library for a different ABI. With autoconf defaults, this will happen, e.g., if you compile on Solaris (or on some gnu/linux siystem which actually obeys the FHS), using a compiler which by default generates 64-bit code). Now, most packages are not aware of what ABI they are being compiled for, but nettle is. It has to figure it out, in order to select the right assembly files. > The distributions already have their own ways of using --libdir on > autoconf'ed packages so you don't need to worry about it yourself. I don't worry so much for distributors. To use a sane libdir default is intended to help people who compile nettle from source themselves, rather than installing their distribution's nettle package. I'd be happy to have autoconf solve this problem for me, but currently it doesn't. Library installation is a bit complex, with various workarounds. Another issue not currently solved by autoconf (nor by nettle's build system) is w*ndows dlls, which should usually be installed in bin rather than lib. I've heard that automake (or maybe it was libtool) uses the workaround to install dlls in $libdir/../bin. Which is really really ugly, but which appears to work most of the time. Autoconf simply doesn't solve everything. Finally: If the current hack doesn't work, I'd appreciate a complete bug report. What system is it? Which library directories exists (incluing symlinks)? Which directory is expected to hold libraries for which ABI? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

Re: different lib directories for gnutls and nettle
by Nikos Mavrogiannopoulos 12 Apr '11

12 Apr '11

On 03/31/2011 12:48 AM, Brian Gough wrote: > Hi, now that GNU TLS is using nettle I notice there is a difference > between the --libdir for the two packages on 64 bit. > Nettle installs to $prefix/lib64/ and GNU TLS looks for it in > $prefix/lib/ -- so it fails and the standard configure/install to a > prefix doesn't work. Indeed it seems nettle for some reason uses the /usr/lib64. Niels, is there really a reason for that? As I understand from the FHS[0] /usr/lib is the system library directory. /usr/lib64 and /usr/lib32 might not even be there. regards, Nikos [0]. http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGA…

2 1

struct nettle_cipher for weak-key ciphers
by Daniel Kahn Gillmor 01 Apr '11

01 Apr '11

hi nettle folks-- now that Crypt::Nettle seems effective and functional, i'm starting to look at using it in other systems i'm working on. Suddenly, i realize i'm missing access to 3DES and BLOWFISH, which i find i actually want :/ I'm missing them because there is no struct nettle_cipher for these algorithms (or for DES, for that matter, though i care less about DES). I seem to have a few options: 0) Crypt::Nettle could write unique interfaces to those ciphers and expose them to the user of the perl module as (for example) Crypt::Nettle::Cipher::3DES and Crypt::Nettle::Cipher::Blowfish . this breaks symmetry with the rest of the interface, though. 1) Crypt::Nettle could create its own struct nettle_cipher objects for these ciphers, wrapping the weak key checking in some code of that belongs to the perl module 2) I could propose that nettle to create struct nettle_cipher objects for these ciphers directly. I prefer (1) or (2) because they'll keep a simple interface for Crypt::Nettle. I'm not sure how to do (2) without breaking ABI in nettle somehow (or losing the weak-key error checking). But going with option (1) seems likely to cause code duplication in any other higher-level bindings that use the struct nettle_cipher objects to present a normalized interface. Any thoughts on how i should proceed? I can certainly do (1) independently of libnettle itself, but if there's a way to handle (2) more cleanly than i've been able to imagine thus far, i'd be happy to hear about it. Or, am i barking up the wrong tree entirely? I'm imagining (for example) a user who has in their possession a symmetrically-encrypted message that they happen to know the key for. The cipher used was one of the "weak-key" ciphers, and it's even possible that the key is in fact a weak key. The user should still be able to decrypt the message using Crypt::Nettle (or any other binding). --dkg

3 8

weak-key ciphers and arcfour
by Daniel Kahn Gillmor 29 Mar '11

29 Mar '11

hi nettle folks-- the nettle docs say: > In Nettle, most key setup functions have no return value, but > for ciphers with weak keys, the return value indicates whether or not > the given key is weak. [...] > A problem is that the key > setup of ARCFOUR is quite weak, you should never use keys with > structure, keys that are ordinary passwords, or sequences of keys like > ``secret:1'', ``secret:2'', ... [...] > void arcfour_set_key (struct arcfour_ctx *ctx, unsigned length, const uint8_t *key) > Initialize the cipher. The same function is used for both encryption and > decryption. Put together, these three statements seem contradictory. If arcfour has weak keys, shouldn't arcfour_set_key return an int indicating whether the key is considered weak (like the key setup functions for BLOWFISH, DES, and DES3 do)? Is the problem that there is no clear way to determine if an arcfour key is weak? --dkg

3 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