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

Re: nettle-pbkdf2 dumps core when executed with an unknown option
by nisse＠lysator.liu.se 26 Jan '16

26 Jan '16

dongsheng zhang <dongsheng.zhang(a)oracle.com> writes: > Will a newer version of nettle with the fix be released soon please? Your bug report was very timely, a new relase, nettle-3.2, is planned this week. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

Re: nettle-pbkdf2 dumps core when executed with an unknown option
by nisse＠lysator.liu.se 26 Jan '16

26 Jan '16

dongsheng zhang <dongsheng.zhang(a)oracle.com> writes: > We have found that nettle-pbkdf2 dumps core when executed with an > unknown option. Thanks for the bug report. There was a missing "case '?':" in the option handling, and a similar bug also in nettle-hash. Fix checked in now, the programs should display a usage message and exit. (Some of the other programs just call exit (EXIT_FAILURE) in this situation, and some lack usage messages, so it's not completely consistent). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

using gitlab CI for nettle
by Nikos Mavrogiannopoulos 25 Jan '16

25 Jan '16

Hi, gitlab now allows mirroring projects so I've setup a mirror of nettle at gitlab main server: https://gitlab.com/gnutls/nettle This has the advantage of using gnutls' CI servers. For that I attach the file needed to be present to enable using these servers. On every commit nettle will be tested for building + make check, in the available platforms and a mail will be sent to the author/committer. An example run can be seen at: https://gitlab.com/gnutls/nettle/builds?scope=finished regards, Nikos

2 7

Hashing with short input assertion question
by Tim Ruehsen 08 Jan '16

08 Jan '16

Hi, just experienced a crash (assertion) when using md5 on short input. test: md5.c:81: nettle_md5_digest: Assertion `length <= 16' failed. The code is struct md5_ctx md5; md5_init(&md5); md5_update(&md5, "moin", 4); md5_digest(&md5, 20, digest); My system is Debian SID (libnettle6:amd64 3.1.1-4). The example (http://www.lysator.liu.se/~nisse/nettle/nettle.html#Example) does not mention special handling for short input (nettle_sha1_digest() has a similar assert()). I searched the document for 'padding' but found nothing relevant. How should I proceed ? Pad with 0 bytes ? Is it reasonable to open a Debian bug suggesting to use -DNDEBUG ? IMO, these assertions needs to be disabled on a production system or replaced by proper error handling. It would be fine to have them in the respective -dbg (debugging) package though. Best regards, Tim

3 8

Miscalculations on secp384 curve
by Hanno Böck 15 Dec '15

15 Dec '15

Hi, Attached is an example elliptic curve multiplication that will produce a wrong result in nettle. It's a multiplication of these coordinates 23000000000000000000000000000000000000000000000000110011C2DD0000000000000000000 46BE3FEF75FCA4BD52CE28EC3F1483A05EE154965B05282F9029E14277409908C0EBAAD2CA5449FFA61FEC78473816BC with this scalar 23000000000000C1DD3FF800E83E2CACA1010A21 The example code will do the calculation with both openssl and nettle and will produce different results (I have verified the result with nss, which produces the same result as openssl). Compile with gcc nettle-nistp384-miscalc.c -lhogweed -lgmp -lcrypto -- Hanno Böck http://hboeck.de/ mail/jabber: hanno(a)hboeck.de GPG: BBB51E42

2 4

secp256 calculation bug (already fixed)
by Hanno Böck 12 Dec '15

12 Dec '15

Hi, I had reported this privately to Niels Möller, but I'm re-sending it here so it's publicly available and archived. (Niels didn't think it's neccesary to keep this private.) The attached example will show a bug in the nistp256 point multiplication of nettle. It compiles a certain curve point with 1 which should not change the coordinates, however it does. Was fixed here: https://git.lysator.liu.se/nettle/nettle/commit/c71d2c9d20eeebb985e3872e455… -- Hanno Böck http://hboeck.de/ mail/jabber: hanno(a)hboeck.de GPG: BBB51E42

1 0

nettle + rsa crt fix
by Nikos Mavrogiannopoulos 11 Dec '15

11 Dec '15

Hi, Given this issue in openssl [0] , I think the issue of software errors helping retrieve an RSA key seems less and less foreign. Given its repercussions if such an issue exists (RSA private keys can be retrieved) would it make sense to have a bug fix release with that? regards, Nikos [0]. https://blog.fuzzing-project.org/31-Fuzzing-Math-miscalculations-in-OpenSSL…

3 4

RSASSA-PSS API
by andy lawrence 08 Dec '15

08 Dec '15

Hello, I have been thinking about implementing RSASSA-PSS in Nettle. I would like to propose the following API for performing and verifying signatures: diff --git a/rsa.h b/rsa.h > index 6d2574b..b9faffe 100644 > --- a/rsa.h > +++ b/rsa.h > @@ -35,6 +35,7 @@ > #define NETTLE_RSA_H_INCLUDED > > #include "nettle-types.h" > +#include "nettle-meta.h" > #include "bignum.h" > > #include "md5.h" > @@ -188,6 +189,27 @@ int > rsa_private_key_prepare(struct rsa_private_key *key); > > > +/* PSS style signatures */ > +int > +rsa_pss_sign(const struct rsa_private_key *key, > + size_t length, const uint8_t *digest_info, > + mpz_t s, const struct nettle_hash *hash_func, > + size_t salt_length, const uint8_t *salt); > + > +int > +rsa_pss_sign_tr(const struct rsa_public_key *pub, > + const struct rsa_private_key *key, > + void *random_ctx, nettle_random_func *random, > + size_t length, const uint8_t *digest_info, > + mpz_t s, const struct nettle_hash *hash_func, > + size_t salt_length, const uint8_t *salt); > + > +int > +rsa_pss_verify(const struct rsa_public_key *key, > + size_t length, const uint8_t *digest_info, > + const mpz_t signature, const struct nettle_hash *hash_func, > + size_t salt_length); > + > /* PKCS#1 style signatures */ > int > rsa_pkcs1_sign(const struct rsa_private_key *key, > It is fairly similar to PKCS#1 API but with the addition of a hash function and salt. If this sounds reasonable then I will have a go at writing the implementations. Best wishes, Andrew Lawrence

4 6

SIGILL on armv7
by Nikos Mavrogiannopoulos 03 Dec '15

03 Dec '15

Hi, It was reported that nettle crashes with SIGILL on an armv7 system. I've gather some info from the report [0], but let me know if you need anything else. My hunch is that this is neon related, and that the system that was used for compilation supported it but the final system doesn't. I'll disable neon support in the fedora builds and see how it works out. The instruction that fails is: (gdb) x/i$pc => 0xb6647af8 <_nettle_salsa20_core+8>: vldmia r12, {d20-d25} And the backtrace is: (gdb) backtrace #0 _nettle_salsa20_core () at salsa20-core-internal.s:58 #1 0xb6647db4 in nettle_salsa20r12_crypt (ctx=ctx@entry=0xb6cc7f40 <nonce_ctx>, length=<optimized out>, length@entry=29, c=c@entry=0x7f67ce83 "", m=m@entry=0x7f67ce83 "") at salsa20r12-crypt.c:65 #2 0xb6c9b1e0 in wrap_nettle_rnd_nonce (_ctx=<optimized out>, datasize=29, data=0x7f67ce83) at rnd.c:302 #3 wrap_nettle_rnd (_ctx=<optimized out>, level=level@entry=0, data=0x7f67ce83, datasize=datasize@entry=29) at rnd.c:321 #4 0xb6bcdd2c in _gnutls_rnd (len=29, data=<optimized out>, level=GNUTLS_RND_NONCE) at ./random.h:37 #5 create_tls_random (dst=<optimized out>) at gnutls_handshake.c:205 #6 0xb6bce0e0 in _gnutls_set_client_random (session=<optimized out>, rnd=<optimized out>) at gnutls_handshake.c:230 #7 0xb6bcf460 in send_client_hello (again=<optimized out>, session=0x7f67ce38) at gnutls_handshake.c:2039 #8 send_hello (session=session@entry=0x7f67ce38, again=<optimized out>) at gnutls_handshake.c:2249 #9 0xb6bd2ca4 in handshake_client (session=0x7f67ce38) at gnutls_handshake.c:2732 #10 gnutls_handshake (session=0x7f67ce38) at gnutls_handshake.c:2583 #11 0xb6f9a9d8 in cstp_handshake (vpninfo=vpninfo@entry=0x7f58ccf8, init=64, init@entry=1) at gnutls.c:2250 #12 0xb6f9aff8 in openconnect_open_https (vpninfo=vpninfo@entry=0x7f58ccf8) at gnutls.c:2227 #13 0xb6f7cc70 in do_https_request (vpninfo=vpninfo@entry=0x7f58ccf8, method=0xb6f9f700 "POST", method@entry=0xb6ffec80 <__stack_chk_guard> "", request_body_type=request_body_type@entry=0xb6f9fa28 "application/x-www-form-urlencoded", request_body=request_body@entry=0x7f58d480, form_buf=0xbefff25c, form_buf@entry=0x1bb, fetch_redirect=fetch_redirect@entry=0) at http.c:875 #14 0xb6f8d1a0 in cstp_obtain_cookie (vpninfo=<optimized out>) at auth.c:1238 #15 0x7f559508 in main (argc=0, argv=0x0) at main.c:1388 [0]. The full report: https://bugzilla.redhat.com/show_bug.cgi?id=1287298#c10 regards, Nikos

2 3

RSA-CRT hardening
by Florian Weimer 15 Nov '15

15 Nov '15

I strongly suggest to implement RSA-CRT hardening, by checking that RSA signature have not been miscomputed accidentally: <https://securityblog.redhat.com/2015/09/02/factoring-rsa-keys-with-tls-perf…> <https://people.redhat.com/~fweimer/rsa-crt-leaks.pdf> We did not see any key leaks which could be attributed to Nettle, but I think the added verification is still a reasonable precaution. Thanks, Florian -- Florian Weimer / Red Hat Product Security

3 20

Travel plans
by nisse＠lysator.liu.se 22 Oct '15

22 Oct '15

I'm going to be in San Francisco and Mountain View the next two weeks. I don't know if we have any list members in the area, but if so, I'd be happy to meet up over a coffee or beer. When I'm back home I'll start working at google's Stockholm office. I guess there might be some initial obstacles, but the plan is that I'll keep hacking on Nettle as a mostly spare-time project, like I've been doing for the past few years. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

[PATCH] sha3 update
by Nikos Mavrogiannopoulos 26 Aug '15

26 Aug '15

The attached two patches update SHA3 to the final published version.

2 13

sha3
by Nikos Mavrogiannopoulos 07 Aug '15

07 Aug '15

It seems that as of today SHA-3 is finalized as a standard algorithm. http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf

1 0

Helping out
by andy lawrence 31 Jul '15

31 Jul '15

Hello, I am interested in helping out with the development of Nettle. Are there any small projects I could undertake to get started? Best wishes, Andrew Lawrence

2 1

SHAKE
by Simon Josefsson 05 Jul '15

05 Jul '15

Can Nettle compute the SHAKE128/SHAKE256 variant of SHA-3? What do you think about adding APIs for them? /Simon

2 1

dlopen nettle-3.1 built with --enable-fat leads to SIGSEGV
by Mark H Weaver 24 Jun '15

24 Jun '15

The following test program leads to SIGSEGV in 'get_x86_features' while loading libnettle.so from nettle-3.1 built with --enable-fat: --8<---------------cut here---------------start------------->8--- #include <stdio.h> #include <stdlib.h> #include <dlfcn.h> int main (int argc, char *argv[]) { void *handle; handle = dlopen ("libnettle.so", RTLD_NOW); if (!handle) { fprintf (stderr, "%s\n", dlerror ()); exit (EXIT_FAILURE); } dlclose (handle); exit (EXIT_SUCCESS); } --8<---------------cut here---------------end--------------->8--- Here's the backtrace: --8<---------------cut here---------------start------------->8--- #0 0x0000000000009006 in ?? () #1 0x00007ffff73f6a37 in get_x86_features (features=<synthetic pointer>) at fat-x86_64.c:94 #2 fat_init () at fat-x86_64.c:133 #3 0x00007ffff7412475 in nettle_memxor_resolve () at fat-x86_64.c:185 #4 0x00007ffff7de8c41 in elf_machine_rela (reloc=0x7ffff73f5170, reloc=0x7ffff73f5170, skip_ifunc=0, reloc_addr_arg=<optimized out>, version=<optimized out>, sym=0x7ffff73ee2d0, map=0x601050) at ../sysdeps/x86_64/dl-machine.h:286 #5 elf_dynamic_do_Rela (skip_ifunc=0, lazy=0, nrelative=<optimized out>, relsize=<optimized out>, reladdr=<optimized out>, map=0x601050) at do-rel.h:137 #6 _dl_relocate_object (scope=<optimized out>, reloc_mode=reloc_mode@entry=0, consider_profiling=<optimized out>, consider_profiling@entry=0) at dl-reloc.c:264 #7 0x00007ffff7defb36 in dl_open_worker (a=a@entry=0x7fffffffcea8) at dl-open.c:418 #8 0x00007ffff7deb704 in _dl_catch_error (objname=objname@entry=0x7fffffffce98, errstring=errstring@entry=0x7fffffffcea0, mallocedp=mallocedp@entry=0x7fffffffce97, operate=operate@entry=0x7ffff7def800 <dl_open_worker>, args=args@entry=0x7fffffffcea8) at dl-error.c:187 #9 0x00007ffff7def2db in _dl_open (file=0x4009f4 "libnettle.so", mode=-2147483646, caller_dlopen=<optimized out>, nsid=-2, argc=1, argv=0x7fffffffd1f8, env=0x7fffffffd208) at dl-open.c:652 #10 0x00007ffff7bd9fab in dlopen_doit (a=a@entry=0x7fffffffd0c0) at dlopen.c:66 #11 0x00007ffff7deb704 in _dl_catch_error (objname=0x7ffff7ddc0f0 <last_result+16>, errstring=0x7ffff7ddc0f8 <last_result+24>, mallocedp=0x7ffff7ddc0e8 <last_result+8>, operate=0x7ffff7bd9f50 <dlopen_doit>, args=0x7fffffffd0c0) at dl-error.c:187 #12 0x00007ffff7bda55d in _dlerror_run (operate=operate@entry=0x7ffff7bd9f50 <dlopen_doit>, args=args@entry=0x7fffffffd0c0) at dlerror.c:163 #13 0x00007ffff7bda041 in __dlopen (file=<optimized out>, mode=<optimized out>) at dlopen.c:87 #14 0x0000000000400924 in main () --8<---------------cut here---------------end--------------->8--- The SIGSEGV happens in the following call: _nettle_cpuid (0, cpuid_data); The problem appears to be that the PLT entry for '_nettle_cpuid' has not yet been initialized when 'fat_init' is called via 'nettle_memxor_resolve': --8<---------------cut here---------------start------------->8--- mhw@jojen:~$ LD_LIBRARY_PATH=$HOME/.guix-profile/lib gdb ./test GNU gdb (GDB) 7.9.1 Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ./test...(no debugging symbols found)...done. (gdb) directory /home/mhw/nettle-3.1 Source directories searched: /home/mhw/nettle-3.1:$cdir:$cwd (gdb) run Starting program: /home/mhw/test Program received signal SIGSEGV, Segmentation fault. 0x0000000000009006 in ?? () (gdb) up #1 0x00007ffff73f6a37 in get_x86_features (features=<synthetic pointer>) at fat-x86_64.c:94 warning: Source file is more recent than executable. 94 _nettle_cpuid (0, cpuid_data); (gdb) break 94 Breakpoint 1 at 0x7ffff73f6a1f: file fat-x86_64.c, line 94. (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /home/mhw/test Breakpoint 1, fat_init () at fat-x86_64.c:133 warning: Source file is more recent than executable. 133 get_x86_features (&features); (gdb) si 0x00007ffff73f6a24 in get_x86_features (features=<synthetic pointer>) at fat-x86_64.c:94 94 _nettle_cpuid (0, cpuid_data); (gdb) 96 features->vendor = X86_INTEL; (gdb) 94 _nettle_cpuid (0, cpuid_data); (gdb) 95 if (memcmp (cpuid_data + 1, "Genu" "ntel" "ineI", 12) == 0) (gdb) 94 _nettle_cpuid (0, cpuid_data); (gdb) 0x00007ffff73f6000 in _nettle_cpuid@plt () from /home/mhw/.guix-profile/lib/libnettle.so (gdb) disassemble /m 0x00007ffff73f6000 Dump of assembler code for function _nettle_cpuid@plt: => 0x00007ffff73f6000 <+0>: jmpq *0x22c722(%rip) # 0x7ffff7622728 <_nettle_cpuid(a)got.plt> 0x00007ffff73f6006 <+6>: pushq $0x26 0x00007ffff73f600b <+11>: jmpq 0x7ffff73f5d90 End of assembler dump. (gdb) disassemble /m 0x7ffff7622728 Dump of assembler code for function _nettle_cpuid(a)got.plt: 0x00007ffff7622728 <+0>: (bad) 0x00007ffff7622729 <+1>: nop 0x00007ffff762272a <+2>: add %al,(%rax) 0x00007ffff762272c <+4>: add %al,(%rax) 0x00007ffff762272e <+6>: add %al,(%rax) End of assembler dump. (gdb) si 0x0000000000009006 in ?? () (gdb) --8<---------------cut here---------------end--------------->8--- This is a problem for GNU Guix because 'gstreamer' loads its modules using the glib function 'g_module_open' (based on 'dlopen') and the 'gst-libav' module is linked with nettle. This breaks 'gst-libav' on x86_64. Details ======= System type: x86_64-unknown-linux-gnu nettle-3.1 compiled with: gcc-4.8.4 binutils-2.25 glibc-2.21 Nettle configure flags: CONFIG_SHELL=/gnu/store/wxcgfy43r6lmxhm2m7xk1vsgyddhx3y0-bash-4.3.33/bin/bash SHELL=/gnu/store/wxcgfy43r6lmxhm2m7xk1vsgyddhx3y0-bash-4.3.33/bin/bash --prefix=/gnu/store/k0bhgy2l5kj1hp2vxx3ys42pn4kr599h-nettle-3.1 --enable-fast-install --enable-fat LDFLAGS=-Wl,-rpath=/gnu/store/k0bhgy2l5kj1hp2vxx3ys42pn4kr599h-nettle-3.1/lib Here's the build log for the nettle used in the above tests: http://hydra.gnu.org/build/381502/log/raw If needed, I can explain how to reproduce this exact environment using GNU Guix. Mark

2 4

Two issues found by Address sanitizer
by Tomáš Chvátal 21 Jun '15

21 Jun '15

Hello everybody, we at suse ran address sanitizer against libnettle and found two bugs [1][2]. The first one is easy to fix (simple off by one) and thus we already have the patch (see attachment 0001-...). The second one is about memory leaks, and it would be better if someone more aware of the source took a look wether and how to fix it. Cheers Tom [1] https://bugzilla.suse.com/show_bug.cgi?id=928328 [2] https://bugzilla.suse.com/show_bug.cgi?id=929109 PS: I am not subscribed so keep me in CC please.

2 1

Re: Bug#783699: nettle-dev is not Multi-Arch compatible
by nisse＠lysator.liu.se 28 May '15

28 May '15

[I'm cross-posting to the nettle list and a debian bug, so please take care when replying] The issue is that there are some differences in generated nettle header files depending on architecture and compiler version. Francois Gouget <fgouget(a)free.fr> writes: > Here is a proposed patch for the compiler version issue in nettle-stdint.h: > > $ cat debian/patches/multiarch.patch > --- a/aclocal.m4 > +++ b/aclocal.m4 > @@ -857,7 +857,7 @@ > fi # shortcircut to system "stdint.h" > # ------------------ PREPARE VARIABLES ------------------------------ > if test "$GCC" = "yes" ; then > -ac_cv_stdint_message="using gnu compiler "`$CC --version | head -1` > +ac_cv_stdint_message="using gnu compiler $CC" > else > ac_cv_stdint_message="using $CC" > fi If we go this path, maybe just drop the conditional and unconditionally print "using $CC"? I'm not sure about the reason for displaying the version, but I guess some older gcc versions did stdint and/or inttypes.h differently. If you have the time, it would be helpful to look at the latest version of AX_CREATE_STDINT_H (from autoconf archive) and see if it does anything differently. Nettle uses a pretty old version (which seems to work fine). > For GMP_NUMB_BITS here are some thoughts: You must understand that nettle defines GMP_NUMB_BITS only if configured with --enable-mini-gmp. This configuration is not intended to be compatible with anything else, and should never be installed on a normal debian system. It's intended for small embedded systems which needs to verify digital signatures, but which consider the real libgmp too large. > * Is it really necessary to install version.h? > IMHO the right place for other packages to figure out library versions is through > some scripting in the configure script rather than through a > header. This has been requested by users. Not everyone uses autoconf. And it's very common practice, I think both gmp and gnutls have similar version defines. > * GMP_NUMB_BITS is already defined by libgmp-dev in gmp.h. More > preceisely Exactly, and when not configuring with --enable-mini-gmp, that's the definitions which is used. Getting into the details, Nettle's definition of GMP_NUMB_BITS conceptually belongs in mini-gmp.h. However, mini-gmp is a standalone package which doesn't use autoconf. And it has to be a preprocessor *constant*, so definiting it like sizeof(unsigned long) * CHAR_BIT won't cut it, since the preprocessor doesn't understand sizeof. Therefore the definition, for the --enable-mini-gmp configuration which needs it, should be in a nettle include file. Then the cleanest way would be to omit the definition completely when not using --enable-mini-gmp. I haven't done that, because it would make the substitution logic harder, and because I was thinking that #define NETTLE_USE_MINI_GMP 0 #if NETTLE_USE_MINI_GMP # define GMP_NUMB_BITS 64 #endif is harmless whatever value appears in the second define. If it helps, I guess this could be changed into the architecture independent #define NETTLE_USE_MINI_GMP 0 #if NETTLE_USE_MINI_GMP # define GMP_NUMB_BITS the moon is made of green cheese #endif Opinions? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 1

Version API
by Elliot Saba 12 May '15

12 May '15

Hello there, I saw the recent addition of the version #define's, which are great, but a runtime function that I can call to find out libnettle's API is essential for dynamic bindings. I maintain the Julia language bindings for Nettle <https://github.com/staticfloat/Nettle.jl> which loads the dynamic library and generates methods to use Nettle's cryptographic functions on the fly. This process does not use header files, it's similar to Python's ctypes functionality, and thus knowing which API version we're dealing with by only using the dynamic library itself is necessary. Most other projects have some method or other for determining this, as you guys have already discussed, but simply placing the information into a header file is not sufficient for this use case. Is this something it would be possible to support? Thanks! -E

2 5

nettle-3.1 transition and symbol versions
by nisse＠lysator.liu.se 02 May '15

02 May '15

Now we see some transition problems, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784009, and it's going to also hit other distributions than debian. Would it make sense to issue a nettle-2.7.2, which is nettle-2.7.1 + symbol versions? There's at least one bugfix which could be backported if we do another 2.7.x: 2014-06-30 Niels Möller <nisse(a)lysator.liu.se> * camellia-absorb.c: Include <limits.h>, needed for correct use of HAVE_NATIVE_64_BIT. Reported and debugged by Magnus Holmgren. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 1

ANNOUNCE: Nettle-3.1.1
by nisse＠lysator.liu.se 24 Apr '15

24 Apr '15

I've made another release of GNU Nettle, a low-level cryptographics library, to fix bugs reported for Nettle 3.1. The Nettle home page can be found at http://www.lysator.liu.se/~nisse/nettle/, and the manual at http://www.lysator.liu.se/~nisse/nettle/nettle.html. NEWS for the Nettle 3.1.1 release This release fixes a couple of non-critical bugs. Bug fixes: * By accident, nettle-3.1 disabled the assembly code for the secp_224r1 and secp_521r1 elliptic curves on all x86_64 configurations, making signature operations on those curves 10%-30% slower. This code is now re-enabled. * The x86_64 assembly implementation of gcm hashing has been fixed to work with the Sun/Oracle assembler. The shared library names are libnettle.so.6.1 and libhogweed.so.4.1, with sonames still libnettle.so.6 and libhogweed.so.4. It is intended to be fully binary compatible with nettle-3.1. Available at: https://ftp.gnu.org/gnu/nettle/nettle-3.1.1.tar.gz ftp://ftp.gnu.org/gnu/nettle/nettle-3.1.1.tar.gz http://www.lysator.liu.se/~nisse/archive/nettle-3.1.1.tar.gz ftp://ftp.lysator.liu.se/pub/security/lsh/nettle-3.1.1.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

Re: bug against .short value
by nisse＠lysator.liu.se 22 Apr '15

22 Apr '15

dongsheng zhang <dongsheng.zhang(a)oracle.com> writes: > Solaris doesn't take .short value, but instead only takes .value value. > We thus cannot compile the following file: > nettle-3.1/x86_64/gcm-hash8.asm I've checked in a fix. Can you try to check out https://git.lysator.liu.se/nettle/nettle.git and test if it solves the problem? You need to run the script ./.boostrap before configure and make. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

Re: bug against .short value
by nisse＠lysator.liu.se 21 Apr '15

21 Apr '15

dongsheng zhang <dongsheng.zhang(a)oracle.com> writes: > Solaris doesn't take .short value, but instead only takes .value value. > We thus cannot compile the following file: > nettle-3.1/x86_64/gcm-hash8.asm I see. From some testing, it seems that GNU as treats all of .short, .word, .value and .2byte as aliases, defining 16-bit constants. We currently use .short, and that breaks x86_64 builds using the Sun/Oracle assembler. Does anyone know which of ".word", ".value" and ".2byte" is more portable (.value sounds very unspecific to me)? I'd prefer to use a pseudo op supported by all relevant x86_64 assemblers, and not have to add a configure test for this. I think the relevant assemblers are GNU as (including older versions), Sun/Oracle as, and the assembler used with clang on freebsd. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

ANNOUNCE: Nettle-3.0
by nisse＠lysator.liu.se 13 Apr '15

13 Apr '15

I'm happy to announce a new version of GNU Nettle, a low-level cryptographics library. The Nettle home page can be found at http://www.lysator.liu.se/~nisse/nettle/. This release is dual licensed as LGPLv3 or later, or GPLv2 or later. See the manual for details. NEWS for the Nettle 3.0 release This is a major release, including several interface changes, and new features, some of which are a bit experimental. Feedback is highly appreciated. It is *not* binary (ABI) compatible with earlier versions. It is mostly source-level (API) compatible, with a couple of incompatibilities noted below. The shared library names are libnettle.so.5.0 and libhogweed.so.3.0, with sonames libnettle.so.5 and libhogweed.so.3. There may be some problems in the new interfaces and new features which really need incompatible fixes. It is likely that there will be an update in the form of a 3.1 release in the not too distant future, with small but incompatible changes, and if that happens, bugfix-only releases 3.0.x are unlikely. Users and applications which desire better API and ABI stability are advised to stay with nettle-2.7.x (latest version is now 2.7.1) until the dust settles. Interface changes: * For the many _set_key functions, it is now consider the normal case to have a fixed key size, with no key_size arguments. _set_key functions with a length parameter are provided only for algorithms with a truly variable keysize, and where it makes sense for backwards compatibility. INCOMPATIBLE CHANGE: cast128_set_key no longer accepts a key size argument. The old function is available under a new name, cast5_set_key. INCOMPATIBLE CHANGE: The function typedef nettle_set_key_func no longer accepts a key size argument. In particular, this affects users of struct nettle_cipher. * The nettle_cipher abstraction (in nettle-meta.h) is restricted to block ciphers only. The encrypt and decrypt functions now take a const argument for the context. INCOMPATIBLE CHANGE: nettle_arcfour, i.e., the nettle_cipher abstraction for the arcfour stream cipher, is deleted. INCOMPATIBLE CHANGE: New type, nettle_cipher_func, for the encrypt and decrypt fields of struct nettle_cipher. * New DSA interface, with a separate struct dsa_param to represent the underlying group, and generalized dsa_sign and dsa_verify functions which don't care about the hash function used. Limited backwards compatibility provided in dsa-compat.h. INCOMPATIBLE CHANGE: Declarations of the old interface, e.g., struct dsa_public_key, dsa_sha1_sign, etc, is moved to dsa-compat.h. INCOMPATIBLE CHANGE: The various key conversion functions, e.g., dsa_keypair_to_sexp, all use the new DSA interface, with no backwards compatible functions. INCOMPATIBLE CHANGE: dsa_generate_keypair also uses the new interface. dsa-compat.h declares a function dsa_compat_generate_keypair, implementing the old interface, and #defines dsa_generate_keypair to refer to this backwards compatible function. * New AES and Camellia interfaces. There are now separate context structs for each key size, e.g., aes128_ctx and camellia256_ctx, and corresponding new functions. The old interface, with struct aes_ctx and struct camellia_ctx, is kept for backwards compatibility, but might be removed in later versions. * The type of most length arguments is changed from unsigned to size_t. The memxor functions have their pointer arguments changed from uint8_t * to void *, for consistency with related libc functions. * For hash functions, the constants *_DATA_SIZE have been renamed to *_BLOCK_SIZE. Old names kept for backwards compatibility. Removed features: * The nettle_next_prime function has been deleted. Applications should use GMP's mpz_nextprime instead. * Deleted the RSAREF compatibility, including the header file rsa-compat.h and everything declared therein. * Also under consideration for removal is des-compat.h and everything declared therein. This implements a subset of the old libdes/ssleay/openssl interface for DES and triple-DES, and it is poorly tested. If anyone uses this interface, please speak up! Otherwise, it will likely be removed in the next release. Bug fixes: * Building with ./configure --disable-static now works. * Use GMP's allocation functions for temporary storage related to bignums, to avoid potentially large stack allocations. * Fixes for shared libraries on M$ Windows. New features: * Support for Poly1305-AES MAC. * Support for the ChaCha stream cipher and EXPERIMENTAL support for the ChaCha-Poly1305 AEAD mode. Specifications are still in flux, and future releases may do incompatible changes to track standardization. Currently uses 256-bit key and 64-bit nonce. * Support for EAX mode. * Support for CCM mode. Contributed by Owen Kirby. * Additional variants of SHA512 with output size of 224 and 256 bits. Contributed by Joachim Strömbergson. * New interface, struct nettle_aead, for mechanisms providing authenticated encryption with associated data (AEAD). * DSA: Support a wider range for the size of q and a wider range for the digest size. Optimizations: * New x86_64 assembly for GCM and MD5. Modest speedups on the order of 10%-20%. Miscellaneous: * SHA3 is now documented as EXPERIMENTAL. Nettle currently implements SHA3 as specified at the time Keccak won the SHA3 competition. However, the final standard specified by NIST is likely to be incompatible, in which case future releases may do incompatible changes to track standardization. * The portability fix for the rotation macros, mentioned in NEWS for 2.7.1, actually didn't make it into that release. It is included now. * cast128_set_key rewritten for clarity, also eliminating a couple of compiler warnings. * New command line tool nettle-pbkdf2. Available at: https://ftp.gnu.org/gnu/nettle/nettle-3.0.tar.gz ftp://ftp.gnu.org/gnu/nettle/nettle-3.0.tar.gz http://www.lysator.liu.se/~nisse/archive/nettle-3.0.tar.gz ftp://ftp.lysator.liu.se/pub/security/lsh/nettle-3.0.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.

5 12

nettle-3.1rc1
by nisse＠lysator.liu.se 03 Apr '15

03 Apr '15

Available now, at http://www.lysator.liu.se/~nisse/archive/nettle-3.1rc1.tar.gz http://www.lysator.liu.se/~nisse/archive/nettle-3.1rc1.tar.gz.sig There's also a corresponding tag in the repo (except that the suffix "rc1" on the package version in configure.ac is not committed). All testing and proof-reading highly appreciated. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

4 12

Getting closer to nettle-3.1
by nisse＠lysator.liu.se 26 Mar '15

26 Mar '15

I think the remaining items on http://www.lysator.liu.se/~nisse/nettle/plan.html aren't very urgent, and can be postponed. Discussed recently, but not on that list, is mem_equalp (or whatever it should be called). That's also not very urgent. I plan to move NETTLE_USE_MINI_GMP from bignum.h to version.h, and drop bignum.h.in. It should be enough with one configure-generated header like that. It also has the advantage that version.h actually gets used during the build. That change touches a couple of files, so I don't want to check that in tonight. Anyway, I think it's time to get into final testing. I've done some tests on freebsd, revealing one real bug (triggered only when compiled with the ancient gcc version freebsd keeps in /usr/bin). And I've made some fixes to what gets included by make dist. I hope to be able to create a nettle-3.1rc1.tar.gz in a day or two. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 2

curve25519 and eddsa
by nisse＠lysator.liu.se 19 Mar '15

19 Mar '15

I've just pushed some documentation for the curve25519 and eddsa functions. This raises a few questions on the current interfaces. 1. Should ecc-curves.h really declare nettle_curve25519? Its' not needed for any of the documented functions, except for obscurities like doing ecdsa (not eddsa) over the curve. It could be moved to ecc-internal, or be marked as internal in some other way. Perhaps renaming to _nettle_ed25519 would be appropriate. 2. curve25519_mul should be changed to have a void return type (an earlier implementation failed for inputs which didn't correspond to points on the curve, but instead were points on its twist). But the current implementation, using the Montgomery ladder, doesn't care and computes a well defined result for all inputs. 3. struct ed25519_private_key and struct ed25519_public_key include compile-time constant limb arrays. At least for the public key, this will imply an ABI break if/when we switch to a base 2^51 representations for GF(2^255 - 19). So maybe switch to dynamic allocation for struct ed25519_public_key, or both structs? 4. There's no function to generate eddsa key pairs. To generate a private key, use a random 32-octet string. To get the corresponding public key, one can call ed25519_set_private_key, and copy the pub element of the struct. This needs some additional documentation or maybe some additional function. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

3 12

patch: define API version number
by Nikos Mavrogiannopoulos 19 Mar '15

19 Mar '15

Hello, This patch adds a definition in nettle-meta.h with nettle's version number. That way applications can be easily modified to support both the 2.7 and the 3.x API. I didn't add for hogweed because it didn't seem to make sense, the API version is fully determined by nettle only. regards, Nikos

2 8

patch: added missing dist files
by Nikos Mavrogiannopoulos 19 Mar '15

19 Mar '15

1 0

test failures on powerpc64le-redhat-linux
by Martin Sebor 17 Mar '15

17 Mar '15

Running Nettle 3.0 tests on a powerpc64le RHEL 7.1 box shows the two failures below. The cause is in the second definition of the HAVE_NATIVE_64_BIT configuration macro: $ grep HAVE_NATIVE_64_BIT config.* config.h:# define HAVE_NATIVE_64_BIT 1 config.h:# define HAVE_NATIVE_64_BIT (SIZEOF_LONG * CHAR_BIT >= 64) The macro relies on the CHAR_BIT macro being defined at the point of its expansion. Uses of HAVE_NATIVE_64_BIT of the form #if !HAVE_NATIVE_64_BIT in files that don't include <limits.h> (and thus don't have the CHAR_BIT macro defined) end up compiling the conditional blocks that are intended to be included only when the target has no native support for 64 bit arithmetic. One such file that comes into play in the failing tests is camellia-absorb.c. Since powerpc64le obviously does have such support, the code is unnecessary and, as it turns out, introduces errors. Once <limits.h> is included all of Nettle's tests pass even on powerpc64le-redhat-linux. Martin ... Encrypt failed: Input: 0123456789abcdef fedcba9876543210 Output: df51fc645013f77c 25c472e2871f742a Expected: 6767313854966973 0857065648eabe43 /src/nettle-3.0/run-tests: line 57: 46381 Aborted "$1" $testflags FAIL: camellia ... Assert failed: /src/nettle-3.0/testsuite/testutils.c:513: MEMEQ(digest->length, buffer, digest->data) /src/nettle-3.0/run-tests: line 57: 49811 Aborted "$1" $testflags FAIL: gcm ... ==================== 2 of 55 tests failed ====================

2 1

memeql_sec
by nisse＠lysator.liu.se 14 Mar '15

14 Mar '15

I think there's only one sensitive use of memcmp within nettle, and that's the tag comparison in ccm_decrypt_message. I've now written a private function memeql_sec to do that comparison in a more side-channel silent fashion. static int memeql_sec (const void *a, const void *b, size_t n) { volatile const unsigned char *ap = (const unsigned char *) a; volatile const unsigned char *bp = (const unsigned char *) b; volatile unsigned char d; size_t i; for (d = i = 0; i < n; i++) d |= (ap[i] ^ bp[i]); return d == 0; } The idea is to avoid leaking (via timing or memory access patterns) the location of the first difference. Information that a guess for a forged MAC tag matches some characters of the correct MAC can be used to attack the MAC key, in particular for MAC algorithms with linear structure such as gcm and poly1305 (which is why chacha-poly1305 uses a new poly1305 key for each message, and why one shouldn't use gcm with short authentication tags). memeql_sec is a bit similar to http://nacl.cr.yp.to/verify.html. Now, applications using nettle are likely doing a lot of similar comparisons on hash and hmac digests. So it would be good to make this function public. But then I'd need to decide on 1. A good name. 2. A suitable headerfile to declare it in. It would make some sense to group it together with memxor, but memxor.h isn't a good name for that header file. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

3 5

Please add base-64 URL-safe alphabet
by Amos Jeffries 10 Feb '15

10 Feb '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 RFC 4648 (https://tools.ietf.org/html/rfc4648) standardizes two Base-64 alphabets. Nettle currently only supports the traditional base-64 alphabet from section 4. There is growing use amongst new protocol definitions and extensions, particularly in the HTTP area for the URL-safe extension alphabet instead of the classical Base-64 alphabet. The attached patch implements a proposed API/ABI extension adding support for RFC 4648 section 5 "Base 64 Encoding with URL and Filename Safe Alphabet" External code simply calls the init() function relevant to the alphabet it is needing to encode/decode with. The library internally uses the context to select which lookup table to use for later base64 function calls. The base64_encode_raw() and base64_encode_group() functions which do not use contexts are left untouched for now. Amos Jeffries Treehouse Networks Ltd. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUiXerAAoJELJo5wb/XPRjPxEIAJGMXNF0H84kJntKpe1idimr +x7/xg55GJ2sWEBAbVIHvKvjFZoBIeqNmPeeK+yrqMdA+dtALA37AuezqhiNBtuj YfGd/DyRvys2O2bQ4XNRHxj6zGQU6tlRHHZzSnWp9ywwN4xk/zfNc5JM0EKYqiuu 8crNPzQxP91N33gkdi9LrOkAA8v+/bTYJgTrT46D/2Ut+8ECAcpjS5jwsJiljETu uqO50QlhqGC3ZsHKs1kYnjrbl1Peiqw/b/srEnY3shfS9MKrTYe3qLOsvU5CQpnD A7e8w/SW716D0s4t0SGf85WvUnS6UvDTfAdm3EXAPKNU8PaYpK9D8izq8kgxCP4= =NgGG -----END PGP SIGNATURE-----

4 15

nettle-3.1 loose ends
by nisse＠lysator.liu.se 05 Feb '15

05 Feb '15

Looking at http://www.lysator.liu.se/~nisse/nettle/plan.html, the most important things are done. I think documentation is the only item left which is both important and requires several hours of work. * Versioned symbols. I think this is complete, I just have forgotten to merge that branch. * Base64 with other alphabets. A patch was posted to the list some month ago, I had some comments, and then it seems to have stalled. If it's desirable to break the ABI to implement it, 3.1 may be the last chance for some years time. * OCB mode. Is it a good idea to try to get this into the release? I don't think patents are a problem, but I've mailed sflc, and it would be nice to get their opinion too. Needs not just the code, but also test cases and documentation. * Also OFB mode has been requested, used by openpgp, iirc. Anything else I've missed? And which of the above items are important? There are a lot of things that could be better optimized, including the curve25519 code and the aesni code, but I don't think the release should be delayed for that. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

4 10

OCB mode
by Nikos Mavrogiannopoulos 28 Jan '15

28 Jan '15

Hello, What do you think of having OCB mode in nettle? I particularly like OCB due to it's simplicity and performance comparing to GCM/CCM, but was always patented. However in [0] there is license1 which states: "Under this license, you are authorized to make, use, and distribute open-source software implementations of OCB. This license terminates for you if you sue someone over their open-source software implementation of OCB claiming that you have a patent covering their implementation." What do you think? Should the FSF be consulted on that? regards, Nikos [0]. http://www.cs.ucdavis.edu/~rogaway/ocb/license.htm

4 8

ecc.h vs ecc-internal.h
by nisse＠lysator.liu.se 27 Jan '15

27 Jan '15

I'm about to remove a lot of the internal declarations from ecc.h, and move the ones which still are needed to ecc-internal.h. Problem is that most of these functions work only with particular curve types, and are typically installed in function pointers in struct ecc_curve. If they really are needed as public functions, they must be reimplemented to jump via the appropriate function pointer. And some, like most or all of the corresponding itch functions, are not even defined anywhere anymore (replaced by macros in ecc-internal.h, and fields in struct ecc_curve). ecc_size_j is a borderline case, not sure if it should be public (if so, it should probably be renamed, and not mean "convert to jacobian coordinates", but "convert to whatever internal representation is appropriate for the curve". And everything below ecc_size_j in ecc.h should be removed. Any objections? Any function applications are relying on? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 2

Intel aes instructions
by nisse＠lysator.liu.se 25 Jan '15

25 Jan '15

I've just pushed new aes code using intel's aesni instructions. See https://git.lysator.liu.se/nettle/nettle/blob/530014f3f811d9018ec83a8748fdb… It gave a speedup of almost 10 times on the haswell machine where I tested it (and in addition, it should avoid sidechannel leaks in those functions). Clearly, this will be more useful after adding support for fat binaries, detecting presence of these instructions at runtime. For now, it has to be enabled explicitly with the configure argument --enable-x86-aesni. I have one question, on how to enable support for these instructions in the assembler. For now I added a pseudo-op .arch bdver2 and that seems to work, but it's a bit too specific for my taste. I would have preferred something like .arch generic64,aes, but I couldn't get that to work. So what's the right way to do this? I haven't played with the corresponding arch flags to gcc, but I'd prefer do declare within the .asm file itself which instruction set it is intended for. Feedback on the actual assembler code is also appreciated, of course. It's pretty basic, a dozen lines, no unrolling or other cleverness. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

5 34

[PATCH 1/2] arm: Add .arch directives for armv6
by Martin Storsjö 24 Jan '15

24 Jan '15

This allows building these files as part of a fat build, even if the assembler by default targets a lower architecture version. --- arm/v6/aes-decrypt-internal.asm | 2 ++ arm/v6/aes-encrypt-internal.asm | 2 ++ arm/v6/sha1-compress.asm | 1 + arm/v6/sha256-compress.asm | 1 + 4 files changed, 6 insertions(+) diff --git a/arm/v6/aes-decrypt-internal.asm b/arm/v6/aes-decrypt-internal.asm index 28d8f6f..3eab3eb 100644 --- a/arm/v6/aes-decrypt-internal.asm +++ b/arm/v6/aes-decrypt-internal.asm @@ -30,6 +30,8 @@ ifelse(< not, see http://www.gnu.org/licenses/. >) + .arch armv6 + include_src(<arm/aes.m4>) define(<PARAM_ROUNDS>, <r0>) diff --git a/arm/v6/aes-encrypt-internal.asm b/arm/v6/aes-encrypt-internal.asm index f7f4769..e4fa25d 100644 --- a/arm/v6/aes-encrypt-internal.asm +++ b/arm/v6/aes-encrypt-internal.asm @@ -30,6 +30,8 @@ ifelse(< not, see http://www.gnu.org/licenses/. >) + .arch armv6 + include_src(<arm/aes.m4>) C Benchmarked at at 706, 870, 963 cycles/block on cortex A9, diff --git a/arm/v6/sha1-compress.asm b/arm/v6/sha1-compress.asm index fc1ebf0..59d6297 100644 --- a/arm/v6/sha1-compress.asm +++ b/arm/v6/sha1-compress.asm @@ -31,6 +31,7 @@ ifelse(< >) .file "sha1-compress.asm" + .arch armv6 define(<STATE>, <r0>) define(<INPUT>, <r1>) diff --git a/arm/v6/sha256-compress.asm b/arm/v6/sha256-compress.asm index 93c12b1..7560778 100644 --- a/arm/v6/sha256-compress.asm +++ b/arm/v6/sha256-compress.asm @@ -31,6 +31,7 @@ ifelse(< >) .file "sha256-compress.asm" + .arch armv6 define(<STATE>, <r0>) define(<INPUT>, <r1>) -- 1.9.3 (Apple Git-50)

1 1

[Fwd: [gnutls-help] Generating DH Parameters larger than 3072 bits]
by Nikos Mavrogiannopoulos 16 Dec '14

16 Dec '14

Hello, It seems that by switching gnutls to nettle 2.7.x for DSA (and DH) key generation the forwarded issues occur. Would it be possible to have a 2.7.x release with the attached patch? That would allow gnutls 3.3.x generate arbitrary DH parameters. regards, Nikos

1 0

function casts
by Nikos Mavrogiannopoulos 13 Dec '14

13 Dec '14

It seems that in the GCM macros nettle uses casts to functions. That is pretty dangerous with the changes of parameters in functions in nettle 3. The issue is the compiler will not warn for serious errors such as different function type. An example macro is GCM_ENCRYPT. #define GCM_ENCRYPT(ctx, encrypt, length, dst, src) \ (0 ? (encrypt)(&(ctx)->cipher, 0, (void *)0, (void *)0) \ : gcm_encrypt(&(ctx)->gcm, &(ctx)->key, &(ctx)->cipher, \ (nettle_cipher_func *) (encrypt), \ (length), (dst), (src))) I don't think that nettle should be casting functions. The issue seems to be present in ctr, eax and cbc modes as well. regards, Nikos

2 10

Potential bug in nettle-benchmark.c
by Eli Zaretskii 12 Dec '14

12 Dec '14

This was flagged by GCC: nettle-benchmark.c: In function 'time_cipher': nettle-benchmark.c:504:29: warning: argument to 'sizeof' in 'memset' call is the same expression as the destination; did you mean to provide an explicit length? [-Wsizeof-pointer-memaccess] memset(iv, 0, sizeof(iv)); ^ nettle-benchmark.c:520:29: warning: argument to 'sizeof' in 'memset' call is the same expression as the destination; did you mean to provide an explicit length? [-Wsizeof-pointer-memaccess] memset(iv, 0, sizeof(iv)); ^ nettle-benchmark.c:537:29: warning: argument to 'sizeof' in 'memset' call is the same expression as the destination; did you mean to provide an explicit length? [-Wsizeof-pointer-memaccess] memset(iv, 0, sizeof(iv)); ^ Here's a suggested patch: --- examples/nettle-benchmark.c~0 2013-05-28 17:21:54.000000000 +0300 +++ examples/nettle-benchmark.c 2014-12-12 17:58:10.670625000 +0200 @@ -501,7 +501,7 @@ time_cipher(const struct nettle_cipher * info.block_size = cipher->block_size; info.iv = iv; - memset(iv, 0, sizeof(iv)); + memset(iv, 0, sizeof(*iv)); cipher->set_encrypt_key(ctx, cipher->key_size, key); @@ -517,7 +517,7 @@ time_cipher(const struct nettle_cipher * info.block_size = cipher->block_size; info.iv = iv; - memset(iv, 0, sizeof(iv)); + memset(iv, 0, sizeof(*iv)); cipher->set_decrypt_key(ctx, cipher->key_size, key); @@ -534,7 +534,7 @@ time_cipher(const struct nettle_cipher * info.block_size = cipher->block_size; info.iv = iv; - memset(iv, 0, sizeof(iv)); + memset(iv, 0, sizeof(*iv)); cipher->set_encrypt_key(ctx, cipher->key_size, key);

2 2

issues found while converting from 2.7 to 3.0
by Nikos Mavrogiannopoulos 08 Dec '14

08 Dec '14

Hello, * gcm.h: The GCM_SET_KEY macro uses key both as input and to access a ctx element, and thus requires the last parameter to be called "key" as well. #define GCM_SET_KEY(ctx, set_key, encrypt, key) \ do { \ (set_key)(&(ctx)->cipher, (key)); \ if (0) (encrypt)(&(ctx)->cipher, 0, (void *)0, (void *)0); \ gcm_set_key(&(ctx)->key, &(ctx)->cipher, \ (nettle_cipher_func *) (encrypt)); \ } while (0) * cbc.h: cbc_encrypt and decrypt use const void* as first parameter. That is, it cannot be wrapped over a function that works for cbc_encrypt as well as gcm_aes_encrypt (the latter doesn't use const). Without casts that is. Overall, what I didn't like it that the new cipher API required more code to wrap around it. * macros.h: The MD_INCR(ctx) macro is now only applicable for sha512. * nettle-types.h: There is still nettle_crypt_func which is identical to nettle_cipher_func. Is that intentional? I was wondering what was its use. * dsa_verify() Note sure if this is a regression, but this function will now succeed verifying data signed with a DSA-2048 key and SHA1 as hash. * libhogweed soname: libhogweed has the same soname with 2.7.1, so applications crash if they are linked against nettle 2.7.1 and 3.0 is installed (that is because hogweed links against libnettle.so.5). It may make sense for both libraries to share the same so version. regards, Nikos

2 16

gcm + encrypt_message
by Nikos Mavrogiannopoulos 25 Nov '14

25 Nov '14

I am trying to figure out how to wrap around CCM and GCM, and it seems like a hard task. They are totally incompatible. Would it make sense instead of have an equivalent of ccm_decrypt_message() in gcm as well, and make that the AEAD API? regards, Nikos

3 2

symbol versioning
by Nikos Mavrogiannopoulos 24 Nov '14

24 Nov '14

The attached patch will add symbol versioning in nettle. That would mean that software linked against nettle 3.x will be able to interoperate with libraries that are linked on a previous version of nettle (and vice versa). You could check the new symbol names with "readelf -Ws libnettle.so" regards, Nikos

2 2

FAILs in make check
by braga 10 Nov '14

10 Nov '14

Dear nettle community I am triyng to install nettle2.7.1 (because I want to install gnutls-cli but it doesn't support nettle3.0) on my Ubuntu 12.04 i686 architecture but I always get this result on make check zaamus@zaamuspc:~/Dependencies/nettle-2.7.1$ make check make check-here make[1]: ingresso nella directory "/home/zaamus/Dependencies/nettle-2.7.1" true make[1]: uscita dalla directory "/home/zaamus/Dependencies/nettle-2.7.1" set -e; for d in tools testsuite examples; do \ echo "Making check in $d" ; (cd $d && make check); done Making check in tools make[1]: ingresso nella directory "/home/zaamus/Dependencies/nettle-2.7.1/tools" true make[1]: uscita dalla directory "/home/zaamus/Dependencies/nettle-2.7.1/tools" Making check in testsuite make[1]: ingresso nella directory "/home/zaamus/Dependencies/nettle-2.7.1/testsuite" LD_LIBRARY_PATH=../.lib PATH="../.lib:$PATH" srcdir="." \ EMULATOR="" NM="nm" EXEEXT="" \ ../run-tests aes-test arcfour-test arctwo-test blowfish-test cast128-test base16-test base64-test camellia-test des-test des3-test des-compat-test md2-test md4-test md5-test md5-compat-test memxor-test gosthash94-test ripemd160-test salsa20-test sha1-test sha224-test sha256-test sha384-test sha512-test sha3-permute-test sha3-224-test sha3-256-test sha3-384-test sha3-512-test serpent-test twofish-test knuth-lfib-test cbc-test ctr-test gcm-test hmac-test umac-test meta-hash-test meta-cipher-test meta-armor-test buffer-test yarrow-test pbkdf2-test sexp-test sexp-format-test rsa2sexp-test sexp2rsa-test bignum-test random-prime-test pkcs1-test rsa-test rsa-encrypt-test rsa-keygen-test dsa-test dsa-keygen-test ecc-mod-test ecc-modinv-test ecc-redc-test ecc-mul-g-test ecc-mul-a-test ecdsa-sign-test ecdsa-verify-test ecdsa-keygen-test cxx-test sexp-conv-test pkcs1-conv-test symbols-test PASS: aes PASS: arcfour PASS: arctwo PASS: blowfish PASS: cast128 PASS: base16 PASS: base64 PASS: camellia PASS: des PASS: des3 PASS: des-compat PASS: md2 PASS: md4 PASS: md5 PASS: md5-compat PASS: memxor PASS: gosthash94 PASS: ripemd160 PASS: salsa20 PASS: sha1 PASS: sha224 PASS: sha256 PASS: sha384 PASS: sha512 PASS: sha3-permute PASS: sha3-224 PASS: sha3-256 PASS: sha3-384 PASS: sha3-512 PASS: serpent PASS: twofish PASS: knuth-lfib PASS: cbc PASS: ctr PASS: gcm PASS: hmac PASS: umac PASS: meta-hash PASS: meta-cipher PASS: meta-armor PASS: buffer PASS: yarrow PASS: pbkdf2 PASS: sexp PASS: sexp-format PASS: rsa2sexp PASS: sexp2rsa PASS: bignum PASS: random-prime PASS: pkcs1 PASS: rsa PASS: rsa-encrypt PASS: rsa-keygen PASS: dsa PASS: dsa-keygen ./ecc-mod-test: symbol lookup error: ../.lib/libhogweed.so.2: undefined symbol: __gmpz_limbs_read FAIL: ecc-mod ./ecc-modinv-test: symbol lookup error: ../.lib/libhogweed.so.2: undefined symbol: __gmpz_limbs_read FAIL: ecc-modinv ./ecc-redc-test: symbol lookup error: ../.lib/libhogweed.so.2: undefined symbol: __gmpz_limbs_read FAIL: ecc-redc ./ecc-mul-g-test: symbol lookup error: ../.lib/libhogweed.so.2: undefined symbol: __gmpn_cnd_add_n FAIL: ecc-mul-g ./ecc-mul-a-test: symbol lookup error: ../.lib/libhogweed.so.2: undefined symbol: __gmpn_cnd_add_n FAIL: ecc-mul-a ./ecdsa-sign-test: symbol lookup error: ../.lib/libhogweed.so.2: undefined symbol: __gmpz_limbs_modify FAIL: ecdsa-sign ./ecdsa-verify-test: symbol lookup error: ../.lib/libhogweed.so.2: undefined symbol: __gmpz_limbs_read FAIL: ecdsa-verify ./ecdsa-keygen-test: symbol lookup error: ../.lib/libhogweed.so.2: undefined symbol: __gmpn_cnd_add_n FAIL: ecdsa-keygen PASS: cxx PASS: sexp-conv PASS: pkcs1-conv PASS: symbols ==================== 8 of 67 tests failed ==================== make[1]: *** [check] Errore 1 make[1]: uscita dalla directory "/home/zaamus/Dependencies/nettle-2.7.1/testsuite" make: *** [check] Errore 2 I have libgcrypt1.6.2, libgpg-error1.17, m4 macro processor and gmp6.0.0 installed. Library lgmp is correctly found when I compile some random c source. Can you help me? Do you need other information? Thanks, Vittorio -- Vittorio Francesco Braga PhD student in Tor Vergata University of Rome Mobile: +393203753307, Office (PhD room): +390672594868

2 10

chacha-poly1305
by Nikos Mavrogiannopoulos 31 Oct '14

31 Oct '14

Hello, I was checking what is required for the chacha-poly1305 implementation to be kept up to date with the current draft [0], on Last-Call. My understanding is that the current implementation: 1. Is missing support for 96-bit nonce Chacha (could be solved by adding a chacha_set_nonce96 function) 2. Misses the optimization which you proposed to CFRG (and was incorporated). It seems however, that if nettle is changed for the latter (i.e., to pad AAD), then using chacha_poly1305_update() becomes tricky. It could only be called once. Would in that case make sense to rename it to chacha_poly1305_set_aad() rather than update? regards, Nikos [0]. https://tools.ietf.org/html/draft-irtf-cfrg-chacha20-poly1305-02

3 8

Side-channel silence
by nisse＠lysator.liu.se 29 Oct '14

29 Oct '14

I've written a simple program to setup valgrind to check for bad uses of secret data. Maybe you have heard of Adam Langley's ctgrind (https://github.com/agl/ctgrind), but it seems to work fine to use plain valgrind and mark the secret data with VALGRIND_MAKE_MEM_UNDEFINED. Non-silent algorithms include aes, camellia, cast128, twofish, arctwo, des, blowfish, gcm (the hashing), arcfour. Almost anything using sboxes. Silent algorithms include serpent (sboxes, but with nice bit-slicing instead of tables), salsa20, chacha, poly1305. Not sure if and how this testing could be added to a plain make check EMULATOR='$(VALGRIND)' As for AES, an implementations using the aesni instructions ought to be side-channel silent. And if one is concerned about side channel attacks on AES, but too conservative to jump to salsa20 or chacha, serpent might be a good alternative. (I'll be doing a short talk on side-channel attacks on Southpole's 15 year anniversary party on November 7, so that's why I'm looking into this now). Regards, /Niels -----8<--- /* cipher-sidechannel-test.c Copyright (C) 2014 Niels MÃ¶ller This file is part of GNU Nettle. GNU Nettle is free software: you can redistribute it and/or modify it under the terms of either: * the GNU Lesser General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. or * the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. or both in parallel, as here. GNU Nettle 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 General Public License for more details. You should have received copies of the GNU General Public License and the GNU Lesser General Public License along with this program. If not, see http://www.gnu.org/licenses/. */ #include "testutils.h" #include "nettle-internal.h" #if !HAVE_VALGRIND_MEMCHECK_H void testmain (void) { SKIP (); } #else /* HAVE_VALGRIND_MEMCHECK_H */ #include <valgrind/memcheck.h> static uint8_t * xalloc_secret (size_t size) { uint8_t *p = xalloc (size); memset (p, 0, size); VALGRIND_MAKE_MEM_UNDEFINED (p, size); return p; } static void test_sc_cipher (const struct nettle_cipher *cipher) { void *ctx; uint8_t *key; uint8_t *src; uint8_t *dst; ctx = xalloc (cipher->context_size); key = xalloc_secret (cipher->key_size); src = xalloc_secret (cipher->block_size); dst = xalloc (cipher->block_size); cipher->set_encrypt_key (ctx, key); cipher->encrypt (ctx, cipher->block_size, dst, src); free (ctx); free (key); free (src); free (dst); } #define DATA_SIZE 32 static void test_sc_aead (const struct nettle_aead *aead) { void *ctx; uint8_t *key; uint8_t *nonce; uint8_t *src; uint8_t *data; uint8_t *dst; uint8_t *digest; ctx = xalloc (aead->context_size); key = xalloc_secret (aead->key_size); nonce = xalloc_secret (aead->nonce_size); src = xalloc_secret (aead->block_size); data = xalloc_secret (DATA_SIZE); dst = xalloc (aead->block_size); digest = xalloc (aead->digest_size); aead->set_encrypt_key (ctx, key); if (aead->set_nonce) aead->set_nonce (ctx, nonce); if (aead->update) aead->update (ctx, DATA_SIZE, data); aead->encrypt (ctx, aead->block_size, dst, src); if (aead->update) aead->digest (ctx, aead->digest_size, digest); free (ctx); free (key); free (nonce); free (src); free (data); free (dst); free (digest); } static const struct nettle_cipher * other_ciphers[] = { &nettle_des, &nettle_des3, &nettle_blowfish128, NULL, }; static const struct nettle_aead * other_aeads[] = { &nettle_arcfour128, &nettle_chacha, &nettle_salsa20, &nettle_salsa20r12, NULL, }; void test_main (void) { unsigned i; const struct nettle_cipher *cipher; const struct nettle_aead *aead; for (i = 0; ((cipher = nettle_ciphers[i])); i++) test_sc_cipher (cipher); for (i = 0; ((cipher = other_ciphers[i])); i++) test_sc_cipher (cipher); for (i = 0; ((aead = nettle_aeads[i])); i++) test_sc_aead (aead); for (i = 0; ((aead = other_aeads[i])); i++) test_sc_aead (aead); } #endif /* HAVE_VALGRIND_MEMCHECK_H */ -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

Fat binaries
by nisse＠lysator.liu.se 22 Oct '14

22 Oct '14

I think I will leave the curve25519 and eddsa code for now, even though there are several important optimizations left to do (see the just updated http://www.lysator.liu.se/~nisse/nettle/plan.html). I think it's getting time to do fat binaries. To make progress, I think it's best to start with something simple, relying on __attribute__((constructor) and/or __attribute__(ifunc ...)). For the case of memxor (where on x86_64, the fat binary mechanism needs to select between sse2 and non-sse2 code), I'm also considering some reorganization: * Use smaller assembly routines doing one case each, and let the main entry point always be C code which can sort out the different cases and handle bytes at the beginning and end of the buffer. * Fix the cases where the current current code reads a few bytes outside of input buffers (but luckily without crossing word boundaries, iirc). * Add some internal entry points, for cases where alignment is known by the caller. I think some additional overhead is acceptable for the cases of small badly aligned buffers, if one can gain cleaner or more efficient handling of the other cases. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 1

curve25519 progress
by nisse＠lysator.liu.se 22 Oct '14

22 Oct '14

I've now pushed some crude code (on the curve25519 branch) which agrees with the test vectors in draft-josefsson-tls-curve25519-05. It uses the equivalent Edwards curve for the internal operations. For scalar multiplication of the fix generator, it uses Pippenger's algorithm and tables very similar to the other curves, just with different point operations and no special caes (since the Edwards operations are "complete"). At the end, the x-coordinate of the corresponding point on the Montgomery-form curve25519 is computed. For scalar multiplication of an arbitrary point (with only x coordinate provided), I first have to compute the y-coordinate using Shanks-Tonelli (this could be used to implement "point compression") also for other curves). Then transform to a point on the Edwards curve, using homogeneneous/projective coordinates. Then the actual scalar multiply is currently done with the binary algorithm; I have code for window-based scalar multiply, but it needs a bit more debugging. All this is very similar to the other corves, but without special cases. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

4 18

ecc_curve and ecc_modulo
by nisse＠lysator.liu.se 24 Sep '14

24 Sep '14

I just pushed some reorganization of the ecc code. It introduces an internal struct ecc_modulo, which keeps the data and function pointers needed for modulo p (or modulo q) arithmetic. Immediate benefit was that a couple of wrapper functions could be deleted. E.g, ecc_generic_modp and ecc_generic_modq both called ecc_mod, but with different constants taken from different fields of struct ecc_curve). Now, one can instead call ecc_mod (&ecc->p, ...) and ecc_mod(&ecc->q, ...), respectively. I also added an invert function pointer, and wrote a specialized modp invert function for curve25519, which gives a nice little speedup. The code can be shared with sqrt, since the main part of the addition chain is the same for p-2 = 2^{255} - 21 (for invert) and (p-5)/8 = 2^{252} - 3 (for sqrt). Similar functions for the secp curves also make sense, at least for the mod p inversion; modq is less structured. The plan is to expand struct ecc_modulo with add, mul and sqr function pointers, to make it possible to have a different internal representation. In particular, using radix-51 for curve25519 modp arithmetic, on 64-bit machines. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

Hashing with EdDSA
by nisse＠lysator.liu.se 09 Sep '14

09 Sep '14

I'm looking into EdDSA. According to the paper, signing of a message M, using private key (a, k), corresponding to public key A, is essentially r = H(k | M), with k the second half of the private key R = rB, with B the specified generator of the curve, S = ((r + H(R | A | M) a) mod l, l is the curve order with some rules to encode R, A, S as strings. H is typically sha-512. If M is the original, arbitrarily long, message to be signed, this breaks the common structure that you can first compute a message digest, and then apply the secret key to produce a signature. But this doesn't work above, because the complete message has to be hashed twice, first with the secret prefix k, next with the prefix R | A, and any hashing without the private key available is useless. And even worse, one has to buffer the complete message because the prefix of the second hash depends on the output of the first hash. Or should M itself be a digest of the message to be signed? That will enable a more main-stream signature interface, where the inputs to the signature function are the private key and the short message digest. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 4

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