- nettle-bugs - lists.lysator.liu.se

Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
by Nikos Mavrogiannopoulos 06 May '12

06 May '12

On 05/06/2012 12:34 PM, Bruno Haible wrote: > Niels Möller wrote: >> One possibility might be to not define the types at all, unless the >> gnulib application explicitly asks for them. Lots of applications want >> uint32_t, and I imagine a lot fewer have any need for int_fast*_t. > Yes. For this reason, libunistring installs a trimmed-down version of > gnulib's stdint.h, that defines only the int{8,16,32}_t types and not > all the rest (int64_t, int_least*_t, int_fast*_t, etc.). [1] Is there a gnulib module that only provides the basic types? regards, Nikos

1 0

Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
by Dagobert Michelsen 06 May '12

06 May '12

Hi Niels, Am 06.05.2012 um 07:02 schrieb Paul Eggert: > On 05/05/2012 12:19 PM, Niels Möller wrote: >> So code which uses the int_fast*_t types and relies on gnulib will get a >> slightly different ABI > > Generally speaking, it's unwise to use > the int_fast*_t types in a public header file. > This is a documented issue in Gnulib. > It's hard to imagine a general fix for this. Do you see a chance to adjust the nettle header files to avoid the fast-types? The current situation makes gnutls uncompilable on platforms like Solaris. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896

1 0

Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
by nisse＠lysator.liu.se 06 May '12

06 May '12

Paul Eggert <eggert(a)cs.ucla.edu> writes: > Generally speaking, it's unwise to use > the int_fast*_t types in a public header file. Why (feel free to point to the relevant section of gnulib docs, if it's explained well there)? Maybe nobody uses these types so it's an academic issue, but if these types are used in the interface to any library (possibly some system library), then it's important that applications agree on the definition. To me, it seems like the authoritative definition of int_fast*_t ought to be the system's ABI specification. And in the case of SunOS-5.9, where the types are missing, I think it makes the most sense to adopt the ABI of SunOS-5.10. Which also seems to be what gcc does. I'm a bit confused by your statement. I had the impression that gnulib *does* fall back on the definitions in public headers like <stdint.h> and <inttypes.h>, for the types which *are* defined there. And that's why nettle and gnutls seem to work together on SunOS-10. Correct? > This is a documented issue in Gnulib. > It's hard to imagine a general fix for this. One possibility might be to not define the types at all, unless the gnulib application *explicitly* asks for them. Lots of applications want uint32_t, and I imagine a lot fewer have any need for int_fast*_t. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
by nisse＠lysator.liu.se 05 May '12

05 May '12

Dagobert Michelsen <dam(a)opencsw.org> writes: > I see different possibilities on how this can be resolved: > > 1. nettle uses the gnulib definitions I currently have no plans to switch to using gnulib. As far as I'm aware, there's no problem with the types which nettle actually uses. So it would be a reasonable workaround to simply not define the int_fast*_t types; then they won't collide with the incompatible definitions gnutls gets from gnulib. Question is just what's the least intrusive way to do that (*if* it's easy to avoid, I'd prefer not to modify the definition of AX_CREATE_STDINT_H). I would appreciate if you can try the workarounds I suggested the other day and let me know how it works. > 2. gnulib changes the definitions to conform to nettle The problem with gnulib is not primarily that it doesn't "conform to nettle", but that it defines some types in a way that differs both from <stdint.h> on later releases on the OS (where the types are included), and from the definition in the stdint.h which comes with gcc. So code which uses the int_fast*_t types and relies on gnulib will get a slightly different ABI if compiled on SunOS-5.9 (or earlier) using Sun's compiler, than if compiled with gcc on the same system, or compiled with Sun's compiler on any later release of the OS. I think that's what needs to be fixed in gnulib. Do the gnulib folks agree? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

RSA private key abstraction
by nisse＠lysator.liu.se 30 Apr '12

30 Apr '12

I'm thinking about how to represent private keys. The context is the desire to support RSA blinding. I'd like to avoid having to duplicate all the signature functions (of which there's already a large number). This email is an expansion of a 3.0 entry in plan.txt. One way would be to pass a function pointer (and some optional ctx) for doing the private key operation. This would then be used wherever the current code calls _rsa_compute_root, and it would represent an RSA private key oracle. If we stick to software implementation, one could pass it as an extra argument, or one could extend the private key struct like struct rsa_private_key { mpz_t d; ... rsa_compute_root_func *f; }; and one could then "subclass" that as struct rsa_private_key_blinding { struct rsa_private_key super; struct whatever_random_ctx_needed ctx; }; (not sure this is the best design, but it's one possibility). Now I have a question: Would it be feasible to support smartcards (and similar hardware) at the same time? Then the secret key wouldn't be available at all to nettle, and a signature function might have an interface like int rsa_sha1_sign(rsa_compute_root_func *f, void *private, struct sha1_ctx *hash, mpz_t signature); where the actual private key data is totally dependent on the smartcard and its interface software. But what interfaces do typical smartcards use? Do they allow you to compute an arbitrary rsa root, or do they only more specific operations like "pkcs#1 v1.5 decrypt", "pkcs#1 v1.5 sha1 sign", #pkcs#1 v2.0 sha256 sign"? I want to figure out if smartcard support at this level is at all feasible. If not, we have to leave that for applications and libraries on top of nettle, and then the nettle interface should be tailored for software keys only. I've also had a quick look at the ssh-agent and gpgagent protocols. Both seems a bit too application specific, so I don't think it's feasible to hook in those as general "private key oracles" here. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 1

Release plans
by nisse＠lysator.liu.se 30 Apr '12

30 Apr '12

I've updated the todo page http://www.lysator.liu.se/~nisse/nettle/plan.html (also as misc/plan.html in the git repo). Any missing items? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 1

Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc
by nisse＠lysator.liu.se 27 Apr '12

27 Apr '12

Dagobert Michelsen <dam(a)opencsw.org> writes: > I just verified that the problem persists with nettle 2.4 and gnutls-3.0.19. As you seem to have > access to the Solaris buildfarm it would be cool if you could finally fix this as it blocks > new releases of gnutls for the OpenCSW distribution. It's some time since I looked in to this. My understaning of the problem is that 1. This Solaris version lack both <stdint.h> and <inttypes.h>. (A comment in AX_CREATE_STDINT_H seems to imply that it does have a <sys/inttypes.h>, should we use that?) 2. Nettle defines uint32_t and friends using the AX_CREATE_STDINT_H autoconf macro. 3. gnulib defines them in a different way. 4. The multiple definitions of, e.g., uint32_t, agree and are no problem. 5. The definitions of some other (unused) types are incompatible, e.g., int_fast8_t, and cause the compilation errors. 6. The definitions from AX_CREATE_STDINT_H is compatible with the definitions of these types in Solaris 10. gnulib's definitions aren't, so any code using them can potentially break if linked together with code compiled on Solaris 10. Hence I think it ought to be fixed in gnulib. Simon (and any other gnulib people on these lists), do you agree? To address (1), maybe you can try diff --git a/configure.ac b/configure.ac index 6bf2b8b..77bb9b1 100644 --- a/configure.ac +++ b/configure.ac @@ -518,7 +518,7 @@ LSH_GCC_ATTRIBUTES # According to Simon Josefsson, looking for uint32_t and friends in # sys/types.h is needed on some systems, in particular cygwin. -AX_CREATE_STDINT_H([nettle-stdint.h], [sys/types.h]) +AX_CREATE_STDINT_H([nettle-stdint.h], [sys/types.h], [sys/inttypes.h]) # Check for file locking. We (AC_PROG_CC?) have already checked for # sys/types.h and unistd.h. but I suspect you would still get compilation errors due to incompatible definitions in gnulib and sys/inttypes.h. Maybe the easiest nettle workaround would be to somehow disable the definitions of the problematic types, which we don't use anyway. Could you try something like the following? diff --git a/nettle-types.h b/nettle-types.h index b694332..d0aa332 100644 --- a/nettle-types.h +++ b/nettle-types.h @@ -23,6 +23,9 @@ #ifndef NETTLE_TYPES_H #define NETTLE_TYPES_H +/* Pretend this type always exists. Nettle doesn't use it. */ +#define _STDINT_HAVE_INT_FAST32_T 1 + #include "nettle-stdint.h" #ifdef __cplusplus Have a look into the generated nettle-stdint.h (or the template in aclocal.m4) for other potentially useful defines. The closest Solaris 5.8 box I used to have acccess to (hanna.lysator.liu.se) seems to have been decomissioned. Regardss, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 2

