nettle-bugs December 2013

nettle-bugs@lists.lysator.liu.se

9 participants
20 discussions

Mentioning of .bootstrap in INSTALL?
by Joachim Strömbergson 17 Dec '13

17 Dec '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aloha! Cloned nettle and noticed that INSTALL states: "Briefly, the shell commands `./configure; make; make install' should configure, build, and install this package." But at least in the repo there is only a config.ac and you need to run the .bootstrap shell script in order to invoke autoconf and autoheaders in order to get the configure script. Shouldn't INSTALL mention this? - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. ======================================================================== Joachim Strömbergson Secworks AB joachim(a)secworks.se ======================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlKq2LgACgkQZoPr8HT30QEIbACfWjUuo8IAbigziPGwnw4Pbmx5 P8cAni2UtPVOqH52XlBlZmmsGnRfNz7L =ioBH -----END PGP SIGNATURE-----

2 4

TMP_ALLOC and size_t change
by Nikos Mavrogiannopoulos 17 Dec '13

17 Dec '13

Hello, In master (unsigned int) was replaced with (size_t), that allows for even larger sizes to be input to encryption and decryption functions. However, the usage of TMP_ALLOC to make a copy of the input data (e.g., in ctr.c) contradicts that goal. In general I think the usage of alloca() is dangerous as it not always known whether the stack is limited, e.g, when nettle is called in a co-routine or in application with non-growing stack. I think there can be an easy modification of TMP_ALLOC to use malloc for larger than 128 (or any other fixed number), and alloca otherwise. Would you be interested in such a patch? (it would require the introduction of a TMP_FREE as well) regards, Nikos

3 15

[PATCH] source files for chacha
by Joachim Strömbergson 13 Dec '13

13 Dec '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aloha! Here is the patch for the chacha implementation. I will create and send patches for the benchmark, meta, testsuite code when I get nettle to properly build. The code in this patch and my own test program builds and runs as available at: https://github.com/secworks/nettle/tree/master/chacha - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. ======================================================================== Joachim Strömbergson Secworks AB joachim(a)secworks.se ======================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlKq85wACgkQZoPr8HT30QG8JgCfc/scXdxeXKJQSMWsWe7LNDHV 8qwAoN43hGYj1VkXadW65INvvm9OnSyY =AAyY -----END PGP SIGNATURE-----

1 0

ChaCha stream cipher for Nettle available
by Joachim Strömbergson 13 Dec '13

13 Dec '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aloha! I've taken a shot at implementing the ChaCha stream cipher for Nettle. Nettle is a modified version of Salsa20 done by DJB in order to improve both performance (esp on CPUs with support for data parallelism) and somewhat improved performance. ChaCha has been suggested as replacement for RC4 both by Adam Langley from Google and separately by Nikos and Me. http://cr.yp.to/chacha.html The code in this implementation is heavily based on the Salsa20 implementation in Nettle. The major changes beside name changes are the quarterround schedules, the different state init and the quarterround. This implementation also supports different number of rounds. There is a pretty simple test program that verifies the functionality for 128 and 256 keys as well as 8, 12 and 20 rounds using the testt vectors in the chacha test vectors draft: http://tools.ietf.org/html/draft-strombergson-chacha-test-vectors-00 The code for the chacha implementation is available at: https://github.com/secworks/nettle The following files comprises the implementation: chacha-core-internal.c chacha-crypt.c chacha-init.c chacha.h And the test program testsuite/chacha-test.c (The other files are clones from Nettle to be able to build.) ChaCha _should_ be a bit faster than Salsa20 and should esp be easier to optimize in asm for modern CPUs. I have however not done any benchmarks nor asm implementation (yet). Since I'm new as a contributor I don't know how you Niels want to have patches. Please let me know if this looks good and something you want to integrate and if so how. - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. ======================================================================== Joachim Strömbergson Secworks AB joachim(a)secworks.se ======================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlKoxesACgkQZoPr8HT30QE6vACfTIV44gkDKJcsoxR9BjnElBfE zGQAnjbRimEsTp8arbDPtsT/RLrkgw5K =cz3W -----END PGP SIGNATURE-----

