nettle-bugs

nettle-bugs@lists.lysator.liu.se

2198 discussions

[PATCH] Integration of chacha in Makefile.in
by Joachim Strömbergson 10 Feb '14

10 Feb '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aloha! Here is the patch to add build chacha in Nettle. - -- 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/ iEYEARECAAYFAlLJmgcACgkQZoPr8HT30QHYdgCg6PSU2fNILvFIwqKhMpBUBm7w ymwAn2WKB6xlAeCLTp0hZjQk8OUmsauv =1UMx -----END PGP SIGNATURE-----

5 22

Dropping length argument from nettle_set_key_func
by nisse＠lysator.liu.se 06 Feb '14

06 Feb '14

I've done this change. I didn't dare push it to the master branch just yet, so it's on a new branch "set_key-changes". The more interesting pieces of the ChangeLog below. Anyone who'd like to comment (or test) before I merge it to the master branch? One maybe questionable renaming was that for cast128. I'm not sure if anyone is using cast5/cast128 with keys smaller than 128 bits. But I'd expect it to be uncommon, and then it makes sense to me to use "cast128" for the variant with 128 bit keys. I now let "cast128_set_key" take a key of fixed size 128 bits (16 bytes), and then I named the variable key size function "cast5_set_key". It just seemed a bit too awkward to name the fix-sized function cast128_128_set_key. If we ever add a specific set_key function for, e.g., 80-bit cast5/cast128, I think that could be named "cast5_80_set_key". Regards, /Niels 2014-01-29 Niels Möller <nisse(a)lysator.liu.se> * nettle-types.h (typedef nettle_set_key_func): Deleted length argument. * arctwo.c (arctwo40_set_key, arctwo64_set_key) (arctwo128_set_key, arctwo128_set_key_gutmann): New functions. * arctwo.h: Declare them. * arctwo-meta.c (ARCTWO): New macro. (nettle_arctwo40, nettle_arctwo64, nettle_arctwo128) (nettle_arctwo_gutmann128): Use new _set_key functions. * arcfour.h (ARCFOUR128_KEY_SIZE): New constant. * arcfour.c (arcfour128_set_key): New function. * arcfour-meta.c (nettle_arcfour128): Use arcfour128_set_key and ARCFOUR128_KEY_SIZE. * cast128.c (cast5_set_key): Renamed, was cast128_set_key. (cast128_set_key): New definition, with fixed key size. * cast128.h (CAST128_MIN_KEY_SIZE, CAST128_MAX_KEY_SIZE): Renamed constants, to... (CAST5_MIN_KEY_SIZE, CAST5_MAX_KEY_SIZE): ... new names. * eax.h (EAX_SET_KEY): Deleted length argument. * aes128-meta.c: Deleted _set_key wrappers. * aes192-meta.c: Likewise. * aes256-meta.c: Likewise. * camellia128-meta.c: Likewise. * camellia192-meta.c: Likewise. * camellia256-meta.c: Likewise. * gcm-aes128.c (gcm_aes128_set_key): Deleted length argument. * gcm-aes192.c (gcm_aes192_set_key): Likewise. * gcm-aes256.c (gcm_aes256_set_key): Likewise. * gcm.h: Updated prototypes. * serpent-set-key.c (serpent128_set_key, serpent192_set_key) (serpent256_set_key): New functions. * serpent.h: Declare new functions. (SERPENT128_KEY_SIZE, SERPENT192_KEY_SIZE) (SERPENT256_KEY_SIZE): New constants. * serpent-meta.c (SERPENT): New macro. (nettle_serpent128, nettle_serpent192, nettle_serpent256): Use new _set_key functions. * twofish-set-key.c (twofish128_set_key, twofish192_set_key) (twofish256_set_key): New functions. * twofish.h: Declare new functions. (TWOFISH128_KEY_SIZE, TWOFISH192_KEY_SIZE) (TWOFISH256_KEY_SIZE): New constants. * twofish-meta.c (TWOFISH): New macro. (nettle_twofish128, nettle_twofish192, nettle_twofish256): Use new _set_key functions. -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 1

brainpool curves
by Nikos Mavrogiannopoulos 02 Feb '14

02 Feb '14

Hello, There has been lately an attempt to avoid the NIST's curves due to suspicions about their generation. One of them are the brainpool curves at: http://tools.ietf.org/html/rfc5639 which seem to be sponsored by the German BSI. Having them in nettle would be a good thing (the same authors are working on standardizing these curves in TLS and PKIX). regards, Nikos

5 7

Deterministic DSA and ECDSA signatures
by nisse＠lysator.liu.se 30 Jan '14

30 Jan '14

I just became aware of RFC 6979 "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)" (Informational). I think determinstic signatures are a good thing, and using the secret key also as a HMAC key to generate the random input is a natural idea. But then one could arrange the details in many different ways. Is the method in RFC 6979 a good way? After a quick reading, the steps c. and d. (Sec. 3.2) seems questionable; HMAC with a known constant key just seems more complicated than a simple hashing operation, and no more secure. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 1

