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

salsa20r12
by Nikos Mavrogiannopoulos 25 Mar '13

25 Mar '13

Hello, This patch adds a function to use the Salsa20 with 12 rounds. regards, Nikos

2 3

[PATCH] Factorize timing functions to a separate file
by Martin Storsjö 25 Mar '13

25 Mar '13

This avoids unconditionally using clock_gettime in {ecc,hogweed}-benchmark, falling back to clock() in these as well. This makes building succeed on e.g. OS X. --- examples/Makefile.in | 16 +++--- examples/ecc-benchmark.c | 26 ++-------- examples/hogweed-benchmark.c | 26 ++-------- examples/nettle-benchmark.c | 69 ++------------------------ examples/timing.c | 110 ++++++++++++++++++++++++++++++++++++++++++ examples/timing.h | 30 ++++++++++++ 6 files changed, 162 insertions(+), 115 deletions(-) create mode 100644 examples/timing.c create mode 100644 examples/timing.h diff --git a/examples/Makefile.in b/examples/Makefile.in index 3455a58..563d0dc 100644 --- a/examples/Makefile.in +++ b/examples/Makefile.in @@ -28,7 +28,7 @@ SOURCES = nettle-benchmark.c hogweed-benchmark.c ecc-benchmark.c \ nettle-openssl.c \ io.c read_rsa_key.c \ rsa-encrypt.c rsa-decrypt.c rsa-keygen.c rsa-sign.c rsa-verify.c \ - base16enc.c base16dec.c base64enc.c base64dec.c + base16enc.c base16dec.c base64enc.c base64dec.c timing.c GETOPT_OBJS = ../getopt.$(OBJEXT) ../getopt1.$(OBJEXT) @@ -36,7 +36,7 @@ GETOPT_OBJS = ../getopt.$(OBJEXT) ../getopt1.$(OBJEXT) TS_ALL = rsa-sign-test rsa-verify-test rsa-encrypt-test DISTFILES= $(SOURCES) Makefile.in $(TS_ALL) setup-env teardown-env \ - io.h rsa-session.h + io.h rsa-session.h timing.h all: $(TARGETS) @@ -102,16 +102,18 @@ eratosthenes$(EXEEXT): eratosthenes.$(OBJEXT) $(GETOPT_OBJS) $(LINK) eratosthenes.$(OBJEXT) $(GETOPT_OBJS) -o eratosthenes$(EXEEXT) BENCH_OBJS = nettle-benchmark.$(OBJEXT) nettle-openssl.$(OBJEXT) \ - $(GETOPT_OBJS) ../nettle-internal.$(OBJEXT) + $(GETOPT_OBJS) ../nettle-internal.$(OBJEXT) timing.$(OBJEXT) nettle-benchmark$(EXEEXT): $(BENCH_OBJS) $(LINK) $(BENCH_OBJS) -lnettle $(BENCH_LIBS) $(OPENSSL_LIBFLAGS) -o nettle-benchmark$(EXEEXT) -ecc-benchmark$(EXEEXT): ecc-benchmark.$(OBJEXT) - $(LINK) ecc-benchmark.$(OBJEXT) -lhogweed -lnettle $(BENCH_LIBS) $(LIBS) \ +ECC_BENCH_OBJS = ecc-benchmark.$(OBJEXT) timing.$(OBJEXT) +ecc-benchmark$(EXEEXT): $(ECC_BENCH_OBJS) + $(LINK) $(ECC_BENCH_OBJS) -lhogweed -lnettle $(BENCH_LIBS) $(LIBS) \ -o ecc-benchmark$(EXEEXT) -hogweed-benchmark$(EXEEXT): hogweed-benchmark.$(OBJEXT) - $(LINK) hogweed-benchmark.$(OBJEXT) \ +HOGWEED_BENCH_OBJS = hogweed-benchmark.$(OBJEXT) timing.$(OBJEXT) +hogweed-benchmark$(EXEEXT): $(HOGWEED_BENCH_OBJS) + $(LINK) $(HOGWEED_BENCH_OBJS) \ -lhogweed -lnettle $(BENCH_LIBS) $(LIBS) $(OPENSSL_LIBFLAGS) \ -o hogweed-benchmark$(EXEEXT) diff --git a/examples/ecc-benchmark.c b/examples/ecc-benchmark.c index 596b2ff..e14e55e 100644 --- a/examples/ecc-benchmark.c +++ b/examples/ecc-benchmark.c @@ -35,6 +35,8 @@ #include <time.h> +#include "timing.h" + #include "../ecc.h" #include "../ecc-internal.h" #include "../gmp-glue.h" @@ -70,24 +72,6 @@ xalloc_limbs (mp_size_t size) return xalloc (size * sizeof(mp_limb_t)); } -inline static void -time_start(struct timespec *start) -{ - if (clock_gettime(CLOCK_PROCESS_CPUTIME_ID, start) < 0) - die("clock_gettime failed: %s\n", strerror(errno)); -} - -static inline double -time_end(struct timespec *start) -{ - struct timespec end; - if (clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &end) < 0) - die("clock_gettime failed: %s\n", strerror(errno)); - - return end.tv_sec - start->tv_sec - + 1e-9 * (end.tv_nsec - start->tv_nsec); -} - /* Returns second per function call */ static double time_function(void (*f)(void *arg), void *arg) @@ -100,12 +84,11 @@ time_function(void (*f)(void *arg), void *arg) for (ncalls = 10 ;;) { unsigned i; - struct timespec t; - time_start(&t); + time_start(); for (i = 0; i < ncalls; i++) f(arg); - elapsed = time_end(&t); + elapsed = time_end(); if (elapsed > BENCH_INTERVAL) break; else if (elapsed < BENCH_INTERVAL / 10) @@ -293,6 +276,7 @@ main (int argc UNUSED, char **argv UNUSED) { unsigned i; + time_init(); printf ("%4s %6s %6s %6s %6s %6s %6s %6s %6s %6s %6s (us)\n", "size", "modp", "redc", "modq", "modinv", "mi_gcd", "dup_jj", "ad_jja", "ad_jjj", diff --git a/examples/hogweed-benchmark.c b/examples/hogweed-benchmark.c index f6ceda9..56860e0 100644 --- a/examples/hogweed-benchmark.c +++ b/examples/hogweed-benchmark.c @@ -34,6 +34,8 @@ #include <time.h> +#include "timing.h" + #include "dsa.h" #include "rsa.h" @@ -90,24 +92,6 @@ hash_string (const struct nettle_hash *hash, return digest; } -inline static void -time_start(struct timespec *start) -{ - if (clock_gettime(CLOCK_PROCESS_CPUTIME_ID, start) < 0) - die("clock_gettime failed: %s\n", strerror(errno)); -} - -static inline double -time_end(struct timespec *start) -{ - struct timespec end; - if (clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &end) < 0) - die("clock_gettime failed: %s\n", strerror(errno)); - - return end.tv_sec - start->tv_sec - + 1e-9 * (end.tv_nsec - start->tv_nsec); -} - struct alg { const char *name; unsigned size; @@ -129,12 +113,11 @@ time_function(void (*f)(void *arg), void *arg) for (ncalls = 10 ;;) { unsigned i; - struct timespec t; - time_start(&t); + time_start(); for (i = 0; i < ncalls; i++) f(arg); - elapsed = time_end(&t); + elapsed = time_end(); if (elapsed > BENCH_INTERVAL) break; else if (elapsed < BENCH_INTERVAL / 10) @@ -625,6 +608,7 @@ main (int argc, char **argv) if (argc > 1) filter = argv[1]; + time_init(); printf ("%15s %4s %9s %9s\n", "name", "size", "sign/ms", "verify/ms"); diff --git a/examples/nettle-benchmark.c b/examples/nettle-benchmark.c index 90d6c72..852baef 100644 --- a/examples/nettle-benchmark.c +++ b/examples/nettle-benchmark.c @@ -38,6 +38,8 @@ #include <time.h> +#include "timing.h" + #include "aes.h" #include "arcfour.h" #include "blowfish.h" @@ -112,58 +114,6 @@ die(const char *format, ...) static double overhead = 0.0; -#if HAVE_CLOCK_GETTIME && defined CLOCK_PROCESS_CPUTIME_ID -#define TRY_CLOCK_GETTIME 1 -struct timespec cgt_start; - -static int -cgt_works_p(void) -{ - struct timespec now; - return clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &now) == 0; -} - -static void -cgt_time_start(void) -{ - if (clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &cgt_start) < 0) - die("clock_gettime failed: %s\n", strerror(errno)); -} - -static double -cgt_time_end(void) -{ - struct timespec end; - if (clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &end) < 0) - die("clock_gettime failed: %s\n", strerror(errno)); - - return end.tv_sec - cgt_start.tv_sec - + 1e-9 * (end.tv_nsec - cgt_start.tv_nsec); -} - -static void (*time_start)(void); -static double (*time_end)(void); - -#else /* !HAVE_CLOCK_GETTIME */ -#define TRY_CLOCK_GETTIME 0 -#define time_start clock_time_start -#define time_end clock_time_end -#endif /* !HAVE_CLOCK_GETTIME */ - -static clock_t clock_start; - -static void -clock_time_start(void) -{ - clock_start = clock(); -} - -static double -clock_time_end(void) -{ - return (double) (clock() - (clock_start)) / CLOCKS_PER_SEC; -} - /* Returns second per function call */ static double time_function(void (*f)(void *arg), void *arg) @@ -700,20 +650,7 @@ main(int argc, char **argv) alg = argv[optind]; - /* Choose timing function */ -#if TRY_CLOCK_GETTIME - if (cgt_works_p()) - { - time_start = cgt_time_start; - time_end = cgt_time_end; - } - else - { - fprintf(stderr, "clock_gettime not working, falling back to clock\n"); - time_start = clock_time_start; - time_end = clock_time_end; - } -#endif + time_init(); bench_sha1_compress(); bench_salsa20_core(); bench_sha3_permute(); diff --git a/examples/timing.c b/examples/timing.c new file mode 100644 index 0000000..108399a --- /dev/null +++ b/examples/timing.c @@ -0,0 +1,110 @@ +/* timing.c */ + +/* nettle, low-level cryptographics library + * + * Copyright (C) 2013 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., 51 Franklin Street, Fifth Floor, Boston, + * MA 02111-1301, USA. + */ + +#if HAVE_CONFIG_H +# include "config.h" +#endif + +#include "timing.h" + +#include <errno.h> +#include <stdarg.h> +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <time.h> + +#if HAVE_CLOCK_GETTIME && defined CLOCK_PROCESS_CPUTIME_ID +#define TRY_CLOCK_GETTIME 1 +struct timespec cgt_start; + +static void NORETURN PRINTF_STYLE(1,2) +die(const char *format, ...) +{ + va_list args; + va_start(args, format); + vfprintf(stderr, format, args); + va_end(args); + + exit(EXIT_FAILURE); +} + +static int +cgt_works_p(void) +{ + struct timespec now; + return clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &now) == 0; +} + +static void +cgt_time_start(void) +{ + if (clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &cgt_start) < 0) + die("clock_gettime failed: %s\n", strerror(errno)); +} + +static double +cgt_time_end(void) +{ + struct timespec end; + if (clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &end) < 0) + die("clock_gettime failed: %s\n", strerror(errno)); + + return end.tv_sec - cgt_start.tv_sec + + 1e-9 * (end.tv_nsec - cgt_start.tv_nsec); +} +#endif /* !HAVE_CLOCK_GETTIME */ + +static clock_t clock_start; + +static void +clock_time_start(void) +{ + clock_start = clock(); +} + +static double +clock_time_end(void) +{ + return (double) (clock() - (clock_start)) / CLOCKS_PER_SEC; +} + +void (*time_start)(void) = clock_time_start; +double (*time_end)(void) = clock_time_end; + +void time_init(void) +{ + /* Choose timing function */ +#if TRY_CLOCK_GETTIME + if (cgt_works_p()) + { + time_start = cgt_time_start; + time_end = cgt_time_end; + } + else + { + fprintf(stderr, "clock_gettime not working, falling back to clock\n"); + time_start = clock_time_start; + time_end = clock_time_end; + } +#endif +} diff --git a/examples/timing.h b/examples/timing.h new file mode 100644 index 0000000..7307fa1 --- /dev/null +++ b/examples/timing.h @@ -0,0 +1,30 @@ +/* timing.c */ + +/* nettle, low-level cryptographics library + * + * Copyright (C) 2013 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., 51 Franklin Street, Fifth Floor, Boston, + * MA 02111-1301, USA. + */ + +#ifndef NETTLE_EXAMPLES_TIMING_H_INCLUDED +#define NETTLE_EXAMPLES_TIMING_H_INCLUDED + +void time_init(void); +extern void (*time_start)(void); +extern double (*time_end)(void); + +#endif /* NETTLE_EXAMPLES_TIMING_H_INCLUDED */ -- 1.7.9.4

2 1

