nettle-bugs

nettle-bugs@lists.lysator.liu.se

2191 discussions

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

20 Jul '11

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

1 0

ECC
by Nikos Mavrogiannopoulos 17 Jul '11

17 Jul '11

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

3 27

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

11 Jul '11

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

1 0

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

01 Jul '11

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

2 1

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

30 Jun '11

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

2 1

rsa keygen replicability
by Daniel Kahn Gillmor 13 Jun '11

13 Jun '11

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

2 3

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

08 Jun '11

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

2 1

memory leak fix
by Nikos Mavrogiannopoulos 21 May '11

21 May '11

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

2 1

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

06 May '11

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

1 0

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

16 Apr '11

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

5 11

Jump to page:

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