nettle-bugs March 2011

nettle-bugs@lists.lysator.liu.se

6 participants
7 discussions

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

15 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

struct nettle_cipher for weak-key ciphers
by Daniel Kahn Gillmor 31 Mar '11

31 Mar '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 28 Mar '11

28 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 28 Mar '11

28 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

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 March 2011