[PATCH] Add a fallback definition for mpn_sqr
by Martin Storsjö 25 Mar '13

25 Mar '13

--- gmp-glue.h | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/gmp-glue.h b/gmp-glue.h index 0cde62f..d154a50 100644 --- a/gmp-glue.h +++ b/gmp-glue.h @@ -58,6 +58,10 @@ typedef unsigned long int mp_bitcnt_t; #define mpn_zero _nettle_mpn_zero #endif +#ifndef mpn_sqr +#define mpn_sqr(rp, ap, n) mpn_mul_n((rp), (ap), (ap), (n)) +#endif + #define mpz_limbs_cmp _nettle_mpz_limbs_cmp #define mpz_limbs_read_n _nettle_mpz_limbs_read_n #define mpz_limbs_copy _nettle_mpz_limbs_copy -- 1.7.9.4

1 0

[PATCH] Use local paths for including headers in examples and tests
by Martin Storsjö 23 Mar '13

23 Mar '13

This makes sure a plain "make" succeeds without doing "make install". --- examples/hogweed-benchmark.c | 10 +++++----- testsuite/ecdsa-keygen-test.c | 2 +- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/examples/hogweed-benchmark.c b/examples/hogweed-benchmark.c index 803f056..b1a0e89 100644 --- a/examples/hogweed-benchmark.c +++ b/examples/hogweed-benchmark.c @@ -34,12 +34,12 @@ #include <time.h> -#include <nettle/dsa.h> -#include <nettle/rsa.h> +#include "dsa.h" +#include "rsa.h" -#include <nettle/nettle-meta.h> -#include <nettle/sexp.h> -#include <nettle/knuth-lfib.h> +#include "nettle-meta.h" +#include "sexp.h" +#include "knuth-lfib.h" #include "../ecdsa.h" #include "../ecc-internal.h" diff --git a/testsuite/ecdsa-keygen-test.c b/testsuite/ecdsa-keygen-test.c index 4f46d0d..7c25421 100644 --- a/testsuite/ecdsa-keygen-test.c +++ b/testsuite/ecdsa-keygen-test.c @@ -1,5 +1,5 @@ #include "testutils.h" -#include <nettle/knuth-lfib.h> +#include "knuth-lfib.h" /* Check if y^2 = x^3 - 3x + b */ static int -- 1.7.9.4

1 0

ARM assembly
by nisse＠lysator.liu.se 16 Mar '13

16 Mar '13

I've new written some ARM assembly files for AES, SHA1 and SHA256. I haven't tried any clever scheduling (it seems quite unpredictable), so I think I win over the C code is mainly because I fit the important values in registers. I have benchmarked on a cortex-a9 system, with nice but not earth-shattering improvements over the C implementation. In my benchmarks, AES decrypt is significantly slower than AES decrypt, for no reason that I understand, and I have tried some other variants of instruction scheduling. I have one question on the ABI, if there's anyone on the list with more ARM experience: In the ABI spec, register r9 is reserved for use for things such as thread local storage. I'm almost sure that a leaf function can use r9 like any other callee-save register, but I'd like to have that confirmed before I make use of it. Potential problem case is if the function is interrupted by a signal and signal handler somehow depends on having a valid value in r9, or if context switching somehow assumes that r9 is never modified. Any suggestion for what to try optimizing next? I imagine all algorithms that make use of 64-bit data or are designed for simd operations could be sped up a bit using the neon simd instructions (which I so far haven't made any use of). This includes sha512, sha3, serpent, salsa, maybe camellia. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

3 3

ECC integration
by nisse＠lysator.liu.se 18 Feb '13

18 Feb '13

I'm working on integration of the new ECC code into nettle, on a separate branch, see http://git.lysator.liu.se/nettle/nettle/commits/ecc-support I've probably broken cross-compilation support, but otherwise it should be working. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

ECC low-level interface
by nisse＠lysator.liu.se 18 Feb '13

18 Feb '13

I'd like to post the interface I use for low-level ecc functions. All functions are intended to be side-channel silent. I have tried to stick to the nettle principle of "no allocation" (I mostly call low-level gmp functions which don't allocate storage). Functions which need scratch space gets this space from the caller, as an extra argument. And for the function foo, there's a corresponding function foo_itch, saying how much working storage is needed. Sizes are in units of mp_limb_t. Of these low-level functions, the highest level ones are ecc_mul_g and ecc_mul_a. Feedback is appreciated. The rest of the code is available at http://git.lysator.liu.se/nettle/se-nettle-2013 Regards, /Niels /* ecc.h */ /* nettle, low-level cryptographics library * * Copyright (C) 2013 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., 51 Franklin Street, Fifth Floor, Boston, * MA 02111-1301, USA. */ /* Development of Nettle's ECC support was funded by Internetfonden. */ #ifndef NETTLE_ECC_H_INCLUDED #define NETTLE_ECC_H_INCLUDED #include <stdint.h> #include <gmp.h> /* The contets of this struct is internal. */ struct ecc_curve; extern const struct ecc_curve ecc_secp_192r1; extern const struct ecc_curve ecc_secp_224r1; extern const struct ecc_curve ecc_secp_256r1; extern const struct ecc_curve ecc_secp_384r1; extern const struct ecc_curve ecc_secp_521r1; /* Points on a curve are represented as arrays of mp_limb_t. For some curves, point coordinates are represented in montgomery form. We use either affine coordinates x,y, or Jacobian coordinates X, Y, Z, where x = X/Z^2 and y = X/Z^2. Since we use additive notation for the groups, the infinity point on the curve is denoted 0. The infinity point can be represented with x = y = 0 in affine coordinates, and Z = 0 in Jacobian coordinates. However, note that most of the ECC functions do *not* support infinity as an input or output. */ /* FIXME: Also provided some compile time constants? */ /* Returns the size of a single coordinate. */ mp_size_t ecc_size (const struct ecc_curve *ecc); /* Size of a point, using affine coordinates x, y. */ mp_size_t ecc_size_a (const struct ecc_curve *ecc); /* Size of a point, using jacobian coordinates X, Y and Z. */ mp_size_t ecc_size_j (const struct ecc_curve *ecc); /* FIXME: Rename the low-level (and side-channel silent) functions to _ecc_*, and provide public ecc_* functions which handle the infinity points properly? */ /* Converts the affine coordinates of a point into montgomery form, if used for this curve. */ mp_size_t ecc_a_to_a_itch (const struct ecc_curve *ecc); void ecc_a_to_a (const struct ecc_curve *ecc, mp_limb_t *r, const mp_limb_t *p, mp_limb_t *scratch); /* Converts a point P in affine coordinates into a point R in jacobian coordinates. If INITIAL is non-zero, and the curve uses montgomery coordinates, also convert coordinates to montgomery form. */ void ecc_a_to_j (const struct ecc_curve *ecc, int initial, mp_limb_t *r, const mp_limb_t *p); /* Converts a point P in jacobian coordinates into a point R in affine coordinates. If FLAGS has bit 0 set, and the curve uses montgomery coordinates, also undo the montgomery conversion. If flags has bit 1 set, produce x coordinate only. */ mp_size_t ecc_j_to_a_itch (const struct ecc_curve *ecc); void ecc_j_to_a (const struct ecc_curve *ecc, int flags, mp_limb_t *r, const mp_limb_t *p, mp_limb_t *scratch); /* Group operations */ /* Point doubling, with jacobian output and affine input. Corner cases: Correctly sets R = 0 (r_Z = 0) if p = 0 or 2p = 0. */ mp_size_t ecc_dup_ja_itch (const struct ecc_curve *ecc); void ecc_dup_ja (const struct ecc_curve *ecc, mp_limb_t *r, const mp_limb_t *p, mp_limb_t *scratch); /* Point doubling, with jacobian input and output. Corner cases: Correctly sets R = 0 (r_Z = 0) if p = 0 or 2p = 0. */ mp_size_t ecc_dup_jj_itch (const struct ecc_curve *ecc); void ecc_dup_jj (const struct ecc_curve *ecc, mp_limb_t *r, const mp_limb_t *p, mp_limb_t *scratch); /* Point addition, with jacobian output, one jacobian input and one affine input. Corner cases: Fails for the cases P = Q != 0 Duplication of non-zero point P = 0, Q != 0 or P != 0, Q = 0 One input zero Correctly gives R = 0 if P = Q = 0 or P = -Q. */ mp_size_t ecc_add_jja_itch (const struct ecc_curve *ecc); void ecc_add_jja (const struct ecc_curve *ecc, mp_limb_t *r, const mp_limb_t *p, const mp_limb_t *q, mp_limb_t *scratch); /* Point addition with Jacobian input and output. */ mp_size_t ecc_add_jjj_itch (const struct ecc_curve *ecc); void ecc_add_jjj (const struct ecc_curve *ecc, mp_limb_t *r, const mp_limb_t *p, const mp_limb_t *q, mp_limb_t *scratch); /* Computes N * the group generator. N is an array of ecc_size() limbs. It must be in the range 0 < N < group order, then R != 0, and the algorithm can work without any intermediate values getting to zero. */ mp_size_t ecc_mul_g_itch (const struct ecc_curve *ecc); void ecc_mul_g (const struct ecc_curve *ecc, mp_limb_t *r, const mp_limb_t *np, mp_limb_t *scratch); /* Computes N * P. The scalar N is the same as for ecc_mul_g. P is a non-zero point on the curve, in affine coordinates. Pass a non-zero INITIAL if the point coordinates have not previously been converted to Montgomery representation. Output R is a non-zero point, in Jacobian coordinates. */ mp_size_t ecc_mul_a_itch (const struct ecc_curve *ecc); void ecc_mul_a (const struct ecc_curve *ecc, int initial, mp_limb_t *r, const mp_limb_t *np, const mp_limb_t *p, mp_limb_t *scratch); #endif /* NETTLE_ECC_H_INCLUDED */ -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 11

ECC benchmarks
by nisse＠lysator.liu.se 17 Feb '13

17 Feb '13

