nettle-bugs

nettle-bugs@lists.lysator.liu.se

2205 discussions

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

18 Feb '12

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

4 17

make issues
by Coel May 06 Feb '12

06 Feb '12

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

6 9

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

17 Jan '12

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

4 11

_nettle_write_be32
by Nikos Mavrogiannopoulos 26 Oct '11

26 Oct '11

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

2 4

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

18 Oct '11

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

2 4

memxor
by Nikos Mavrogiannopoulos 14 Sep '11

14 Sep '11

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

2 3

memxor
by Nikos Mavrogiannopoulos 13 Sep '11

13 Sep '11

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

2 8

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

03 Sep '11

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

1 0

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

03 Sep '11

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

1 1

RIPEMD-160 Implementation
by Andres Mejia 01 Sep '11

01 Sep '11

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

2 8

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

nettle-bugs