nettle-bugs

nettle-bugs@lists.lysator.liu.se

2208 discussions

rsa blinding patch
by Nikos Mavrogiannopoulos 14 Apr '12

14 Apr '12

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

4 19

comparison between crypto libraries
by Nikos Mavrogiannopoulos 02 Apr '12

02 Apr '12

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

1 0

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

29 Mar '12

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

2 1

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

19 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 07 Feb '12

07 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 18 Jan '12

18 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 19 Oct '11

19 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

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