nettle-bugs

nettle-bugs@lists.lysator.liu.se

2205 discussions

use gitlab's shared runners
by Nikos Mavrogiannopoulos 14 Sep '16

14 Sep '16

Hi, This patch converts nettle's CI to use gitlab's infrastructure. Red Hat's specific runners currently used for CI will be phased out, so it makes sense to switch to gitlab.com shared infrastructure. An other advantage is that more (Linux) systems can be checked due to the fact that this CI is based on docker. An example run can be seen at: https://gitlab.com/gnutls/nettle/pipelines/4146073 regards, Nikos

3 4

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

TLS 1.3 in gnutls
by Nikos Mavrogiannopoulos 05 Sep '16

05 Sep '16

Hi, I've tried to make a rough sketch of the requirements needed to support TLS 1.3 in gnutls. I've split the task in sub-tasks on [0]. Some need to be handled in gnutls and some need to be handled in nettle. Do you think I've missed something, or there are tasks that can be further split? About the nettle additions, is there anyone already working or willing to work on these? On the gnutls part is there anyone already working or willing to work on the missing parts? regards, Nikos [0]. https://gitlab.com/gnutls/gnutls/milestones/8

2 2

display code coverage
by Nikos Mavrogiannopoulos 05 Sep '16

05 Sep '16

Hi, The attached patch uses lcov to display the code coverage of the test suite. It uses ax_code_coverage.m4 which assumes automake, so this patch modifies it to be able to work. This is a preliminary patch to demo the functionality, as I haven't gone through all the automake- related variables. regards, Nikos

2 1

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

[patch] Nettle add missing cflags to some objects
by Tomas Chvatal 04 Aug '16

04 Aug '16

Hello, I noticed that some objects are compiled without cflags. See attached patch that fixes the situation. :) Cheers Tom

3 4

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

Porting openssl code to nettle
by Aaron Boxer 30 May '16

30 May '16

Hello! I am porting some openssl code to nettle. It involves working with SHA1 keys. What would people recommend as a guide to doing this port? I know very little about cryptography. The code can be found here: https://github.com/GrokImageCompression/asdcplib/blob/master/src/KM_prng.cpp Thanks so much, Aaron

2 10

Curve25519 and RFC 7748
by nisse＠lysator.liu.se 02 May '16

02 May '16

Hi, Nikos pointed out to me that there's a slight difference between curve25519 as implemented by Nettle and the spec in RFC 7748. As far as I see, the difference is that RFC 7748 says that bit 255 of an encoded x coordinates is ignored. Or more precisely, the high bit of the 31:st octet in the x input string is cleared before convertion into an integer. While nettle's curve25519_mul includes it in the computation, with the usual wrap-around, 2^255 = 19 (mod p). I don't see any difference in handling scalars. Do you agree? So I'm considering this change, diff --git a/curve25519-mul.c b/curve25519-mul.c index adb20cb..f5127d7 100644 --- a/curve25519-mul.c +++ b/curve25519-mul.c @@ -72,7 +72,11 @@ curve25519_mul (uint8_t *q, const uint8_t *n, const uint8_t *p) itch = ecc->p.size * 12; scratch = gmp_alloc_limbs (itch); + /* Note that 255 % GMP_NUMB_BITS == 0 isn't supported, so x1 always + holds at least 256 bits. */ mpn_set_base256_le (x1, ecc->p.size, p, CURVE25519_SIZE); + /* Clear bit 255, as required by RFC 7748. */ + x1[255/GMP_NUMB_BITS] &= ~((mp_limb_t) 1 << (255 % GMP_NUMB_BITS)); /* Initialize, x2 = x1, z2 = 1 */ mpn_copyi (x2, x1, ecc->p.size); I wouldn't expect any problems from this, its a corner case with input values which are arguably invalid. The motivation in the RFC, as I understand it, is to leave open for protocols to use the top bit for their own, without bothering to clear it before invoking curve25519. Which at first seems a bit silly, but there's some value in not leaving corner cases implementation defined, and it would maybe have been even more silly to require that implementations do wraparound of that improper high bit. This change would also need some updates of testcases and documentation. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.

2 3

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