Salsa20
by Simon Josefsson 26 Apr '12

26 Apr '12

Hi! Please find attached a port of DJB's public domain code for Salsa20 to nettle. The patch is not meant to be applied as-is but to start a discussion. Review of the code itself is welcome. While writing this I noticed a sub-optimal design of Nettle, in that it overloads the meaning of struct nettle_cipher->block_size as a flag of whether the cipher is a stream cipher or not. Before arcfour was the only stream cipher in nettle, and using block_size=0 to signal that it is a stream cipher worked fine. However, Salsa20 has a block size of 8 bytes. Another odd thing is that Salsa20 requires an IV. So some changes to the nettle_cipher struct are required. This could be resolved better than I have done in the patch below. I see two reasonable alternatives: 1) Introduce a new struct 'struct nettle_stream_cipher' that applies to stream ciphers and use that. 2) Add a flag in 'struct nettle_cipher' to tell whether the cipher is a stream cipher or not. I started out strongly prefering 1) because it appeared cleaner. After thinking about the changes required to implement that, I am now leaning towards 2) because of: A) a lot of code would have to be duplicated if we have both 'struct nettle_cipher' and 'struct nettle_stream_cipher' for apparently little gain. Otherwise, most code could be the same, and where the distinction matters there could be a simple if-test. B) it allows for full backwards compatibility in a clean way. With 1) we would have a transition period where people switch arcfour usage from nettle_cipher to nettle_stream_cipher. With 2) arcfour would continue to have block_size==0 but it would also set the new stream cipher flag. External code could incrementally be updated to check the new flag instead of block_size==0 (if it does that at all) but that is something that doesn't uglify nettle. What do you think? I'd be happy to propose a patch to implement 2) and then a follow-on patch to add support for Salsa20. /Simon >From 600ae2815634ad95c4d2d93821316ce20df19ae3 Mon Sep 17 00:00:00 2001 From: Simon Josefsson <simon(a)josefsson.org> Date: Wed, 21 Mar 2012 17:06:13 +0100 Subject: [PATCH] Implement Salsa20. --- Makefile.in | 3 +- examples/nettle-benchmark.c | 3 + nettle-meta-ciphers.c | 2 + nettle-meta.h | 8 ++- nettle-types.h | 5 + salsa20-meta.c | 49 ++++++++++++ salsa20.c | 172 ++++++++++++++++++++++++++++++++++++++++++ salsa20.h | 71 +++++++++++++++++ testsuite/.gitignore | 1 + testsuite/.test-rules.make | 3 + testsuite/Makefile.in | 1 + testsuite/meta-cipher-test.c | 2 + testsuite/salsa20-test.c | 49 ++++++++++++ testsuite/testutils.c | 36 +++++++-- testsuite/testutils.h | 10 +++ 15 files changed, 407 insertions(+), 8 deletions(-) create mode 100644 salsa20-meta.c create mode 100644 salsa20.c create mode 100644 salsa20.h create mode 100644 testsuite/salsa20-test.c diff --git a/Makefile.in b/Makefile.in index 1813a0d..6e2ec60 100644 --- a/Makefile.in +++ b/Makefile.in @@ -79,6 +79,7 @@ nettle_SOURCES = aes-decrypt-internal.c aes-decrypt.c \ md2.c md2-meta.c md4.c md4-meta.c \ md5.c md5-compress.c md5-compat.c md5-meta.c \ ripemd160.c ripemd160-compress.c ripemd160-meta.c \ + salsa20.c salsa20-meta.c \ sha1.c sha1-compress.c sha1-meta.c \ sha256.c sha256-compress.c sha224-meta.c sha256-meta.c \ sha512.c sha512-compress.c sha384-meta.c sha512-meta.c \ @@ -113,7 +114,7 @@ hogweed_SOURCES = sexp.c sexp-format.c \ pgp-encode.c rsa2openpgp.c \ der-iterator.c der2rsa.c der2dsa.c -HEADERS = aes.h arcfour.h arctwo.h asn1.h bignum.h blowfish.h \ +HEADERS = aes.h arcfour.h salsa20.h arctwo.h asn1.h bignum.h blowfish.h \ base16.h base64.h buffer.h camellia.h cast128.h \ cbc.h ctr.h gcm.h \ des.h des-compat.h dsa.h \ diff --git a/examples/nettle-benchmark.c b/examples/nettle-benchmark.c index 424ef19..44fca4e 100644 --- a/examples/nettle-benchmark.c +++ b/examples/nettle-benchmark.c @@ -40,6 +40,7 @@ #include "aes.h" #include "arcfour.h" +#include "salsa20.h" #include "blowfish.h" #include "cast128.h" #include "cbc.h" @@ -612,6 +613,8 @@ main(int argc, char **argv) OPENSSL(&nettle_openssl_aes192) OPENSSL(&nettle_openssl_aes256) &nettle_arcfour128, OPENSSL(&nettle_openssl_arcfour128) + &nettle_salsa20_128, + &nettle_salsa20_256, &nettle_blowfish128, OPENSSL(&nettle_openssl_blowfish128) &nettle_camellia128, &nettle_camellia192, &nettle_camellia256, &nettle_cast128, OPENSSL(&nettle_openssl_cast128) diff --git a/nettle-meta-ciphers.c b/nettle-meta-ciphers.c index 1f07595..aae90f9 100644 --- a/nettle-meta-ciphers.c +++ b/nettle-meta-ciphers.c @@ -36,6 +36,8 @@ const struct nettle_cipher * const nettle_ciphers[] = { &nettle_camellia192, &nettle_camellia256, &nettle_cast128, + &nettle_salsa20_128, + &nettle_salsa20_256, &nettle_serpent128, &nettle_serpent192, &nettle_serpent256, diff --git a/nettle-meta.h b/nettle-meta.h index 54cbbd2..c8aabda 100644 --- a/nettle-meta.h +++ b/nettle-meta.h @@ -5,6 +5,7 @@ /* nettle, low-level cryptographics library * + * Copyright (C) 2012 Simon Josefsson * Copyright (C) 2002 Niels Möller * * The nettle library is free software; you can redistribute it and/or modify @@ -39,7 +40,7 @@ struct nettle_cipher unsigned context_size; - /* Zero for stream ciphers */ + /* Block size; 0 for byte-oriented stream ciphers. */ unsigned block_size; /* Suggested key size; other sizes are sometimes possible. */ @@ -50,6 +51,8 @@ struct nettle_cipher nettle_crypt_func *encrypt; nettle_crypt_func *decrypt; + + nettle_set_iv_func *set_iv; }; #define _NETTLE_CIPHER(name, NAME, key_size) { \ @@ -105,6 +108,9 @@ extern const struct nettle_cipher nettle_aes256; extern const struct nettle_cipher nettle_arcfour128; +extern const struct nettle_cipher nettle_salsa20_128; +extern const struct nettle_cipher nettle_salsa20_256; + extern const struct nettle_cipher nettle_camellia128; extern const struct nettle_cipher nettle_camellia192; extern const struct nettle_cipher nettle_camellia256; diff --git a/nettle-types.h b/nettle-types.h index b694332..e68cacb 100644 --- a/nettle-types.h +++ b/nettle-types.h @@ -2,6 +2,7 @@ /* nettle, low-level cryptographics library * + * Copyright (C) 2012 Simon Josefsson * Copyright (C) 2005 Niels Möller * * The nettle library is free software; you can redistribute it and/or modify @@ -44,6 +45,10 @@ typedef void nettle_set_key_func(void *ctx, unsigned length, const uint8_t *key); +typedef void nettle_set_iv_func(void *ctx, + unsigned length, + const uint8_t *iv); + /* Uses a void * for cipher contexts. For block ciphers it would make sense with a const void * for the diff --git a/salsa20-meta.c b/salsa20-meta.c new file mode 100644 index 0000000..8278e09 --- /dev/null +++ b/salsa20-meta.c @@ -0,0 +1,49 @@ +/* salsa20-meta.c */ + +/* nettle, low-level cryptographics library + * + * Copyright (C) 2012 Simon Josefsson + * + * The nettle library is free software; you can redistribute it and/or modify + * it under the terms of the GNU Lesser General Public License as published by + * the Free Software Foundation; either version 2.1 of the License, or (at your + * option) any later version. + * + * The nettle library is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY + * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public + * License for more details. + * + * You should have received a copy of the GNU Lesser General Public License + * along with the nettle library; see the file COPYING.LIB. If not, write to + * the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, + * MA 02111-1307, USA. + */ + +#if HAVE_CONFIG_H +# include "config.h" +#endif + +#include "nettle-meta.h" + +#include "salsa20.h" + +const struct nettle_cipher nettle_salsa20_128 = + { "salsa20-128", sizeof(struct salsa20_ctx), + 8, 16, + (nettle_set_key_func *) salsa20_set_key, + (nettle_set_key_func *) salsa20_set_key, + (nettle_crypt_func *) salsa20_crypt, + (nettle_crypt_func *) salsa20_crypt, + (nettle_set_iv_func *) salsa20_set_iv + }; + +const struct nettle_cipher nettle_salsa20_256 = + { "salsa20-256", sizeof(struct salsa20_ctx), + 8, 32, + (nettle_set_key_func *) salsa20_set_key, + (nettle_set_key_func *) salsa20_set_key, + (nettle_crypt_func *) salsa20_crypt, + (nettle_crypt_func *) salsa20_crypt, + (nettle_set_iv_func *) salsa20_set_iv + }; diff --git a/salsa20.c b/salsa20.c new file mode 100644 index 0000000..7885199 --- /dev/null +++ b/salsa20.c @@ -0,0 +1,172 @@ +/* salsa20.c + * + * The Salsa20 stream cipher. + */ + +/* nettle, low-level cryptographics library + * + * Copyright (C) 2012 Simon Josefsson + * + * The nettle library is free software; you can redistribute it and/or modify + * it under the terms of the GNU Lesser General Public License as published by + * the Free Software Foundation; either version 2.1 of the License, or (at your + * option) any later version. + * + * The nettle library is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY + * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public + * License for more details. + * + * You should have received a copy of the GNU Lesser General Public License + * along with the nettle library; see the file COPYING.LIB. If not, write to + * the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, + * MA 02111-1307, USA. + */ + +#if HAVE_CONFIG_H +# include "config.h" +#endif + +#include <assert.h> + +#include "salsa20.h" + +#define ROTL32(x,n) ((((x))<<(n)) | (((x))>>(32-(n)))) + +#define SWAP32(v) \ + ((ROTL32(v, 8) & 0x00FF00FFUL) | \ + (ROTL32(v, 24) & 0xFF00FF00UL)) + +#ifdef WORDS_BIGENDIAN +#define U32TO32_LITTLE(v) SWAP32(v) +#else +#define U32TO32_LITTLE(v) (v) +#endif + +#define U8TO32_LITTLE(p) U32TO32_LITTLE(((uint32_t*)(p))[0]) +#define U32TO8_LITTLE(p, v) (((uint32_t*)(p))[0] = U32TO32_LITTLE(v)) + +/* +salsa20-ref.c version 20051118 +D. J. Bernstein +Public domain. +*/ + +#define ROTATE(v,c) (ROTL32(v,c)) +#define XOR(v,w) ((v) ^ (w)) +#define PLUS(v,w) ((v) + (w)) +#define PLUSONE(v) (PLUS((v),1)) + +static void salsa20_wordtobyte(uint8_t output[64],const uint32_t input[16]) +{ + uint32_t x[16]; + int i; + + for (i = 0;i < 16;++i) x[i] = input[i]; + for (i = 20;i > 0;i -= 2) { + x[ 4] = XOR(x[ 4],ROTATE(PLUS(x[ 0],x[12]), 7)); + x[ 8] = XOR(x[ 8],ROTATE(PLUS(x[ 4],x[ 0]), 9)); + x[12] = XOR(x[12],ROTATE(PLUS(x[ 8],x[ 4]),13)); + x[ 0] = XOR(x[ 0],ROTATE(PLUS(x[12],x[ 8]),18)); + x[ 9] = XOR(x[ 9],ROTATE(PLUS(x[ 5],x[ 1]), 7)); + x[13] = XOR(x[13],ROTATE(PLUS(x[ 9],x[ 5]), 9)); + x[ 1] = XOR(x[ 1],ROTATE(PLUS(x[13],x[ 9]),13)); + x[ 5] = XOR(x[ 5],ROTATE(PLUS(x[ 1],x[13]),18)); + x[14] = XOR(x[14],ROTATE(PLUS(x[10],x[ 6]), 7)); + x[ 2] = XOR(x[ 2],ROTATE(PLUS(x[14],x[10]), 9)); + x[ 6] = XOR(x[ 6],ROTATE(PLUS(x[ 2],x[14]),13)); + x[10] = XOR(x[10],ROTATE(PLUS(x[ 6],x[ 2]),18)); + x[ 3] = XOR(x[ 3],ROTATE(PLUS(x[15],x[11]), 7)); + x[ 7] = XOR(x[ 7],ROTATE(PLUS(x[ 3],x[15]), 9)); + x[11] = XOR(x[11],ROTATE(PLUS(x[ 7],x[ 3]),13)); + x[15] = XOR(x[15],ROTATE(PLUS(x[11],x[ 7]),18)); + x[ 1] = XOR(x[ 1],ROTATE(PLUS(x[ 0],x[ 3]), 7)); + x[ 2] = XOR(x[ 2],ROTATE(PLUS(x[ 1],x[ 0]), 9)); + x[ 3] = XOR(x[ 3],ROTATE(PLUS(x[ 2],x[ 1]),13)); + x[ 0] = XOR(x[ 0],ROTATE(PLUS(x[ 3],x[ 2]),18)); + x[ 6] = XOR(x[ 6],ROTATE(PLUS(x[ 5],x[ 4]), 7)); + x[ 7] = XOR(x[ 7],ROTATE(PLUS(x[ 6],x[ 5]), 9)); + x[ 4] = XOR(x[ 4],ROTATE(PLUS(x[ 7],x[ 6]),13)); + x[ 5] = XOR(x[ 5],ROTATE(PLUS(x[ 4],x[ 7]),18)); + x[11] = XOR(x[11],ROTATE(PLUS(x[10],x[ 9]), 7)); + x[ 8] = XOR(x[ 8],ROTATE(PLUS(x[11],x[10]), 9)); + x[ 9] = XOR(x[ 9],ROTATE(PLUS(x[ 8],x[11]),13)); + x[10] = XOR(x[10],ROTATE(PLUS(x[ 9],x[ 8]),18)); + x[12] = XOR(x[12],ROTATE(PLUS(x[15],x[14]), 7)); + x[13] = XOR(x[13],ROTATE(PLUS(x[12],x[15]), 9)); + x[14] = XOR(x[14],ROTATE(PLUS(x[13],x[12]),13)); + x[15] = XOR(x[15],ROTATE(PLUS(x[14],x[13]),18)); + } + for (i = 0;i < 16;++i) x[i] = PLUS(x[i],input[i]); + for (i = 0;i < 16;++i) U32TO8_LITTLE(output + 4 * i,x[i]); +} + +static const char sigma[16] = "expand 32-byte k"; +static const char tau[16] = "expand 16-byte k"; + +void +salsa20_set_key(struct salsa20_ctx *ctx, + unsigned length, const uint8_t *key) +{ + const char *constants; + + assert (length == SALSA20_MIN_KEY_SIZE || length == SALSA20_MAX_KEY_SIZE); + + ctx->input[1] = U8TO32_LITTLE(key + 0); + ctx->input[2] = U8TO32_LITTLE(key + 4); + ctx->input[3] = U8TO32_LITTLE(key + 8); + ctx->input[4] = U8TO32_LITTLE(key + 12); + if (length == SALSA20_MAX_KEY_SIZE) { /* recommended */ + key += 16; + constants = sigma; + } else { /* kbits == 128 */ + constants = tau; + } + ctx->input[11] = U8TO32_LITTLE(key + 0); + ctx->input[12] = U8TO32_LITTLE(key + 4); + ctx->input[13] = U8TO32_LITTLE(key + 8); + ctx->input[14] = U8TO32_LITTLE(key + 12); + ctx->input[0] = U8TO32_LITTLE(constants + 0); + ctx->input[5] = U8TO32_LITTLE(constants + 4); + ctx->input[10] = U8TO32_LITTLE(constants + 8); + ctx->input[15] = U8TO32_LITTLE(constants + 12); +} + +void +salsa20_set_iv(struct salsa20_ctx *ctx, unsigned length, const uint8_t *iv) +{ + assert (length == SALSA20_IV_SIZE); + + ctx->input[6] = U8TO32_LITTLE(iv + 0); + ctx->input[7] = U8TO32_LITTLE(iv + 4); + ctx->input[8] = 0; + ctx->input[9] = 0; +} + +void +salsa20_crypt(struct salsa20_ctx *ctx, + unsigned length, + uint8_t *c, + const uint8_t *m) +{ + uint8_t output[64]; + unsigned i; + + if (!length) return; + for (;;) { + salsa20_wordtobyte(output,ctx->input); + ctx->input[8] = PLUSONE(ctx->input[8]); + if (!ctx->input[8]) { + ctx->input[9] = PLUSONE(ctx->input[9]); + /* stopping at 2^70 length per nonce is user's responsibility */ + } + if (length <= 64) { + for (i = 0;i < length;++i) c[i] = m[i] ^ output[i]; + return; + } + for (i = 0;i < 64;++i) c[i] = m[i] ^ output[i]; + length -= 64; + c += 64; + m += 64; + } +} diff --git a/salsa20.h b/salsa20.h new file mode 100644 index 0000000..79f1505 --- /dev/null +++ b/salsa20.h @@ -0,0 +1,71 @@ +/* salsa20.h + * + * The Salsa20 stream cipher. + */ + +/* nettle, low-level cryptographics library + * + * Copyright (C) 2012 Simon Josefsson + * Copyright (C) 2001 Niels Möller + * + * The nettle library is free software; you can redistribute it and/or modify + * it under the terms of the GNU Lesser General Public License as published by + * the Free Software Foundation; either version 2.1 of the License, or (at your + * option) any later version. + * + * The nettle library is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY + * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public + * License for more details. + * + * You should have received a copy of the GNU Lesser General Public License + * along with the nettle library; see the file COPYING.LIB. If not, write to + * the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, + * MA 02111-1307, USA. + */ + +#ifndef NETTLE_SALSA20_H_INCLUDED +#define NETTLE_SALSA20_H_INCLUDED + +#include "nettle-types.h" + +#ifdef __cplusplus +extern "C" { +#endif + +/* Name mangling */ +#define salsa20_set_key nettle_salsa20_set_key +#define salsa20_set_iv nettle_salsa20_set_iv +#define salsa20_crypt nettle_salsa20_crypt + +/* Minimum and maximum keysizes, and a reasonable default. In + * octets.*/ +#define SALSA20_MIN_KEY_SIZE 16 +#define SALSA20_MAX_KEY_SIZE 32 +#define SALSA20_KEY_SIZE 32 + +#define SALSA20_IV_SIZE 8 + +struct salsa20_ctx +{ + uint32_t input[16]; +}; + +void +salsa20_set_key(struct salsa20_ctx *ctx, + unsigned length, const uint8_t *key); + +void +salsa20_set_iv(struct salsa20_ctx *ctx, + unsigned length, const uint8_t *iv); + +void +salsa20_crypt(struct salsa20_ctx *ctx, + unsigned length, uint8_t *dst, + const uint8_t *src); + +#ifdef __cplusplus +} +#endif + +#endif /* NETTLE_SALSA20_H_INCLUDED */ diff --git a/testsuite/.gitignore b/testsuite/.gitignore index 1147cfb..c9f4698 100644 --- a/testsuite/.gitignore +++ b/testsuite/.gitignore @@ -36,6 +36,7 @@ /rsa-keygen-test /rsa-test /rsa2sexp-test +/salsa20-test /serpent-test /sexp-format-test /sexp-test diff --git a/testsuite/.test-rules.make b/testsuite/.test-rules.make index e8f6650..10c993f 100644 --- a/testsuite/.test-rules.make +++ b/testsuite/.test-rules.make @@ -49,6 +49,9 @@ memxor-test$(EXEEXT): memxor-test.$(OBJEXT) ripemd160-test$(EXEEXT): ripemd160-test.$(OBJEXT) $(LINK) ripemd160-test.$(OBJEXT) $(TEST_OBJS) -o ripemd160-test$(EXEEXT) +salsa20-test$(EXEEXT): salsa20-test.$(OBJEXT) + $(LINK) salsa20-test.$(OBJEXT) $(TEST_OBJS) -o salsa20-test$(EXEEXT) + sha1-test$(EXEEXT): sha1-test.$(OBJEXT) $(LINK) sha1-test.$(OBJEXT) $(TEST_OBJS) -o sha1-test$(EXEEXT) diff --git a/testsuite/Makefile.in b/testsuite/Makefile.in index 8dfc62b..10ffae9 100644 --- a/testsuite/Makefile.in +++ b/testsuite/Makefile.in @@ -18,6 +18,7 @@ TS_NETTLE_SOURCES = aes-test.c arcfour-test.c arctwo-test.c \ md2-test.c md4-test.c md5-test.c md5-compat-test.c \ memxor-test.c \ ripemd160-test.c \ + salsa20-test.c \ sha1-test.c sha224-test.c sha256-test.c \ sha384-test.c sha512-test.c \ serpent-test.c twofish-test.c \ diff --git a/testsuite/meta-cipher-test.c b/testsuite/meta-cipher-test.c index 1bb74d8..50a02ba 100644 --- a/testsuite/meta-cipher-test.c +++ b/testsuite/meta-cipher-test.c @@ -14,6 +14,8 @@ const char* ciphers[] = { "camellia192", "camellia256", "cast128", + "salsa20-128", + "salsa20-256", "serpent128", "serpent192", "serpent256", diff --git a/testsuite/salsa20-test.c b/testsuite/salsa20-test.c new file mode 100644 index 0000000..e1c13dd --- /dev/null +++ b/testsuite/salsa20-test.c @@ -0,0 +1,49 @@ +#include "testutils.h" +#include "salsa20.h" + +int +test_main(void) +{ + /* http://www.ecrypt.eu.org/stream/svn/viewcvs.cgi/ecrypt/trunk/submissions/sa… */ + + test_cipher_iv(&nettle_salsa20_128, + HL("80000000 00000000 00000000 00000000"), + HL("00000000 00000000"), + HL("00000000 00000000"), + H("4DFA5E48 1DA23EA0")); + + test_cipher_iv(&nettle_salsa20_128, + HL("00000000 00000000 00000000 00000000"), + HL("80000000 00000000"), + HL("00000000 00000000"), + H("B66C1E44 46DD9557")); + + test_cipher_iv(&nettle_salsa20_128, + HL("0053A6F94C9FF24598EB3E91E4378ADD"), + HL("0D74DB42A91077DE"), + HL("00000000 00000000"), + H("05E1E7BE B697D999")); + + test_cipher_iv(&nettle_salsa20_256, + HL("80000000 00000000 00000000 00000000" + "00000000 00000000 00000000 00000000"), + HL("00000000 00000000"), + HL("00000000 00000000"), + H("E3BE8FDD 8BECA2E3")); + + test_cipher_iv(&nettle_salsa20_256, + HL("00000000 00000000 00000000 00000000" + "00000000 00000000 00000000 00000000"), + HL("80000000 00000000"), + HL("00000000 00000000"), + H("2ABA3DC45B494700")); + + test_cipher_iv(&nettle_salsa20_256, + HL("0053A6F94C9FF24598EB3E91E4378ADD" + "3083D6297CCF2275C81B6EC11467BA0D"), + HL("0D74DB42A91077DE"), + HL("00000000 00000000"), + H("F5FAD53F 79F9DF58")); + + SUCCESS(); +} diff --git a/testsuite/testutils.c b/testsuite/testutils.c index d77bb7e..8f5dab0 100644 --- a/testsuite/testutils.c +++ b/testsuite/testutils.c @@ -162,17 +162,21 @@ main(int argc, char **argv) } void -test_cipher(const struct nettle_cipher *cipher, - unsigned key_length, - const uint8_t *key, - unsigned length, - const uint8_t *cleartext, - const uint8_t *ciphertext) +test_cipher_iv(const struct nettle_cipher *cipher, + unsigned key_length, + const uint8_t *key, + unsigned iv_length, + const uint8_t *iv, + unsigned length, + const uint8_t *cleartext, + const uint8_t *ciphertext) { void *ctx = xalloc(cipher->context_size); uint8_t *data = xalloc(length); cipher->set_encrypt_key(ctx, key_length, key); + if (iv_length > 0 && iv) + cipher->set_iv(ctx, iv_length, iv); cipher->encrypt(ctx, length, data, cleartext); if (!MEMEQ(length, data, ciphertext)) @@ -187,6 +191,8 @@ test_cipher(const struct nettle_cipher *cipher, FAIL(); } cipher->set_decrypt_key(ctx, key_length, key); + if (iv_length > 0 && iv) + cipher->set_iv(ctx, iv_length, iv); cipher->decrypt(ctx, length, data, data); if (!MEMEQ(length, data, cleartext)) @@ -206,6 +212,24 @@ test_cipher(const struct nettle_cipher *cipher, } void +test_cipher(const struct nettle_cipher *cipher, + unsigned key_length, + const uint8_t *key, + unsigned length, + const uint8_t *cleartext, + const uint8_t *ciphertext) +{ + test_cipher_iv(cipher, + key_length, + key, + 0, + NULL, + length, + cleartext, + ciphertext); +} + +void test_cipher_cbc(const struct nettle_cipher *cipher, unsigned key_length, const uint8_t *key, diff --git a/testsuite/testutils.h b/testsuite/testutils.h index d7ced9a..9d13dff 100644 --- a/testsuite/testutils.h +++ b/testsuite/testutils.h @@ -91,6 +91,16 @@ test_cipher(const struct nettle_cipher *cipher, const uint8_t *ciphertext); void +test_cipher_iv(const struct nettle_cipher *cipher, + unsigned key_length, + const uint8_t *key, + unsigned iv_length, + const uint8_t *iv, + unsigned length, + const uint8_t *cleartext, + const uint8_t *ciphertext); + +void test_cipher_cbc(const struct nettle_cipher *cipher, unsigned key_length, const uint8_t *key, -- 1.7.2.5