It's some time since I posted benchmark figures. The speed dropped a bit when I started to use the slow side-channel silent modinv, but I think it's reasonable. For comparison, I just added openssl's ecdsa functions to my benchmark program. These are the current figures for x86_64: size modp redc modq add_jja dup_jj (us) 192 0.0248 0.0265 0.0450 0.6319 0.5151 224 0.0519 0.0467 0.0680 0.9136 0.7149 256 0.0834 0.0409 0.0802 0.8222 0.6617 384 0.0927 0.0000 0.0607 1.6663 1.2559 521 0.0347 0.0514 0.1289 1.5239 1.1670 name size sign / ms verify / ms rsa 1024 6.3180 102.7909 rsa 2048 0.9562 29.2339 dsa 1024 11.1780 5.7492 ecdsa 192 14.9983 4.5612 ecdsa 224 8.0952 2.6880 ecdsa 256 7.7640 2.5785 ecdsa 384 2.9131 0.9155 ecdsa 521 1.7974 0.6594 ecdsa (openssl) 224 3.4939 3.0582 ecdsa (openssl) 384 1.4637 1.2603 ecdsa (openssl) 521 0.6962 0.5981 If we extract common functions for openssl (it seemed to lack secp192r1 and secp256r1), we get ecdsa 224 8.0952 2.6880 ecdsa (openssl) 224 3.4939 3.0582 ecdsa 384 2.9131 0.9155 ecdsa (openssl) 384 1.4637 1.2603 ecdsa 521 1.7974 0.6594 ecdsa (openssl) 521 0.6962 0.5981 So it looks like for signing, the current code beats openssl by a factor of two. While for verify, we're a little behind. And my code tries hard to be side-channel silent (even for verify, where it doesn't matter). I'm not sure if openssl tries to be side-channel silent. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

3 8

ARM support
by nisse＠lysator.liu.se 06 Feb '13

06 Feb '13

I've now pushed in some configure tweaks to support arm (more specifically, configure recognizes armv7l*. As a warmup, I implemented memxor in arm assembly. Seems to work, and it's a modest performance improvement over the C code (in the aligned case, both memxor and memxor3 do 0.75 cycles per byte when I benchmark on Cortex-A9). Could surely be further improved. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

ECC status update for January
by nisse＠lysator.liu.se 04 Feb '13

04 Feb '13

Here's a copy of the status update for January which I just submitted to Internetfonden. Regards, /Niels Nettle project funded by Internetfonden Status update for January 2013 * Summary Project has started. ARM-based test system is up and running. A first implementation of elliptic curve-based signatures is done. * Activities Work on the project was initiated January 9, installing the test hardware: A Pandaboard, based on a dual core Arm Cortex-A9 processor, now running Debian GNU/Linux. I used the instructions on http://www.eewiki.net/display/linuxonarm/PandaBoard for the installation, but after cross compiling kernel etc, I can now use native compiler and debugger for development. I have confirmed that current versions of GNU Nettle and GNU GMP work fine on this hardware. I have been reading ARM manuals (but not yet done any ARM assembly coding), and reading up on relevant methods for elliptic curve operations. For the elliptic curves, I have decided to aim for "side-channel silent" algorithms. This means that for each curve, instructions executed and memory access pattern must not depend on the input data. This is to avoid leaking information about secret keys to an attacker monitoring the timing of operations, as well as to an attacker running an untrusted process which can manipulate and observe cache misses. Most of January have been spent on implementing the elliptic curve machinery needed for creating and verifying ECDSA signatures, over the standard curves secp192r1, secp224r1, secp256r1, secp384r1 and secp521r1. The work-in-progress code as, well as various working notes, is published as a public git repository, see http://git.lysator.liu.se/nettle/se-nettle-2013. During the month, roughly 130 working hours have been spent on the project. * About elliptic curves Elliptic curve operations are based on Jacobi coordinates (http://www.hyperelliptic.org/EFD/g1p/auto-shortw-jacobian-3.html). Multiplication involving the group generator use a special case of Pippenger's algorithm (described in Daniel J. Bernstein's draft paper http://cr.yp.to/papers.html#pippenger). This algorithm has later been rediscovered and is covered by a couple of, most likely invalid, patents (also explained by Daniel J. Bernstein). With current parameter choices, we use precomputed tables of modest size, roughly 16 KByte for each supported curve, which are compiled into the library. I have not yet decided on the algorithm to use for multiplication involving an arbitrary point. The current implementation uses a side-channel silent variant of the most basic binary multiplication; it can be improved by using window-based algorithm, similar to what GMP uses for the function mpz_powm_sec. The implementation includes a testsuite, and it is tested both on x86_64 (a 64-bit PC platform) and on the Pandaboard (32-bit ARM platform). It is also benchmarked on both those platforms. To give some quantitative numbers, I compare performance to 2048-bit RSA, and measure number of signing and verifications operations that can be done per ms. Intel i5, 3.4 GHz: name size sign / ms verify / ms rsa 1024 6.3228 102.9886 rsa 2048 0.9559 29.5987 dsa 1024 11.1867 5.7500 ecdsa 192 17.9380 3.7946 ecdsa 224 10.0423 2.0285 ecdsa 256 9.3953 2.2191 ecdsa 384 3.5025 0.7830 ecdsa 521 2.1572 0.5291 ARM Cortex A9, 1 GHz: name size sign / ms verify / ms rsa 1024 0.2627 4.5487 rsa 2048 0.0392 1.2488 dsa 1024 0.4691 0.2377 ecdsa 192 1.2888 0.2883 ecdsa 224 0.7856 0.1790 ecdsa 256 0.5900 0.1280 ecdsa 384 0.2423 0.0545 ecdsa 521 0.1327 0.0296 When looking at the verify operations, ECDSA is not competitive to RSA, and maybe never will. RSA has the advantage of using a small public exponent; in these benchmarks, I use e = 65537. For signing operations, let us focus on ECDSA 224, which is believed to give slightly higher security than RSA 2048 (see http://www.keylength.com/en/3/). Then ECDSA signatures, with the current code, is a factor 10 faster on ARM, and a factor 20 faster on x86_64. When comparing the benchmark numbers, one should keep in mind that performance is not everything. In some applications, the smaller size of keys and signatures for ECDSA is also of high importance. * Remaining tasks For elliptic curve signatures, one large remaining task is designing, implementing, and documenting the public programming interface. This is part of the integration work required, before the elliptic curve implementation can be incorporated in the Nettle library. For optimizations, performance of the verify operations can be improved by algorithmic improvements. Performance of all operations can be further improved by platform-specific optimizations, implementing a few key functions in assembly. It's also possible to write alternative elliptic curve primitives, without the requirement of side-channel silence. These could be used to speed up operations which don't have any secret inputs, in particular, verification of signatures. I give that a lower priority than the other potential optimizations, though. For the other sub-project, to do ARM-specific optimizations for cryptographic primitives unrelated to elliptic curves, no work has been done during January, beyond a general study of the ARM architecture. Most important functions are the AES block cipher and the hash functions in the SHA family: SHA1, SHA256, SHA512, and possibly also the recently standardized SHA3 hash function. Also the memxor function is a candidate to be the first ARM-assembly function in Nettle. -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

ECC plans
by nisse＠lysator.liu.se 26 Jan '13

26 Jan '13

I've started to read up on ECC again (and I've also spent some time reading up on ARM architecture, but that's for a different message). As I wrote earlier, for a start I'll limit the support to standard NIST curves. So first question is naming; what's the most established names for these curves? It seems gnutls uses, e.g., "SECP256R1", I guess we can just follow that (rather than, e.g, "P-256", as it's called in the DSA spec fips-186-3)? My current plan is as follows: 1. The top-level functions for ECDSA and the like will use mpz_t to represent point coordinates, exponents, etc, just like the current DSA code. 2. Internally, I think I want to use GMP's lower-level mpn interface, for two reasons: (i) that should make it possible, with some effort, to use ecc functions without any allocation inside Nettle. (ii) For performance, I'd like to do specific mod p functions for the various curves, and this is done best on top of functions such as mpn_add_n and mpn_addmul_1. After all, the primes p used for the curves are carefully chosen to have special structure, to enable optimizations. 3. Representation of a curve will for now be an opaque struct. The header will just declare struct ecc_curve; extern const struct ecc_curve nettle secp256r1; Tables for point multiplication will be compiled into the library. They will be somewhat machine dependent, depending on the GMP limb size, so they have to be generated at build time. 4. I think I'll use Jacobian coordinates. These have a penalty for addition of arbitrary points, but we can try to use multiplication algorithms where one of the points being added always is a constant, which can be represented in normalized form. Then there's no penalty over plain homogeneous coordinates (this is the operation called "madd" in gnutls sources). I've been intrigued by the recent (2007) breakthrough of Edwards curves, but as far as I understand, that can't easily be applied to the standard NIST curves. See http://cr.yp.to/newelliptic/newelliptic.html. 5. For point multiplication with the fixed generator, I think I'll use the L=1 special case of Pippenger's algorithm, described in Daniel Bernstein's paper http://cr.yp.to/papers/pippenger.pdf. I think this is more or less the same as the "comb" method or "Lim-Lee"-method, but predating any bogus patents on the algorithm. (I can try to summarize the algorithm later, but it's pretty simple once one gets past the notation). I think it's fairly easy to silence with regards to timing and cache side-channels. One nice feature is that even with pretty large tables, not all of the table index bits are data-dependent (extracted from the exponent). Then it should be practical to read all possible table entries and use masking to copy the selected one, see http://gmplib.org:8000/gmp/file/eee6b8e54765/mpn/generic/tabselect.c. This operation is the working horse for ECDSA signing, and for the first half of ECDH. I'm not sure how large tables it makes sense to create for each curve, but I guess somewehere between a few KByte to at most 100 Kbyte. This could be made configurable at compile time, but I'd expect almost all users to stick to the default tables. 6. For general point multiplication, I tend towards using a simple non-sliding window, with a small point-specific table computed at run time. If the table is small enough, it might make sense to normalize the entries. As far as I understand, one can't beat the plain binary algorithm by a large factor; the algorithms I'm aware of only reduce the number of adds, but not the number of dups. This operation is the working horse for the second half of ECDH. 7. For verifying ECDSA signatures, one needs to operate on two points, computing e_1 G + e_2 Y, where G is the generator (and hence offers possibilities for precomputation), and Y is the public key. I haven't yet looked into this in detail, but it seems clear this should be done as a single operation, with only one chain of point duplications. Preferably, it should be implemented in such a way that the tables for G (from 5 above) can be reused. Comments? Does this make sense, or is it anything which ought to be done differently? I have had a quick look at the gnutls code. wmNAF makes me a bit uneasy when I think about side channels; there seems to be a lot of branches depending on exponent bits. In the point addition, it seems hard to avoid special cases when adding a point to itself or to its negation, or adding the zero point. Which will cause sidechannel leaks. Not sure what to do about that, but there are some papers on "unified" ecc operations, or maybe one can do something analogous to rsa blinding. As far as I understand, for point multiplication in both ECDSA and ECDH, it's only the scalar that ever is secret, the points multiplied are always public. Are there other uses of point multiplication where also the point is secret? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

4 13

ANNOUNCE: Nettle-2.6
by nisse＠lysator.liu.se 16 Jan '13

16 Jan '13

I'm happy to annnounce 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/. The release is signed using a new gpg key (2560R/28C67298). That key is also signed by the previous, 13 year old, release key (1024D/A8F4C2FD). NEWS for the 2.6 release Bug fixes: * Fixed a bug in ctr_crypt. For zero length (which should be a NOP), it sometimes incremented the counter. Reported by Tim Kosse. * Fixed a small memory leak in nettle_realloc and nettle_xrealloc. New features: * Support for PKCS #5 PBKDF2, to generate a key from a password or passphrase. Contributed by Simon Josefsson. Specification in RFC 2898 and test vectors in RFC 6070. * Support for SHA3. * Support for the GOST R 34.11-94 hash algorithm. Ported from librhash by Nikos Mavrogiannopoulos. Written by Aleksey Kravchenko. More information in RFC4357. Test vectors taken from the GOST hash wikipedia page. Miscellaneous: * The include file <nettle/sha.h> has been split into <nettle/sha1.h> and <nettle/sha2.h>. For now, sha.h is kept for backwards compatibility and it simply includes both files, but applications are encouraged to use the new names. The new SHA3 functions are declared in <nettle/sha3.h>. * Testsuite can be run under valgrind, using make check EMULATOR='$(VALGRIND)' For this to work, test programs and other executables now deallocate storage. * New configure options --disable-documentation and --disable-static. Contributed by Sam Thursfield and Alon Bar-Lev, respectively. * The section on hash functions in the manual is split into separate nodes for recommended hash functions and legacy hash functions. * Various smaller improvements, most of them portability fixes. Credits go to David Woodhouse, Tim Rühsen, Martin Storsjö, Nikos Mavrogiannopoulos, Fredrik Thulin and Dennis Clarke. Finally, a note on the naming of the various "SHA" hash functions. Naming is a bit inconsistent; we have, e.g., SHA1: sha1_digest SHA2: sha256_digest (not sha2_256_digest) SHA3: sha3_256_digest Renaming the SHA2 functions to make Nettle's naming more consistent has been considered, but the current naming follows common usage. Most documents (including the specification for SHA2) refer to 256-bit SHA2 as "SHA-256" or "SHA256" rather than "SHA2-256". The libraries are intended to be binary compatible with nettle-2.2 and later. The shared library names are libnettle.so.4.5 and libhogweed.so.2.3, with sonames still libnettle.so.4 and libhogweed.so.2 Available at http://ftp.gnu.org/gnu/nettle/nettle-2.6.tar.gz ftp://ftp.gnu.org/gnu/nettle/nettle-2.6.tar.gz http://www.lysator.liu.se/~nisse/archive/nettle-2.6.tar.gz and soon also at ftp://ftp.lysator.liu.se/pub/security/lsh/nettle-2.6.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

Getting closer to nettle-2.6
by nisse＠lysator.liu.se 04 Jan '13

04 Jan '13

I think I'd like to make a nettle-2.6 release fairly soon. Recent changes: 1. I disabled the x86_64 assembly for sha3_permute. It gave a very modest speedup on the Intel processor I benchmarked it on, and a sever slowdown on the AMD processor I also benchmarked it on. The latter machine seemed to execute the loop at only one instruction per cycle, rather than three as it should; my best guess is that it's the moves of data between regular registers and xmm registers that somehow stall. Maybe it could be rewritten to use xmm registers exclusively, but then register allocation gets *very* tight, so one might need to keep a few words of the state on the stack instead. But I don't think I'll try that soon; the current C implementation is reasonably efficient, with performance of sha256 and sha3-256 in the same ballbark (but both slower than sha512). 2. I think I fixed the bugs in some subdirectory make targets which broke "make install" without a preceding "make all". Ah, and a technical detail. There are no new features added to to libhogweed, but I still intend to increment the minor number of that shared library in the release. Is that right, or should I keep the same hogweed minor number as in nettle-2.5 (i.e., libhogweed.so.4.4)? I've updated the NEWS file (current version of the 2.6 entries appended below, for convenience). Are you aware of any missing pieces, either in the code, in NEWS, or in other documentation? Regards, /Niels NEWS for the 2.6 release Bug fixes: * Fixed a bug in ctr_crypt. For zero length (which should be a NOP), it sometimes incremented the counter. Reported by Tim Kosse. * Fixed a small memory leak in nettle_realloc and nettle_xrealloc. New features: * Support for PKCS #5 PBKDF2. Contributed by Simon Josefsson. Specification in RFC 2898 and test vectors in RFC 6070. * Support for GOST R 34.11-94 hash algorithm. Ported from librhash by Nikos Mavrogiannopoulos. Written by Aleksey Kravchenko. More information in RFC4357. Test vectors taken from the GOST hash wikipedia page. * Support for SHA3. Miscellaneous: * The include file <nettle/sha.h> has been split into <nettle/sha1.h> and <nettle/sha2.h>. For now, sha.h is kept for backwards compatibility and it simply includes both files, but applications are encouraged to use the new names. The new SHA3 functions are declared in <nettle/sha3.h>. * Testsuite can be run under valgrind, using make check EMULATOR='$(VALGRIND)' For this to work, test programs and other executables now deallocate storage. * New configure options --disable-documentation and --disable-static. Contributed by Sam Thursfield and Alon Bar-Lev, respectively. * The section on hash functions in the manual is split into separate nodes for recommended hash functions and legacy hash functions. * Various smaller improvements, most of them portability fixes. Credits go to David Woodhouse, Tim Rühsen, Martin Storsjö, Nikos Mavrogiannopoulos, Fredrik Thulin and Dennis Clarke. Finally, a note on the naming of the various "SHA" hash functions. Naming is a bit inconsistent; we have, e.g., SHA1: sha1_digest SHA2: sha256_digest (not sha2_256_digest) SHA3: sha3_256_digest Renaming the SHA2 functions to make Nettle's naming more consistent has been considered, but the current naming follows common usage. Most documents (including the specification for SHA2) refer to 256-bit SHA2 as "SHA-256" or "SHA256" rather than "SHA2-256". The libraries are intended to be binary compatible with nettle-2.2 and later. The shared library names are libnettle.so.4.5 and libhogweed.so.2.3, with sonames still libnettle.so.4 and libhogweed.so.2 -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

3 6

[PATCH] silence more warnings
by Tim Ruehsen 21 Dec '12

21 Dec '12

some little fixes for nettle-hash.c:53:2: warning: ISO C does not allow extra ';' outside of a function [-pedantic] testutils.c:1072:2: warning: ISO C does not allow extra ';' outside of a function [-pedantic] des-compat-test.c:748:14: warning: old-style function definition [-Wold-style-definition] des-compat-test.c:755:17: warning: initialization discards 'const' qualifier from pointer target type [enabled by default] Regards, Tim diff --cc testsuite/des-compat-test.c index 257c343,257c343..4021ee8 --- a/testsuite/des-compat-test.c +++ b/testsuite/des-compat-test.c @@@ -745,14 -745,14 +745,13 @@@ plain[8+4], plain[8+5], plain[8+6], pla return(0); } --static char *pt(p) --const unsigned char *p; ++static char *pt(const unsigned char *p) { static char bufs[10][20]; static int bnum=0; char *ret; int i; -- static char *f="0123456789ABCDEF"; ++ static const char *f="0123456789ABCDEF"; ret= &(bufs[bnum++][0]); bnum%=10; diff --cc testsuite/testutils.c index d77bb7e,d77bb7e..1b0fd88 --- a/testsuite/testutils.c +++ b/testsuite/testutils.c @@@ -1069,7 -1069,7 +1069,7 @@@ test_dsa_key(struct dsa_public_key *pub mpz_powm(t, pub->g, key->x, pub->p); ASSERT(0 == mpz_cmp(t, pub->y)); --}; ++} #endif /* WITH_HOGWEED */ diff --cc tools/nettle-hash.c index 842f9ff,5710216..bd03b18 --- a/tools/nettle-hash.c +++ b/tools/nettle-hash.c @@@ -50,9 -49,9 +50,9 @@@ list_algorithms (void for (i = 0; (alg = nettle_hashes[i]); i++) printf ("%10s %d (%d)\n", alg->name, alg->digest_size, alg->block_size); --}; ++} -static const struct nettle_hash * +static const struct nettle_hash * NONNULL(1) find_algorithm (const char *name) { const struct nettle_hash *alg;

