nettle-bugs

nettle-bugs@lists.lysator.liu.se

1 participants
2200 discussions

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

developing nettle with git
by Daniel Kahn Gillmor 29 Mar '11

29 Mar '11

hi folks-- I'm managing my nettle work via git. I've extracted the cvs history of the upstream repo (nettle-only -- i'd rather not deal with all of lsh) and imported it into git. OF at all possible I plan to keep the "origin" branch up-to-date with the upstream CVS. Anyone who prefers to use git is welcome to use my repo as a jumping off point so you don't have to hassle with git cvsimport yourself. You can find it here: git clone git://lair.fifthhorseman.net/~dkg/nettle I would be happy to have nettle sources tracked as a separate project from lsh, just to make it easier for people to hack on it. Niels, if you want to consider transitioning nettle sources out of the the lsh repository and into something like git (or any other dvcs), i'd be happy to help you do that. Regards, --dkg

5 14

making algorithms in nettle dynamically enumerable
by Daniel Kahn Gillmor 23 Mar '11

23 Mar '11

Hi Nettle folks-- In the course of writing Crypt::Nettle, it occurs to me that i'm going to need to update the list of available ciphers and digests for each new version of nettle that comes out. This also means that newer versions of the perl bindings won't work by default against older versions of libnettle, which seems like it might make the perl bindings less useful for people who are stuck (for whatever reason) with an older version of libnettle. The attached patch would present an interface to dynamically enumerate the available ciphers and digest algorithms (and armor methods) supported by the current version of libnettle. bindings built against this meta-interface wouldn't need to be closely tied to any particular version of nettle, and so could be both forward- and backward-compatible. I'd be happy with any other interface that would give me the same effect, of course, and i'm not convinced that this is the best way to do it -- it just seemed the simplest in the current implementation. It would also be nice to make a similar interface to genericize cipher modes (ECB, CBC, CTR, and GCM), if that's possible; i'm not sure what the best approach is for doing that. Feedback welcome, of course. --dkg

3 12

typo in manual for arctwo
by Daniel Kahn Gillmor 21 Mar '11

21 Mar '11

Hi Nettle folks-- There's a typo in the Nettle manual about the ARCTWO block size. the attached patch (against 2.1) should fix it. Of course, it might already be fixed on the development trunk. Is there a public revision control system for nettle someplace i can look at? --dkg PS i sent this message earlier PGP/MIME-signed, but it was rejected by the mailing list with "After content filtering, the message was empty" -- could the content filtering be relaxed a little bit to allow multipart/signed messages? The message MIME structure looked like this: └┬╴multipart/signed ├┬╴multipart/mixed │├╴text/plain │└╴text/x-diff attachment └╴application/pgp-signature attachment I then tried re-sending it without the cryptographic signature, which produced a message like this: └┬╴multipart/mixed ├╴text/plain └╴text/x-diff attachment This second message was rejected with the message: "The message's content type was not explicitly allowed" Both of these seem like pretty reasonable message structures for posts to a cryptographic software development mailing list; it'd be nice if they could go through :) Here is the patch inline: arctwo-doc-fix.patch --- nettle.texinfo.orig 2011-03-16 19:08:50.000000000 -0400 +++ nettle.texinfo 2011-03-16 19:09:26.000000000 -0400 @@ -871,7 +871,7 @@ @end deftp @defvr Constant ARCTWO_BLOCK_SIZE -The AES block-size, 8 +The ARCTWO block-size, 8 @end defvr @defvr Constant ARCTWO_MIN_KEY_SIZE

2 4

nettle perl bindings
by Daniel Kahn Gillmor 18 Mar '11

18 Mar '11

Hi Nettle Folks-- I'm building Perl bindings for libnettle. I hope to claim the Crypt::Nettle namespace. The project is in its infancy, but i currently have coverage for all hash functions and ciphers. My next steps are adding bindings for Yarrow and RSA. At the moment, my source code is available via git: git clone git://lair.fifthhorseman.net/~dkg/libcrypt-nettle-perl You can test it with: cd libcrypt-nettle-perl perl Makefile.PL make make test You can read the docs with: pod2text lib/Crypt/Nettle.pm pod2text lib/Crypt/Nettle/Hash.pm pod2text lib/Crypt/Nettle/Cipher.pm I have not yet uploaded it to CPAN. I'd be very happy to get feedback from anyone interested. Regards, --dkg

4 13

nettle documentation tweaks?
by Daniel Kahn Gillmor 28 Feb '11

28 Feb '11

hi nettle folks-- i've been reading the latest nettle docs [0], and i wanted to say that they are excellent. Clear explanations, and useful contextual help about how various crypto primitives can be used in real-world settings as well. Thanks for this! I have two nit-picks that i'd like to share in hopes of making excellent documentation even better. 0) avoid replay attacks in pubkey authorization example. Section 6.5 contains the following paragraph: > Besides signing meaningful messages, digital signatures can be used for > authorization. A server can be configured with a public key, such that > any client that connects to the service is given a random nonce > message. If the server gets a reply with a correct signature matching > the nonce message and the configured public key, the client is granted > access. So the configuration of the server can be understood as “grant > access to whoever knows the private key corresponding to this > particular public key, and to no others”. This simple scheme is actually vulnerable to a replay attack: an man-in-the-middle attacker can pose as the service to the user while simultaneously connecting to the service directly. The attacker gets a nonce from the server, passes it to the user for signing, returns the user's response to the service, and gains access. One way to avoid this is to ensure that the "random nonce" to be signed by the user is actually a negotiated value that neither party can fully control. I recognize that this documentation shouldn't go into deep detail here, but i've seen real-world attempts to implement cryptosystems that are subject to this kind of replay attack :(. i think it would be a good idea to warn against it somehow. 1) "bad things may happen", "a few subtle issues", etc. should have outbound links There are several places in the docs that mention potential security concerns implementators should be aware of. For example, the remark about CBC providing "information leakage" could link to http://www.kb.cert.org/vuls/id/958563 Again, i'm not pushing for major changes or lots of intrusive commentary here (and i don't know how difficult it is to make outbound links in the documentation system used by nettle) but it would make already good docs even better. Thanks again for this library! Regards, --dkg [0] http://www.lysator.liu.se/~nisse/nettle/nettle.html#Cipher-modes

2 1

Re: LGPL blowfish
by nisse＠lysator.liu.se 10 Feb '11

10 Feb '11

[ Resend, the posting originally used an incorrect list address. /nisse ] Simon Josefsson <simon(a)josefsson.org> writes: > I wonder which of nettle or libgcrypt is correct -- and further, I > really wonder if anyone cares at all about Serpent if a problem like > this haven't been noticed before? Interesting... As far as I recall the nettle history (and also looking at the comments), the nettle adaptation of serpent.c was done by Rafael Sevilla, if I have touched that code I think it's trivial changes only. And I think that I wrote serpent-test.c, based on the test vectors in the serpent AES-competition package. I don't remember if I have ever done any interoperability testing of serpent with lsh (which uses nettle's implementation). Trying to connect to some openssh servers, it seems they don't enable serpent by default. 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). 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