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

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

Re: Nettle-2.7.1 with static GMP error
by nisse＠lysator.liu.se 30 Nov '13

30 Nov '13

Alexey Pavlov <alexpux(a)gmail.com> writes: > 2013/11/29 Niels Möller <nisse(a)lysator.liu.se>: >> What failed? Can I repost your message to the list? > > I do it already. I receive subscribing message now. Ok. I'm now cc:ing the list. Context: Link error when building a dynamic libnettle.dll and libhogweed.dll, and statically linking to libgmp.a. >>> i686-w64-mingw32-gcc -march=i686 -mtune=generic -O2 -pipe >>> -I/mingw32/include -ggdb3 -Wno-pointer-sign -Wall -W >>> -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes >>> -Wpointer-arith -Wbad-function-cast -Wnested-externs -L.. -pipe >>> -L/mingw32/lib ecc-mod-test.o testutils.o ../nettle-internal.o >>> -lhogweed -lnettle -lgmp -o ecc-mod-test.exe >>> >>> C:/msys64/mingw32/lib/libgmp.a(sub_n.o):(.text+0x0): multiple >>> definition of `__gmpn_sub_n' >>> >>> ../libhogweed.dll.a(d000131.o):(.text+0x0): first defined here >>> >>> collect2.exe: error: ld returned 1 exit status >> >> So you're building shared libraries for nettle, but you have a static >> gmp library? The way I understand the error, the used gmp functions gets >> copied into libhogweed.dll. Not sure if that is the best behavior. >> > Yes I have static GMP because we build toolchains with static > prerequisites and don't want to has dynamic dependencies from them > (gmp, mpc, mpfr, clog, isl). I prefer to use static versions of them. >> But I'm not sure I understand the link error. There's some function >> depending on __gmpn_sub_n ("mpn_sub_n" to user code), but if that >> function is included in libhogweed.dll, why isn't that function just >> skipped when the linker processes libgmp.a? > > A program in C can have only one definition (declaration which assigns > a value) for each object (storage space for a variable). But when doing linking with static libraries, multiple definitions are generally ok. The linker copies only the object files which are needed, and when it needs a symbol, it includes only the first object file in any of the libraries, which define the symbol. One may still get clashes if each object file includes multiple symbols, since in the set of object files selected by the linker in the end, multiple definitions of the same symbol are not allowed. > As I understand, somewhere header file contains definitions for > several functions __gmpn_sub_n which when included in several > different translation units results in the linker throwing this error. I don't think so. My understanding is that 1. The symbol __gmp_sub_n is defined in some object file included in libgmp.a, and nowhere in the nettle source or object code (and mini-gmp.c doesn't count, it's not involved in the link, and it uses different linker symbol names than the real gmp). 2. This object file gets copied from libgmp.a into libhogweed.dll by the linker. Not sure if this is right; -lgmp was added to the libhogweed link command primarily to get dependencies between *shared* libraries right. 3. You then link the executable ecc-mod-test.exe with -lhogweed and -lgmp. The linked sees two definitions of the symbol __gmpn_sub_n, one in libgmp.a, and one in libhogweed.dll, and it considers this an error. What I don't understand, is why, in (3) above, the linker doesn't just ignore the object in libgmp.a which defines the symbol. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 3

Building nettle-2.7.1 with static GMP bug
by Alexey Pavlov 29 Nov '13

29 Nov '13

Hi! I'm try to build nettle-2.7.1 with static GMP with mingw-w64 toolchain GCC-4.8.2 and got error while linking with static GMP: i686-w64-mingw32-gcc -march=i686 -mtune=generic -O2 -pipe -I/mingw32/include -ggdb3 -Wno-pointer-sign -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wnested-externs -L.. -pipe -L/mingw32/lib ecc-mod-test.o testutils.o ../nettle-internal.o -lhogweed -lnettle -lgmp -o ecc-mod-test.exe C:/msys64/mingw32/lib/libgmp.a(sub_n.o):(.text+0x0): multiple definition of `__gmpn_sub_n' ../libhogweed.dll.a(d000131.o):(.text+0x0): first defined here collect2.exe: error: ld returned 1 exit status /msys_repo/mingw-w64-nettle/src/nettle-2.7.1/testsuite/.test-rules.make:167: recipe for target 'ecc-mod-test.exe' failed make[1]: *** [ecc-mod-test.exe] Error 1 Is any fix for this? Regards, Alexey.

1 0

Apparent bug in SHA-1 digests
by Paul Tagliamonte 28 Nov '13

28 Nov '13

Hey hackers, I'm seeing some behavior that confuses me a bit. I'm sure I'm doing something wrong, but I can't tell. Here's a minimal example: / | #include <stdio.h> | #include <nettle/rsa.h> | | int main ( int argc, char ** argv ) { | struct sha1_ctx hash_ctx; | uint8_t headers[] = { | 0xDE, 0xEA, 0xAD, | 0xBE, 0xEF | }; | sha1_update(&hash_ctx, 5, headers); | | for (int i = 0; i < 3; ++i) { | uint8_t _fingerprint[SHA1_DIGEST_SIZE]; | sha1_digest(&hash_ctx, SHA1_DIGEST_SIZE, _fingerprint); | for (int i = 0; i < SHA1_DIGEST_SIZE; ++i) | printf("%02X ", _fingerprint[i]); | printf("\n"); | } | } \ The output, when run is: / | 89 22 AA 95 F2 02 C9 BB 35 FC 2D A2 DE 22 BE 48 2B B6 6C 1D | DA 39 A3 EE 5E 6B 4B 0D 32 55 BF EF 95 60 18 90 AF D8 07 09 | DA 39 A3 EE 5E 6B 4B 0D 32 55 BF EF 95 60 18 90 AF D8 07 09 \ (that last line is stable after the inital hash) Does doing the sha1_digest alter state in some way? I can't image it is, but then how does this behavior crop up? Much love, thanks all! Cheers, Paul -- #define sizeof(x) rand() :wq

3 2

poly1305 nonce increments
by nisse＠lysator.liu.se 21 Nov '13

21 Nov '13

As I wrote, I'm working with poly1305. One question: The _digest function will update the nonce value, so that by default one gets a nonce sequence of 0, 1, 2, .... In the code I'm working with (contributed by Nikos), this increment is done in a big-endian fashion, just like increments for CTR mode. Is this going to be the common way to generate nonces for poly1305? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 2

Make error on CentOS 6.4 x64
by Martin Lambev 16 Nov '13

16 Nov '13

Hello nettle gurus, I'm trying to build GnuTLS 3.2.6 on CentOS 6.4 x64, but having some issues with nettle during compilation. nettle 2.7.1 make errors: configure: summary of build options: Version: nettle 2.7.1 Host type: x86_64-unknown-linux-gnu ABI: 64 Assembly files: x86_64 Install prefix: /usr/local Library directory: ${exec_prefix}/lib64 Compiler: gcc Static libraries: yes Shared libraries: yes Public key crypto: yes Documentation: no During "$ make" exits with error: hogweed-benchmark.c:575: error: ‘struct openssl_ctx’ has no member named ‘key’ hogweed-benchmark.c:576: error: ‘struct openssl_ctx’ has no member named ‘digest’ make[1]: *** [hogweed-benchmark.o] Error 1 make[1]: Leaving directory `/home/mve/Downloads/ocserv/nettle/nettle-2.7.1/examples' make: *** [all] Error 1 It fails "error: ‘struct openssl_ctx’" so I looked configure help options… $ make clean $ ./configure --help #give a few options so I disabled this one as I'm assuming it's not used in my case isn't it? $ ./configre --disable-openssl #Do not include openssl glue in the benchmark program after doing this "make" successfully finished and I can install "nettle" Is this proper workaround or not? If not how should be handed properly? Thank you! Regards, Martin

2 1

Re: undefined behaviors
by John Regehr 13 Nov '13

13 Nov '13

> I imagine you intended to mail the nettle-bugs list, rather than > nettle-bugs-owner administrative address? Feel free to reply on list. Ugh, sorry, cut and paste... > That's unexpected. Hmm. The NEWS file for 2.7.1 claims that this problem > was fixed in that release, but appearantly it wasn't. You can check if > the error disappears if you replace the definition of ROT32 in macros.h > by > > #define ROTL32(n,x) (((x)<<(n)) | ((x)>>((-(n)&31)))) I'll check this tonight. >> blowfish.c:353:19: runtime error: left shift of 244 by 24 places >> cannot be represented in type 'int' >> twofish.c:196:54: runtime error: left shift of 184 by 24 places cannot >> be represented in type 'int' > > These should have some casts to uint32_t, I think. Unlikely to cause > real problems. Right, I don't know of any compiler that exploits these, and in fact in C++ (but not C) this particular case is covered by a defect report that makes it defined. Thanks, John

2 4

added functions to zeroize
by Nikos Mavrogiannopoulos 13 Nov '13

13 Nov '13

Hello, Attached is a patch that allows overwriting values (points and scalars) in the ECC API. regards, Nikos

2 4

Re: Git repository down?
by nisse＠lysator.liu.se 17 Oct '13

17 Oct '13

Andrew Walrond <andrew(a)walrond.org> writes: > Is the git repository down? Now it seems to work again. Some deamon had died, for unknown reason, and has been restarted. BTW, switching git.lysator.liu.se from gitorious to some other software is under consideraton. Any recommendations? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 3

Re: Git repository down?
by nisse＠lysator.liu.se 16 Oct '13

16 Oct '13

Andrew Walrond <andrew(a)walrond.org> writes: > Is the git repository down? Appearantly, yes. The machine is still up, though, and responding to http. I'll ask sysadm what's happening. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

internal bug in pgp_put_public_rsa_key
by Paul Tagliamonte 15 Oct '13

15 Oct '13