2 8

AES assembler not compatible with Windows x64
by Mann Ern Kang 26 Apr '12

26 Apr '12

Hi all, An issue arose while testing gnutls, which has a dependency on nettle, on Windows x64. The x86_64 aes assembler code in nettle is not compatible with the Windows calling convention, leading to crashes. The related gnutls item is here: https://savannah.gnu.org/support/?108038 This can be worked around for now with --disable-assembler during ./configure. Going forward, will there be any plans to support assembler for x64 Windows? Cheers, Mann Ern

3 2

rsa blinding patch
by Nikos Mavrogiannopoulos 14 Apr '12

14 Apr '12

Hello, Attached you'll find an initial patch that adds timing resistant versions of rsa_compute_root() and rsa_decrypt(). regards, Nikos

4 19

comparison between crypto libraries
by Nikos Mavrogiannopoulos 01 Apr '12

01 Apr '12

Hello, Actually this comparison is pretty old, but was unknown to me until today. It compares the various cryptographic libraries on cipher performance. https://idlebox.net/2008/0714-cryptography-speedtest-comparison/ Since then many things might have changed, but I also noticed the AES performance difference on a 32-bit processor. However, in RSA and DH nettle/gmp seem to offer much better performance than openssl [0]. regards, Nikos [0]. http://nikmav.blogspot.com/2012/04/in-some-embedded-systems-space-may.html https://bitbucket.org/yarosla/nxweb/wiki/Benchmarks