2 1

building without fp
by Nikos Mavrogiannopoulos 16 Dec '12

16 Dec '12

I noticed that trying to build nettle in systems without floating point fails at the shadata, aesdata tools. The attached patch adds a flag (disable-data-targets) to prevent them from being built. regards, Nikos

2 1

Re: [PATCH] build: add --enable-static option
by nisse＠lysator.liu.se 15 Dec '12

15 Dec '12

Alon Bar-Lev <alon.barlev(a)gmail.com> writes: >> Maybe a make install without a previous make all should be supported? > > Usually yes. I just checked the GNU coding standards, and they seem to agree with you. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

Re: [PATCH] build: add --enable-static option
by nisse＠lysator.liu.se 15 Dec '12

15 Dec '12

Alon Bar-Lev <alon.barlev(a)gmail.com> writes: > Working, thanks! Thanks for testing. ---disable-static checked in now. > BTW: > There is an issue with: > $ ./configure > $ make install DESTDIR=/tmp/xxx Skipping make is not currently supported. I.e., you're supposed to do $ ./configure $ make $ make install or even better $ ./configure $ make $ make check && make install Maybe a make install without a previous make all should be supported? Nevertheless, I guess the reported problem is a bug in tools/Makefile.in, the rule $(getopt_OBJS): ( cd .. && $(MAKE) $@ ) Does it work to replace $@ by `basename $@` ? (I haven't thought this through, maybe there's some better way to do it...) Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

Some news for the next year
by nisse＠lysator.liu.se 15 Dec '12

15 Dec '12

The first item is a personal one. From January 7, I'll start working for Southpole Consulting AB, a small Sockholm-based consulting company mainly doing embedded (GNU/)Linux development. Second item is more directly related to Nettle. I will get funding from Internetfonden, for "Adapting GNU Nettle for embedded systems". This will mean two things: Support for elliptic curve signatures (and possibly some other ECC-related things), and optimizations for the ARM architecture. The funding is for 420 hours of work, most of which will be spent during the spring, and the project will be carried out under the umbrella of Southpole Consulting. A question for the list: Which variants of the ARM family are most important for Nettle applications? I'm not yet very familiar with the ARM world, but the following are some alternatives for testing and benchmarking: * The current most high-end processor, Cortex-A15, where an affordable development system seems to be a recent "chromebook". Not sure exactly which model, but I guess it's this one: http://www.amazon.co.uk/Samsung-Chromebook-Wifi-Latest-Model/dp/B009RF0AQ8/… * The previous "most high-end" processor, Cortex-A9. An affordable development system is the PandaBoard. http://www.omappedia.com/wiki/PandaBoard_FAQ * The Raspberry Pi computer, featuring an older (obsolete?) ARM1176JFZ, "ARMv6" architecture. http://www.raspberrypi.org/faqs * The low-end Cortex-M0, competing with less than $1 microcontrollers. Also "ARMv6" architecture. An affordable development system seems to be LPCXPRESSO board. http://www.embeddedartists.com/products/lpcxpresso/lpc11U14_xpr.php And if anybody here has some interesting ARM hardware to donate to the project, this is the right time. Best regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

3 5

Re: [PATCH] Probe for archiver tool
by nisse＠lysator.liu.se 15 Dec '12

15 Dec '12

Comitted now. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

Re: [PATCH] build: add --enable-static option
by nisse＠lysator.liu.se 15 Dec '12

15 Dec '12

Alon Bar-Lev <alon.barlev(a)gmail.com> writes: > Gentoo bug#405525, support not installing static libraries. Can you check if the following, simpler, patch to Makefile.in does the job (still depends on IF_STATIC, from configure, of course)? It will use the install-static and uninstall-static targets unconditionally, but they won't do anything when LIBTARGETS is empty. Regards, /Niels diff --git a/Makefile.in b/Makefile.in index c63465c..d6be465 100644 --- a/Makefile.in +++ b/Makefile.in @@ -20,8 +20,8 @@ include config.make PRE_CPPFLAGS = -I. # FIXME: Add configuration of LIBEXT? -LIBTARGETS = libnettle.a @IF_HOGWEED@ libhogweed.a -SHLIBTARGETS = $(LIBNETTLE_FORLINK) @IF_HOGWEED@ $(LIBHOGWEED_FORLINK) +LIBTARGETS = @IF_STATIC@ libnettle.a @IF_HOGWEED@ libhogweed.a +SHLIBTARGETS = @IF_SHARED@ $(LIBNETTLE_FORLINK) @IF_HOGWEED@ $(LIBHOGWEED_FORLINK) getopt_SOURCES = getopt.c getopt1.c getopt_TARGETS = $(getopt_SOURCES:.c=.$(OBJEXT)) @@ -32,7 +32,7 @@ internal_TARGETS = $(internal_SOURCES:.c=.$(OBJEXT)) TARGETS = aesdata$(EXEEXT) desdata$(EXEEXT) twofishdata$(EXEEXT) \ shadata$(EXEEXT) gcmdata$(EXEEXT) \ $(getopt_TARGETS) $(internal_TARGETS) \ - $(LIBTARGETS) @IF_SHARED@ $(SHLIBTARGETS) + $(LIBTARGETS) $(SHLIBTARGETS) IMPLICIT_TARGETS = @IF_DLL@ $(LIBNETTLE_FILE) $(LIBHOGWEED_FILE) DOCTARGETS = @IF_DOCUMENTATION@ nettle.info nettle.html nettle.pdf -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

Re: [PATCH] build: add --enable-static option
by nisse＠lysator.liu.se 15 Dec '12

15 Dec '12

Alon Bar-Lev <alon.barlev(a)gmail.com> writes: Thanks. I have one comment on the patch. > --- a/Makefile.in > +++ b/Makefile.in > @@ -21,7 +21,11 @@ include config.make > PRE_CPPFLAGS = -I. > # FIXME: Add configuration of LIBEXT? > LIBTARGETS = libnettle.a @IF_HOGWEED@ libhogweed.a > -SHLIBTARGETS = $(LIBNETTLE_FORLINK) @IF_HOGWEED@ $(LIBHOGWEED_FORLINK) > +@IF_STATIC@INSTALL_LIBTARGETS = install-static > +@IF_STATIC@UNINSTALL_LIBTARGETS = uninstall-static > +@IF_SHARED@SHLIBTARGETS = $(LIBNETTLE_FORLINK) @IF_HOGWEED@ $(LIBHOGWEED_FORLINK) > +@IF_SHARED@INSTALL_SHLIBTARGETS = install-shared-nettle @IF_HOGWEED@ install-shared-hogweed > +@IF_SHARED@UNINSTALL_SHLIBTARGETS = uninstall-shared I think I'd prefer to make the definitions unconditional, but with conditional values. E.g. UNINSTALL_SHLIBTARGETS = @IF_SHARED@ uninstall-shared rather than @IF_SHARED@UNINSTALL_SHLIBTARGETS = uninstall-shared Is there any reason that won't work? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

sha3 optimization
by nisse＠lysator.liu.se 13 Dec '12

13 Dec '12

I've spent the evening on optimizing sha3. I've written a first basic x86_64 implementation of sha3_permute, using 128-bit sse2 operations where practical, which gave a 30% speedup. And after working with the algorithm for a bit, I realized that it's fairly easy to reduce the number of passes each round makes over the data. So I tried that in the C implementation, and it gave a 20% speedup there. So now when I understand the algorithm better, I guess I'll have to rewrite the x86_64 implementation to reduce the number of passes there too. Still pretty slow, with sha3-256 at 32 cycles per byte at best. Which is far behind the claimed performance of 6-7 cycles/byte on x86_64 (close to the performance of sha1). I guess I should also have a look at that code (or does aybody on the list know which tricks are relevant?). The internal state is a 5x5 matrix of 64-bit words. If represented using 128-bit xmm registers, each row fits in two xmm registers and one regular 64-bit register. The steps which seem hardest to fit with 128-bit instructions is the permutation and rotation steps, which appear to want to treat 64-bit words individually. The current code (both C and assembly) keeps the state in memory, using double buffering, and doesn't try to fit more than one row at a time in registers. Keeping more of the state in registers is highly desirable. See http://git.lysator.liu.se/nettle/nettle/blobs/master/sha3-permute.c and http://git.lysator.liu.se/nettle/nettle/blobs/master/x86_64/sha3-permute.asm Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 2

SHA2 renaming
by nisse＠lysator.liu.se 03 Dec '12

03 Dec '12

With support for SHA3, it seems clear that nettle's naming for sha2 functions was a mistake. It should be "sha2_256", rather than "sha256". This is my current plan. Step 1 is as backwards compatible as practical, while step 2, to be taken at some later time, drops backwards compatibility. Step 1: * Split sha.h into sha1.h and sha2.h, and use the new names in sha2.h. Except for the name mangling, e.g., #define sha2_256_init nettle_sha256_init not #define sha2_256_init nettle_sha2_256_init in order to maintain ABI compatibility. * Keep sha.h for backwards compatibility. Have it include sha1.h and sha2.h, and use #define to make old names aliases for the new names. * Do a thorough rename in the implementation; use new names for all internal use of sha2, rename files, etc. * For all other interfaces where a sha2 function shows up in a name, e.g., hmac_sha256_set_key, and DSA_SHA256_MIN_P_BITS, rename for consistency and use #defines to make old names aliases. * For nettle_hash, make the new name of the struct an alias for the old, e.g., #define nettle_sha2_256 nettle_sha256 but for now do *not* change the contents of the name. I.e., nettle_sha2_256.name will still contain the string "sha256", not "sha2_256". Step 2: * Delete sha.h, and the other compatibility aliases defined elsewhere. * Do the rename also on library symbols, i.e., nettle_sha256_init -> nettle_sha2_256_init. * Change the value of the name fields of the nettle_hash objects. As far as I see, Step 1 maintains reasonably complete API and ABI compatibility. The only subtlety I'm aware of is C++ ABI compatibility for code *using* nettle, where I think struct sha256_ctx; vs struct sha2_256_ctx; #define sha256_ctx sha2_256_ctx would give different name mangling of C++ functions using arguments of this type (and not declared extern "C"). I think that is a problem that I'm going to ignore. Or do you think it is important enough to make the aliases for the struct tags the other way around? Comments? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

