nettle-bugs

nettle-bugs@lists.lysator.liu.se

2219 discussions

Abstractinos for stream ciphers and authenticated encryption
by nisse＠lysator.liu.se 16 Feb '14

16 Feb '14

Maybe it's time to specify some nettle-meta.h types for stream ciphers and algorithms for authenticated encryption. Currently we have nettle_hash, which I don't think needs any changes, and nettle_cipher, where I'm considering the following changes: 1. Drop the length argument from nettle_set_key_func. 2. Make the context argument of nettle_crypt_func const. 3. Previous point implies that we can no longer have struct nettle_cipher nettle_arcfour128. nettle_cipher will then be limited to block ciphers only. Then there are some minor variations. Maybe nettle_crypt_func should be left unmodified, and we should have a new type, say nettle_cipher_func, for block ciphers with a const context. What should the right abstraction look like for stream ciphers? Currently, arcfour, salsa20, and (soon) chacha. Consider struct nettle_stream_cipher { const char *name; unsigned context_size; unsigned key_size; unsigned nonce_size; nettle_set_key_func *set_key; nettle_set_key_func *set_nonce; nettle_crypt_func *crypt; }; Here, nettle_crypt_func should be the current definition without const. This assumes encryption and decryption are identical, which is the case for out current stream cipher list (and anything else xoring a stream to the plaintext). For arcfour, set_nonce would be NULL. Not sure how useful that really is to applications, ciphers with a nonce might not be used interchangably with a cipher that has no nonce. So lacking features in that definition are * Support for stream ciphers with different processing for encryption and decryption. * Support for the random-access possibilities in salsa20 and chacha. * Support for algorithms with arbitrary nonce size. Also, internal block size is not visible. To use salsa20 with this interface, one would need a one-block buffer, and new logic to handle partial blocks. For applications of stream ciphers, as well as ctr mode, is it important to be able to process a message byte by byte? Or is it sufficient to do like the current ctr and salsa20 code, to require that if a message is processed using several calls to the crypt function, all but the last must be an integral number of blocks? If we keep that requirement, we'd have to add a block_size field to struct nettle_stream_cipher. Next, AEAD (authenticated encryption with associated data). Currently implemented algorithms are GCM and EAX. For internal use, nettle-internal.h currently defines /* Tentative interface for "authenticated encryption with associated data" algorithms. Should be moved to nettle-meta.h when stable. */ struct nettle_aead { const char *name; size_t context_size; /* Block size of the input, and the size of the output digest */ size_t block_size; /* Suggested key size; other sizes are sometimes possible. */ size_t key_size; nettle_set_key_func *set_key; nettle_set_key_func *set_iv; nettle_hash_update_func *update; nettle_crypt_func *encrypt; nettle_crypt_func *decrypt; nettle_hash_digest_func *digest; }; Like for stream ciphers, nettle_crypt_func is the variant without const; the context *is* modified as the message is processed. Limitations: * Assumes identical key setup for encrypt and decrypt, which is true for GCM and AEX (both based on CTR mode for the encryption). Do we need separate set_encrypt_key and set_decrypt_key functions? * Assumes block size and digest size are identical. They might not be. * set_iv should be renamed to set_nonce. Can the nonce be restricted to fixed size here? Both gcm and eax are specified for arbitrary nonce size. We may need two nettle_set_* function typedefs, one without length argument (used for set_key in all these abstractions), and one with a length argument, used for arbitrary size nonces, as well as any interfaces supporting variable key size. One might use the same abstraction for constructions with no associated data (say, aes128-ctr-hmac-sha256) by setting update to NULL, or for schemes with no authentication at all, like aes 128-ctr, by also setting digest to NULL. Or for methods to provide authentication but no encryption, like hmac-sha256 or poly1305. But I doubt that's very useful. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

4 16

[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 07 Feb '14

07 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 03 Feb '14

03 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 31 Jan '14

31 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

Jump to page:

2026

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