Howdy folks! Thanks for working on nettle, pgp_put_public_rsa_key seems to throw an assertion error: > assert(buffer->size == start + length) buffer->size is 3 larger than (start + length). Removing the PGP_LENGTH_TWO_OCTETS works (but this is wrong, since 4880 defines it as it's written, I think, still new with the spec), so I think there might be a bug in the assert. Can someone who groks the code confirm this? Thanks! Paul -- #define sizeof(x) rand() :wq

2 2

loading RSA keys from a PEM file
by Ted Zlatanov 06 Oct '13

06 Oct '13

If I generate a public RSA key into a PEM file and then base64-decode the contents (this is in Emacs): (string-to-unibyte (base64-decode-string "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAreGA/Qky9W3izQV0kzba 7wKl/wzwxkbbQxvcUqUT1krgAbO/n1tYFjXdJZoWwbMO/qv7NRoMDY4yPWGpsQfY +PSIknAhTZVbgwXrm/wb37+hKRKax2UZ9A/Rx4vJZRYlkpvZ9LbBziseFNN7SMWW qkjBO/NeT8/I9mURDa+4RoYfT6ZwjTvt808PH7uIghk+MHAx9EMBAfafF1Jn9TqW y+Hgdqik9sZteMvCumvGK4grSwzdfPO5I05tt/0I7QVPxlXbHIk/bBsE7mpgOxur P0DAkFKtYDM7oZPBwB6X778ba2EEFKPpVIyzw/jlDPd9PB6gE6dixmax3Hlg69RI EwIDAQAB")) I seem unable to load that as a public key (SCHARS macro == length, SDATA macro == data): struct rsa_public_key key; rsa_public_key_init(&key); rsa_keypair_from_der (&key, NULL, 0, SCHARS (public_key), SDATA (public_key)) It keeps failing. From the docs and example it seems like that should work. Can you see what I'm doing wrong? I've spent a few hours on it and can't trace the problem. If not I will start digging into the key loading functions, but was hoping it's something obvious (and if you have a working example that would be great). As soon as I have this working I will publish my work for review; the RSA signatures are the last piece missing. Ted

3 5

PBKDF2 generic hashing method: unclear usage, examples needed
by Ted Zlatanov 05 Oct '13

05 Oct '13

Hi, I'm trying to use the Nettle PBKDF2 functionality from Emacs. This call (assume that the macros and variables are correct): pbkdf2_hmac_sha1 (SCHARS (key), SDATA (key), XINT (iterations), SCHARS (salt), SDATA (salt), outlength, digest); works great, but I'd like to be able to use any generic nettle_hash. I tried this, given alg is a pointer to a nettle_hash: HMAC_SET_KEY(ctx, alg, SCHARS (key), SDATA (key)); PBKDF2 (ctx, alg->update, alg->digest, alg->digest_size, XINT (iterations), SCHARS (salt), SDATA (salt), outlength, digest); in many combinations but couldn't get it to work (the tests don't match up), and the docs don't explain how the PRF needs to be initialized. I tried to copy what pbkdf2_hmac_sha1() does but wasn't successful. Is there an example you could provide here or in the Nettle sources? (The confusing part is that "ctx" is used for both the HMAC context (the one with inner, outer, and state contexts) and for the hashing state context itself. At one point in the macro chain the HMAC context is passed where a hashing state context is expected, I think, and I really need an example to ensure I'm doing it correctly. I am verifying with the RFC 6070 test vectors and can provide the full source if necessary.) Thanks! Ted

2 2

GCM vs SHA1
by nisse＠lysator.liu.se 22 Sep '13

22 Sep '13

Nikos noted (off list) that Nettle's gcm hashing is slower than sha1. Which seems contrary to what's expected. Should gcm be faster, or a lot faster, than sha1 in software (even without fancy instructions for the gf2 arithmetic)? Below is a first rough assembly implementation of the main step of gcm hashing. Gives a speedup of about 20%, making it *slightly* faster than sha1 on my system. BTW, I'm back from some 40 days of travelling with my familiy, and I'm just trying to remember how to do some hacking ;-) Regards, /Niels diff --git a/Makefile.in b/Makefile.in index ebc9357..c900c58 100644 --- a/Makefile.in +++ b/Makefile.in @@ -12,7 +12,8 @@ INSTALL_SCRIPT = @INSTALL_SCRIPT@ INSTALL_STRIP_PROGRAM = $(INSTALL_PROGRAM) -s MKDIR_P = @MKDIR_P@ -OPT_ASM_SOURCES = @OPT_ASM_SOURCES@ +OPT_ASM_NETTLE_SOURCES = @OPT_ASM_NETTLE_SOURCES@ +OPT_ASM_HOGWEED_SOURCES = @OPT_ASM_HOGWEED_SOURCES@ SUBDIRS = tools testsuite examples @@ -179,10 +180,10 @@ DISTFILES = $(SOURCES) $(HEADERS) getopt.h .bootstrap run-tests \ nettle.texinfo nettle.info nettle.html nettle.pdf sha-example.c # Rules building static libraries -nettle_OBJS = $(nettle_SOURCES:.c=.$(OBJEXT)) +nettle_OBJS = $(nettle_SOURCES:.c=.$(OBJEXT)) $(OPT_ASM_NETTLE_SOURCES:.asm=.$(OBJEXT)) nettle_PURE_OBJS = $(nettle_OBJS:.$(OBJEXT)=.p$(OBJEXT)) -hogweed_OBJS = $(hogweed_SOURCES:.c=.$(OBJEXT)) $(OPT_ASM_SOURCES:.asm=.$(OBJEXT)) +hogweed_OBJS = $(hogweed_SOURCES:.c=.$(OBJEXT)) $(OPT_ASM_HOGWEED_SOURCES:.asm=.$(OBJEXT)) hogweed_PURE_OBJS = $(hogweed_OBJS:.$(OBJEXT)=.p$(OBJEXT)) libnettle.a: $(nettle_OBJS) diff --git a/configure.ac b/configure.ac index 3dd3a99..72da6d7 100644 --- a/configure.ac +++ b/configure.ac @@ -266,14 +266,15 @@ asm_replace_list="aes-encrypt-internal.asm aes-decrypt-internal.asm \ sha3-permute.asm umac-nh.asm umac-nh-n.asm machine.m4" # Assembler files which generate additional object files if they are used. -asm_optional_list="" - +asm_nettle_optional_list="gcm-gf-mul-8.asm" +asm_hogweed_optional_list="" if test "x$enable_public_key" = "xyes" ; then - asm_optional_list="ecc-192-modp.asm ecc-224-modp.asm ecc-256-redc.asm \ - ecc-384-modp.asm ecc-521-modp.asm" + asm_hogweed_optional_list="ecc-192-modp.asm ecc-224-modp.asm \ + ecc-256-redc.asm ecc-384-modp.asm ecc-521-modp.asm" fi -OPT_ASM_SOURCES="" +OPT_ASM_NETTLE_SOURCES="" +OPT_ASM_HOGWEED_SOURCES="" asm_file_list="" @@ -291,18 +292,34 @@ if test "x$enable_assembler" = xyes ; then done dnl Workaround for AC_CONFIG_LINKS, which complains if we use the dnl same destination argument $tmp_f multiple times. - for tmp_o in $asm_optional_list ; do + for tmp_n in $asm_nettle_optional_list ; do + for asm_dir in $asm_path ; do + if test -f "$srcdir/$asm_dir/$tmp_n"; then + asm_file_list="$asm_file_list $tmp_n" + AC_CONFIG_LINKS($tmp_n:$asm_dir/$tmp_n) + while read tmp_func ; do + AC_DEFINE_UNQUOTED(HAVE_NATIVE_$tmp_func) + eval HAVE_NATIVE_$tmp_func=yes + done <<EOF +[`sed -n 's/[^ ]*PROLOGUE(_*$nettle_$*$[^)]*$).*$/\2/p' < "$srcdir/$asm_dir/$tmp_n"`] +EOF + OPT_ASM_NETTLE_SOURCES="$OPT_ASM_NETTLE_SOURCES $tmp_n" + break + fi + done + done + for tmp_h in $asm_hogweed_optional_list ; do for asm_dir in $asm_path ; do - if test -f "$srcdir/$asm_dir/$tmp_o"; then - asm_file_list="$asm_file_list $tmp_o" - AC_CONFIG_LINKS($tmp_o:$asm_dir/$tmp_o) + if test -f "$srcdir/$asm_dir/$tmp_h"; then + asm_file_list="$asm_file_list $tmp_h" + AC_CONFIG_LINKS($tmp_h:$asm_dir/$tmp_h) while read tmp_func ; do AC_DEFINE_UNQUOTED(HAVE_NATIVE_$tmp_func) eval HAVE_NATIVE_$tmp_func=yes done <<EOF -[`sed -n 's/[^ ]*PROLOGUE(_*$nettle_$*$[^)]*$).*$/\2/p' < "$srcdir/$asm_dir/$tmp_o"`] +[`sed -n 's/[^ ]*PROLOGUE(_*$nettle_$*$[^)]*$).*$/\2/p' < "$srcdir/$asm_dir/$tmp_h"`] EOF - OPT_ASM_SOURCES="$OPT_ASM_SOURCES $tmp_o" + OPT_ASM_HOGWEED_SOURCES="$OPT_ASM_HOGWEED_SOURCES $tmp_h" break fi done @@ -314,7 +331,8 @@ EOF fi fi -AC_SUBST([OPT_ASM_SOURCES]) +AC_SUBST([OPT_ASM_NETTLE_SOURCES]) +AC_SUBST([OPT_ASM_HOGWEED_SOURCES]) AH_VERBATIM([HAVE_NATIVE], [/* Define to 1 each of the following for which a native (ie. CPU specific) @@ -328,7 +346,8 @@ AH_VERBATIM([HAVE_NATIVE], #undef HAVE_NATIVE_ecc_384_modp #undef HAVE_NATIVE_ecc_384_redc #undef HAVE_NATIVE_ecc_521_modp -#undef HAVE_NATIVE_ecc_521_redc]) +#undef HAVE_NATIVE_ecc_521_redc +#undef HAVE_NATIVE_gcm_gf_mul_8]) # Besides getting correct dependencies, the explicit rules also tell # make that the .s files "ought to exist", so they are preferred over diff --git a/gcm.c b/gcm.c index 6893d51..7b387ba 100644 --- a/gcm.c +++ b/gcm.c @@ -214,6 +214,12 @@ gcm_gf_mul (union gcm_block *x, const union gcm_block *table) memcpy (x->b, Z.b, sizeof(Z)); } # elif GCM_TABLE_BITS == 8 +# if HAVE_NATIVE_gcm_gf_mul_8 + +#define gcm_gf_mul _nettle_gcm_gf_mul_8 +void +gcm_gf_mul (union gcm_block *x, const union gcm_block *y); +# else /* !HAVE_NATIVE_gcm_gf_mul_8 */ static const uint16_t shift_table[0x100] = { W(00,00),W(01,c2),W(03,84),W(02,46),W(07,08),W(06,ca),W(04,8c),W(05,4e), @@ -304,7 +310,7 @@ gcm_gf_mul (union gcm_block *x, const union gcm_block *table) gcm_gf_shift_8(&Z); gcm_gf_add(x, &Z, &table[x->b[0]]); } - +# endif /* ! HAVE_NATIVE_gcm_gf_mul_8 */ # else /* GCM_TABLE_BITS != 8 */ # error Unsupported table size. # endif /* GCM_TABLE_BITS != 8 */ diff --git a/x86_64/gcm-gf-mul-8.asm b/x86_64/gcm-gf-mul-8.asm new file mode 100644 index 0000000..2296ba8 --- /dev/null +++ b/x86_64/gcm-gf-mul-8.asm @@ -0,0 +1,130 @@ +C nettle, low-level cryptographics library +C +C Copyright (C) 2013, Niels MÃ¶ller +C +C The nettle library is free software; you can redistribute it and/or modify +C it under the terms of the GNU Lesser General Public License as published by +C the Free Software Foundation; either version 2.1 of the License, or (at your +C option) any later version. +C +C The nettle library is distributed in the hope that it will be useful, but +C WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY +C or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public +C License for more details. +C +C You should have received a copy of the GNU Lesser General Public License +C along with the nettle library; see the file COPYING.LIB. If not, write to +C the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +C MA 02111-1301, USA. + +C Register usage: + +define(<XP>, <%rdi>) +define(<TABLE>, <%rsi>) +define(<XW>, <%rax>) +define(<CNT>, <%ecx>) +define(<Z0>, <%rdx>) +define(<Z1>, <%r8>) +define(<T0>, <%r9>) +define(<T1>, <%r10>) +define(<T2>, <%r11>) +define(<SHIFT_TABLE>, <%rbx>) + +C The C code is 12.5 c/byte, slower than sha1 (10.6), while this code runs +C at 10.2, slightly faster. Benchmarked on a low-end AMD E-350. + + .file "gcm-gf-mul-8.asm" + + C void _gcm_gf_mul_8(union gcm_block *x, const union gcm_block *table) + .text + ALIGN(16) +PROLOGUE(_nettle_gcm_gf_mul_8) + W64_ENTRY(2, 0) + push %rbx + mov 8(XP), XW + rol $8, XW + movzbl LREG(XW), XREG(T0) + shl $4, T0 + mov (TABLE, T0), Z0 + mov 8(TABLE, T0), Z1 + lea .Lshift_table(%rip), SHIFT_TABLE + movl $7, CNT + call .Lmul_word + mov (XP), XW + movl $8, CNT + call .Lmul_word + mov Z0, (XP) + mov Z1, 8(XP) + W64_EXIT(2, 0) + pop %rbx + ret + +.Lmul_word: + C shift Z1, Z0, transforming + C +-----------------------+-----------------------+ + C |15 14 13 12 11 10 09 08|07 06 05 04 03 02 01 00| + C +-----------------------+-----------------------+ + C into + C +-----------------------+-----------------------+ + C |14 13 12 11 10 09 08 07|06 05 04 03 02 01 00 | + C +-----------------------+-----------------+-----+ + C xor |T[15]| + C +-----+ + mov Z1, T1 + mov Z0, T0 + shl $8, Z1 C Use shld? + shl $8, Z0 + shr $56, T1 + shr $56, T0 + movzwl (SHIFT_TABLE, T1, 2), XREG(T1) + rol $8, XW + add T0, Z1 + xor T1, Z0 + movzbl LREG(XW), XREG(T2) + shl $4, T2 + xor (TABLE, T2), Z0 + xor 8(TABLE, T2), Z1 + decl CNT + jne .Lmul_word + ret + +EPILOGUE(_nettle_gcm_gf_mul_8) + +define(<W>, <0x$2$1>) + .section .rodata + ALIGN(2) +.Lshift_table: +.hword W(00,00),W(01,c2),W(03,84),W(02,46),W(07,08),W(06,ca),W(04,8c),W(05,4e) +.hword W(0e,10),W(0f,d2),W(0d,94),W(0c,56),W(09,18),W(08,da),W(0a,9c),W(0b,5e) +.hword W(1c,20),W(1d,e2),W(1f,a4),W(1e,66),W(1b,28),W(1a,ea),W(18,ac),W(19,6e) +.hword W(12,30),W(13,f2),W(11,b4),W(10,76),W(15,38),W(14,fa),W(16,bc),W(17,7e) +.hword W(38,40),W(39,82),W(3b,c4),W(3a,06),W(3f,48),W(3e,8a),W(3c,cc),W(3d,0e) +.hword W(36,50),W(37,92),W(35,d4),W(34,16),W(31,58),W(30,9a),W(32,dc),W(33,1e) +.hword W(24,60),W(25,a2),W(27,e4),W(26,26),W(23,68),W(22,aa),W(20,ec),W(21,2e) +.hword W(2a,70),W(2b,b2),W(29,f4),W(28,36),W(2d,78),W(2c,ba),W(2e,fc),W(2f,3e) +.hword W(70,80),W(71,42),W(73,04),W(72,c6),W(77,88),W(76,4a),W(74,0c),W(75,ce) +.hword W(7e,90),W(7f,52),W(7d,14),W(7c,d6),W(79,98),W(78,5a),W(7a,1c),W(7b,de) +.hword W(6c,a0),W(6d,62),W(6f,24),W(6e,e6),W(6b,a8),W(6a,6a),W(68,2c),W(69,ee) +.hword W(62,b0),W(63,72),W(61,34),W(60,f6),W(65,b8),W(64,7a),W(66,3c),W(67,fe) +.hword W(48,c0),W(49,02),W(4b,44),W(4a,86),W(4f,c8),W(4e,0a),W(4c,4c),W(4d,8e) +.hword W(46,d0),W(47,12),W(45,54),W(44,96),W(41,d8),W(40,1a),W(42,5c),W(43,9e) +.hword W(54,e0),W(55,22),W(57,64),W(56,a6),W(53,e8),W(52,2a),W(50,6c),W(51,ae) +.hword W(5a,f0),W(5b,32),W(59,74),W(58,b6),W(5d,f8),W(5c,3a),W(5e,7c),W(5f,be) +.hword W(e1,00),W(e0,c2),W(e2,84),W(e3,46),W(e6,08),W(e7,ca),W(e5,8c),W(e4,4e) +.hword W(ef,10),W(ee,d2),W(ec,94),W(ed,56),W(e8,18),W(e9,da),W(eb,9c),W(ea,5e) +.hword W(fd,20),W(fc,e2),W(fe,a4),W(ff,66),W(fa,28),W(fb,ea),W(f9,ac),W(f8,6e) +.hword W(f3,30),W(f2,f2),W(f0,b4),W(f1,76),W(f4,38),W(f5,fa),W(f7,bc),W(f6,7e) +.hword W(d9,40),W(d8,82),W(da,c4),W(db,06),W(de,48),W(df,8a),W(dd,cc),W(dc,0e) +.hword W(d7,50),W(d6,92),W(d4,d4),W(d5,16),W(d0,58),W(d1,9a),W(d3,dc),W(d2,1e) +.hword W(c5,60),W(c4,a2),W(c6,e4),W(c7,26),W(c2,68),W(c3,aa),W(c1,ec),W(c0,2e) +.hword W(cb,70),W(ca,b2),W(c8,f4),W(c9,36),W(cc,78),W(cd,ba),W(cf,fc),W(ce,3e) +.hword W(91,80),W(90,42),W(92,04),W(93,c6),W(96,88),W(97,4a),W(95,0c),W(94,ce) +.hword W(9f,90),W(9e,52),W(9c,14),W(9d,d6),W(98,98),W(99,5a),W(9b,1c),W(9a,de) +.hword W(8d,a0),W(8c,62),W(8e,24),W(8f,e6),W(8a,a8),W(8b,6a),W(89,2c),W(88,ee) +.hword W(83,b0),W(82,72),W(80,34),W(81,f6),W(84,b8),W(85,7a),W(87,3c),W(86,fe) +.hword W(a9,c0),W(a8,02),W(aa,44),W(ab,86),W(ae,c8),W(af,0a),W(ad,4c),W(ac,8e) +.hword W(a7,d0),W(a6,12),W(a4,54),W(a5,96),W(a0,d8),W(a1,1a),W(a3,5c),W(a2,9e) +.hword W(b5,e0),W(b4,22),W(b6,64),W(b7,a6),W(b2,e8),W(b3,2a),W(b1,6c),W(b0,ae) +.hword W(bb,f0),W(ba,32),W(b8,74),W(b9,b6),W(bc,f8),W(bd,3a),W(bf,7c),W(be,be) + + -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 3