3 8

PBKDF2-HMAC-SHA512 test cases
by Fredrik Thulin 28 Nov '12

28 Nov '12

>From another thread : On Tue, 2012-11-27 at 22:47 +0100, Niels Möller wrote: ... > For lack of more authoritative test vectors, adding a couple of > testvectors generated by python-pbkdf2, to the nettle testsuite would > be nice. Attached is a patch that tries to validate the Nettle PBKDF2-HMAC-SHA512 implementation with a few values generated with python-pbkdf2 from https://www.dlitz.net/software/python-pbkdf2/. I also conducted 300,000 semi-random tests comparing the Nettle digest with corresponding OpenSSL digests, using QuickCheck-like testing, with good results. I did not use python-pbkdf2 checks for these, because frankly they were too slow. In case anyone is interested, I'm attaching the QC test too. Quick instructions for that one would be to install 'qc' from git://github.com/dbravender/qc.git, my python-ndnkdf from https://github.com/fredrikt/python-ndnkdf and then do $ nosetests -d qc-test.py /Fredrik

2 1

Salsa20/8 and Salsa20/12
by Simon Josefsson 28 Nov '12

28 Nov '12

I quickly discovered that I needed the round-reduced variants of Salsa20. Here they are. I didn't update the assembler part, so I would need help finishing that part. /Simon

3 17

Fast PBKDF2 in Python, using Nettle
by Fredrik Thulin 28 Nov '12

28 Nov '12

Hi I just published a module used in some PBKDF2-HMAC-SHA512 testing I've been doing under a contract with NORDUnet A/S. https://github.com/fredrikt/python-ndnkdf I invoke the new PBKDF2 functions in libnettle using Python ctypes, which achieves a ~ 25x speedup compared to the standard python-pbkdf2 that uses SHA512 from hashlib (presumably a C function), but does the xoring in native Python. PBKDF2-HMAC-SHA512 benchmark result : N= 16 -> Python == 0 ms, Nettle == 0 ms N= 32 -> Python == 1 ms, Nettle == 0 ms N= 64 -> Python == 2 ms, Nettle == 0 ms N= 128 -> Python == 4 ms, Nettle == 0 ms N= 256 -> Python == 8 ms, Nettle == 0 ms N= 512 -> Python == 18 ms, Nettle == 0 ms N= 1024 -> Python == 35 ms, Nettle == 1 ms N= 2048 -> Python == 68 ms, Nettle == 2 ms N= 4096 -> Python == 133 ms, Nettle == 5 ms N= 8192 -> Python == 262 ms, Nettle == 11 ms N= 16384 -> Python == 521 ms, Nettle == 22 ms If someone has access to a modern AMD CPU, I would be very interested in getting the benchmark output of examples/pbkdf2-plot on that machine. Thanks. /Fredrik

2 4

Keccak is SHA-3
by Nikos Mavrogiannopoulos 15 Nov '12

15 Nov '12

It seems that the "Keccak" algorithm is now SHA-3: http://www.nist.gov/itl/csd/sha-100212.cfm regards, Nikos

2 5

gost hash
by Nikos Mavrogiannopoulos 11 Nov '12

11 Nov '12

[this is a resend, sorry if you received it multiple times] Hello, The attached patch adds the GOST R 34.11-94 hash algorithm. I based this code on Alexei Kravchenko's code from librhash. The original code [0] had inline assembly for x86 and x86-64 which is removed from this version. Although this is not a modern algorithm it is being used in the russian digital signature standard (GOST R 34.11-2001). I had issue making the test gost94-test compile. For some reason the makefile wouldn't link it against gmp (all the other tests were ok), and couldn't figure out why. regards, Nikos [0]. http://hg.splayer.org/splayer/src/5027d6aa04f1/Thirdparty/librhash/librhash/

3 16

[PATCH] Use an extended sed RE for matching source files when generating dummy deps
by Martin Storsjo 29 Oct '12

29 Oct '12

On Mac OS X 10.8 sed, the | operator isn't available in basic REs, only in extended ones. The null string also has to be expressed with (). Another Mac OS X-compatible version of the RE is 's/\.c$xx$\{0,1\}//'. Both of these versions have been tested for compatibility with GNU sed. A third alternative is to omit generating these dummy deps altogether, and prefixing the include statements in the Makefiles with a '-', which haves make ignore any failures in including those files. --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 998ed55..1114c71 100644 --- a/configure.ac +++ b/configure.ac @@ -122,7 +122,7 @@ if test x$enable_dependency_tracking = xyes ; then AC_CONFIG_COMMANDS([dummy-dep-files], [(cd "$srcdir" && find . '(' -name '*.c' -o -name '*.cxx' ')' -print) \ - | sed 's/\.c$xx\|$$//' | (while read f; do echo > "$f.o.d"; echo > "$f.po.d"; done) + | sed -E 's/\.c(xx|())$//' | (while read f; do echo > "$f.o.d"; echo > "$f.po.d"; done) ]) fi -- 1.7.9.4

2 5

nettle-2.5 on solaris 10 Sparc issues
by Dennis Clarke 26 Oct '12

26 Oct '12