arctwo
by nisse＠lysator.liu.se 30 Jan '14

30 Jan '14

Currently, arctwo-meta.c defines nettle_cipher structs for three key sizes, nettle_arctwo40 nettle_arctwo64 nettle_arctwo128 I'm thinking that 40 bit and 64 bit keys are way too small, and I hope they aren't mainstream, and then maybe the first two definitions can be deleted. (Keeping them for backwards compatibility is no big deal, but I'd prefer to only have reasonably secure ciphers on the nettle_ciphers list). The underlying arctwo_set_key function would still support all key sizes specified for arctwo, for applications which really need that. The arctwo code, including these definitions, was added back in 2004 (a decade ago!), and the header says /* This implementation was written by Nikos Mavroyanopoulos for GNUTLS * as a Libgcrypt module (gnutls/lib/x509/rc2.c) and later adapted for * direct use by Libgcrypt by Werner Koch and later adapted for direct * use by Nettle by Simon Josefsson and Niels Möller. * * The implementation here is based on Peter Gutmann's RRC.2 paper and * RFC 2268. */ Does anyone here know what applications or protocols use arctwo, and with which key sizes? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

4 5

chacha assembly
by nisse＠lysator.liu.se 30 Jan '14

30 Jan '14

I've now added some basic chacha x86_64 assembly. This gives a modest speedup over the code generated by gcc-4.7.2, about 8% in this machine. Apparently, gcc is pretty good at vectorizing this (and there seems to virtually no difference for salsa20). I have one question, regarding the different rotation counts in chacha, including 16 and 8. I think I've read that this is supposed to be advantageous on x86_64, but after reviewing the various pshuf* instructions, it's not clear how. I now do these as left shith + right shift + or. Maybe the rotate by 16 bits can be done with pshufhw + pshuflw. Or am I missing some other way to do a rotate on an %xmm register? Anyway, there are other ways to optimize chacha (and salsa20), by doing two blocks at a time (and I think we have enough registers for doing three chacha blocks at a time, if needed). For simplicity, I'm considering to write an assembly _chacha_crypt function which supports only an integral number of blocks, and then let chacha_crypt handle a final partial block using _chacha_core + memxor instead. (Half of the current x86_64/salsa20-crypt.asm is the logic to store the final partial block, for questionable benefit). So if this works out well for chacha, the same could be done for salsa20. Ah, and chacha seems to be about 15% faster than salsa20 Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 2

Status of Poly1305 and use of AES-NI in Poly1305, UMAC?
by Joachim Strömbergson 22 Jan '14

22 Jan '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aloha! What is the status of Poly1305 in Nettle, i.e. is the branch ready to be merged into master or when might that happen? I have to admit that I haven't studied how UMAC and Poly1305 uses (in what phase) the block cipher. Would they gain any substantial performance if they could use AES-NI when available? - -- 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/ iEYEARECAAYFAlKo3KQACgkQZoPr8HT30QH6gwCg5Ry4e20cHvqpd8MzuFNkzhC3 fisAn0olck6OFNqh6FHkvd9Kx/YKD7mn =Zn5G -----END PGP SIGNATURE-----

3 8

Release plans
by nisse＠lysator.liu.se 22 Jan '14

22 Jan '14

I have updated the release plans, at http://www.lysator.liu.se/~nisse/nettle/plan.html. I aim to get a release out within a month or two. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

3 26

Proper flags for linking .so files
by nisse＠lysator.liu.se 18 Jan '14

18 Jan '14

I got a problem report for Nettle on Solaris x86_64. Apparantly, crt1.o got included into libnettle.so, which makes no sense. One suggestion is to add -nostartfiles to the linker command, which could be done generally, not only for Solaris. Is that a good idea? Do non-gcc compilers recognise -nostartfiles? We currently pass -G on solaris, -dynamiclib on darwin/macos, and -shared everywhere else. I'd expect those flags to imply -nostartfiles, but I don't really know how that works. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

1 0

memxor3 could lead to invalid mem accesses
by Nikos Mavrogiannopoulos 16 Jan '14

16 Jan '14

Hello and best wishes for new year, I was debugging an invalid memory access in gnutls and realized that the issue is in memxor3 of nettle (2.7.x branch). I have not yet a fix for that, but the attached patch modifies the memxor-test.c to reproduce the issue. regards, Nikos $ valgrind ./memxor-test [...] ==26108== Invalid read of size 8 ==26108== at 0x4E817BD: memxor3 (memxor.s:137) ==26108== by 0x4029D8: test_main (memxor-test.c:157) ==26108== by 0x4024C6: main (testutils.c:204) ==26108== Address 0x5094498 is 104 bytes inside a block of size 111 alloc'd ==26108== at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==26108== by 0x402909: test_main (memxor-test.c:152) ==26108== by 0x4024C6: main (testutils.c:204) ==26108== ==26108==

3 9

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

nettle-bugs