EAX mode
by nisse＠lysator.liu.se 25 Jun '13

25 Jun '13

For fun, I've tried implementing the EAX mode for "authenticated encryption with associated data". Patch below. It's pretty simple, the main file, eax.c, is only some 150 lines including comments. Comments appreciated, particularly on the interface. Some features suggested in the paper, http://www.cs.ucdavis.edu/~rogaway/papers/eax.pdf, and currently not implemented: 1. There's no interface for providing the nonce incrementally. I don't think that's needed. In any case, the nonce must be provided before any of the plaintext can be processed. The interface could be extended if there are any reasonable use-cases. 2. There's no interface for reusing the same associated data for multiple messages, which might be an important optimization in some cases. I don't quite like the suggestion that not providing any associated data should imply reuse of the previous message; it seems cleaner that not providing associated data means that the associated data is the empty string. So some additional functions may be needed to provide that feature (if it is deemed important enough). For blocking, the convention is the same as for the CTR and GCM implementations: When the message (or associated data) is provided using multiple calls to _encrypt (or _decrypt or _update), the data size for each call, except the final one, *must* be a multiple of the block size. Regards, /Niels diff --git a/Makefile.in b/Makefile.in index ebc9357..e7eb2e0 100644 --- a/Makefile.in +++ b/Makefile.in @@ -74,8 +74,8 @@ nettle_SOURCES = aes-decrypt-internal.c aes-decrypt.c \ cast128.c cast128-meta.c \ blowfish.c \ cbc.c ctr.c gcm.c gcm-aes.c \ - des.c \ - des3.c des-compat.c \ + des.c des3.c des-compat.c \ + eax.c eax-aes.c \ hmac.c hmac-md5.c hmac-ripemd160.c hmac-sha1.c \ hmac-sha224.c hmac-sha256.c hmac-sha384.c hmac-sha512.c \ pbkdf2.c pbkdf2-hmac-sha1.c pbkdf2-hmac-sha256.c \ diff --git a/eax-aes.c b/eax-aes.c index e69de29..24a5560 100644 --- a/eax-aes.c +++ b/eax-aes.c @@ -0,0 +1,70 @@ +/* eax-aes.c + * + * EAX mode using AES as the underlying cipher. + */ + +/* nettle, low-level cryptographics library + * + * Copyright (C) 2011, 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 "eax.h" + +void +eax_aes_set_key(struct eax_aes_ctx *ctx, size_t length, const uint8_t *key) +{ + EAX_SET_KEY(ctx, aes_set_encrypt_key, aes_encrypt, length, key); +} + +void +eax_aes_set_nonce(struct eax_aes_ctx *ctx, + size_t length, const uint8_t *iv) +{ + EAX_SET_NONCE(ctx, aes_encrypt, length, iv); +} + +void +eax_aes_update(struct eax_aes_ctx *ctx, size_t length, const uint8_t *data) +{ + EAX_UPDATE(ctx, aes_encrypt, length, data); +} + +void +eax_aes_encrypt(struct eax_aes_ctx *ctx, + size_t length, uint8_t *dst, const uint8_t *src) +{ + EAX_ENCRYPT(ctx, aes_encrypt, length, dst, src); +} + +void +eax_aes_decrypt(struct eax_aes_ctx *ctx, + size_t length, uint8_t *dst, const uint8_t *src) +{ + EAX_DECRYPT(ctx, aes_encrypt, length, dst, src); +} + +void +eax_aes_digest(struct eax_aes_ctx *ctx, + size_t length, uint8_t *digest) +{ + EAX_DIGEST(ctx, aes_encrypt, length, digest); +} diff --git a/eax.c b/eax.c index e69de29..ec0dda9 100644 --- a/eax.c +++ b/eax.c @@ -0,0 +1,152 @@ +/* eax.c + * + * EAX mode, see http://www.cs.ucdavis.edu/~rogaway/papers/eax.pdf + */ + +/* 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 <assert.h> +#include <string.h> + +#include "eax.h" + +#include "ctr.h" +#include "memxor.h" + +static void +omac_init (uint8_t *state, unsigned t) +{ + memset (state, 0, EAX_BLOCK_SIZE - 1); + state[EAX_BLOCK_SIZE - 1] = t; +} + +static void +omac_update (uint8_t *state, const struct eax_key *key, + void *cipher, nettle_crypt_func *f, + size_t length, const uint8_t *data) +{ + for (; length >= EAX_BLOCK_SIZE; + length -= EAX_BLOCK_SIZE, data += EAX_BLOCK_SIZE) + { + f (cipher, EAX_BLOCK_SIZE, state, state); + memxor (state, data, EAX_BLOCK_SIZE); + } + if (length > 0) + { + /* Allowed only for the last call */ + f (cipher, EAX_BLOCK_SIZE, state, state); + memxor (state, data, length); + state[length] ^= 0x80; + /* XOR with (P ^ B), since the digest processing + * unconditionally XORs with B */ + memxor (state, key->pad_partial, EAX_BLOCK_SIZE); + } +} + +static void +omac_final (uint8_t *state, const struct eax_key *key, + void *cipher, nettle_crypt_func *f) +{ + memxor (state, key->pad_block, EAX_BLOCK_SIZE); + f (cipher, EAX_BLOCK_SIZE, state, state); +} + +/* Allows r == a */ +static void +gf2_double (uint8_t *r, const uint8_t *a) +{ + unsigned high = - (a[0] >> 7); + unsigned i; + /* Shift left */ + for (i = 0; i < EAX_BLOCK_SIZE - 1; i++) + r[i] = (a[i] << 1) + (a[i+1] >> 7); + + /* Wrap around for x^{128} = x^7 + x^2 + x + 1 */ + r[EAX_BLOCK_SIZE - 1] = (a[EAX_BLOCK_SIZE - 1] << 1) ^ (high & 0x87); +} + +void +eax_set_key (struct eax_key *key, void *cipher, nettle_crypt_func *f) +{ + static const uint8_t zero_block[EAX_BLOCK_SIZE]; + f (cipher, EAX_BLOCK_SIZE, key->pad_block, zero_block); + gf2_double (key->pad_block, key->pad_block); + gf2_double (key->pad_partial, key->pad_block); + memxor (key->pad_partial, key->pad_block, EAX_BLOCK_SIZE); +} + +void +eax_set_nonce (struct eax_ctx *eax, const struct eax_key *key, + void *cipher, nettle_crypt_func *f, + size_t nonce_length, const uint8_t *nonce) +{ + omac_init (eax->omac_nonce, 0); + omac_update (eax->omac_nonce, key, cipher, f, nonce_length, nonce); + omac_final (eax->omac_nonce, key, cipher, f); + memcpy (eax->ctr, eax->omac_nonce, EAX_BLOCK_SIZE); + + omac_init (eax->omac_data, 1); + omac_init (eax->omac_message, 2); +} + +void +eax_update (struct eax_ctx *eax, const struct eax_key *key, + void *cipher, nettle_crypt_func *f, + size_t data_length, const uint8_t *data) +{ + omac_update (eax->omac_data, key, cipher, f, data_length, data); +} + +void +eax_encrypt (struct eax_ctx *eax, const struct eax_key *key, + void *cipher, nettle_crypt_func *f, + size_t length, uint8_t *dst, const uint8_t *src) +{ + ctr_crypt (cipher, f, EAX_BLOCK_SIZE, eax->ctr, length, dst, src); + omac_update (eax->omac_message, key, cipher, f, length, dst); +} + +void +eax_decrypt (struct eax_ctx *eax, const struct eax_key *key, + void *cipher, nettle_crypt_func *f, + size_t length, uint8_t *dst, const uint8_t *src) +{ + omac_update (eax->omac_message, key, cipher, f, length, src); + ctr_crypt (cipher, f, EAX_BLOCK_SIZE, eax->ctr, length, dst, src); +} + +void +eax_digest (struct eax_ctx *eax, const struct eax_key *key, + void *cipher, nettle_crypt_func *f, + size_t length, uint8_t *digest) +{ + assert (length > 0); + assert (length <= EAX_BLOCK_SIZE); + omac_final (eax->omac_data, key, cipher, f); + omac_final (eax->omac_message, key, cipher, f); + + memxor (eax->omac_nonce, eax->omac_data, length); + memxor3 (digest, eax->omac_nonce, eax->omac_message, length); +} diff --git a/eax.h b/eax.h index e69de29..0177767 100644 --- a/eax.h +++ b/eax.h @@ -0,0 +1,169 @@ +/* eax.h + * + * EAX mode, see http://www.cs.ucdavis.edu/~rogaway/papers/eax.pdf + */ + +/* 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_EAX_H_INCLUDED +#define NETTLE_EAX_H_INCLUDED + +#include "aes.h" + +#ifdef __cplusplus +extern "C" { +#endif + +/* Name mangling */ +#define eax_set_key nettle_eax_set_key +#define eax_set_nonce nettle_eax_set_nonce +#define eax_update nettle_eax_update +#define eax_encrypt nettle_eax_encrypt +#define eax_decrypt nettle_eax_decrypt +#define eax_digest nettle_eax_digest + +#define eax_aes_set_key nettle_eax_aes_set_key +#define eax_aes_set_nonce nettle_eax_aes_set_nonce +#define eax_aes_update nettle_eax_aes_update +#define eax_aes_encrypt nettle_eax_aes_encrypt +#define eax_aes_decrypt nettle_eax_aes_decrypt +#define eax_aes_digest nettle_eax_aes_digest + +/* Restricted to block ciphers with 128 bit block size. FIXME: Reflect + this in naming? */ + +#define EAX_BLOCK_SIZE 16 + +/* FIXME: Ensure nice alignment. See gcm.h, union gcm_block. */ + +/* Values independent of message and nonce */ +struct eax_key +{ + uint8_t pad_block[EAX_BLOCK_SIZE]; + uint8_t pad_partial[EAX_BLOCK_SIZE]; +}; + +struct eax_ctx +{ + uint8_t omac_nonce[EAX_BLOCK_SIZE]; + uint8_t omac_data[EAX_BLOCK_SIZE]; + uint8_t omac_message[EAX_BLOCK_SIZE]; + uint8_t ctr[EAX_BLOCK_SIZE]; +}; + +void +eax_set_key (struct eax_key *key, void *cipher, nettle_crypt_func *f); + +void +eax_set_nonce (struct eax_ctx *eax, const struct eax_key *key, + void *cipher, nettle_crypt_func *f, + size_t nonce_length, const uint8_t *nonce); + +void +eax_update (struct eax_ctx *eax, const struct eax_key *key, + void *cipher, nettle_crypt_func *f, + size_t data_length, const uint8_t *data); + +void +eax_encrypt (struct eax_ctx *eax, const struct eax_key *key, + void *cipher, nettle_crypt_func *f, + size_t length, uint8_t *dst, const uint8_t *src); + +void +eax_decrypt (struct eax_ctx *eax, const struct eax_key *key, + void *cipher, nettle_crypt_func *f, + size_t length, uint8_t *dst, const uint8_t *src); + +void +eax_digest (struct eax_ctx *eax, const struct eax_key *key, + void *cipher, nettle_crypt_func *f, + size_t length, uint8_t *digest); + +#define EAX_CTX(type) \ + { type cipher; struct eax_key key; struct eax_ctx eax; } + +#define EAX_SET_KEY(ctx, set_key, encrypt, length, data) \ + do { \ + (set_key)(&(ctx)->cipher, (length), (data)); \ + if (0) (encrypt) (&(ctx)->cipher, 0, (void *) 0, (void *) 0); \ + eax_set_key (&(ctx)->key, &(ctx)->cipher, (nettle_crypt_func *) encrypt); \ + } while (0) + +#define EAX_SET_NONCE(ctx, encrypt, length, nonce) \ + (0 ? (encrypt) (&(ctx)->cipher, 0, (void *) 0, (void *) 0) \ + : eax_set_nonce (&(ctx)->eax, &(ctx)->key, \ + &(ctx)->cipher, (nettle_crypt_func *) (encrypt), \ + (length), (nonce))) + +#define EAX_UPDATE(ctx, encrypt, length, data) \ + (0 ? (encrypt) (&(ctx)->cipher, 0, (void *) 0, (void *) 0) \ + : eax_update (&(ctx)->eax, &(ctx)->key, \ + &(ctx)->cipher, (nettle_crypt_func *) (encrypt), \ + (length), (data))) + +#define EAX_ENCRYPT(ctx, encrypt, length, dst, src) \ + (0 ? (encrypt) (&(ctx)->cipher, 0, (void *) 0, (void *) 0) \ + : eax_encrypt (&(ctx)->eax, &(ctx)->key, \ + &(ctx)->cipher, (nettle_crypt_func *) (encrypt), \ + (length), (dst), (src))) + +#define EAX_DECRYPT(ctx, encrypt, length, dst, src) \ + (0 ? (encrypt) (&(ctx)->cipher, 0, (void *) 0, (void *) 0) \ + : eax_decrypt (&(ctx)->eax, &(ctx)->key, \ + &(ctx)->cipher, (nettle_crypt_func *) (encrypt), \ + (length), (dst), (src))) + +#define EAX_DIGEST(ctx, encrypt, length, digest) \ + (0 ? (encrypt) (&(ctx)->cipher, 0, (void *) 0, (void *) 0) \ + : eax_digest (&(ctx)->eax, &(ctx)->key, \ + &(ctx)->cipher, (nettle_crypt_func *) (encrypt), \ + (length), (digest))) + +struct eax_aes_ctx EAX_CTX(struct aes_ctx); + +void +eax_aes_set_key(struct eax_aes_ctx *ctx, + size_t length, const uint8_t *key); + +void +eax_aes_set_nonce(struct eax_aes_ctx *ctx, + size_t length, const uint8_t *iv); + +void +eax_aes_update(struct eax_aes_ctx *ctx, + size_t length, const uint8_t *data); + +void +eax_aes_encrypt(struct eax_aes_ctx *ctx, + size_t length, uint8_t *dst, const uint8_t *src); + +void +eax_aes_decrypt(struct eax_aes_ctx *ctx, + size_t length, uint8_t *dst, const uint8_t *src); + +void +eax_aes_digest(struct eax_aes_ctx *ctx, size_t length, uint8_t *digest); + +#ifdef __cplusplus +} +#endif + +#endif /* NETTLE_EAX_H_INCLUDED */ diff --git a/nettle-internal.c b/nettle-internal.c index 5cd5828..f6ff864 100644 --- a/nettle-internal.c +++ b/nettle-internal.c @@ -34,6 +34,7 @@ #include "nettle-internal.h" #include "blowfish.h" #include "des.h" +#include "eax.h" #include "gcm.h" #include "salsa20.h" @@ -112,3 +113,12 @@ const struct nettle_aead nettle_gcm_aes192 = _NETTLE_AEAD(gcm, GCM, aes, 192); const struct nettle_aead nettle_gcm_aes256 = _NETTLE_AEAD(gcm, GCM, aes, 256); + +#define eax_aes_set_iv eax_aes_set_nonce + +const struct nettle_aead +nettle_eax_aes128 = _NETTLE_AEAD(eax, EAX, aes, 128); +const struct nettle_aead +nettle_eax_aes192 = _NETTLE_AEAD(eax, EAX, aes, 192); +const struct nettle_aead +nettle_eax_aes256 = _NETTLE_AEAD(eax, EAX, aes, 256); diff --git a/nettle-internal.h b/nettle-internal.h index e094064..d9f1195 100644 --- a/nettle-internal.h +++ b/nettle-internal.h @@ -127,4 +127,8 @@ extern const struct nettle_aead nettle_gcm_twofish128; extern const struct nettle_aead nettle_gcm_twofish192; extern const struct nettle_aead nettle_gcm_twofish256; +extern const struct nettle_aead nettle_eax_aes128; +extern const struct nettle_aead nettle_eax_aes192; +extern const struct nettle_aead nettle_eax_aes256; + #endif /* NETTLE_INTERNAL_H_INCLUDED */ diff --git a/testsuite/.test-rules.make b/testsuite/.test-rules.make index 93ba9a8..5549fc0 100644 --- a/testsuite/.test-rules.make +++ b/testsuite/.test-rules.make @@ -103,6 +103,9 @@ ctr-test$(EXEEXT): ctr-test.$(OBJEXT) gcm-test$(EXEEXT): gcm-test.$(OBJEXT) $(LINK) gcm-test.$(OBJEXT) $(TEST_OBJS) -o gcm-test$(EXEEXT) +eax-test$(EXEEXT): eax-test.$(OBJEXT) + $(LINK) eax-test.$(OBJEXT) $(TEST_OBJS) -o eax-test$(EXEEXT) + hmac-test$(EXEEXT): hmac-test.$(OBJEXT) $(LINK) hmac-test.$(OBJEXT) $(TEST_OBJS) -o hmac-test$(EXEEXT) diff --git a/testsuite/Makefile.in b/testsuite/Makefile.in index bf0e53c..4a4aa69 100644 --- a/testsuite/Makefile.in +++ b/testsuite/Makefile.in @@ -25,7 +25,8 @@ TS_NETTLE_SOURCES = aes-test.c arcfour-test.c arctwo-test.c \ sha3-384-test.c sha3-512-test.c \ serpent-test.c twofish-test.c \ knuth-lfib-test.c \ - cbc-test.c ctr-test.c gcm-test.c hmac-test.c umac-test.c \ + cbc-test.c ctr-test.c gcm-test.c eax-test \ + hmac-test.c umac-test.c \ meta-hash-test.c meta-cipher-test.c meta-armor-test.c \ buffer-test.c yarrow-test.c pbkdf2-test.c diff --git a/testsuite/eax-test.c b/testsuite/eax-test.c index e69de29..5fe0b3f 100644 --- a/testsuite/eax-test.c +++ b/testsuite/eax-test.c @@ -0,0 +1,87 @@ +#include "testutils.h" +#include "nettle-internal.h" + +void +test_main(void) +{ + /* From the EAX specification, http://www.cs.ucdavis.edu/~rogaway/papers/eax.pdf */ + test_aead(&nettle_eax_aes128, + SHEX("233952DEE4D5ED5F9B9C6D6FF80FF478"), /* key */ + SHEX("6BFB914FD07EAE6B"), /* auth data */ + SHEX(""), /* plaintext */ + SHEX(""), /* ciphertext */ + SHEX("62EC67F9C3A4A407FCB2A8C49031A8B3"), /* nonce */ + SHEX("E037830E8389F27B025A2D6527E79D01")); /* tag */ + + test_aead(&nettle_eax_aes128, + SHEX("91945D3F4DCBEE0BF45EF52255F095A4"), + SHEX("FA3BFD4806EB53FA"), + SHEX("F7FB"), + SHEX("19DD"), + SHEX("BECAF043B0A23D843194BA972C66DEBD"), + SHEX("5C4C9331049D0BDAB0277408F67967E5")); + + test_aead(&nettle_eax_aes128, + SHEX("01F74AD64077F2E704C0F60ADA3DD523"), + SHEX("234A3463C1264AC6"), + SHEX("1A47CB4933"), + SHEX("D851D5BAE0"), + SHEX("70C3DB4F0D26368400A10ED05D2BFF5E"), + SHEX("3A59F238A23E39199DC9266626C40F80")); + + test_aead(&nettle_eax_aes128, + SHEX("D07CF6CBB7F313BDDE66B727AFD3C5E8"), + SHEX("33CCE2EABFF5A79D"), + SHEX("481C9E39B1"), + SHEX("632A9D131A"), + SHEX("8408DFFF3C1A2B1292DC199E46B7D617"), + SHEX("D4C168A4225D8E1FF755939974A7BEDE")); + + test_aead(&nettle_eax_aes128, + SHEX("35B6D0580005BBC12B0587124557D2C2"), + SHEX("AEB96EAEBE2970E9"), + SHEX("40D0C07DA5E4"), + SHEX("071DFE16C675"), + SHEX("FDB6B06676EEDC5C61D74276E1F8E816"), + SHEX("CB0677E536F73AFE6A14B74EE49844DD")); + + test_aead(&nettle_eax_aes128, + SHEX("BD8E6E11475E60B268784C38C62FEB22"), + SHEX("D4482D1CA78DCE0F"), + SHEX("4DE3B35C3FC039245BD1FB7D"), + SHEX("835BB4F15D743E350E728414"), + SHEX("6EAC5C93072D8E8513F750935E46DA1B"), + SHEX("ABB8644FD6CCB86947C5E10590210A4F")); + + test_aead(&nettle_eax_aes128, + SHEX("7C77D6E813BED5AC98BAA417477A2E7D"), + SHEX("65D2017990D62528"), + SHEX("8B0A79306C9CE7ED99DAE4F87F8DD61636"), + SHEX("02083E3979DA014812F59F11D52630DA30"), + SHEX("1A8C98DCD73D38393B2BF1569DEEFC19"), + SHEX("137327D10649B0AA6E1C181DB617D7F2")); + + test_aead(&nettle_eax_aes128, + SHEX("5FFF20CAFAB119CA2FC73549E20F5B0D"), + SHEX("54B9F04E6A09189A"), + SHEX("1BDA122BCE8A8DBAF1877D962B8592DD2D56"), + SHEX("2EC47B2C4954A489AFC7BA4897EDCDAE8CC3"), + SHEX("DDE59B97D722156D4D9AFF2BC7559826"), + SHEX("3B60450599BD02C96382902AEF7F832A")); + + test_aead(&nettle_eax_aes128, + SHEX("A4A4782BCFFD3EC5E7EF6D8C34A56123"), + SHEX("899A175897561D7E"), + SHEX("6CF36720872B8513F6EAB1A8A44438D5EF11"), + SHEX("0DE18FD0FDD91E7AF19F1D8EE8733938B1E8"), + SHEX("B781FCF2F75FA5A8DE97A9CA48E522EC"), + SHEX("E7F6D2231618102FDB7FE55FF1991700")); + + test_aead(&nettle_eax_aes128, + SHEX("8395FCF1E95BEBD697BD010BC766AAC3"), + SHEX("126735FCC320D25A"), + SHEX("CA40D7446E545FFAED3BD12A740A659FFBBB3CEAB7"), + SHEX("CB8920F87A6C75CFF39627B56E3ED197C552D295A7"), + SHEX("22E7ADD93CFC6393C57EC0B3C17D6B44"), + SHEX("CFC46AFC253B4652B1AF3795B124AB6E")); +} -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