4 14

Adding number of rounds to context for Salsa20?
by Joachim Strömbergson 11 Dec '13

11 Dec '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aloha! I'm looking at the source for Salsa20 and notice that there are separate versions for Salsa20 with 20 rounds and Salsa20 with 12 rounds (with specific r12 function names). Would it be possible to instead add the given number of rounds to the context? This would allow the user to select at key-init time to select the number of rounds being used and also declutter the interface with round specific functions. The default could still be 20, but allows for such things as using 8 rounds, 12, 14 or even 24 rounds etc. - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. ======================================================================== Joachim Strömbergson Secworks AB joachim(a)secworks.se ======================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlKoRusACgkQZoPr8HT30QEiXgCgwTUIbpFeXgh2gNk+WCSrlSw1 E/sAoNWKDrSdVhTh4bw9s8YgOau+NpLf =znL7 -----END PGP SIGNATURE-----

2 1

Safe curves (was: brainpool, Curve25519)
by Joachim Strömbergson 11 Dec '13

11 Dec '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aloha! New to the list and responding to an old thread re curves. In September Nikos mentioned the Brainpool curves: http://tools.ietf.org/html/rfc5639 Daniel responded by pointing to Curve25519 by DJB: http://ed25519.cr.yp.to/ DJB and Tanja Lange has a good page about different specified and standardized curves: http://safecurves.cr.yp.to/ Note that they don't consider the Brainpool curves as safe. I myself is somewhat cautious due to their origin. Having Curve25519 and its sister Curve3617 would be really nice albeit for acceptance, support for the NIST curves might be needed. - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. ======================================================================== Joachim Strömbergson Secworks AB joachim(a)secworks.se ======================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlKoMlkACgkQZoPr8HT30QGyvQCfcTSEnhWXy12zEWmsdb7SPK9M isYAoO7BJ1FeJxBaqIw1UROxFf1T9rXO =mHZ7 -----END PGP SIGNATURE-----

1 0

Re: benchmarks
by nisse＠lysator.liu.se 10 Dec '13

10 Dec '13