Looks like nettle 2.5 should build pretty much out of the box but the Makefiles seem to have a few issues. After one tosses a ./configure at it we can build just fine up until a lingage is requires thus : $ ./configure checking build system type... sparc-sun-solaris2.10 checking host system type... sparc-sun-solaris2.10 checking for -R flag... using -R Searching for libraries checking /usr/local/lib/lib... not found checking /usr/local/lib... added checking /sw/local/lib... not found checking /sw/lib... not found checking /usr/gnu/lib... not found checking /opt/gnu/lib... not found checking /sw/gnu/lib... not found checking /usr/freeware/lib... not found checking /usr/pkg/lib... not found checking for gcc... /opt/solarisstudio12.3/bin/cc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... . . . etc etc . . . checking for fcntl file locking... yes checking for __gmpz_getlimbn in -lgmp... no configure: WARNING: GNU MP not found, or not 3.1 or up, see http://gmplib.org/. Support for public key algorithms will be unavailable. checking for __gmpz_powm_sec... no checking for library containing clock_gettime... -lrt configure: creating ./config.status config.status: creating config.make config.status: creating config.m4 config.status: creating Makefile config.status: creating tools/Makefile config.status: creating testsuite/Makefile config.status: creating examples/Makefile config.status: creating nettle.pc config.status: creating hogweed.pc config.status: creating config.h config.status: linking sparc64/aes-encrypt-internal.asm to aes-encrypt-internal.asm config.status: linking sparc64/aes-decrypt-internal.asm to aes-decrypt-internal.asm config.status: linking sparc64/arcfour-crypt.asm to arcfour-crypt.asm config.status: linking sparc64/machine.m4 to machine.m4 config.status: executing nettle-stdint.h commands config.status: creating nettle-stdint.h : __NETTLE_STDINT_H configure: summary of build options: Version: nettle 2.5 Host type: sparc-sun-solaris2.10 ABI: 64 Assembly files: sparc64 Install prefix: /usr/local Library directory: ${exec_prefix}/lib/64 Compiler: /opt/solarisstudio12.3/bin/cc Shared libraries: yes Public key crypto: no First thing wrong there is that libgmp does exist just fine. ... anyways .. fire off a gmake and it all looks golden : $ gmake gmake all-here gmake[1]: Entering directory `/usr/local/build/nettle-2.5_sparcv9_001' /opt/solarisstudio12.3/bin/cc -I. -I/usr/local/include:/usr/sfw/include -DHAVE_CONFIG_H -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -KPIC -Bdynamic -KPIC -Bdynamic -c aesdata.c \ && true /opt/solarisstudio12.3/bin/cc -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE aesdata.o -o aesdata /opt/solarisstudio12.3/bin/cc -I. -I/usr/local/include:/usr/sfw/include -DHAVE_CONFIG_H -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -KPIC -Bdynamic -KPIC -Bdynamic -c desdata.c \ && true . . . ... and then link goes boom because of the totally missing options to the compiler/linker : /opt/solarisstudio12.3/bin/cc -I. -I/usr/local/include:/usr/sfw/include -DHAVE_CONFIG_H -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -KPIC -Bdynamic -KPIC -Bdynamic -c memxor.c -o memxor.po \ && true /opt/solarisstudio12.3/bin/cc -G -h libnettle.so.4 aes-decrypt-internal.po aes-decrypt.po aes-encrypt-internal.po aes-encrypt.po aes-encrypt-table.po aes-set-encrypt-key.po aes-set-decrypt-key.po aes-meta.po arcfour.po arcfour-crypt.po arcfour-meta.po arctwo.po arctwo-meta.po base16-encode.po base16-decode.po base16-meta.po base64-encode.po base64-decode.po base64-meta.po camellia-crypt.po camellia-crypt-internal.po camellia-set-encrypt-key.po camellia-set-decrypt-key.po camellia-table.po camellia-meta.po cast128.po cast128-meta.po blowfish.po cbc.po ctr.po gcm.po gcm-aes.po des.po des3.po des-compat.po hmac.po hmac-md5.po hmac-ripemd160.po hmac-sha1.po hmac-sha224.po hmac-sha256.po hmac-sha384.po hmac-sha512.po knuth-lfib.po md2.po md2-meta.po md4.po md4-meta.po md5.po md5-compress.po md5-compat.po md5-meta.po ripemd160.po ripemd160-compress.po ripemd160-meta.po salsa20-crypt.po salsa20-set-key.po sha1.po sha1-compress.po sha1-meta.po sha256.po sha256-compress.po sha224-me ta.po sha256-meta.po sha512.po sha512-compress.po sha384-meta.po sha512-meta.po serpent-set-key.po serpent-encrypt.po serpent-decrypt.po serpent-meta.po twofish.po twofish-meta.po yarrow256.po yarrow_key_event.po buffer.po buffer-init.po realloc.po nettle-meta-hashes.po nettle-meta-ciphers.po nettle-meta-armors.po write-be32.po write-le32.po memxor.po -o libnettle.so ld: fatal: file aes-decrypt-internal.po: wrong ELF class: ELFCLASS64 ld: fatal: file processing errors. No output written to libnettle.so gmake[1]: *** [libnettle.so] Error 2 gmake[1]: Leaving directory `/usr/local/build/nettle-2.5_sparcv9_001' gmake: *** [all] Error 2 $ So let's drop that into a script and kick it off thus : $ cat link_hack.sh #!/bin/ksh CFLAGS=\-errfmt=error\ \-erroff=%none\ \-errshort=full\ \-xstrconst\ \ \-xildoff\ \-m64\ \-xmemalign=8s\ \-xnolibmil\ \-Xa\ \-xcode=pic32\ \ \-xregs=no%appl\ \-xlibmieee\ \-mc\ \-g\ \-xs\ \-ftrap=%none\ \-Qy\ \ \-xbuiltin=%none\ \-xdebugformat=dwarf\ \-xunroll=1\ \-xtarget=ultraT2\ \ \-xcache=8/16/4:4096/64/16\ \-D_TS_ERRNO\ \-D_POSIX_PTHREAD_SEMANTICS\ \ \-D_LARGEFILE64_SOURCE export CFLAGS /opt/solarisstudio12.3/bin/cc -\# $CFLAGS -G -h libnettle.so.4 \ aes-decrypt-internal.po \ aes-decrypt.po aes-encrypt-internal.po aes-encrypt.po aes-encrypt-table.po \ aes-set-encrypt-key.po aes-set-decrypt-key.po aes-meta.po arcfour.po \ arcfour-crypt.po arcfour-meta.po arctwo.po arctwo-meta.po base16-encode.po \ base16-decode.po base16-meta.po base64-encode.po base64-decode.po \ base64-meta.po camellia-crypt.po camellia-crypt-internal.po \ camellia-set-encrypt-key.po camellia-set-decrypt-key.po camellia-table.po \ camellia-meta.po cast128.po cast128-meta.po blowfish.po cbc.po ctr.po \ gcm.po gcm-aes.po des.po des3.po des-compat.po hmac.po hmac-md5.po \ hmac-ripemd160.po hmac-sha1.po hmac-sha224.po hmac-sha256.po hmac-sha384.po \ hmac-sha512.po knuth-lfib.po md2.po md2-meta.po md4.po md4-meta.po md5.po \ md5-compress.po md5-compat.po md5-meta.po ripemd160.po ripemd160-compress.po \ ripemd160-meta.po salsa20-crypt.po salsa20-set-key.po sha1.po sha1-compress.po \ sha1-meta.po sha256.po sha256-compress.po sha224-meta.po sha256-meta.po \ sha512.po sha512-compress.po sha384-meta.po sha512-meta.po serpent-set-key.po \ serpent-encrypt.po serpent-decrypt.po serpent-meta.po twofish.po \ twofish-meta.po yarrow256.po yarrow_key_event.po buffer.po buffer-init.po \ realloc.po nettle-meta-hashes.po nettle-meta-ciphers.po nettle-meta-armors.po \ write-be32.po write-le32.po memxor.po \ -o libnettle.so $ beauty .. links fine now : $ $ ./link_hack.sh ### cc: Note: NLSPATH = /opt/solarisstudio12.3/prod/bin/../lib/locale/%L/LC_MESSAGES/%N.cat:/opt/solarisstudio12.3/prod/bin/../../lib/locale/%L/LC_MESSAGES/%N.cat ### command line files and options (expanded): ### -# -errfmt=error -erroff=%none -errshort=full -xstrconst -m64 -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xchip=ultraT2 -xarch=sparcvis2 -xcache=8/16/4:4096/64/16 -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -G -hlibnettle.so.4 aes-decrypt-internal.po aes-decrypt.po aes-encrypt-internal.po aes-encrypt.po aes-encrypt-table.po aes-set-encrypt-key.po aes-set-decrypt-key.po aes-meta.po arcfour.po arcfour-crypt.po arcfour-meta.po arctwo.po arctwo-meta.po base16-encode.po base16-decode.po base16-meta.po base64-encode.po base64-decode.po base64-meta.po camellia-crypt.po camellia-crypt-internal.po camellia-set-encrypt-key.po camellia-set-decrypt-key.po camellia-table.po camellia-meta.po cast128.po cast128-meta.po blowfish.po cbc.po ctr.po gcm.po gcm-aes.po des.po des3.po des-compat.po hmac.po hmac-md5.po hmac-ripemd160.po hmac-sha1.po hmac-sha224.po hmac-sha256.po hmac-sha384.po hmac-sha512.po knuth-lfib.po md2.po md2-meta.po md4.po md4-meta.po md5.po md5-compress.po md5-compat.po md5-meta.po ripemd160.po ripemd160-compress.po ripemd160-meta.po salsa20-crypt.po salsa20-set-key.po sha1.po sha1-compress.po sha1-meta.po sha256.po sha256-compress.po sha224-meta.po sha256-meta.po sha512.po sha512-compress.po sha384-meta.po sha512-meta.po serpent-set-key.po serpent-encrypt.po serpent-decrypt.po serpent-meta.po twofish.po twofish-meta.po yarrow256.po yarrow_key_event.po buffer.po buffer-init.po realloc.po nettle-meta-hashes.po nettle-meta-ciphers.po nettle-meta-armors.po write-be32.po write-le32.po memxor.po -olibnettle.so ### cc: Note: LD_LIBRARY_PATH = (null) ### cc: Note: LD_LIBRARY_PATH_64 = (null) ### cc: Note: LD_RUN_PATH = /usr/local/lib/$ISALIST:/usr/sfw/lib/$ISALIST ### cc: Note: LD_OPTIONS = -R/usr/local/lib/$ISALIST:/usr/sfw/lib/$ISALIST:/usr/local/lib:/usr/sfw/lib -L/usr/local/lib/$ISALIST:/usr/sfw/lib/$ISALIST:/usr/local/lib:/usr/sfw/lib ln -s /opt/solarisstudio12.3/prod/lib /tmp/lib_link.1351194670.1817.01 /usr/ccs/bin/ld -zld32=-S/tmp/lib_link.1351194670.1817.01/libldstab_ws.so -zld64=-S/tmp/lib_link.1351194670.1817.01/v9/libldstab_ws.so -zld32=-S/tmp/lib_link.1351194670.1817.01/libld_annotate.so -zld64=-S/tmp/lib_link.1351194670.1817.01/v9/libld_annotate.so /opt/solarisstudio12.3/prod/lib/v9/crti.o /opt/solarisstudio12.3/prod/lib/v9/values-xi.o -hlibnettle.so.4 aes-decrypt-internal.po aes-decrypt.po aes-encrypt-internal.po aes-encrypt.po aes-encrypt-table.po aes-set-encrypt-key.po aes-set-decrypt-key.po aes-meta.po arcfour.po arcfour-crypt.po arcfour-meta.po arctwo.po arctwo-meta.po base16-encode.po base16-decode.po base16-meta.po base64-encode.po base64-decode.po base64-meta.po camellia-crypt.po camellia-crypt-internal.po camellia-set-encrypt-key.po camellia-set-decrypt-key.po camellia-table.po camellia-meta.po cast128.po cast128-meta.po blowfish.po cbc.po ctr.po gcm.po gcm-aes.po des.po des3.po des-compat.po hmac.po hmac-md5.po hmac-ripemd160.po hmac-sha1.po hmac-sha224.po hmac-sha256.po hmac-sha384.po hmac-sha512.po knuth-lfib.po md2.po md2-meta.po md4.po md4-meta.po md5.po md5-compress.po md5-compat.po md5-meta.po ripemd160.po ripemd160-compress.po ripemd160-meta.po salsa20-crypt.po salsa20-set-key.po sha1.po sha1-compress.po sha1-meta.po sha256.po sha256-compress.po sha224-meta.po sha256-meta.po sha512.po sha512-compress.po sha384-meta.po sha512-meta.po serpent-set-key.po serpent-encrypt.po serpent-decrypt.po serpent-meta.po twofish.po twofish-meta.po yarrow256.po yarrow_key_event.po buffer.po buffer-init.po realloc.po nettle-meta-hashes.po nettle-meta-ciphers.po nettle-meta-armors.po write-be32.po write-le32.po memxor.po -G -o libnettle.so -Y "P,/opt/solarisstudio12.3/prod/lib/sparcvis2/64:/opt/solarisstudio12.3/prod/lib/v9:/usr/ccs/lib/sparcv9:/lib/64:/usr/lib/64" -Qy /opt/solarisstudio12.3/prod/lib/v9/crtn.o /usr/ccs/bin/mcs -c libnettle.so $ $ ls -lap libnettle.so -rwxr-xr-x 1 dclarke other 590976 Oct 25 19:51 libnettle.so $ $ file libnettle.so libnettle.so: ELF 64-bit MSB dynamic lib SPARCV9 Version 1, UltraSPARC3 Extensions Required, dynamically linked, not stripped $ elfdump -d libnettle.so Dynamic Section: .dynamic index tag value [0] INIT 0x39f28 [1] FINI 0x39f38 [2] SONAME 0x163d libnettle.so.4 [3] RUNPATH 0x164c /usr/local/lib/$ISALIST:/usr/sfw/lib/$ISALIST:/usr/local/lib:/usr/sfw/lib [4] RPATH 0x164c /usr/local/lib/$ISALIST:/usr/sfw/lib/$ISALIST:/usr/local/lib:/usr/sfw/lib [5] HASH 0x328 [6] STRTAB 0x23a0 [7] STRSZ 0x1896 [8] SYMTAB 0xb58 [9] SYMENT 0x18 [10] CHECKSUM 0xbcd1 [11] RELACOUNT 0x89 [12] PLTRELSZ 0x690 [13] PLTREL 0x7 [14] JMPREL 0x5ca8 [15] RELA 0x3c38 [16] RELASZ 0x2700 [17] RELAENT 0x18 [18] REGISTER 0x4e [19] REGISTER 0x60 [20] FLAGS 0 0 [21] FLAGS_1 0 0 [22] SUNW_STRPAD 0x200 [23] SUNW_LDMACH 0x2b EM_SPARCV9 [24] PLTGOT 0x142f00 [25-35] NULL 0 $ For some reasons your makefiles seem to forget that this may be a 64-bit sparc server and you toss away the $CFLAGS entirely. If I try to continue from here .. all is beautiful and we get a nice clean build. Piles of warnings and lots of noise about "incompatible with prototype" stuff but certainly compilable and buildable. $ find . -type f | xargs file | grep ELF | cut -f1 -d\: | grep -v "\.o$" | sort | cat -n - 1 ./aes-decrypt-internal.po 2 ./aes-decrypt.po 3 ./aes-encrypt-internal.po 4 ./aes-encrypt-table.po 5 ./aes-encrypt.po 6 ./aes-meta.po 7 ./aes-set-decrypt-key.po 8 ./aes-set-encrypt-key.po 9 ./aesdata 10 ./arcfour-crypt.po 11 ./arcfour-meta.po 12 ./arcfour.po 13 ./arctwo-meta.po 14 ./arctwo.po 15 ./base16-decode.po 16 ./base16-encode.po 17 ./base16-meta.po 18 ./base64-decode.po 19 ./base64-encode.po 20 ./base64-meta.po 21 ./blowfish.po 22 ./buffer-init.po 23 ./buffer.po 24 ./camellia-crypt-internal.po 25 ./camellia-crypt.po 26 ./camellia-meta.po 27 ./camellia-set-decrypt-key.po 28 ./camellia-set-encrypt-key.po 29 ./camellia-table.po 30 ./cast128-meta.po 31 ./cast128.po 32 ./cbc.po 33 ./ctr.po 34 ./des-compat.po 35 ./des.po 36 ./des3.po 37 ./desdata 38 ./examples/base16dec 39 ./examples/base16enc 40 ./examples/base64dec 41 ./examples/base64enc 42 ./examples/eratosthenes 43 ./examples/nettle-benchmark 44 ./examples/next-prime 45 ./examples/random-prime 46 ./examples/rsa-decrypt 47 ./examples/rsa-encrypt 48 ./examples/rsa-keygen 49 ./examples/rsa-sign 50 ./examples/rsa-verify 51 ./gcm-aes.po 52 ./gcm.po 53 ./gcmdata 54 ./hmac-md5.po 55 ./hmac-ripemd160.po 56 ./hmac-sha1.po 57 ./hmac-sha224.po 58 ./hmac-sha256.po 59 ./hmac-sha384.po 60 ./hmac-sha512.po 61 ./hmac.po 62 ./knuth-lfib.po 63 ./libhogweed.so 64 ./libnettle.so 65 ./md2-meta.po 66 ./md2.po 67 ./md4-meta.po 68 ./md4.po 69 ./md5-compat.po 70 ./md5-compress.po 71 ./md5-meta.po 72 ./md5.po 73 ./memxor.po 74 ./nettle-meta-armors.po 75 ./nettle-meta-ciphers.po 76 ./nettle-meta-hashes.po 77 ./realloc.po 78 ./ripemd160-compress.po 79 ./ripemd160-meta.po 80 ./ripemd160.po 81 ./salsa20-crypt.po 82 ./salsa20-set-key.po 83 ./serpent-decrypt.po 84 ./serpent-encrypt.po 85 ./serpent-meta.po 86 ./serpent-set-key.po 87 ./sha1-compress.po 88 ./sha1-meta.po 89 ./sha1.po 90 ./sha224-meta.po 91 ./sha256-compress.po 92 ./sha256-meta.po 93 ./sha256.po 94 ./sha384-meta.po 95 ./sha512-compress.po 96 ./sha512-meta.po 97 ./sha512.po 98 ./shadata 99 ./testsuite/aes-test 100 ./testsuite/arcfour-test 101 ./testsuite/arctwo-test 102 ./testsuite/base16-test 103 ./testsuite/base64-test 104 ./testsuite/bignum-test 105 ./testsuite/blowfish-test 106 ./testsuite/buffer-test 107 ./testsuite/camellia-test 108 ./testsuite/cast128-test 109 ./testsuite/cbc-test 110 ./testsuite/ctr-test 111 ./testsuite/cxx-test 112 ./testsuite/des-compat-test 113 ./testsuite/des-test 114 ./testsuite/des3-test 115 ./testsuite/dsa-keygen-test 116 ./testsuite/dsa-test 117 ./testsuite/gcm-test 118 ./testsuite/hmac-test 119 ./testsuite/knuth-lfib-test 120 ./testsuite/md2-test 121 ./testsuite/md4-test 122 ./testsuite/md5-compat-test 123 ./testsuite/md5-test 124 ./testsuite/memxor-test 125 ./testsuite/meta-armor-test 126 ./testsuite/meta-cipher-test 127 ./testsuite/meta-hash-test 128 ./testsuite/pkcs1-test 129 ./testsuite/random-prime-test 130 ./testsuite/ripemd160-test 131 ./testsuite/rsa-encrypt-test 132 ./testsuite/rsa-keygen-test 133 ./testsuite/rsa-test 134 ./testsuite/rsa2sexp-test 135 ./testsuite/salsa20-test 136 ./testsuite/serpent-test 137 ./testsuite/sexp-format-test 138 ./testsuite/sexp-test 139 ./testsuite/sexp2rsa-test 140 ./testsuite/sha1-huge-test 141 ./testsuite/sha1-test 142 ./testsuite/sha224-test 143 ./testsuite/sha256-test 144 ./testsuite/sha384-test 145 ./testsuite/sha512-test 146 ./testsuite/twofish-test 147 ./testsuite/yarrow-test 148 ./tools/nettle-hash 149 ./tools/nettle-lfib-stream 150 ./tools/pkcs1-conv 151 ./tools/sexp-conv 152 ./twofish-meta.po 153 ./twofish.po 154 ./twofishdata 155 ./write-be32.po 156 ./write-le32.po 157 ./yarrow256.po 158 ./yarrow_key_event.po $ what the heck is a po file ? Anyways ... makefiles seem a bit off and a autoreconf --verbose --install may be needed after a tweak to Makefile.am or similar. Dennis