1 0

GNU MP not found (mingw)
by yyy 29 Mar '12

29 Mar '12

Configure fails to find gmp GMP version 5.0.4 nettle version 2.4 mingw on windows xp sp3 config.log did not contain any recognizable links to missing files (there were multiple references to "-lgmp", but it was not a file) (entire config.log is ~35KB, should I post it here? Compiling and building GMP was successful, it produced file libgmp.a with size of 648 236 bytes. Leaving that file in default lib directory, did not work. Putting it in nettle directory did not work either. Renaming that file to lgmp.a, libgmp.a.dll or lgmp.a.dll and copying to nettle directory did not work either. Where nettle's configure script is looking for lgmp and what is the required filename? Could it be, that nettle 2.4 does not work with GMP 5.0.4 and requires older version?

2 1

Migration from CVS to GIT
by nisse＠lysator.liu.se 18 Feb '12

18 Feb '12

I'm finally looking into conversion of the lsh repository from CVS to GIT, and this naturally also includes nettle. A public test repository can be found at lysator's gitorious installation, at http://git.lysator.liu.se/lsh/test-2. The conversion was done by the pcvs2git.pike program (see git://pike-git.lysator.liu.se/pcvs2git.git), and I got some help from Henrik Grubbström to write a config file to handle the few peculiarities in the lsh repository. The intention is that the new git repository should include all branches and tags from the old cvs repository, and record major merge events, like the 2006-05-16 merge from the experimental branch to the trunk. Please test, and if all goes well I'll rename this repository to "lsh" (or recreate, if I can't figure out how to do repository renames with gitorious). If this first steps works out ok, step two is to do a some cleanups (switching to utf-8 for the files, deleting old $Id$ tags, etc). And then step three is to extract the nettle subdirectory as an independent project and repository, using git subtree of git filter-branch or so (I'm not sure what's the best tool for that job). Other sub-projects, e.g., the argp implementation, can be split out later, if desired. For the few "common files" (e.g., misc/run-tests), they'll simply have to be duplicated in several repositories. If I still want to bundle nettle with the lsh distribution, I'll handle that by setting up some symlink in my working tree. git submodule is probably not a solution, and git subtree is most likely overkill. The old CVS repository can be considered read-only now. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

4 17

make issues
by Coel May 06 Feb '12

06 Feb '12

Hi, In the process of attempting to build gnutls under os x I get an error saying libnettle is not found. Ok. So I download nettle-2.4.tar.gz, extract and run ./configure. No problems. Then I run make. the result is below. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - $ make make all-here /usr/bin/m4 ./asm.m4 machine.m4 config.m4 \ aes-decrypt-internal.asm >aes-decrypt-internal.s gcc -I. -DHAVE_CONFIG_H -g -O2 -ggdb3 -Wno-pointer-sign -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wnested-externs -fPIC -MT aes-decrypt-internal.o -MD -MP -MF aes-decrypt-internal.o.d -fPIC -c aes-decrypt-internal.s aes-decrypt-internal.asm:109:suffix or operands invalid for `push' aes-decrypt-internal.asm:110:suffix or operands invalid for `push' aes-decrypt-internal.asm:111:suffix or operands invalid for `push' aes-decrypt-internal.asm:112:suffix or operands invalid for `push' aes-decrypt-internal.asm:328:suffix or operands invalid for `pop' aes-decrypt-internal.asm:329:suffix or operands invalid for `pop' aes-decrypt-internal.asm:330:suffix or operands invalid for `pop' aes-decrypt-internal.asm:331:suffix or operands invalid for `pop' make[1]: *** [aes-decrypt-internal.o] Error 1 make: *** [all] Error 2 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Am I missing something? I must be, right? Any help appreciated. coel may e: coel(a)coelmay.com w: http://coelmay.com t: twitter.com/coelmay

6 9

Building libnettle on MS-Windows
by Eli Zaretskii 17 Jan '12

17 Jan '12

About a week ago, I built libnettle 2.4 on MS-Windows using the MinGW tools. While doing that, I found a few problems; this message reports them. For the record, I configured using " --disable-openssl --enable-shared". This was suggested by the GnuTLS README file; as I needed libnettle to build GnuTLS, I followed that advice. Problem #1: Compiler warnings while compiling cbc.c: cbc.c: In function `nettle_cbc_decrypt': cbc.c:101: warning: implicit declaration of function `alloca' cbc.c:101: warning: nested extern declaration of `alloca' I fixed this by adding this to config.h.in: /* Needed for alloca on MinGW */ # if HAVE_MALLOC_H # include <malloc.h> # endif malloc.h in MinGW defines alloca to the GCC builtin; if the above is absent, the compiler falls back on "char *alloca()" which causes the warnings. Problem #2: "make install" incorrectly copies the DLL files into lib/*.dll.a. *.dll.a are the Windows import libraries for using during the link stage; the *.dll dynamic libraries themselves should be copied into the $(bindir) directory. My solution was to add commands to corresponding recipes that cater to Windows, where *_SONAME variables are empty: install-shared-hogweed: $(LIBHOGWEED_FORLINK) $(MKDIR_P) $(DESTDIR)$(libdir) $(MKDIR_P) $(DESTDIR)$(bindir) [ -z "$(LIBHOGWEED_SONAME)" ] \ && $(INSTALL_DATA) $(LIBHOGWEED_FORLINK) $(DESTDIR)$(bindir) [ -z "$(LIBHOGWEED_SONAME)" ] \ && $(INSTALL_DATA) $(LIBHOGWEED_FILE) $(DESTDIR)$(libdir) [ -z "$(LIBHOGWEED_SONAME)" ] \ || $(INSTALL_DATA) $(LIBHOGWEED_FORLINK) $(DESTDIR)$(libdir)/$(LIBHOGWEED_FILE) [ -z "$(LIBHOGWEED_SONAME)" ] \ || (cd $(DESTDIR)$(libdir) \ && $(LN_S) $(LIBHOGWEED_FILE) $(LIBHOGWEED_SONAME) \ && $(LN_S) $(LIBHOGWEED_FILE) $(LIBHOGWEED_FORLINK)) Problem #3: Tests crash because they don't find libhogweed-2-1.dll. This is because Makefile uses "ln -sf" to create .lib/*.dll. Solution: add LN_S variable to Makefile.in, and then re-run the build with "make LN_S='cp -prf'. Also, add this command to the recipes that build shared libraries: [ -z "$(LIBNETTLE_SONAME)" ] && (cd .lib \ && $(LN_S) ../$(LIBNETTLE_FORLINK) $(LIBNETTLE_FORLINK)) so that the DLLs are copied to .lib/ under the same name. Problem #4: Tests in `examples' crash, cannot find libhogweed-2-1. Solution: add ../.lib to PATH, like testsuite/Makefile.in does. Problem #5: testsuite/pkcs1-conv fails due to CRLF vs LF issue in compared files (MinGW programs produce text files where each line ends in CRLF, while the test expects the Unix-style LF-only end-of-line format). Solution: add --strip-trailing-cr switch to diff. Problem #6: testsuite/sexp-conv fails due to CRLF vs LF issue in compared files. Solution: use "diff --strip-trailing-cr" instead of "cmp". Problem #7: examples/setup-env fails because it tries to read from rsa-decrypt, which doesn't exist. It should instead read from rsa-decrypt.exe. Solution: fix setup-env to check which program file is actually present and read from that. A similar problem is in examples/rsa-encrypt-test. Problem #8: examples/rsa-encrypt-test fails because rsa-encrypt.c and rsa-decrypt.c read/write binary data from stdin to stdout, but do not set these streams to binary mode. To solve this, I added code to the test programs to use binary mode. Let me know if you want me to submit patches for that. Last, but not least: thanks for developing and maintaining libnettle!

4 11

_nettle_write_be32
by Nikos Mavrogiannopoulos 26 Oct '11

26 Oct '11

Hello, Would it be possible to export _nettle_write_be32? It is a useful function and can be used on the accelerated versions of SHA in architectures that support it (i.e. VIA cpus). I currently include a copy of it, but would be nice if it was exported from the nettle API as well. btw. the MD_* macros were also proved to be very useful in that case. regards, Nikos

2 4

PATCH: Build proper Mac OS X dynamic libraries (dylibs)
by Ryan Schmidt 18 Oct '11

18 Oct '11

Hello, I've patched nettle in MacPorts to build proper Mac OS X dynamic libraries, and wanted to share the patch with you.

2 4

memxor
by Nikos Mavrogiannopoulos 14 Sep '11

14 Sep '11

On Tue, Sep 13, 2011 at 1:17 PM, Niels Möller <nisse(a)lysator.liu.se> wrote: > Then you shouldn't need to bother about the lsh directory again. You > have a symlink to the shared aclocal.m4 (and to some other shared > files). Ok I figured out. I attach a working SSE2 detection. > Thanks. I'll have to think some more on how to organize this. Some > properties I'd like to have: > 1. Don't require users to call any init function. > One could define memxor to jump via a function pointer, and have an > initial value for that pointer which jumps to the routine to set the > pointer to the right function, and then use it. Overwriting the > pointer should be atomic, so no locking needed even for multithreaded > programs. I don't think locking is an issue if you only call a function on initialization. You can expect (and require) that a library isn't going to be initialized by multiple threads. I don't know however of a portable way to do initialization transparently without an explicit function call. > 3. Avoid using gcc-specific things, including inline asm, in the C > source files. The cpuid test would have then to be moved to an assembly file. > Other obvious uses for cpu detection in nettle: > * The AES code could check for the special aes instructions. Indeed. Once a framework for overwriting functionality is set, those would be not very hard to add. However setting such framework in nettle seems to require substantial work as all exported functions need to be replaced by function pointers thus breaking ABI. If this is done gradually (it has to, as you never know what you would be able to optimize in a new processor) it would be worse, since every optimization added would break ABI. Maybe it makes sense to have a libgcrypt-like high level interface and optimizations would be used only there. The existing C api remains an API to access the C implementation. This could also address the problem with optimized hash algorithms[0], since most cpu-assisted sha1 or sha256 implementations work on an output=hash(data,length) basis and do not map to the existing API. [0]. http://www.mail-archive.com/openssl-dev@openssl.org/msg21787.html > * The serpent code can use %xmm and %ymm registers, when present. On > x86_64, as far as I'm aware all current implementations have sse2, > but one could check for, and make use of, the 256-bit %ymm > registers. I wouldn't care of serpent optimizations much :) regards, Nikos

2 3

memxor
by Nikos Mavrogiannopoulos 13 Sep '11

13 Sep '11

Hello, I've run some tests with memxor on a x86-64 machine. My results are: * C implementation (compiled with gcc 4.4): Xoring in chunks of 32768 bytes: done. 50.09 Gb in 5.00 secs: 10.02 Gb/sec Xoring (unaligned) in chunks of 32768 bytes: done. 39.90 Gb in 5.00 secs: 7.98 Gb/sec * ASM implementation: Xoring in chunks of 32768 bytes: done. 38.32 Gb in 5.00 secs: 7.66 Gb/sec Xoring (unaligned) in chunks of 32768 bytes: done. 30.16 Gb in 5.00 secs: 6.03 Gb/sec It seems that in x86-64 the ASM version is slower than the C one. Moreover I noticed that the loop unrolling techniques used in the C code have no visible performance benefit. However, an SSE2 version of memxor (attached) increases performance by 30% or more in the same CPU. * SSE2: Xoring in chunks of 32768 bytes: done. 69.94 Gb in 5.00 secs: 13.98 Gb/sec Xoring (unaligned) in chunks of 32768 bytes: done. 65.96 Gb in 5.00 secs: 13.19 Gb/sec regards, Nikos

2 8

ANNOUNCE: Nettle-2.4
by nisse＠lysator.liu.se 03 Sep '11

03 Sep '11

Due to a bug discovered in Nettle-2.3, released yesterday, I'm a bit embarrassed to announce a new release of GNU Nettle. Nettle is a low-level cryptographic library. Homepage at http://www.lysator.liu.se/~nisse/nettle/. NEWS for the 2.4 release This is a bugfix release only. It turned out ripemd160 in the 2.3 release was broken on all big-endian systems, due to a missing include of config.h. nettle-2.4 fixes this. The library is intended to be binary compatible with nettle-2.2 and nettle-2.3. The shared library names are libnettle.so.4.3 and libhogweed.so.2.1, with sonames still libnettle.so.4 and libhogweed.so.2. NEWS for the 2.3 release * Support for the ripemd-160 hash function. * Generates and installs nettle.pc and hogweed.pc files, for use with pkg-config. Feedback appreciated. For projects using autoconf, the traditional non-pkg-config ways of detecting libraries, and setting LIBS and LDFLAGS, is still recommended. * Fixed a bug which made the testsuite fail in the GCM test on certain platforms. Should not affect any documented features of the library. * Reorganization of the code for the various Merkle-Damgård hash functions. Some fields in the context structs for md4, md5 and sha1 have been renamed, for consistency. Applications should not peek inside these structs, and the ABI is unchanged. * In the manual, fixed mis-placed const in certain function prototypes. The library is intended to be binary compatible with nettle-2.2. The shared library names are libnettle.so.4.2 and libhogweed.so.2.1, with sonames still libnettle.so.4 and libhogweed.so.2. The latest version is available at http://www.lysator.liu.se/~nisse/archive/nettle-2.4.tar.gz ftp://ftp.lysator.liu.se/pub/security/lsh/nettle-2.4.tar.gz ftp://ftp.gnu.org/gnu/nettle/nettle-2.4.tar.gz Happy hacking, /Niels möller -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

ANNOUNCE: Nettle-2.3
by nisse＠lysator.liu.se 03 Sep '11

03 Sep '11

I'm happy to announce a new version of GNU Nettle, a low-level cryptographics library. The Nettle home page can be found at http://www.lysator.liu.se/~nisse/nettle/. NEWS for the 2.3 release * Support for the ripemd-160 hash function. * Generates and installs nettle.pc and hogweed.pc files, for use with pkg-config. Feedback appreciated. For projects using autoconf, the traditional non-pkg-config ways of detecting libraries, and setting LIBS and LDFLAGS, is still recommended. * Fixed a bug which made the testsuite fail in the GCM test on certain platforms. Should not affect any documented features of the library. * Reorganization of the code for the various Merkle-Damgård hash functions. Some fields in the context structs for md4, md5 and sha1 have been renamed, for consistency. Applications should not peek inside these structs, and the ABI is unchanged. * In the manual, fixed mis-placed const in certain function prototypes. The library is intended to be binary compatible with nettle-2.2. The shared library names are libnettle.so.4.2 and libhogweed.so.2.1, with sonames still libnettle.so.4 and libhogweed.so.2. Available at http://www.lysator.liu.se/~nisse/archive/nettle-2.3.tar.gz and soon also at ftp://ftp.lysator.liu.se/pub/security/lsh/nettle-2.3.tar.gz ftp://ftp.gnu.org/gnu/nettle/nettle-2.3.tar.gz Happy hacking, /Niels Möller -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 1

RIPEMD-160 Implementation
by Andres Mejia 01 Sep '11

01 Sep '11

Here's a patch that will implement RIPEMD-160 for nettle. It's code ported from libgcrypt. A reference to RIPEMD-160 is in the source. Also, this patch includes testcases and I followed what looked to me as nettle coding conventions. There's no documentation update in this patch. I didn't look into how documentation was generated in nettle. Also, this patch is against the nettle-2.2 release. I couldn't get the CVS snapshot of nettle building, particularly because of the integration of LSH. -- Regards, Andres Mejia

2 8

make in freebsd
by Nikos Mavrogiannopoulos 28 Aug '11

28 Aug '11

Hello, I tried to do a "./configure && make" in freebsd an got an error during make. If I use GNU make instead it works. I attach the error output from the make command and the generated Makefile. regards, Nikos

2 3

Re: RIPEMD-160 Implementation
by Nikos Mavrogiannopoulos 27 Aug '11

27 Aug '11

On 08/27/2011 09:05 PM, Niels Möller wrote: > Are any other variants of ripemd in use? (According to wikipedia, > there's original ripemd, ripemd-128, ripend-160, ripemd-256 and > ripemd-320, but I have no idea which of them are in use today or are > likely to be used in the future). ripemd and ripemd-128 are considered broken. I don't know if ripemd-x, x>=256 have been used anywhere. Having the SHA-3 winner instead would be a much better choice. regards, Nikos

2 2

Few Questions About Nettle Project
by Andres Mejia 26 Aug '11

26 Aug '11

Hi, Keep up the great work. I was looking for an LGPL-2.1 crypto library that can be used as an alternative to libgcrypt. Reason being can best be explained at [1]. So here are some questions I have. GNU Nettle is going to stick with LGPL-2.1+ correct? I ask this since I'm currently working on implementing full RAR archive support with libarchive, to ultimately be used in XBMC Media Center. XBMC is GPL-2+ and we have no desire to go to GPL-3. Another question, the only thing I see missing in nettle that libarchive can make use of is RIPEMD-160. In case I want to submit patches, I should submit them here correct? Also, I suppose if I wanted to submit patches, there's no issue in porting code from gcrypt over to nettle correct? I think it would be easier (and faster) to reuse the implementation in gcrypt than to implement the algorithm from scratch. -- Regards, Andres Mejia 1. http://lists.debian.org/debian-devel/2011/04/msg01170.html

3 5

ECC support
by Nikos Mavrogiannopoulos 15 Aug '11

15 Aug '11

Hello, This patch adds ECC support using the GnuTLS libtomcrypt adaptation. regards, Nikos btw. I had issues building the cvs version. The compilation was failing: nettle-hash.o: In function `list_algorithms': /home/nmav/cvs/lsh/nettle/tools/nettle-hash.c:49: undefined reference to `nettle_hashes'

2 5

pkg-config
by nisse＠lysator.liu.se 20 Jul '11

20 Jul '11

I just checked in nettle.pc.in and hogweed.pc.in. configure then generates nettle.pc and hogweed.pc, for use wiith pkg-config. I don't have any previous experience with pkg-config, so comments are much appreciated. Not yet any make rules to install them. I don't know if installation should be unconditional, or if one should first check, somehow, if pkg-config is installed. (And then hogweed.pc should be installed only if the hogweed library is built and installed). Apparantly, at least one user wants pkg-config support, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=634294 Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

ECC
by Nikos Mavrogiannopoulos 17 Jul '11

17 Jul '11

I'm working towards adding ECDH and ECDSA support to gnutls. I've currently ported libtomcrypt to use gmp directly and nettle's types. The code is under development, and can be found at: http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=tree;f=lib/nettle;h=23d9… The ECC functionality is confined to the ecc* files. It would be nice if nettle included it or something similar. btw. Is there any plan on an 2.2 release? regards, Nikos

3 27

ANNOUNCE: Nettle-2.2
by nisse＠lysator.liu.se 11 Jul '11

11 Jul '11

I'm happy to announce a new version of GNU Nettle, a low-level cryptographic library. Unlike earlier releases, nettle is now licenced under the LGPL, rather then the GPL. The nettle home page can be found at http://www.lysator.liu.se/~nisse/nettle/ NEWS for the 2.2 release Licensing change: * Relicensed as LGPL v2.1 or later (user's option). * Replaced blowfish and serpent implementation. New code is based on the LGPLed code in libgcrypt. New features: * Support for Galois/Counter Mode (GCM). * New interface for enumerating (most) available algorithms, contributed by Daniel Kahn Gillmor. * New tool nettle-hash. Can generate hash digests using any supported hash function, with output compatible with md5sum and friends from GNU coreutils. Checking (like md5sum -c) not yet implemented. Bug fixes: * The old serpent code had a byte order bug (introduced by yours truly about ten years ago). New serpent implementation does not interoperate with earlier versions of nettle. * Fixed ABI-dependent libdir default for Linux-based systems which do not follow the Linux File Hierarchy Standard, e.g., Debian GNU/Linux. Optimizations: * x86_64 implemention of serpent. * x86_64 implemention of camellia. * Optimized memxor using word rather than byte operations. Both generic C and x86_64 assembler. * Eliminated a memcpy for in-place CBC decrypt. Miscellaneous: * In command line tools, no longer support -? for requesting help, since using it without shell quoting is a dangerous habit. Use long option --help instead. The shared library names are libnettle.so.4.1 and libhogweed.so.2.1, with sonames libnettle.so.4 and libhogweed.so.2. Available at http://www.lysator.liu.se/~nisse/archive/nettle-2.2.tar.gz ftp://ftp.gnu.org/gnu/nettle/nettle-2.2.tar.gz Happy hacking, /Niels Möller -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

Fwd: Problem compiling gnutls 2.12.7 on Solaris 9
by Nikos Mavrogiannopoulos 01 Jul '11

01 Jul '11

Hello Niels, nettle-stdint.h conflicts with gnulib's stdint.h on solaris. Is there any real reason for nettle to define the uint_t types in the exported API? Even if it wasn't for gnulib I would expect most applications to define those types if not available, thus a conflict would anyway occur. ---------- Forwarded message ---------- From: Dagobert Michelsen <dam(a)opencsw.org> Date: Wed, Jun 29, 2011 at 5:10 PM Subject: Problem compiling gnutls 2.12.7 on Solaris 9 To: gnutls-devel(a)gnu.org Hi, I am trying to compile gnutls 2.12.7 with libnettle 2.1 on Solaris 9 Sparc with Sun Studio 12 and get the following error: gmake[6]: Entering directory `/home/dam/mgar/pkg/gnutls/trunk/work/solaris9-sparc/build-isa-sparcv8/gnutls-2.12.7/lib/nettle' CC pk.lo "/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 "/opt/csw/include/nettle/nettle-stdint.h", line 238: warning: modification of typedef with "int" ignored "/opt/csw/include/nettle/nettle-stdint.h", line 238: identifier redeclared: gl_int_fast16_t current : int previous: long : "./../gl/stdint.h", line 243 "/opt/csw/include/nettle/nettle-stdint.h", line 239: warning: modification of typedef with "int" ignored "/opt/csw/include/nettle/nettle-stdint.h", line 239: identifier redeclared: gl_int_fast32_t current : int previous: long : "./../gl/stdint.h", line 245 "/opt/csw/include/nettle/nettle-stdint.h", line 241: warning: typedef redeclared: int64_t "/opt/csw/include/nettle/nettle-stdint.h", line 244: identifier redeclared: gl_uint_fast8_t current : unsigned char previous: unsigned long : "./../gl/stdint.h", line 242 "/opt/csw/include/nettle/nettle-stdint.h", line 245: identifier redeclared: gl_uint_fast16_t current : unsigned int previous: unsigned long : "./../gl/stdint.h", line 244 "/opt/csw/include/nettle/nettle-stdint.h", line 246: identifier redeclared: gl_uint_fast32_t current : unsigned int previous: unsigned long : "./../gl/stdint.h", line 246 "/opt/csw/include/nettle/nettle-stdint.h", line 248: warning: typedef redeclared: uint64_t cc: acomp failed for pk.c It looks like a gnulib incompatibility. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 _______________________________________________ Gnutls-devel mailing list Gnutls-devel(a)gnu.org https://lists.gnu.org/mailman/listinfo/gnutls-devel

2 1

serpent on x86_64, using sse2 instructions
by nisse＠lysator.liu.se 30 Jun '11

30 Jun '11

I've now tried to write some sse2 assembly code for serpent, to do four blocks at a time in parallell (which helps for ecb and ctr mode, and cbc decrypt, but not at all for cbc encrypt). First time I've tried to use these x86 instructions for anything. I'm currently under the belief that all existing x86_64 processors have the needed instructions, so there are no configure time or run time tests of the corresponding cpuid flags. Speed is then close to aes128 (aes128 is slightly faster for encypt, and serpent slightly faster for decrypt), and a bit faster than other aes variants as well as camellia. I imagine that with processors with whatever sse extension is needed to get the 256-bit ymm registers, one can get almost twice the performance for serpent, compared to the current using only the 128-bit xmm registers. And in the other direction, the code could easily be ported to 32-bit x86 with sse2, with just a small penalty from the fewer registers. Benchmark results on my laptop (intel SU4100): Algorithm mode Mbyte/s cycles/byte cycles/block aes128 ECB encrypt 73.47 16.87 269.98 aes128 ECB decrypt 71.73 17.28 276.53 aes128 CBC encrypt 61.99 20.00 320.01 aes128 CBC decrypt 70.52 17.58 281.29 aes192 ECB encrypt 63.23 19.61 313.72 aes192 ECB decrypt 61.86 20.04 320.69 aes192 CBC encrypt 54.30 22.83 365.31 aes192 CBC decrypt 61.04 20.31 324.97 aes256 ECB encrypt 54.35 22.81 364.97 aes256 ECB decrypt 54.28 22.84 365.42 aes256 CBC encrypt 48.52 25.55 408.80 aes256 CBC decrypt 53.56 23.15 370.34 camellia128 ECB encrypt 57.53 21.55 344.80 camellia128 ECB decrypt 57.52 21.55 344.86 camellia128 CBC encrypt 51.99 23.84 381.51 camellia128 CBC decrypt 56.72 21.86 349.74 camellia192 ECB encrypt 43.05 28.80 460.72 camellia192 ECB decrypt 43.01 28.82 461.16 camellia192 CBC encrypt 39.94 31.04 496.68 camellia192 CBC decrypt 42.53 29.15 466.40 camellia256 ECB encrypt 43.03 28.81 461.00 camellia256 ECB decrypt 43.02 28.82 461.14 camellia256 CBC encrypt 39.90 31.07 497.11 camellia256 CBC decrypt 42.61 29.10 465.54 serpent256 ECB encrypt 68.88 18.00 287.98 serpent256 ECB decrypt 79.81 15.53 248.54 serpent256 CBC encrypt 23.20 53.43 854.86 serpent256 CBC decrypt 78.25 15.84 253.50 It's conceivable that one can use simd instructions to get some speedup also for aes and camellia, but it's not going to be almost trivial like it is for serpent. (And for aes, I don't yet have any code using the special instructions available in newer x86_64 processors). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 1

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

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 11 Feb '11

11 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

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

10 Feb '11

[ Resending, got list address wrong first time. ] Simon Josefsson <simon(a)josefsson.org> writes: > nisse(a)lysator.liu.se (Niels Möller) writes: > >> Simon Josefsson <simon(a)josefsson.org> writes: >> >>> I'll look at serpent next. >> >> Great! > > Turns out it was a bit more complicated, will debug some more... BTW, how far did you get with serpent? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

GCM mode and GMAC
by nisse＠lysator.liu.se 10 Feb '11

10 Feb '11

Hi, Nikos Mavrogiannopoulos have been looking into support for Galois Counter Mode (GCM), see http://www.cryptobarn.com/papers/gcm-spec.pdf My understanding of GCM is that the main point is a new MAC function which allows efficient hardware implementation. As far as I see, there's no clear advantage of using GCM instead of plain CTR mode combined with the same MAC function (applied to the plaintext). For Nettle, I think the first step ought to be to properly support the MAC function, GMAC. The most fundamental difference to other MAC functions is that it takes two input strings (besides the key). When used as a plain MAC, the second input is empty, while when used with GCM, the first input is auxillary data to be authenticated, and the second input is the cryptotext. Some questions: * Naming: Is "gmac" a good enough name? Or "ghash" (the name of the primitive which takes a key and two inputs, in the paper)? Or do we need something more verbose, like galois_mac or gmac128 or so? * Specification: It's not entirely clear to me how the spec is to be interpreted when one of the input strings is empty. The most reasonable interpretation would be that there should be zero blocks to process (n or m equal to zero). This requires some bending of the notation in equation (2), for example, with m = 0, n = 1, we should have X_0 = 0 X_1 = C_1^* · H X_2 = (X_1 + (0 || len(C))) · H and with m = 1, n = 0, X_0 = 0 X_1 = A_1^* · H X_2 = (X_1 0 (len(A) || 0)) · H Do you agree? * Interface: I think the basic use case with empty second input should be just like other MAC:s, struct gmac_ctx; /* Key size fixed to GMAC_KEY_SIZE == 16 */ void gmac_set_key(struct gmac_ctx *ctx, const uint8_t *key); void gmac_update(struct gmac_ctx *ctx, unsigned length, const uint8_t *data); void gmac_digest(struct gmac_ctx *ctx, unsigned length, uint8_t *digest); The context struct and the set_key function is essential to be able to do any optimizations using key-dependant tables. But then we need a function to mark the end of the first input and the start of the second. Name for that one? void gmac_next(struct gmac_ctx *ctx); This will pad the current input to a block boundary, and switch to using a different length counter. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

4 30

elliptic curve in nettle?
by Daniel Kahn Gillmor 07 Jan '11

07 Jan '11

Hey Niels and other Nettle folks-- Have you given any thought about adding elliptic curve cryptography to nettle as another public-key algorithm? There are many references for elliptic curve online (i confess i'm not up on the implementation details), including: http://www.secg.org/?action=docs_secg and OpenSSL, libecc, sks-ecc, and libcrypto++ have free implementations that might be worth perusing for reference or for comparison / test suites: http://openssl.org/ http://libecc.sourceforge.net/ http://sks.merseine.nu/ http://www.cryptopp.com/ It would be great to have a GPL-compatible, C implementation of ECC, and nettle seems like a good fit. Any thoughts, plans, or concerns about this? --dkg

4 7

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