nettle-bugs July 2016

nettle-bugs@lists.lysator.liu.se

5 participants
4 discussions

plan for 3.3
by Nikos Mavrogiannopoulos 06 Sep '16

06 Sep '16

Hi, Some comments on the 3.3, plan: > + Add larger "safe" curves, e.g., M-383, curve41417, curve448 and > + E-521. I think curve448 should be prioritized over anything else since it seems to be the only thing being standardized at the moment by CFRG: https://tools.ietf.org/html/rfc7748 For password hashing (pbkdf2), it may also worth considering to add support for argon2,which seems to be the only password hashing algorithm coming out of a competition: https://password-hashing.net/ > Side-channel silent mem_equalp. Do you mean a function with run time independent of its input values? I have such a function at gnutls: https://gitlab.com/gnutls/gnutls/blob/master/lib/safe-memfuncs.c#L70 regards, Nikos

2 3

char vs uint8_t
by nisse＠lysator.liu.se 03 Sep '16

03 Sep '16

I'd like to eliminate pointer-signedness warnings. I'm afraid some ugly casts will have to be involved, since most functions work with uint8_t, and at least test code needs to pass literal strings, of type char *. I have one question, on the ascii-armor funtions: Would ie make sense to change the type of ascii inputs and outputs to char? I.e., size_t base64_encode_update(struct base64_encode_ctx *ctx, - uint8_t *dst, + char *dst, size_t length, const uint8_t *src); and similarly for all related functions. It would be an API change but not an ABI change for any ABI spec I'm aware of. What do you think? So the input to encoding is an octet string (uint8_t), and the output is a string of plain char. And vice versa for decoding functions. Also applies to the type arguments for sexp_iterator_check_type, sexp_iterator_check_types and sexp_iterator_assoc, currently using uint8_t. They are usually called with literal ascii strings, so it would make some sense to type as char rather than uint8_t. (I don't think these are used much by any application except lsh and libspki). And no matter how things are typed, I wouldn't expect nettle to work out of the box on platforms where char and uint8_t are of different size, or where string literals use a non-asciii character set. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

3 3

Using mpz_powm_sec
by nisse＠lysator.liu.se 08 Aug '16

08 Aug '16

I'm considering the below patch, making use of the side-channel silent mpz_powm_sec function. The idea is to make the RSA and DSA code less vulnerable to side-channel attacks. Exponentiation routines typically build a small table of powers at run time, and then look up exponent bits in the table, a few bits at the time. This table lookup may leak information about the exponent bits (which in the case of RSA and DSA are secret) to an attacker running other processes on the same physical machine. mpz_powm_sec uses a slower table-lookup function, which for each lookup does a sequential read of the entire table. Some caveats: * The CRT code used for RSA signing uses other functions which may leak, in particular division functions with branches depending on secret data. * Since we still use the mpz interface rather than the mpn interface in gmp, the exponents use a normalized size field (so top limb is non-zero). This might still leak information about the top exponent bits. * The patch drops support for GMP versions older than GMP-5.0, relased in 2010. * Mini-gmp builds don't try to be side-channel silent, they will use a #define mpz_powm_sec mpz_powm. * I haven't yet had time to do proper benchmarks. Signing should get a bit slower, but I don't know how much. Despite not plugging *all* potential leaks in the RSA code, I think the simple change to use use mpz_powm_sec should make attacks using the cache side-channel considerably more difficult. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

5 27

gitlab merge requests
by Nikos Mavrogiannopoulos 07 Jul '16

07 Jul '16

Hi, The gitlab pages on git.lysator.liu.se seem like they are not actively being followed. Although pull and merge requests are the norm for some, if they are not followed, it may make more sense to turn off from the admin interface the merge request option (btw. also the builds option because it tries to build although no runners are configured). Some merge requests in gitlab which look reasonable: https://git.lysator.liu.se/nettle/nettle/merge_requests/1 https://git.lysator.liu.se/nettle/nettle/merge_requests/4 (btw. I have an automatically updated mirror of nettle at https://github.com/gnutls/nettle ) Not sure about the usefulness of: https://git.lysator.liu.se/nettle/nettle/merge_requests/2 https://git.lysator.liu.se/nettle/nettle/merge_requests/3 (this seems identical to 4) regards, Nikos

1 0

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