2 1

nettle-2.5 on Solaris 10 on UltraSPARC-T2+ : flawless
by Dennis Clarke 25 Oct '12

25 Oct '12

Just an FYI that nettle-2.5 builds and passes all tests flawlessly with Oracle Studio 12.3 compilers : $ fpversion A SPARC-based CPU is available. Kernel says CPU's clock rate is 1581.6 MHz. The clock rate is probably 14.3 MHz. Sun-4 floating-point controller version 0 found. An UltraSPARC chip is available. Use "-xtarget=generic -xcache=generic" code-generation option. $ psrinfo -pv The physical processor has 64 virtual processors (0-63) UltraSPARC-T2+ (chipid 0, clock 1582 MHz) The physical processor has 64 virtual processors (64-127) UltraSPARC-T2+ (chipid 1, clock 1582 MHz) $ pwd /usr/local/build/nettle-2.5_sparcv9_001 $ gmake check gmake check-here gmake[1]: Entering directory `/usr/local/build/nettle-2.5_sparcv9_001' true gmake[1]: Leaving directory `/usr/local/build/nettle-2.5_sparcv9_001' set -e; for d in tools testsuite examples; do \ echo "Making check in $d" ; (cd $d && gmake check); done Making check in tools gmake[1]: Entering directory `/usr/local/build/nettle-2.5_sparcv9_001/tools' true gmake[1]: Leaving directory `/usr/local/build/nettle-2.5_sparcv9_001/tools' Making check in testsuite gmake[1]: Entering directory `/usr/local/build/nettle-2.5_sparcv9_001/testsuite' LD_LIBRARY_PATH=../.lib PATH="../.lib:$PATH" srcdir="." \ EMULATOR="" NM="/usr/ccs/bin/nm" EXEEXT="" \ ../run-tests aes-test arcfour-test arctwo-test blowfish-test cast128-test base16-test base64-test camellia-test des-test des3-test des-compat-test md2-test md4-test md5-test md5-compat-test memxor-test ripemd160-test salsa20-test sha1-test sha224-test sha256-test sha384-test sha512-test serpent-test twofish-test knuth-lfib-test cbc-test ctr-test gcm-test hmac-test meta-hash-test meta-cipher-test meta-armor-test buffer-test yarrow-test cxx-test sexp-conv-test pkcs1-conv-test symbols-test PASS: aes PASS: arcfour PASS: arctwo PASS: blowfish PASS: cast128 PASS: base16 PASS: base64 PASS: camellia PASS: des PASS: des3 PASS: des-compat PASS: md2 PASS: md4 PASS: md5 PASS: md5-compat PASS: memxor PASS: ripemd160 PASS: salsa20 PASS: sha1 PASS: sha224 PASS: sha256 PASS: sha384 PASS: sha512 PASS: serpent PASS: twofish PASS: knuth-lfib PASS: cbc PASS: ctr PASS: gcm PASS: hmac PASS: meta-hash PASS: meta-cipher PASS: meta-armor PASS: buffer PASS: yarrow PASS: cxx PASS: sexp-conv PASS: pkcs1-conv PASS: symbols =================== All 39 tests passed =================== gmake[1]: Leaving directory `/usr/local/build/nettle-2.5_sparcv9_001/testsuite' Making check in examples gmake[1]: Entering directory `/usr/local/build/nettle-2.5_sparcv9_001/examples' LD_LIBRARY_PATH=../.lib PATH="../.lib:$PATH" srcdir="." \ EMULATOR="" EXEEXT="" \ ".."/run-tests rsa-sign-test rsa-verify-test rsa-encrypt-test xxxxx xxxxx eeeeeee PASS: rsa-sign PASS: rsa-verify PASS: rsa-encrypt ================== All 3 tests passed ================== gmake[1]: Leaving directory `/usr/local/build/nettle-2.5_sparcv9_001/examples' $ good stuff :-) Dennis

1 0

gost hash
by Nikos Mavrogiannopoulos 25 Sep '12

25 Sep '12

Hello, The attached patch adds the GOST R 34.11-94 hash algorithm. I based this code on Alexei Kravchenko's code from librhash. The original code [0] had inline assembly for x86 and x86-64 which is removed from this version. Although this is not a modern algorithm it is being used in the russian digital signature standard (GOST R 34.11-2001). I had issue making the test gost94-test compile. For some reason the makefile wouldn't link it against gmp (all the other tests were ok), and couldn't figure out why. regards, Nikos [0]. http://hg.splayer.org/splayer/src/5027d6aa04f1/Thirdparty/librhash/librhash/

1 0

Salsa20 core
by Simon Josefsson 23 Sep '12

23 Sep '12

I realized that I didn't have any use for the round-reduced Salsa20 stream functions. So I'll focus on what I needed instead, which resulted in a much smaller patch. What do you think? Open issues: * I'm not particular happy about the name SALSA20_CORE_INOUT_SIZE. * Where could this be documented in the manual? "Miscellaneous functions"? We could also create a new section "Non-cryptographic Hash functions". There is the FNV and CRC hashes that could be implemented under that umbrella. /Simon

2 19

[PATCH] PKCS #5 PBKDF2
by Simon Josefsson 21 Sep '12

21 Sep '12

How about adding KDFs? Here is a starting pointer for the most common function, PKCS #5 PBKDF2. Review appreciated. /Simon

2 27

[PATCH] some patches to fix compiler warnings
by Tim Ruehsen 19 Sep '12

19 Sep '12

Some things I fixed, when having a look at the sources. Just two points for code reviewing: 1. #define NONNULL(...) __attribute__ ((nonnull(__VA_ARGS__))) is contains a C99 feature (...), but there are also C99 long long constants somewhere in the code (if you mind C89 compliancy). 2. In cast128.c I removed the wiping of t, l and r. Instead I set t=0 at the beginning of the loops (It seemed to be used uninitialized in F1 macro). Please just have a short look into it - maybe the "wiping" has some undocumented deeper meaning !? Regards, Tim

4 29

Three tests can't be created
by Tim Ruehsen 13 Sep '12

13 Sep '12

Hi, there are three tests which cannot be build from source: testsuite/sexp-conv-test testsuite/symbols-test testsuite/pkcs1-conv-test If you remove them the following fails: make clean make make check Making check in testsuite make[1]: Entering directory `/usr/oms/src/nettle/testsuite' make[1]: *** No rule to make target `sexp-conv-test', needed by `check'. Stop. These three binaries are in the git repository ... what's that ? Shouldn't there be sources a possibility to build the binaries ? Regards ,Tim

2 2

minor documentation patches
by Daniel Kahn Gillmor 08 Aug '12

08 Aug '12

hi nettle folks-- i've pushed a couple minor documentation patches to my git repo at: git://lair.fifthhorseman.net/~dkg/nettle they're also attached below, if you prefer. Thanks for maintaining nettle, --dkg

1 0

Patch: Fix building of nettle-benchmark on uclibc systems
by Anthony G. Basile 07 Jul '12

07 Jul '12

Attached is a patch to fix the building of examples/nettle-benchmark on uclibc systems while not introducing a regression on glibc. The downstream bug is https://bugs.gentoo.org/show_bug.cgi?id=415193 -- Anthony G. Basile, Ph. D. Chair of Information Technology D'Youville College Buffalo, NY 14201 (716) 829-8197

2 1

ANNOUNCE: Nettle-2.5
by nisse＠lysator.liu.se 07 Jul '12

07 Jul '12

I'm happy to annnounce 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.5 release This release includes important portability fixes for Windows and MacOS. There are also a few new features. First a *warning*: Some internal functions have been removed from the library. Since the functions in question are internal and not documented, this is not considered a change of ABI or API. Programs explicitly using any of these functions will break. * The function pkcs1_signature_prefix has been renamed to _pkcs1_signature_prefix, and with slightly different behavior. * The file nettle-internal.c is no longer included in the library (the features defined there are used by the benchmark and test programs, and were never intended for public use). New features: * Support for the salsa20 block cipher, including x86_64 assembler. Originally contributed by Simon Josefsson, based on the reference implementation, then further optimized. * Tentative interface for timing-resistant RSA functions, contributed by Nikos Mavrogiannopoulos. * A more general interface for PKCS#1 signatures, taking the input in the form of a "DigestInfo". Suggested by Nikos Mavrogiannopoulos. Configuration: * Building of shared libraries (./configure --enable-shared) is now enabled by default. * Various portability fixes for MacOS and M$ Windows. A lot of this work done by Martin Storsjö. * In particular, Nettle now hopefully works on 64-bit Windows builds, "W64", including the x86_64 assembly code. Miscellaneous: * Documentation and example programs for the base16 and base64 functions. Was contributed by Jeronimo Pellegrini back in 2006, but unfortunately forgotten until now. * Use an additional table to avoid GF2^8 multiplications in aes_invert_key (mainly used by aes_set_decrypt_key). Also tabulate round constants in aes_set_encrypt_key. * The nettle repository has been migrated from cvs to git, with a public repository at http://git.lysator.liu.se/nettle. To make it independent of the LSH repository, a few files have been moved around. While at it, files have also been converted from latin-1 to utf-8. The libraries are intended to be binary compatible with nettle-2.2 and later. The shared library names are libnettle.so.4.4 and libhogweed.so.2.2, with sonames still libnettle.so.4 and libhogweed.so.2 Available at http://www.lysator.liu.se/~nisse/archive/nettle-2.5.tar.gz ftp://ftp.gnu.org/gnu/nettle/nettle-2.5.tar.gz and soon also at ftp://ftp.lysator.liu.se/pub/security/lsh/nettle-2.5.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

Final nettle-2.5 prerelease
by nisse＠lysator.liu.se 06 Jul '12

06 Jul '12

I think everything's in shape for release. But I'll postpone the formal release to an evening *before* having a glass or two of wine. ;-) So here's a final prerelease http://www.lysator.liu.se/~nisse/archive/nettle-2.5-pre2.tar.gz http://www.lysator.liu.se/~nisse/archive/nettle-2.5-pre2.tar.gz.sig Hopefully the 2.5 release will differ in filename only. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

Getting a bit closer to release
by nisse＠lysator.liu.se 05 Jul '12

05 Jul '12

I've done some documentatiion for Salsa20, so we're getting closer to release. See http://www.lysator.liu.se/~nisse/nettle/plan.html. NEWS-file review and some more testing remains on the list. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 5

Using alloca on windows
by nisse＠lysator.liu.se 03 Jul '12

03 Jul '12

When I try cross-compiling using ./configure '--host=i586-mingw32msvc' I get warnings on alloca usage, e.g., /home/nisse/hack/nettle/cbc.c: In function `nettle_cbc_decrypt': /home/nisse/hack/nettle/cbc.c:101: warning: implicit declaration of function `alloca' /home/nisse/hack/nettle/cbc.c:101: warning: incompatible implicit declaration of built-in function `alloca' Which header should I include to get a proper declaration? In config.h, I have some boilerplate code which includes malloc.h, but only if *not* using gcc. Should I always include malloc.h if it exists, regardless of the compiler used? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 2

Interface for new rsa features
by nisse＠lysator.liu.se 20 Jun '12

20 Jun '12

In recent months, some new RSA functions have been added, from suggestions and work of Nikos. I'd like to hear comments on the interface before release. Timing resistant decryption function, using RSA blinding: int rsa_decrypt_tr(const struct rsa_public_key *pub, const struct rsa_private_key *key, void *random_ctx, nettle_random_func *random, unsigned *length, uint8_t *message, const mpz_t gibberish); New signing functions taking a "DigestInfo" as input: int rsa_pkcs1_sign(const struct rsa_private_key *key, unsigned length, const uint8_t *digest_info, mpz_t s); int rsa_pkcs1_verify(const struct rsa_public_key *key, unsigned length, const uint8_t *digest_info, const mpz_t signature); Timing-resistant version of the signing function: int rsa_pkcs1_sign_tr(const struct rsa_public_key *pub, const struct rsa_private_key *key, void *random_ctx, nettle_random_func random, unsigned length, const uint8_t *digest_info, mpz_t s); The _tr fucntions use these internal functions for RSA blinding: void _rsa_blind (const struct rsa_public_key *pub, void *random_ctx, nettle_random_func random, mpz_t c, mpz_t ri); void _rsa_unblind (const struct rsa_public_key *pub, mpz_t c, const mpz_t ri); Do you think this looks good? I see that there's some inconsistency of using "nettle_random_func random" vs "nettle_random_func *random", the latter variant is the preferred form. It would be nice with timing resistant versions of the other signing functions, byt I hesitate since we would end up with such a large number of functions. Some redesign (for some later version) may be appropriate. It's possible to do deterministic RSA blinding, using something like HMAC(encoding of private key, message) to generate the random number. And in similar way, one can do deterministic DSA signatures. That's also for later, but you may want to take that possibility into account when commenting on the interface. In somewhat related reorganization, the interface of the internal function pkcs1_signature_prefix has changed and is not compatible with the old version. Questions: 1. Is anyone depending on that function? 2. Does a change of this function require a new solib number? (Depends on the answer to previous question). 3. Should I rename it to _pkcs1_signature_prefix, in order to (i) make it more clear it's an internal function, and (ii) make applications depending on the old behaviour break in a more predictable fashion? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 2

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

23 May '12

Hi, Am 08.05.2012 um 23:17 schrieb Paul Eggert: > On 05/08/2012 01:05 PM, Niels Möller wrote: >> I think it should work fine to just get the gnutls release and apply >> Paul's patch to the file gnutls-3.0.9/gl/stdint.in.h before running the >> configure script. > > Yes, that's the idea. Thanks. Sorry for the delay, I got distracted. I just tested the latest stdint.in.h from gnulib master and gnutls 3.0.19 passes this stage now. However, I didn't change anything on the nettle includes and now get lots of warnings. Probably the gl_* definitions should not belong to the installed nettle headers? CC pkcs12_bag.lo "/opt/csw/include/nettle/nettle-stdint.h", line 237: warning: typedef redeclared: gl_int_fast8_t "/opt/csw/include/nettle/nettle-stdint.h", line 238: warning: typedef redeclared: gl_int_fast16_t "/opt/csw/include/nettle/nettle-stdint.h", line 239: warning: typedef redeclared: gl_int_fast32_t "/opt/csw/include/nettle/nettle-stdint.h", line 241: warning: typedef redeclared: int64_t "/opt/csw/include/nettle/nettle-stdint.h", line 244: warning: typedef redeclared: gl_uint_fast8_t "/opt/csw/include/nettle/nettle-stdint.h", line 245: warning: typedef redeclared: gl_uint_fast16_t "/opt/csw/include/nettle/nettle-stdint.h", line 246: warning: typedef redeclared: gl_uint_fast32_t "/opt/csw/include/nettle/nettle-stdint.h", line 248: warning: typedef redeclared: uint64_t 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

2 1

Configure problem on OS-X
by William Morris 21 May '12

21 May '12

Hi. I obtained the latest nettle using git. Running 'configure' on OS-X (10.7.4) fails. config.status: error: cannot find input file: config.h.in Any ideas? Output from 'configure' given below. -- William Morris iMac:nettle $ ./configure checking build system type... x86_64-apple-darwin11.4.0 checking host system type... x86_64-apple-darwin11.4.0 checking for -R flag... none Searching for libraries checking /usr/local/lib/lib... not found checking /usr/local/lib... added checking /sw/local/lib... not found checking /sw/lib... not found checking /usr/gnu/lib... not found checking /opt/gnu/lib... not found checking /sw/gnu/lib... not found checking /usr/freeware/lib... not found checking /usr/pkg/lib... not found checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking whether make sets $(MAKE)... yes checking for ranlib... ranlib checking for nm... nm checking for objdump... no checking for a BSD-compatible install... /usr/bin/install -c checking for a thread-safe mkdir -p... ./install-sh -c -d checking whether ln -s works... yes configure: Compiler uses 64-bit ABI. To change, set CC. configure: WARNING: Don't know where to install 64-bit libraries on this system. configure: Libraries to be installed in ${exec_prefix}/lib. configure: Looking for assembler files in x86_64/. checking CCPIC... -fPIC checking if globals are prefixed by underscore... yes checking if we should use a .note.GNU-stack section... no checking for ELF-style .type,%function pseudo-ops... no checking for ELF-style .type,#function pseudo-ops... no checking if .align assembly directive is logarithmic... yes checking for m4... /usr/bin/m4 checking for an ANSI C-conforming const... yes checking for inline... inline checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for uid_t in sys/types.h... yes checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for size_t... yes checking whether time.h and sys/time.h may both be included... yes checking for long... yes checking size of long... 8 checking for uint64_t... yes checking alignment of uint64_t... 8 checking openssl/blowfish.h usability... yes checking openssl/blowfish.h presence... yes checking for openssl/blowfish.h... yes checking openssl/des.h usability... yes checking openssl/des.h presence... yes checking for openssl/des.h... yes checking openssl/cast.h usability... yes checking openssl/cast.h presence... yes checking for openssl/cast.h... yes checking openssl/aes.h usability... yes checking openssl/aes.h presence... yes checking for openssl/aes.h... yes checking for working alloca.h... yes checking for alloca... yes checking malloc.h usability... no checking malloc.h presence... no checking for malloc.h... no checking for strerror... yes checking whether byte ordering is bigendian... no checking for memxor... no checking for __attribute__... yes checking for stdint types... stdint.h (shortcircuit) make use of stdint.h in nettle-stdint.h (assuming C99 compatible system) checking for fcntl file locking... yes checking for __gmpz_getlimbn in -lgmp... no configure: WARNING: GNU MP not found, or not 3.1 or up, see http://gmplib.org/. Support for public key algorithms will be unavailable. checking for __gmpz_powm_sec... no checking for BF_ecb_encrypt in -lcrypto... yes checking for library containing clock_gettime... no configure: creating ./config.status config.status: creating config.make config.status: creating config.m4 config.status: creating Makefile config.status: creating tools/Makefile config.status: creating testsuite/Makefile config.status: creating examples/Makefile config.status: creating nettle.pc config.status: creating hogweed.pc config.status: error: cannot find input file: config.h.in iMac:nettle $

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 08 May '12

08 May '12

Paul Eggert <eggert(a)cs.ucla.edu> writes: > Thanks. This seems to be a win regardless of whether it > fixes the nettle problems, Dago, can you test if it solves the SunOS-5.9 problem for you? I.e., apply Paul's patch to gnutls/gnulib, then *unapply* the nettle workaround I comitted yesterday, and see if you still get compilation errors related to nettle-stdint.h. I'm not sure how picky the compiler is about multiple but equivalent typedefs of the same name. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 2

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

08 May '12

Paul Eggert <eggert(a)cs.ucla.edu> writes: > Such usage violates the C standard: even if one compiler > is not picky about it, your're likely to run into another that > does. So a better solution is needed. I've committed a workaround to nettle-types.h. It now does /* Pretend these types always exists. Nettle doesn't use them. */ #define _STDINT_HAVE_INT_FAST32_T 1 #include "nettle-stdint.h" which overrides the result of the configure checks used in the generated nettle-stdint.h. Maybe not the prettiest way to do it, but apparantly it solves the problem, independently of your fixes to gnulib. (But I'd still like to know if your fixes also solves this problem, independently of that Nettle workaround). > I'd rather have an approach where the code simply does "#include > <stdint.h>" and assumes that int_fast8_t works. I don't understand the > overall situation, though, so I don't know what exactly to suggest. I think when you build gnutls on a system lacking stdint.h, a typical compilation unit will contain /* From gnulib's stdint.h */ typedef unsigned int gl_uint32_t; #define uint32_t gl_uint32_t ... /* From nettle/nettle-stdint.h */ typedef unsigned int uint32_t; where the final line is macro-expanded to typedef unsigned int gl_uint32_t; >From what I've seen, this has been no problem. And I hope nettle-stdint.h and gnulib/stdint.h always do these types in the same way. There is some freedom in how to define these types; on a system where for example int and long are the same size, typedef unsigned long uint32_t; typedef unsigned int uint32_t; would be a two distinct but correct definitions, and I imagine the compiler would complain. And to consider the problematic int_fast*_t types, until a day or two ago, you got /* From gnulib's stdint.h */ typedef long gl_int_fast8_t; #define int_fast8_t gl_int_fast8_t ... /* From nettle/nettle-stdint.h */ typedef char int_fast8_t; which no reasonable compiler will accept. 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 07 May '12

07 May '12

Paul Eggert <eggert(a)cs.ucla.edu> writes: > Hmm, well, the latter point is dubious. SunOS 5.10 standard headers do not > mention int_fast*_t, except in stdint.h where C requires their definition. I'd consider that definition to be authoritative... > Presumably this is for the same reason that Gnulib avoids these types. > Arguably these types are not part of the SunOS 5.10 ABI, since nothing > in the SunOS library binary interface use them. C is still the system programming language, and int_fast*_t are part of the language. But maybe we're splitting hairs now. > The main reason is to keep gnulib simple and maintainable. > I'd rather not have to hand-maintain details about an > operating system that hasn't shipped since 2009. I thought the point of gnulib was to do those annoying things to keep the maintanance in one place. But I guess I'll have to leave to the judgment of the gnulib maintainers which systems are too old and obsolete to care about. > How does the nettle stuff work? Does it #define int_fast8_t etc > in config.h? It is defined in a generated file nettle-stdint.h. And the names of the types are all typedefs, no #defines. With AX_CREATE_STDINT_H, it's a file generated independently of config.h. The file starts with a section with a bunch of #defines set up by configure, and then the rest of the file uses various tests on these to decide what file to include and which types to define. Where the common case is to just include the system's <stdint.h>. The file is then installed with the other nettle header files. > If so, there's a simple workaround in gnulib: > don't futz with int_fast8_t if it's already #defined. If one could get that to work, it might solve the problem for the case that the types are defined but not used. But if it implies that size of those types will depend on #include order, it seems very brittle to me. I think it would be better to let the gnulib application say explicitly whether or not it needs those types, and not define them at all in the common case that they aren't needed. I.e., #ifdef GL_WANT_INTX_FAST_T # define int_fast8_t gl_int_fast8_t #endif Not sure where one would define GL_WANT_INTX_FAST_T, if desired, though. Should be specified in some way in configure.ac, but it can't be put in config.h if the stdint.h types are needed for installed header files. 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 06 May '12

06 May '12

Paul Eggert <eggert(a)cs.ucla.edu> writes: > Intuitively, it's because the int_fast* types are so fragile: they > depend so much on choice of compiler and compiler option. Short version: I think gnulib should either make an effort to define int_fast*_t in the common way on each system (always doing the same as gcc would be very close to the Right Thing), or by default generate a stdint.h without these types and define the int_fast*_t types only when explicitly asked to. Longer version (sorry I fail to be more concise): I think I misread "public headers" in your previous mail, I thought you meant system header files, rather than public header files provided by portable non-system libraries. Sorry for the confusion. I agree one can expect these types to be a fragile and compiler dependent whenever they're left undefined by system headers and ABI spec, which will be the usual assumption for portable code. But in the particular case of SunOS, the types are defined by system headers in release 5.10 (and presumably nailed down by the ABI spec), but missing in release 5.9. Do you see any good reason for gnulib to not define the types in the same way as on 5.10, if building on 5.9? To me, that really looks like the Right Thing to do, and it also looks like the kind of job gnulib is supposed to do. Defining them in a way which differs from SunOS-5.10 definitely seems broken. In the case of gnutls and nettle, one gets compilation errors when another packed defines the same types, and does it using a configure hack which *is* compatible with SunOS-5.10. Of course, that fix doesn't magically make int_fast*_t universally non-fragile, but it definitely improves compatibility for the system in question. As for nettle, I think it's best to not define these types, which aren't used. On Solaris, it happens that AX_CREATE_STDINT_H defines them more correctly (in my view) than gnulib, but it may well cause problems on other system, so it seems more robust to not try to define them at all. But please also consider the hypothetical situation that nettle *did* use those types, even if only internally. Then I couldn't simply omit the definitions. To not cause problems for gnulib users I'd be forced to either change my definitions to prefer compatibility with gnulib over compatibility with SunOS-5.10, which seems really backwards, or introduce additional complexity in nettle-stdint.h to omit the definitions when my public headers need uint32_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 06 May '12

06 May '12

Bruno Haible <bruno(a)clisp.org> writes: > It doesn't exist so far. But it is feasible. - On the other hand, it > looks like nettle-stdint.h can already be easily trimmed in this way, > by undefining _STDINT_NEED_INT_LEAST_T and _STDINT_NEED_INT_FAST_T ? I think that makes sense. I just need someone (Dagobert Michelsen?) who can try it out. Nettle uses the AX_CREATE_STDINT_H macro to generate that file. If it's easy, I'd prefer not to touch that and just add some extra #define in nettle-types.h before it includes nettle-stdint.h. Or if that doesn't work out, it's fine to hack away in the definition in aclocal.m4 to take out the unneded types. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

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