nettle-bugs

nettle-bugs@lists.lysator.liu.se

2191 discussions

chacha set-key naming
by Stefan Bühler 04 Mar '14

04 Mar '14

Hi, I probably won't convince you anymore, so feel free to ignore this :) Anyway, I just wanted to say that #define CHACHA128_KEY_SIZE 16 #define CHACHA256_KEY_SIZE 32 [...] void chacha128_set_key(struct chacha_ctx *ctx, const uint8_t *key); void chacha256_set_key(struct chacha_ctx *ctx, const uint8_t *key); looks horribly wrong to me. There is no "Chacha128" nor "Chacha256"; given that the standard naming scheme interprets a number after "Chacha" as number of rounds... well, this is just wrong. Forcing the AES naming onto other stuff is just not a good idea imho. My preference, if you want to have a fixed length in the name, is still "chacha_set_key128" and similar. Not sure about "chacha_128_set_key", "chacha20_128_set_key", ... As a side note: the paper for Chacha only mentions the 256-bit key variant, although the reference implementation also provides the 128-bit variant... So I'm not sure whether the 128-bit variant was actually intended being used at all. regards, Stefan

4 6

chacha nonce size changed from 64 to 96 bits?
by nisse＠lysator.liu.se 16 Feb '14

16 Feb '14

I was pointed to https://tools.ietf.org/html/draft-nir-cfrg-chacha20-poly1305-01. This draft specifies chacha as using a 96-bit nonce and a 32-bit block counter. When asking about this discrepancy on the tls list, Adam Langley replied : On Fri, Feb 14, 2014 at 1:57 PM, Niels Möller <nisse(a)lysator.liu.se> wrote: : > [...] And a 32-bit counter (256 GB message size, if I manage to get : > the powers right) ought to be sufficient for almost all applications. : > But I'm afraid it might to slow adoption of chacha if there are : > multiple slightly incompatible specifications. : : I intend for the 64/64 bit version to be dead at this point. I think : everyone can agree on the 96/32 split. I wouldn't want there to be two : versions if it can be avoided. Apparently, IPSec wants 96 bits nonces, and this is also in line with rfc5116, which says that all AEAD algorithms SHOULD support 12-byte nonces. But this change is news to me. Do everyone really agree on the change of 96/32 in chacha? My interpretation is that this move is advocated by people are thinking of various packetized protocols, where 32-bit block counter clearly will be sufficient to encrypt each packet. And that's clearly the most important applications of chacha will be of that type. But maybe there are other applications where a limit of 256 GB for a single message to be encrypted with chacha could be a problem? There is some possibilty to let the two views of these input block coexist, but I'm afraid that will get a bit messy to support in Nettle (although I haven't yet thought very much about the details). Anyway, this makes me feel that support for chacha and chacha-poly1305 must be marked as experimental, until the specifications really settle. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

3 3

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

Jump to page:

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