Supported Algorithms/Key Format
by Mallikarjun Bailamanavar 21 Jun '13

21 Jun '13

Hi *, My name is Malik and I just started using the Nettle. I am looking for APIs for RSA crypto operations. >From rsa.h header file, I can make out that Nettle supports, - RSA crypto APIs only for PKCS#1 v1.5 padding mechanisms and - CRT format for RSA private key My questions, - Does nettle not support PKCS#1 v2.1 padding mechanisms e.g. RSASSA-PSS? - Does nettle not support exponent format for private key?. Meaning private key is made up of modulus and private exponent. - Is there an API for raw RSA crypto operation? Raw meaning, API must not do any encoding with input data but just has to sign/encrypt it. Can someone please clarify my questions? Thanks very much indeed in advance for the clarifications. Regards, Malik

2 1

query on nettle support.
by manish kanchan 21 Jun '13

21 Jun '13

Hi , I am trying to used Nettle cryptolibrary. I download the source, installed on ubuntu wrote a some sample application using the readme, examples files. There are couple of thing which i am still unsure. Can you help me understand this. 1. Does nettle support on PKCS1 encoding fro RSA encrytpion and signing? 2. In the PrivateKey structure, Is the d ( private expoenent ) never used? Does nettle use private key in CRT format only? and not in expoenent format ( i.e modulus and priv exp) I would be glad if you can clarify this to me. Regards Manish Kanchan