Werner Koch <wk(a)gnupg.org> writes: > But the whole discussion is moot; Nettle and Libgcrypt are very > different and there is no need to merge them. I imagine that it would be technically possible to write libgcrypt so that parts of it is a thin layer on top of Nettle. For a simple example, in libcgrypt/cipher/md5.c, either replace the transform function with a call to _nettle_md5_compress (which is implemented in assembly on some platforms, and somewhat internal). Or write the internal (not visible in libgcrypt's ABI) MD5_CONTEXT as something like #include <nettle/md5.h> typedef struct { struct md5_ctx ctx; uint8_t digest[MD5_DIGEST_SIZE]; } MD5_CONTEXT; and redefine _gcr_digest_spec_md5 to point to corresponding nettle functions, or trivial wrappers if needed. I see that there's some impedance mismatch, e.g., (init,write,final,read), vs (init,update,digest). I can't say if that's a big deal, aesthetically or in terms of performance overhead. Now, there may sure be good reasons why that's an undesirable change, but I'd like to understand what the obstacles are. The advantage is sharing of more low-level code. And if libgcrypt is faster than nettle for some particular algorithm, we'd obviously want to get the faster code into Nettle before changing libgcrypt. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

Re: benchmarks
by Nikos Mavrogiannopoulos 10 Dec '13

10 Dec '13

On Tue, Dec 10, 2013 at 11:15 AM, Werner Koch <wk(a)gnupg.org> wrote: >> Well, I really want to think that it is also about collaboration. > Right, I thought about the same lines but back then Niels decided to > compile his own library without the need to comply to the strict GNU > rules. Thus he was able to use all kind of code while I was not. A > decade or more ago I had to reject Brian Gladman's offer to use his code > due simply due to the CA requirement. Latter then the GNU project seems > to have concluded that CAs are not important anymore unless they are > already in use. The effect was that GNUTLS silently started to use > Nettle instead of helping to convince the GNU towers to drop the CA > requirement for Libgcrypt. I thought that this was done quite vocally :) There was quite a long discussion in this list about the issues I had back then, that if I remember well were (a) libgcrypt could not be used in setuid processes, and (b) that it was much slower -more than 2x- than openssl (and nettle). The conclusion of that discussion was that libgcrypt wouldn't change. I now understand that (b) was because you were strictly following the gnu rules, but that provided no comfort to me who was seeing gnutls being at the bottom of any benchmark. That's why I switched to nettle and as it is now we are more than 2x faster compared to openssl in public key operations. >> While I understand that everyone has a different agenda on the things >> that need to be done, schedules etc., a compromise that will benefit >> everyone may be possible. > Well, you removed all support for Libgcrypt from GNUTLS. If you want to > use it again, you only need to add that layer again. I removed it because I changed the internal API and libgcrypt support would be incomplete (gcm was missing at the time). I don't think it is would be trivial to re-add, but it is not hard either. Nevertheless, even if such a switch would be possible today, it would solve nothing, as now we have some few parts that libgcrypt is better than nettle, and other parts which nettle is better than libgcrypt. My argumentation for the merging was with the intention to have the best implementations of each library merged. regards, Nikos

2 1

Re: benchmarks
by Nikos Mavrogiannopoulos 10 Dec '13

10 Dec '13

On Mon, Dec 9, 2013 at 9:48 PM, Werner Koch <wk(a)gnupg.org> wrote: >> Could libgcrypt and nettle share the low level algorithms so >> improvements on one project will be shared with the other? As it is now > Fell free to take whatever you need from Libgcrypt. Of course that is possible, it always was. However, copying isn't easy when different low-level interfaces are involved, and pretty much that just prolongs the current situation. > They both you the > same license me thinks. Only for the cipher/hash/mac part which was the part I suggested to be shared. Nettle's PK interface is effectively LGPLv3 due to reliance on GMP. So that part would be more hard to benefit from a sharing. >> I think there is quite some duplicate effort being spent in making the >> two libraries faster and there is no much reason they couldn't be >> combined. > That is what free software is about, right? Well, I really want to think that it is also about collaboration. While I understand that everyone has a different agenda on the things that need to be done, schedules etc., a compromise that will benefit everyone may be possible. regards, Nikos

1 0

Re: benchmarks
by Nikos Mavrogiannopoulos 09 Dec '13

09 Dec '13

On Mon, 2013-12-09 at 18:04 +0100, Werner Koch wrote: > Hi, > > I did some benchmark charts for Libgcrypt. See > ftp://ftp.g10code.com/g10code/scratch/gcrypt-bench-x220-2300.gnumeric > or just the charts: > ftp://ftp.g10code.com/g10code/scratch/gcrypt-bench-x220-2300.pdf > this nicely shows Jussi's improvements. The values for Nettle have been > taken from the nettle-benchmark example program. I did not add data for > OpenSSL because it is a bit of work to extract the numbers from "openssl > speed". It would be nice to have wrapper for openssl so that > bench-slope can be used to create compatible numbers. Could libgcrypt and nettle share the low level algorithms so improvements on one project will be shared with the other? As it is now I think there is quite some duplicate effort being spent in making the two libraries faster and there is no much reason they couldn't be combined. In the end I feel disappointed to see that because of that, even the gnulib people will use openssl's libcrypto because it is faster: http://lists.gnu.org/archive/html/bug-gnulib/2013-12/msg00058.html regards, Nikos

2 1

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 December 2013