nettle-bugs February 2014

nettle-bugs@lists.lysator.liu.se

7 participants
8 discussions

[PATCH 1/5] Don't include OPT_ASM_SOURCES twice in hogweed_PURE_OBJS
by Martin Storsjö 25 Aug '14

25 Aug '14

OPT_ASM_SOURCES is already included via hogweed_OBJS. This avoids build errors about duplicate symbols in the shared library. --- Makefile.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.in b/Makefile.in index 1ec807b..2db76c5 100644 --- a/Makefile.in +++ b/Makefile.in @@ -180,7 +180,7 @@ nettle_OBJS = $(nettle_SOURCES:.c=.$(OBJEXT)) $(LIBOBJS) nettle_PURE_OBJS = $(nettle_OBJS:.$(OBJEXT)=.p$(OBJEXT)) hogweed_OBJS = $(hogweed_SOURCES:.c=.$(OBJEXT)) $(OPT_ASM_SOURCES:.asm=.$(OBJEXT)) -hogweed_PURE_OBJS = $(hogweed_OBJS:.$(OBJEXT)=.p$(OBJEXT)) $(OPT_ASM_SOURCES:.asm=.p$(OBJEXT)) +hogweed_PURE_OBJS = $(hogweed_OBJS:.$(OBJEXT)=.p$(OBJEXT)) libnettle.a: $(nettle_OBJS) -rm -f $@ -- 1.7.9.4

5 29

dsa_generate_keypair
by Nikos Mavrogiannopoulos 29 Mar '14

29 Mar '14

Hello, I tried to switch gnutls to use dsa_generate_keypair() to generate primes for the DH key exchange, but unfortunately this interface has the strict DSS checks for q_bits. Would it be possible to have a dh_generate_keypair() that does the exact same thing without the q_bits and p_bits limitations? regards, Nikos

4 21

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

05 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 17 Feb '14

17 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 11 Feb '14

11 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

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