2 1

git.lysator.liu.se temporarily down
by nisse＠lysator.liu.se 30 May '13

30 May '13

The machine git.lysator.liu.se is being upgraded to a more recent debian version. Not sure when it will be operational again (it's maintained on a volunteer basis), but hopefully within a day or two. Possibly the gitorious web interface will be replaced by something different (gitolite, gitlab, ...), since gitorious seems to require quite a bit of work to install. Sorry for the inconvenience. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

ANNOUNCE: Nettle-2.7.1
by nisse＠lysator.liu.se 29 May '13

29 May '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/. One serious bug has been found in the new ECC code shipped in nettle-2.7. Thanks to Magnus Holmgren for help tracking down this problem. NEWS for the 2.7.1 release This is a bugfix release. Bug fixes: * Fixed a bug in the new ECC code. The ecc_j_to_a function called GMP:s mpn_mul_n (via ecc_modp_mul) with overlapping input and output arguments, which is not supported. * The assembly files for SHA1, SHA256 and AES depend on ARMv6 instructions, breaking nettle-2.7 for pre-v6 ARM processors. The configure script now enables those assembly files only when building for ARMv6 or later. * Use a more portable C expression for rotations. The previous version used the following "standard" expression for 32-bit rotation: (x << n) | (x >> (32 - n)) But this gives undefined behavior (according to the C specification) for n = 0. The rotate expression is replaced by the more portable: (x << n) | (x >> ((-n)&31)) This change affects only CAST128, which uses non-constant rotation counts. Unfortunately, the new expression is poorly optimized by released versions of gcc, making CAST128 a bit slower. This is being fixed by the gcc hackers, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57157. The following problems have been reported, but are *not* fixed in this release: * ARM assembly files use instruction syntax which is not supported by all assemblers. Workaround: Use a current version of GNU as, or configure with --disable-assembler. * Configuring with --disable-static doesn't work on windows. The libraries are intended to be binary compatible with nettle-2.2 and later. The shared library names are libnettle.so.4.7 and libhogweed.so.2.5, with sonames still libnettle.so.4 and libhogweed.so.2. Available at http://ftp.gnu.org/gnu/nettle/nettle-2.7.1.tar.gz ftp://ftp.gnu.org/gnu/nettle/nettle-2.7.1.tar.gz http://www.lysator.liu.se/~nisse/archive/nettle-2.7.1.tar.gz and in the "nettle-2.7-fixes" branch in the git repository, see http://git.lysator.liu.se/nettle/nettle. 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

arm compilation
by Nikos Mavrogiannopoulos 28 May '13

28 May '13

Hello, Trying to build nettle 2.7 for an arm10 system of mine using its (old) toolchain fails with assembler errors. arm-linux-gcc -Os -I[...] -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.s: Assembler messages: aes-decrypt-internal.s:81: Error: bad instruction `push {r4,r5,r6,r7,r8,r10,r11,lr}' aes-decrypt-internal.s:87: Error: register or shift expression expected -- `orr r4,r8,lsl#8' aes-decrypt-internal.s:89: Error: register or shift expression expected -- `orr r4,r8,lsl#16' aes-decrypt-internal.s:91: Error: register or shift expression expected -- `orr r4,r8,lsl#24' aes-decrypt-internal.s:93: Error: bad arguments to instruction -- `eor r4,r8' [...] make[2]: *** [aes-decrypt-internal.o] Error 1 $ arm-linux-as -v GNU assembler version 2.16.1 (arm-linux-uclibc) using BFD version 2.16.1 Trying with the latest buildroot another error is issued: arm-buildroot-linux-uclibcgnueabi-as -v GNU assembler version 2.21.1 (arm-buildroot-linux-uclibcgnueabi) using BFD version (GNU Binutils) 2.21.1 arm-buildroot-linux-uclibcgnueabi-gcc -I. -DHAVE_CONFIG_H -pipe -Os -Wno-pointer-sign -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wnested-externs -fpic -MT aes-encrypt-internal.o -MD -MP -MF aes-encrypt-internal.o.d -fpic -c aes-encrypt-internal.s aes-encrypt-internal.s: Assembler messages: aes-encrypt-internal.s:140: Error: selected processor does not support ARM mode `uxtb r8,r2' aes-encrypt-internal.s:142: Error: selected processor does not support ARM mode `uxtb r8,r3' aes-encrypt-internal.s:144: Error: selected processor does not support ARM mode `uxtb r8,r12' aes-encrypt-internal.s:146: Error: selected processor does not support ARM mode `uxtb r8,r14' Any ideas? regards, Nikos

3 17

Bug in nettle-2.7 ecc code
by nisse＠lysator.liu.se 17 May '13

17 May '13

Testing on the debian build machines revealed a bug in the new ecc code. Curiously enough, causing failures only on 32-bit sparc (see https://buildd.debian.org/status/fetch.php?pkg=nettle&arch=sparc&ver=2.7-2&…), but the bug is not really platform-specific. It turned out that ecc_j_to_a called GMP:s mpn_mul_n (via ecc_modp_mul) with overlapping input and output arguments, which is not supported. The following patch seems to solve the problem: diff --git a/ecc-j-to-a.c b/ecc-j-to-a.c index df8b876..26c1a03 100644 --- a/ecc-j-to-a.c +++ b/ecc-j-to-a.c @@ -46,6 +46,7 @@ ecc_j_to_a (const struct ecc_curve *ecc, #define up (scratch + ecc->size) #define iz2p (scratch + ecc->size) #define iz3p (scratch + 2*ecc->size) +#define izBp (scratch + 3*ecc->size) #define tp scratch mp_limb_t cy; @@ -72,11 +73,11 @@ ecc_j_to_a (const struct ecc_curve *ecc, if (flags & 1) { /* Divide this common factor by B */ - mpn_copyi (iz3p, izp, ecc->size); - mpn_zero (iz3p + ecc->size, ecc->size); - ecc->redc (ecc, iz3p); - - ecc_modp_mul (ecc, iz2p, izp, iz3p); + mpn_copyi (izBp, izp, ecc->size); + mpn_zero (izBp + ecc->size, ecc->size); + ecc->redc (ecc, izBp); + + ecc_modp_mul (ecc, iz2p, izp, izBp); } else ecc_modp_sqr (ecc, iz2p, izp); Thanks to Magnus Holmgren for tracking this down. Note that this bug causes overwrites *within* a properly allocated limb array, which gives incorrect results, but it does not overwrite any pointers or code. I should plan for a bugfix release reasonably soon. Testing with a GMP library compiled with --enable-assert would have revealed the bug earlier. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

Portable rotates
by nisse＠lysator.liu.se 03 May '13

03 May '13

I'm rewriting the cast128 key schedule, to get rid of false warnings, and avoid lots of conditions, and to separate the rotation and the mask subkeys. Then I noticed a portability problem with the rotation macros, #define ROTL32(n,x) (((x)<<(n)) | ((x)>>(32-(n)))) For n == 0, this will work on most machines, but it's not portable, since x >> 32 gives undefined behaviour according to the C spec (when x is a 32-bit type). (On typical hardware, the result of x >> 32 will be either x or 0, and the rotation macro gives the intended result in either case). In most of nettle, there's no problem, because rotation counts are constant and non-zero. cast128 is an exception, with key-dependent rotation counts, which can well be zero (don't know if that's exercised by the test suite, though). A fix is to redefine the macro as #define ROTL32(n,x) (((x)<<(n)) | ((x)>>((-(n))&31))) It should make no difference when n is constant, but for cast128, this portability fix makes the code almost 20% slower. Apparently, gcc, doens't recognize this as a rotate. I just filed a bug report at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57157 Is there any other trick I'm missing, which is portable C but which doesn't slow it down when compiled with gcc? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

raspberry pi
by nisse＠lysator.liu.se 30 Apr '13

30 Apr '13

I finally got a Raspberry Pi setup. Took almost 20 minutes to compile nettle, and the configure script figured out not to use neon instructions. It passes the testsuite. Benchmark for the public key functions: name size sign/ms verify/ms rsa 1024 0.1073 1.9099 rsa 2048 0.0167 0.5539 dsa 1024 0.1992 0.1014 ecdsa 192 0.5297 0.1922 ecdsa 224 0.3623 0.1354 ecdsa 256 0.2621 0.0971 ecdsa 384 0.1125 0.0391 ecdsa 521 0.0551 0.0190 So 3 to 5 times slower than the pandaboard (although that's not a completely fair comparison, since the raspberry pi is using gmp-5.0.5, not the gmp bleeding edge). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

Problems when compiling 32bit version on 64bit host (multilib)
by Florian Pritz 27 Apr '13

27 Apr '13

Hi, I'm compiling nettle for the Arch Linux multilib repository (32bit libraries for a 64bit system so people can run skype and wine without needing a chroot). Looks like the new ecc code doesn't properly handle integer type sizes. Here[1] is the output of make, make check along with the PKGBUILD used to build this and a sample of the generated ecc-*.h files. [1]: http://flo.server-speed.net/tmp/lib32-nettle/ Can I fix that by setting some env variable or does it need code changes? If you need any more files, please tell me.

2 2

ANNOUNCE: Nettle-2.7
by nisse＠lysator.liu.se 24 Apr '13

24 Apr '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/. NEWS for the 2.7 release This release includes an implementation of elliptic curve cryptography (ECC) and optimizations for the ARM architecture. This work was done at the offices of South Pole AB, and generously funded by the .SE Internet Fund. Bug fixes: * Fixed a bug in the buffer handling for incremental SHA3 hashing, with a possible buffer overflow. Patch by Edgar E. Iglesias. New features: * Support for ECDSA signatures. Elliptic curve operations over the following curves: secp192r1, secp224r1, secp256r1, secp384r1 and secp521r1, including x86_64 and ARM assembly for the most important primitives. * Support for UMAC, including x86_64 and ARM assembly. * Support for 12-round salsa20, "salsa20r12", as specified by eSTREAM. Contributed by Nikos Mavrogiannopoulos. Optimizations: * ARM assembly code for several additional algorithms, including AES, Salsa20, and the SHA family of hash functions. * x86_64 assembly for SHA256, SHA512, and SHA3. (SHA3 assembly was included in the 2.6 release, but disabled due to poor performance on some AMD processors. Hopefully, that performance problem is fixed now). The ARM code was tested and benchmarked on Cortex-A9. Some of the functions use "neon" instructions. The configure script decides if neon instructions can be used, and the command line options --enable-arm-neon and --disable-arm-neon can be used to override its choice. Feedback appreciated. The libraries are intended to be binary compatible with nettle-2.2 and later. The shared library names are libnettle.so.4.6 and libhogweed.so.2.4, with sonames still libnettle.so.4 and libhogweed.so.2. http://ftp.gnu.org/gnu/nettle/nettle-2.7.tar.gz ftp://ftp.gnu.org/gnu/nettle/nettle-2.7.tar.gz http://www.lysator.liu.se/~nisse/archive/nettle-2.7.tar.gz ftp://ftp.lysator.liu.se/pub/security/lsh/nettle-2.7.tar.gz (soon) 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

nettle-2.7 release candidate
by nisse＠lysator.liu.se 24 Apr '13

24 Apr '13

I've generated a release candidate, available at http://www.lysator.liu.se/~nisse/archive/nettle-2.7rc1.tar.gz Testing appreciated. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 9

[PATCH 1/2] sha: Add the missing W64_EXIT epilogue macro
by Martin Storsjö 23 Apr '13

23 Apr '13

--- x86_64/sha256-compress.asm | 1 + x86_64/sha512-compress.asm | 1 + 2 files changed, 2 insertions(+) diff --git a/x86_64/sha256-compress.asm b/x86_64/sha256-compress.asm index 6bfb7a7..385654c 100644 --- a/x86_64/sha256-compress.asm +++ b/x86_64/sha256-compress.asm @@ -192,5 +192,6 @@ PROLOGUE(_nettle_sha256_compress) mov 112(%rsp),%r15 add $120, %rsp + W64_EXIT(3, 0) ret EPILOGUE(_nettle_sha256_compress) diff --git a/x86_64/sha512-compress.asm b/x86_64/sha512-compress.asm index 21df82a..663e68e 100644 --- a/x86_64/sha512-compress.asm +++ b/x86_64/sha512-compress.asm @@ -192,5 +192,6 @@ PROLOGUE(_nettle_sha512_compress) mov 176(%rsp),%r15 add $184, %rsp + W64_EXIT(3, 0) ret EPILOGUE(_nettle_sha512_compress) -- 1.7.9.5

1 1

[PATCH 1/2] Use movdqu instead of movdqa for saving xmm registers
by Martin Storsjö 23 Apr '13

23 Apr '13

The stack is not guaranteed to be 16-byte aligned on win64. --- x86_64/machine.m4 | 40 ++++++++++++++++++++-------------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/x86_64/machine.m4 b/x86_64/machine.m4 index dc23dde..d5d5b37 100644 --- a/x86_64/machine.m4 +++ b/x86_64/machine.m4 @@ -71,34 +71,34 @@ define(<W64_ENTRY>, < ifelse(W64_ABI,yes,[ ifelse(eval($2 > 6), 1, [ sub [$]eval(8 + 16*($2 - 6)), %rsp - movdqa %xmm6, 0(%rsp) + movdqu %xmm6, 0(%rsp) ]) ifelse(eval($2 > 7), 1, [ - movdqa %xmm7, 16(%rsp) + movdqu %xmm7, 16(%rsp) ]) ifelse(eval($2 > 8), 1, [ - movdqa %xmm8, 32(%rsp) + movdqu %xmm8, 32(%rsp) ]) ifelse(eval($2 > 9), 1, [ - movdqa %xmm9, 48(%rsp) + movdqu %xmm9, 48(%rsp) ]) ifelse(eval($2 > 10), 1, [ - movdqa %xmm10, 64(%rsp) + movdqu %xmm10, 64(%rsp) ]) ifelse(eval($2 > 11), 1, [ - movdqa %xmm11, 80(%rsp) + movdqu %xmm11, 80(%rsp) ]) ifelse(eval($2 > 12), 1, [ - movdqa %xmm12, 96(%rsp) + movdqu %xmm12, 96(%rsp) ]) ifelse(eval($2 > 13), 1, [ - movdqa %xmm13, 112(%rsp) + movdqu %xmm13, 112(%rsp) ]) ifelse(eval($2 > 14), 1, [ - movdqa %xmm14, 128(%rsp) + movdqu %xmm14, 128(%rsp) ]) ifelse(eval($2 > 15), 1, [ - movdqa %xmm15, 144(%rsp) + movdqu %xmm15, 144(%rsp) ]) ifelse(eval($1 >= 1), 1, [ push %rdi @@ -133,34 +133,34 @@ define(<W64_EXIT>, < pop %rdi ]) ifelse(eval($2 > 15), 1, [ - movdqa 144(%rsp), %xmm15 + movdqu 144(%rsp), %xmm15 ]) ifelse(eval($2 > 14), 1, [ - movdqa 128(%rsp), %xmm14 + movdqu 128(%rsp), %xmm14 ]) ifelse(eval($2 > 13), 1, [ - movdqa 112(%rsp), %xmm13 + movdqu 112(%rsp), %xmm13 ]) ifelse(eval($2 > 12), 1, [ - movdqa 96(%rsp), %xmm12 + movdqu 96(%rsp), %xmm12 ]) ifelse(eval($2 > 11), 1, [ - movdqa 80(%rsp), %xmm11 + movdqu 80(%rsp), %xmm11 ]) ifelse(eval($2 > 10), 1, [ - movdqa 64(%rsp), %xmm10 + movdqu 64(%rsp), %xmm10 ]) ifelse(eval($2 > 9), 1, [ - movdqa 48(%rsp), %xmm9 + movdqu 48(%rsp), %xmm9 ]) ifelse(eval($2 > 8), 1, [ - movdqa 32(%rsp), %xmm8 + movdqu 32(%rsp), %xmm8 ]) ifelse(eval($2 > 7), 1, [ - movdqa 16(%rsp), %xmm7 + movdqu 16(%rsp), %xmm7 ]) ifelse(eval($2 > 6), 1, [ - movdqa 0(%rsp), %xmm6 + movdqu 0(%rsp), %xmm6 add [$]eval(8 + 16*($2 - 6)), %rsp ]) ]) -- 1.7.9.5

1 1

[PATCH 1/2] Consistently use EXEEXT_FOR_BUILD
by Martin Storsjö 23 Apr '13

23 Apr '13

This fixes cross building for cases where EXEEXT differs from EXEEXT_FOR_BUILD, such as when building for windows from unix. --- Makefile.in | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/Makefile.in b/Makefile.in index c96e3a3..cbc001c 100644 --- a/Makefile.in +++ b/Makefile.in @@ -31,8 +31,9 @@ getopt_TARGETS = $(getopt_SOURCES:.c=.$(OBJEXT)) internal_SOURCES = nettle-internal.c internal_TARGETS = $(internal_SOURCES:.c=.$(OBJEXT)) -TARGETS = aesdata$(EXEEXT) desdata$(EXEEXT) twofishdata$(EXEEXT) \ - shadata$(EXEEXT) gcmdata$(EXEEXT) \ +TARGETS = aesdata$(EXEEXT_FOR_BUILD) desdata$(EXEEXT_FOR_BUILD) \ + twofishdata$(EXEEXT_FOR_BUILD) shadata$(EXEEXT_FOR_BUILD) \ + gcmdata$(EXEEXT_FOR_BUILD) \ $(getopt_TARGETS) $(internal_TARGETS) \ $(LIBTARGETS) $(SHLIBTARGETS) IMPLICIT_TARGETS = @IF_DLL@ $(LIBNETTLE_FILE) $(LIBHOGWEED_FILE) @@ -273,7 +274,7 @@ des.$(OBJEXT): des.c des.h $(des_headers) # k = 7, c = 6, 320 entries, ~15 KB # k = 9, c = 7, 512 entries, ~24 KB ecc-192.h: eccdata.stamp - ./eccdata$(EXEEXT) 192 7 6 $(GMP_NUMB_BITS) > $@T && mv $@T $@ + ./eccdata$(EXEEXT_FOR_BUILD) 192 7 6 $(GMP_NUMB_BITS) > $@T && mv $@T $@ # Some possible choices for 224: # k = 18, c = 4, 64 entries, ~4 KB # k = 24, c = 6, 128 entries, ~8 KB @@ -281,7 +282,7 @@ ecc-192.h: eccdata.stamp # k = 8, c = 6, 320 entries, ~20 KB # k = 10, c = 7, 512 entries, ~32 KB ecc-224.h: eccdata.stamp - ./eccdata$(EXEEXT) 224 12 6 $(GMP_NUMB_BITS) > $@T && mv $@T $@ + ./eccdata$(EXEEXT_FOR_BUILD) 224 12 6 $(GMP_NUMB_BITS) > $@T && mv $@T $@ # Some possible choices for 256: # k = 20, c = 4, 64 entries, ~4 KB # k = 27, c = 6, 128 entries, ~8 KB @@ -289,7 +290,7 @@ ecc-224.h: eccdata.stamp # k = 9, c = 6, 320 entries, ~20 KB # k = 12, c = 7, 512 entries, ~32 KB ecc-256.h: eccdata.stamp - ./eccdata$(EXEEXT) 256 14 6 $(GMP_NUMB_BITS) > $@T && mv $@T $@ + ./eccdata$(EXEEXT_FOR_BUILD) 256 14 6 $(GMP_NUMB_BITS) > $@T && mv $@T $@ # Some possible choices for 384: # k = 31, c = 4, 64 entries, ~6 KB # k = 41, c = 6, 128 entries, ~12 KB @@ -297,7 +298,7 @@ ecc-256.h: eccdata.stamp # k = 14, c = 6, 320 entries, ~30 KB # k = 18, c = 7, 512 entries, ~48 KB ecc-384.h: eccdata.stamp - ./eccdata$(EXEEXT) 384 41 6 $(GMP_NUMB_BITS) > $@T && mv $@T $@ + ./eccdata$(EXEEXT_FOR_BUILD) 384 41 6 $(GMP_NUMB_BITS) > $@T && mv $@T $@ # Some possible choices for 521: # k = 42, c = 4, 64 entries, ~9 KB # k = 56, c = 6, 128 entries, ~18 KB @@ -305,10 +306,10 @@ ecc-384.h: eccdata.stamp # k = 19, c = 6, 320 entries, ~44 KB # k = 24, c = 7, 512 entries, ~70 KB ecc-521.h: eccdata.stamp - ./eccdata$(EXEEXT) 521 56 6 $(GMP_NUMB_BITS) > $@T && mv $@T $@ + ./eccdata$(EXEEXT_FOR_BUILD) 521 56 6 $(GMP_NUMB_BITS) > $@T && mv $@T $@ eccdata.stamp: eccdata.c - $(MAKE) eccdata$(EXEEXT) + $(MAKE) eccdata$(EXEEXT_FOR_BUILD) echo stamp > eccdata.stamp ecc-192.$(OBJEXT): ecc-192.h @@ -575,7 +576,7 @@ distcheck: dist clean-here: -rm -f $(TARGETS) $(IMPLICIT_TARGETS) *.$(OBJEXT) *.p$(OBJEXT) *.s \ ecc-192.h ecc-224.h ecc-256.h ecc-384.h ecc-521.h \ - eccdata$(EXEEXT) eccdata.stamp + eccdata$(EXEEXT_FOR_BUILD) eccdata.stamp -rm -rf .lib distclean-here: clean-here -- 1.7.9.4

1 1

ARM/NEON optimizations
by Martin Storsjö 21 Apr '13

21 Apr '13

Hi, Before the upcoming(?) release, it might be good to tweak the way the NEON optimizations are enabled. Currently, as far as I've seen, they're enabled as soon as you target ARMv7, even if not all ARMv7 CPUs have NEON. I've seen that you've discussed this on the GMP list a few times as well. For static detection in configure, one way is to check whether the assembler can do the neon instructions without actually adding the ".fpu neon" line. If this succeeds, the compiler/assembler is configured with -mfpu=neon, and we can freely use neon instructions wherever. Since there's AFAIK no runtime detection for anything else in nettle so far (nor any state or global variables), I guess you're not going to add it anytime soon - for that case, detecting it statically in configure based on the target configuration is probably good enough. Anyway, for reference on the topic of runtime detection (which is necessary e.g. on Android ARMv7, which explicitly supports a number of ARMv7 devices without NEON), there's a number of ways of doing it. One way that was mentioned on the gmp mailing list was using getauxval from glibc. This obviously isn't available on non-glibc platforms such as Android (or other platforms as well). On general linux, one pretty straightforward way is to parse /proc/self/auxv (which is pretty well structured), the other is parsing /proc/cpuinfo (which requires a little bit more code to parse). The Android NDK comes with a small support library that detects cpu extensions - previously it used to parse /proc/self/auxv, but in recent Android versions this file isn't accessible within release mode processes, so now it parses /proc/cpuinfo. See http://git.libav.org/?p=libav.git;a=blob;f=libavutil/arm/cpu.c or https://android.googlesource.com/platform/ndk/+/a92ba07e8abf397e74285e90d08… for examples on how to parse these files. A third option is to allow the caller to set it, so the caller can use whatever runtime detection that is available on the app level and configure the library accordingly. But this both goes against the design of nettle, and additionally isn't too useful when nettle in many cases is used indirectly via a number of other libraries, and the calling app might not even know much about what lower level libraries are used. // Martin

3 6

Support for via quadcore SHA512 hw acceleration‏
by Shaun Murphy 21 Apr '13

21 Apr '13

The limited literature for the newer VIA QuadCore E-Series embedded platform says that it now supports "Secure Hash Algorithm: SHA-1, SHA-256, SHA-384, SHA-512" but I'm not seeing any acceleration for SHA512 in the kernel modules or nettle / gnutls. I would appreciate some pointers on what I need to do to access that SHA512 acceleration in nettle. Here's my setup:Via Artigo A1250 Ubuntu 12.04 x86_64Gnutls - built from git Nettle - built from 2.6 source Kernel modules: padlock_aes, padlock_sha Here's my dmesg output for the loaded modules:[ 2.345061] padlock_aes: Using VIA PadLock ACE for AES algorithm.[ 2.364105] padlock_sha: Using VIA PadLock ACE for SHA1/SHA256 algorithms. gnutls Benchmark Soft Ciphers:Checking SHA1 (16kb payload)... Processed 464.73 MB in 5.00 secs: 92.95 MB/secChecking SHA256 (16kb payload)... Processed 180.04 MB in 5.00 secs: 36.01 MB/secChecking SHA512 (16kb payload)... Processed 267.39 MB in 5.00 secs: 53.48 MB/sec gnutls Benchmark Ciphers:Checking SHA1 (16kb payload)... Processed 1.51 GB in 5.00 secs: 0.30 GB/secChecking SHA256 (16kb payload)... Processed 1.30 GB in 5.00 secs: 0.26 GB/secChecking SHA512 (16kb payload)... Processed 267.45 MB in 5.00 secs: 53.49 MB/sec The SHA256 numbers are great but I really need SHA512 for my application. Thank you.

2 1

[PATCH] Fix a typo in a comment
by Martin Storsjö 18 Apr '13

18 Apr '13

--- aclocal.m4 | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/aclocal.m4 b/aclocal.m4 index 0d24fc2..98b399b 100644 --- a/aclocal.m4 +++ b/aclocal.m4 @@ -610,8 +610,8 @@ AC_SUBST(EXEEXT_FOR_BUILD,$gmp_cv_prog_exeext_for_build) dnl NETTLE_CHECK_ARM_NEON dnl --------------------- -dnl Check if ARM Neon instructinos should be used. -dnl Obeys enable_arn_neon, which should be set earlier. +dnl Check if ARM Neon instructions should be used. +dnl Obeys enable_arm_neon, which should be set earlier. AC_DEFUN([NETTLE_CHECK_ARM_NEON], [if test "$enable_arm_neon" = auto ; then if test "$cross_compiling" = yes ; then -- 1.7.9.4

1 0

rename of salsa20r12
by Nikos Mavrogiannopoulos 17 Apr '13

17 Apr '13

The attached patch renames the salsa20r12_crypt function to estream_salsa20_crypt(), and adds it in the benchmarks. What is missing is an equivalent of x86_64/salsa20-crypt.asm for the estream variant. regards, Nikos

2 4

Micro optimizations of the umac context structs
by nisse＠lysator.liu.se 16 Apr '13

16 Apr '13

Speaking of umac, I'm also looking at the umac context structs, for potential micro optimizations and fixes before it becomes a part of the ABI. Some fields, like nonce_length, index, and (for umac32 and umac64) nonce_low, fit in 16 or even 8 bits. So it might make sense to make them adjacent. And on the other hand, the umac block count is currently unsigned, and will wraparound after 2*32 blocks or 2^42 bytes. Other hash functions typically support data sizes up to 2^64 (except sha512 which uses a 128-bit coutner, which seems gross overkill). For umac, the block counter is only needed to keep track of when to switch to different layer 2 hashing, and to keep track of odd and even blocks for poly128. So it could probably be made to work with only 16 bits and some saturation logic. But extending it to 64 bits seems simpler. It would also be nice if we could force 16-byte alignment for the l1_key array (this is important for assembly routines), which would them imply 16-byte alignment for the complete context struct. Could help x86 sse2 assembly. And could help also on ARM, but I'm not sure if the system (primarily linker and malloc) really makes 16-byte alignment possible there. And it would also be good to get a reasonably large alignment for the block buffer. In gcc, there's __attribute__ ((aligned (16))), but since this gets part of the ABI, we can't use it in public headers unless we can specify the same alignment for *all* reasonable compilers for the given architecture. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 5

Internal vs installed headers
by nisse＠lysator.liu.se 16 Apr '13

16 Apr '13

I'm considering moving some macros from macros.h (installad as <nettle/macros.h>) to nettle-internal.h (not installed). Only the various READ, WRITE and ROTL macros seem generally useful. Comments? I'm also looking at the current umac.h. It could be split into umac.h and umac-internal.h, but I'm not sure that's needed; the "internal" definitions are reasonably clean and seem unlikely to cause problems. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 3

umac
by nisse＠lysator.liu.se 12 Apr '13

12 Apr '13

I have now read the UMAC spec (RFC 4418) a bit more carefully. I haven't yet read Niko's code (or any other code, for that matter). Some thoughts: o I don't like the way endian conversion is done in the spec. I'd prefer to think about the various functions as operating on arrays of 32-bit words, and implementation should use integer types of the right size to get correct alignment etc. o The "NH" function looks like a candidate for for assembly implementation. I don't know if there's anything else in the algorithm which really is performance critical? (And here we get a contradiction to point (1), it may be best for performance to have the NH function get the unaligned byte array as input, do be able to use assembly tricks when reading it into integers. Anyway, we should really avoid byte arrays in the internal interfaces between L1/L2/L3). o *Maybe* optimization of the L2 and L3 hashes will be important. Profiling is needed, I guess, and they should be optimized *after* L1/NH. o Since I have been work with side-channel silence recently, it seems natural to try to make the POLY function silent, On the other hand, I'm not sure what the threats are. If the MAC is applied to a secret message, we may leak some information about the message, I guess? o I think we ought to handle large messages correctly, which means we need the POLY function also over the 128-bit prime. Performance is not terribly important, at least not initially. o I'm not sure exactly how the building blocks fit together, but we should strive for pipelining. When we have the first message block M_1, apply L1 to that block, then apply L2 and L3 to the output as soon as possible. And for the larger tag lengths, also try to make that looping inside the loop processing the sequence of message blocks, so we can discard M_1 before starting to work on the next block M_2. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

3 20

Building on AIX 6.1
by Perry Smith 10 Apr '13

10 Apr '13

Hi Guys, I got libnettle to build on AIX 6.1 but I had to edit the Makefile.in and the configure.ac file. Editing the configure.ac is fine. But I had to change the make rules so the shared library depended upon nettle_OBJS instead of nettle_PURE_OBJS. I *think* (but I'm not sure) that the .po suffix confuses the linker. It appears as if it was just ignoring all the .po files. I'm happy to post my diffs but they may not help much. I've never seen "pure" objects before. Is this really a useful concept? Thank you, Perry

2 4

Re: [PATCH] sha3: Correct _sha3_update for incremental hashing
by nisse＠lysator.liu.se 06 Apr '13

06 Apr '13

edgar.iglesias(a)gmail.com writes: > diff --git a/sha3.c b/sha3.c > index d7aec46..21e7beb 100644 > --- a/sha3.c > +++ b/sha3.c > @@ -61,7 +61,7 @@ _sha3_update (struct sha3_state *state, > if (pos > 0) > { > unsigned left = block_size - pos; > - if (length < pos) > + if (length < left) > { > memcpy (block + pos, data, length); > return pos + length; Thanks, checked in now. Unfortunately, testutils.c:test_hash doesn't exercise this logic. 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 February
by nisse＠lysator.liu.se 04 Apr '13

04 Apr '13

Here's a copy of the second status update, which I just submitted to Internetfonden. Regards, /Niels Nettle project funded by Internetfonden Status update for February 2013 * Summary New ECC code integrated in the Nettle repository. The code has been optimized with respect to both storage and computation requirements. * Activities Most of the time in February has been spent on the ECC code, both optimization, and integration work. The ECC code has been integrated into Nettle, including a preliminary high-level interface for ECDSA signatures. The code is available in the branch "ecc-support" in the repository at git://git.lysator.liu.se/nettle/nettle.git. Final days and first days of February have been used to implement the most important curve-specific functions in ARM assembly. Independently if the ECC support, also the function memxor has been optimized for ARM. During the month, roughly 120 working hours have been spent on the project. * Elliptic curves Point multiplication involving an arbitrary point now uses a side-channel silent window based algorithm. This gave a speedup of around 30% for ECDSA signature verification. For each curve, arithmetic on the coordinates is done modulo a curve specific prime number, e.g., p = 2^192 - 2^64 + 1 for the curve "secp-192r1", and p = 2^224 - 2^96 - 1 for the curve "secp-224r1". These primes all have special structure, which can be used to speed up the modp operation following each multiplication of two coordinates. Since the key operation is add with carry, which is poorly supported by the C programming language, writing these functions in assembly is attractive. Reducing a 384 bit number, typically the product of two 192-bit numbers, modulo the 192-bit prime above can be done with 12 add with carry instructions on the x86_64 architecture, or 26 on the 32-bit ARM. ARM assembly implementation gave a speedup of 2-4 times of the modulo operations, corresponding to a speedup around 50% for ECDSA sign and verify operations. The functions for doing ECC point addition have also been optimized to reduce the amount of temporary storage. E.g, with the current code, ECDSA signatures over the curve secp-256r1 requires 384 bytes of temporary storage for signing, and 2080 bytes to verify a signature. A few operations did not use side-channel silent algorithms earlier. These have been replaced by side-channel silent versions, which causes some slowdown. In particular, the side-channel silent modular inversion is very slow. Benchmarks, as of March 5, including changes relative the the numbers in the previous status report: Intel i5, 3.4 GHz: name size sign/ms verify/ms rsa 1024 6.3299 105.0161 rsa 2048 0.9573 29.5316 dsa 1024 11.1947 5.7647 ecdsa 192 18.1878 +1.4% 6.2035 +64% ecdsa 224 8.9302 -11% 2.8714 +41% ecdsa 256 8.1958 -13% 2.6707 +20% ecdsa 384 3.1515 -10% 0.9866 +25% ecdsa 521 1.8874 -13% 0.6858 +30% ecdsa (openssl) 224 3.4829 3.0458 ecdsa (openssl) 384 1.4516 1.2711 ecdsa (openssl) 521 0.6855 0.5831 ARM Cortex A9, 1 GHz: name size sign/ms verify/ms rsa 1024 0.2634 4.5464 rsa 2048 0.0392 1.2481 dsa 1024 0.4688 0.2381 ecdsa 192 1.2303 -4.5% 0.4318 +50% ecdsa 224 0.8526 +8.5% 0.3075 +72% ecdsa 256 0.6286 +6.5% 0.2243 +75% ecdsa 384 0.2532 +4.5% 0.0876 +61% ecdsa 521 0.1319 -0.6% 0.0448 +51% ecdsa (openssl) 224 0.1843 0.1563 ecdsa (openssl) 384 0.0693 0.0589 ecdsa (openssl) 521 0.0259 0.0214 So in these benchmarks, the net effect of the development is a great improvement of the speed of signature verification, with more mixed results for signature creation. For comparison, the benchmark also includes figures for the ECDSA functions provided by the OpenSSL library (for the three curves supported by both Nettle and OpenSSL). On x86_64, signing is 2.2 -- 2.8 times faster than OpenSSL, and verification is from 22% slower to 18% faster. On ARM, signature performance is 3.6 -- 5 times faster, and verify performance is 1.5 -- 2 times faster. Speaking of benchmarks, the ARM assembly for Nettle's memxor function, also developed during February, gave a speedup of 20% -- 50% depending on the input alignment. * Remaining tasks The ECC interface needs to be finalized and documented. There are always additional optimizations that are possible. Writing x86_64 assembly for the modulo functions is tempting, but of low priority within this project. As mentioned, the modular inversion is slow, with the current code, 20% -- 30% of the time to create an ECDSA signature is spent computing a modular inverse. This could be sped up by assembly implementation of the primitives this algorithm needs, or by writing the complete function in assembler. The optimization of other cryptographic primitives such as the AES cipher and the SHA256 hash function remains to do. It has turned out that some internal functions in the GMP library, used for arithmetic on larger numbers, would be useful for the ECC implementation. One possible direction is to extend the public GMP interface so these functions can be used. -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 1

Possible bug and patch for nettle
by Sarat Chandra Addepalli 01 Apr '13

01 Apr '13

1 0

openssl tests
by Nikos Mavrogiannopoulos 27 Mar '13

27 Mar '13

Hello, In some systems the elliptic curves part of openssl is disabled. This patch disables the openssl examples/tests if it does not exist (I had issue with the EC tests). Also in some issue I replaced an #if with and #ifdef, because the rule didn't work. -#if WITH_OPENSSL +#ifdef WITH_OPENSSL In general I noticed a lot of uses of "#if" that actually mean ifdef. Are these intentional? I'm not really sure what #if does if followed by an undefined expression. regards, Nikos

2 2

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