nettle-bugs April 2026

nettle-bugs@lists.lysator.liu.se

5 participants
3 discussions

[PATCH] Annotate non-zero-terminated character arrays
by nettle＠gms.tf 18 Apr '26

18 Apr '26

From: Georg Sauthoff <mail(a)gms.tf> This fixes -Wunterminated-string-initialization warnings with gcc 15.2.1. --- aclocal.m4 | 7 +++++++ base16-encode.c | 2 +- base64-encode.c | 2 +- base64url-encode.c | 2 +- blowfish-bcrypt.c | 2 +- tools/pkcs1-conv.c | 6 +++--- 6 files changed, 14 insertions(+), 7 deletions(-) diff --git a/aclocal.m4 b/aclocal.m4 index 73bf0cfb..9f943b45 100644 --- a/aclocal.m4 +++ b/aclocal.m4 @@ -73,6 +73,13 @@ AH_BOTTOM( # define PRINTF_STYLE(f, a) # define UNUSED #endif +#ifdef __has_attribute +# if __has_attribute(nonstring) +# define NONSTRING __attribute__((__nonstring__)) +# else +# define NONSTRING +# endif +#endif ])]) # Check for alloca, and include the standard blurb in config.h diff --git a/base16-encode.c b/base16-encode.c index 9c7f0b1e..c6a4c6b9 100644 --- a/base16-encode.c +++ b/base16-encode.c @@ -39,7 +39,7 @@ static const uint8_t -hex_digits[16] = "0123456789abcdef"; +hex_digits[16] NONSTRING = "0123456789abcdef"; #define DIGIT(x) (hex_digits[(x) & 0xf]) diff --git a/base64-encode.c b/base64-encode.c index ee1ec149..6bb55782 100644 --- a/base64-encode.c +++ b/base64-encode.c @@ -83,7 +83,7 @@ encode_raw(const char *alphabet, assert(out == dst); } -static const char base64_encode_table[64] = +static const char base64_encode_table[64] NONSTRING = "ABCDEFGHIJKLMNOPQRSTUVWXYZ" "abcdefghijklmnopqrstuvwxyz" "0123456789+/"; diff --git a/base64url-encode.c b/base64url-encode.c index d30044ea..2b78a800 100644 --- a/base64url-encode.c +++ b/base64url-encode.c @@ -38,7 +38,7 @@ void base64url_encode_init(struct base64_encode_ctx *ctx) { - static const char base64url_encode_table[64] = + static const char base64url_encode_table[64] NONSTRING = "ABCDEFGHIJKLMNOPQRSTUVWXYZ" "abcdefghijklmnopqrstuvwxyz" "0123456789-_"; diff --git a/blowfish-bcrypt.c b/blowfish-bcrypt.c index 385503ac..0326f1ff 100644 --- a/blowfish-bcrypt.c +++ b/blowfish-bcrypt.c @@ -70,7 +70,7 @@ static const signed char radix64_decode_table[0x100] = { -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, }; -static const char radix64_encode_table[64] = +static const char radix64_encode_table[64] NONSTRING = "./ABCDEFGHIJKLMNOPQRSTUVWXYZ" "abcdefghijklmnopqrstuvwxyz" "0123456789"; diff --git a/tools/pkcs1-conv.c b/tools/pkcs1-conv.c index f6b044d2..68bb67d1 100644 --- a/tools/pkcs1-conv.c +++ b/tools/pkcs1-conv.c @@ -117,13 +117,13 @@ read_file(struct nettle_buffer *buffer, FILE *f) } static const uint8_t -pem_start_pattern[11] = "-----BEGIN "; +pem_start_pattern[11] NONSTRING = "-----BEGIN "; static const uint8_t -pem_end_pattern[9] = "-----END "; +pem_end_pattern[9] NONSTRING = "-----END "; static const uint8_t -pem_trailer_pattern[5] = "-----"; +pem_trailer_pattern[5] NONSTRING = "-----"; static const char pem_ws[33] = { -- 2.53.0

4 6

[PATCH] Synchronize func signatures between code and docs
by nettle＠gms.tf 12 Apr '26

12 Apr '26

From: Georg Sauthoff <mail(a)gms.tf> This mostly affects function signatures in the manual, i.e. to reflect prior code changes where e.g. uint8_t pointers were corrected to char pointers. NB, this change is limited to the base64/base16 functions, deviations in other translation units can be addressed with follow-up patches. --- base64.h | 5 +++-- nettle.texinfo | 18 +++++++++--------- 2 files changed, 12 insertions(+), 11 deletions(-) diff --git a/base64.h b/base64.h index 3a31699e..d1ca61ad 100644 --- a/base64.h +++ b/base64.h @@ -100,7 +100,8 @@ base64_encode_update(struct base64_encode_ctx *ctx, const uint8_t *src); /* DST should point to an area of size at least - * BASE64_ENCODE_FINAL_LENGTH */ + * BASE64_ENCODE_FINAL_LENGTH + * The return value is the number of output bytes generated. */ size_t base64_encode_final(struct base64_encode_ctx *ctx, char *dst); @@ -149,7 +150,7 @@ base64_decode_single(struct base64_decode_ctx *ctx, /* Returns 1 on success, 0 on error. DST should point to an area of * size *DST_LENGTH. Decoding returns failure it output would exceed - * this size. BASE64_DECODE_LENGTH(length) is always sufficient. + * this size. BASE64_DECODE_LENGTH(src_length) is always sufficient. * *DST_LENGTH is updated to reflect the amount of data actually * generated. */ int diff --git a/nettle.texinfo b/nettle.texinfo index 59a395da..50b14072 100644 --- a/nettle.texinfo +++ b/nettle.texinfo @@ -6333,7 +6333,7 @@ alphabet. @end deftypefun -@deftypefun {size_t} base64_encode_single (struct base64_encode_ctx *@var{ctx}, uint8_t *@var{dst}, uint8_t @var{src}) +@deftypefun {size_t} base64_encode_single (struct base64_encode_ctx *@var{ctx}, char *@var{dst}, uint8_t @var{src}) Encodes a single byte. Returns amount of output (always 1 or 2). @end deftypefun @@ -6342,7 +6342,7 @@ The maximum number of output bytes when passing @var{length} input bytes to @code{base64_encode_update}. @end deffn -@deftypefun {size_t} base64_encode_update (struct base64_encode_ctx *@var{ctx}, uint8_t *@var{dst}, size_t @var{length}, const uint8_t *@var{src}) +@deftypefun {size_t} base64_encode_update (struct base64_encode_ctx *@var{ctx}, char *@var{dst}, size_t @var{length}, const uint8_t *@var{src}) After @var{ctx} is initialized, this function may be called to encode @var{length} bytes from @var{src}. The result will be placed in @var{dst}, and the return value will be the number of bytes generated. Note that @var{dst} must be at least of size @@ -6353,7 +6353,7 @@ BASE64_ENCODE_LENGTH(@var{length}). The maximum amount of output from @code{base64_encode_final}. @end defvr -@deftypefun {size_t} base64_encode_final (struct base64_encode_ctx *@var{ctx}, uint8_t *@var{dst}) +@deftypefun {size_t} base64_encode_final (struct base64_encode_ctx *@var{ctx}, char *@var{dst}) After calling base64_encode_update one or more times, this function should be called to generate the final output bytes, including any needed paddding. The return value is the number of output bytes @@ -6371,7 +6371,7 @@ base64 alphabet, while @code{base64url_decode_init} selects the URL safe alphabet. @end deftypefun -@deftypefun {int} base64_decode_single (struct base64_decode_ctx *@var{ctx}, uint8_t *@var{dst}, uint8_t @var{src}) +@deftypefun {int} base64_decode_single (struct base64_decode_ctx *@var{ctx}, uint8_t *@var{dst}, char @var{src}) Decodes a single byte (@var{src}) and stores the result in @var{dst}. Returns amount of output (0 or 1), or -1 on errors. @end deftypefun @@ -6381,7 +6381,7 @@ The maximum number of output bytes when passing @var{length} input bytes to @code{base64_decode_update}. @end deffn -@deftypefun {void} base64_decode_update (struct base64_decode_ctx *@var{ctx}, size_t *@var{dst_length}, uint8_t *@var{dst}, size_t @var{src_length}, const uint8_t *@var{src}) +@deftypefun {int} base64_decode_update (struct base64_decode_ctx *@var{ctx}, size_t *@var{dst_length}, uint8_t *@var{dst}, size_t @var{src_length}, const char *@var{src}) After @var{ctx} is initialized, this function may be called to decode @var{src_length} bytes from @var{src}. The buffer pointed to by @var{dst} must be of size *@var{dst_length}, and the amount of data @@ -6400,7 +6400,7 @@ Similarly to the base64 functions, the following functions perform base16 encodi and are defined in @file{<nettle/base16.h>}. Note that there is no encoding context necessary for doing base16 encoding. -@deftypefun {void} base16_encode_single (uint8_t *@var{dst}, uint8_t @var{src}) +@deftypefun {void} base16_encode_single (char *@var{dst}, uint8_t @var{src}) Encodes a single byte. Always stores two digits in @var{dst}[0] and @var{dst}[1]. @end deftypefun @@ -6409,7 +6409,7 @@ The number of output bytes when passing @var{length} input bytes to @code{base16_encode_update}. @end deffn -@deftypefun {void} base16_encode_update (uint8_t *@var{dst}, size_t @var{length}, const uint8_t *@var{src}) +@deftypefun {void} base16_encode_update (char *@var{dst}, size_t @var{length}, const uint8_t *@var{src}) Always stores BASE16_ENCODE_LENGTH(@var{length}) digits in @var{dst}. @end deftypefun @@ -6421,7 +6421,7 @@ Initializes a base16 decoding context. This is necessary before starting a decod session. @end deftypefun -@deftypefun {int} base16_decode_single (struct base16_decode_ctx *@var{ctx}, uint8_t *@var{dst}, uint8_t @var{src}) +@deftypefun {int} base16_decode_single (struct base16_decode_ctx *@var{ctx}, uint8_t *@var{dst}, char @var{src}) Decodes a single byte from @var{src} into @var{dst}. Returns amount of output (0 or 1), or -1 on errors. @end deftypefun @@ -6430,7 +6430,7 @@ The maximum number of output bytes when passing @var{length} input bytes to @code{base16_decode_update}. @end deffn -@deftypefun {int} base16_decode_update (struct base16_decode_ctx *@var{ctx}, size_t *@var{dst_length}, uint8_t *@var{dst}, size_t @var{src_length}, const uint8_t *@var{src}) +@deftypefun {int} base16_decode_update (struct base16_decode_ctx *@var{ctx}, size_t *@var{dst_length}, uint8_t *@var{dst}, size_t @var{src_length}, const char *@var{src}) After @var{ctx} is initialized, this function may be called to decode @var{src_length} bytes from @var{src}. The buffer pointed to by @var{dst} must be of size *@var{dst_length}, and the amount of data -- 2.53.0

2 1

sntrup761
by Niels Möller 09 Apr '26

09 Apr '26

Hi, I'm having a new look at sntrup761, I have rebased the branch based on Simon's work, and pushed as branch "sntrup761" in the Nettle repository. And I've reread https://ntruprime.cr.yp.to/nist/ntruprime-20201007.pdf (is that still the main spec?). I've also added valgrind-based tests for side-channels. It appears key generation may have leaks (when I mark the output from the randomness generator as secret). Maybe this is just rejection of certain samples, which should not be a problem (for this sampling strategy, it's expected to leak the number of tries needed). Encapsulation appears to not have branches or memory accesses depending on the randomness input. Decapsulation appears to have no branches or memory accesses depending on the secret key, which is the most important property. I don't yet quite understand the implementation. Some issues: * Not entirely sure where the sorting comes from (I saw no mention of it in the spec). I imagine it's part of generating random values of the appropriate types. * The encode/decode step appear to follow the spec closely, but to me it's a bit weird to use the M arrays filled with constant values. * Coding style is a bit odd, e.g., with long long type for values that always appear to always be small constant, short lowercase names like "p" used for preprocessor constants. I think it should be doable to get into good shape. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

4 6

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