nettle-bugs

nettle-bugs@lists.lysator.liu.se

2 participants
2223 discussions

ML-KEM
by Niels Möller 25 Sep '26

25 Sep '26

Hi, I've now merge Daiki's ML-KEM implementation, see https://git.lysator.liu.se/nettle/nettle/-/merge_requests/67. I think there's some further changes I think I'd like to do before release: 1. Add more randomized tests, and add assert_maybe for some of the invariants, in particular for arithmetics. 2. Probably remove the ml_kem_params from the api, and instead use separate functions for ML-KEM 768 and ML-KEM 1024. 3. Add functions exposing structs for expanded keys. To avoid having to expand them over and over again if using the same key repeatedly. And for all-in-one functions, these structs could also be used as the types for needed scratch space, to make things a bit more type/alignment safe, and have a natural way to allocate needed storage without the _itch functions. Should then be done in a consistent way also for sntrup. (The reason sntrup api doesn't have any itch function is that its expanded keys are smaller, and it's more reasonable to just allocate them on the stack). 4. Micro optimize various internals. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

2 4

FYI: Montréal next week
by Niels Möller 23 Sep '26

23 Sep '26

I'll be traveling to Montréal over coming weekend and next week. Tuesday-Thursday I'll attend https://transparency.dev/summit2026/. I'll be offline much of the time, but if anyone is in the area and want to meet up, let me know. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

1 0

Canonicalization problems with gostdsa
by Niels Möller 06 Sep '26

06 Sep '26

Hi, I've received a bug report on gostdsa. When the digest is converted to an integer mod q, the spec says that if that happens to become 0, it should be replaced by 1 (and using 0 results in private key leakage). The current code checks for 0 without first reducing mod q, which is bad. I have a tentative fix on branch https://git.lysator.liu.se/nettle/nettle/-/tree/fix-gostdsa-zero. Then there's a related problem in handling of the "UKM" input for gostdsa_vko, if that happens to equal q or a multiple thereof. I suspect the UKM is usually rather small, which would help. E.g., if I could do something like ukm_max_length = (ecc->q.bit_size - 1) / 8; assert (ukm_length <= ukm_max_length); the number would surely be less than q, and current plain check for 0 would be fine. Is there a specified maximum size? I've looked at * RFC 4357, which seems to say the UKM is 64 bits * RFC 9189, which seems to say that the UKM is 128 bits (16 bytes). * GnuTLS (only user of this function I'm aware of). It's unobvious to me what size of the nonce/ukm is actually passed down to nettle, but at least I've found a #define VKO_GOST_UKM_LEN 8 which seems to indicate 64 bits. Anyone who's more familiar with how this is used in TLS or elsewhere? Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

2 3

A generalized interface for poly1305 independent of the used cipher
by Tim Kosse 13 Aug '26

13 Aug '26

Hi, I'm trying to implement chacha20-poly1305 as used by SSH (https://datatracker.ietf.org/doc/html/draft-ietf-sshm-chacha20-poly1305-04), which differs from RFC 8439's ChaCha-Poly1035 as implemented by Nettle. While Nettle internally has the necessary building blocks, it lacks a public API to directly use poly1305. I think this is fairly straightforward to add one though. Please see below for my initial attempt. If you think this is the right approach, I'd be happy to work on a proper patch including tests and documentation. #define POLY1305_KEY_SIZE 32 #define POLY1305_DIGEST_SIZE 16 struct poly1305_mac_ctx { struct poly1305_ctx pctx; union nettle_block16 s; uint8_t block[POLY1305_BLOCK_SIZE]; unsigned index; }; void poly1305_set_key(struct poly1305_mac_ctx* ctx, const uint8_t *key) { _nettle_poly1305_set_key(&ctx->pctx, key); memcpy(ctx->s.b, key + 16, 16); ctx->index = 0; } void poly1305_update(struct poly1305_mac_ctx* ctx, size_t length, const uint8_t *data) { ctx->index = _nettle_poly1305_update(&ctx->pctx, ctx->block, ctx->index, length, data); } /* After calling this function, context must be re-keyed before calling poly1305_update/poly1305_digest again. */ void poly1305_digest(struct poly1305_mac_ctx* ctx, uint8_t* digest) { if (ctx->index > 0) { ctx->block[ctx->index] = 1; memset (ctx->block + ctx->index + 1, 0, POLY1305_BLOCK_SIZE - 1 - ctx->index); _nettle_poly1305_block (&ctx->pctx, ctx->block, 0); } _nettle_poly1305_digest(&ctx->pctx, &ctx->s); memcpy(digest, ctx->s.b, POLY1305_DIGEST_SIZE); } Regards, Tim

3 3

Vulnerability Report
by Feng Li 13 Aug '26

13 Aug '26

Dear Nettle maintainers, We have identified a security issue in Nettle’s GCM implementation. An adversary can exploit this to recover the authentication subkey H and forge arbitrary messages with valid tags. We provide the detail below. Recall GCM: Given: Key K, Nonce IV, Plaintext P, Additional authenticated data A Step 1. Compute the subkey H: H = AES_K(0^128). Step 2. Compute the initial counter block J0: If len(IV) == 96 bits: J0 = IV||0^31||1 Else: s = 128 * ceil(len(IV)/128) - len(IV) J0 = GHASH_H(IV||0^(s+64)||[len(IV)]_64) where [len(IV)]_64 is the 64-bit big‑endian representation of the bit length of IV. Step 3. Generate the keystream: The counter blocks are inc_32(J0), inc_32(inc_32(J0)), ... where inc_32 increments the lowest 32 bits modulo 2^32. Each counter block is encrypted with AES under key K to produce the keystream blocks. The plaintext blocks are XORed with the keystream blocks to obtain ciphertext C. Step 4. Compute the authentication tag: S = GHASH_H( A||C||[len(A)]_64||[len(C)]_64 ), T = S XOR AES_K(J0). What happens when the nonce (IV) is empty (Corresponding to this part of the code https://github.com/gnutls/nettle/blob/master/gcm.c ). let len(IV) = 0 bits. Step 1. H = AES_K(0^128) Step 2. Compute J0: s = 128 * ceil(0/128) - 0 = 0 The input to GHASH is: IV||0^(s+64)||[len(IV)]_64 = (empty)||0^64||0^64 = 0^128. So J0 = GHASH_H(0^128) = 0^128. (The GHASH accumulator starts at zero, XOR with the zero block remains zero, then multiply by H gives zero. So GHASH_H(0^128) = 0^128.) Step 4. Authentication tag: The mask used to XOR the GHASH result is AES_K(J0) = AES_K(0^128). But by definition this is exactly H. Therefore: T = S XOR H (where S = GHASH_H(A||C||length block)). This equation contains only one unknown variable: H. All other values (A, C, lenblock, T) are known to an attacker. Now, GHASH_H is a polynomial function in H over GF(2^128). For m blocks of input (A, C, and the length block), the GHASH result can be expressed as: S = B1 * H^m XOR B2 * H^(m-1) XOR ... XOR Bm * H where the B_i are known from the input blocks. Therefore the tag equation becomes: B1 * H^m XOR B2 * H^(m-1) XOR ... XOR (Bm XOR 1) * H XOR T = 0. This is a polynomial equation of degree m in H over the finite field GF(2^128). Once the attacker recovers H, they have the authentication subkey. They can now compute valid GHASH for any chosen A' and C' and generate a valid tag for any forged message: T' = GHASH_H(A'||C'||lenblock) XOR H. We suggest following the NIST standard and prohibiting an empty IV. Sincerely, Feng Li and Yaobin Shen

3 6

Return value from SLH-DSA signing functions?
by Niels Möller 26 Jun '26

26 Jun '26

In a different thread, I wrote: > (Somewhat related: I just realized that the slh-dsa signing functions > hit an assertion failure if public and private keys don't match. I think > it may be useful with an alternative signing function with a > success/fail return value). This isn't good; having asserts triggered by invalid input is ok only when inputs are invalid in a way that is (1) documented and (2) easy to check for at the call site. What happens is that creating an SLH-DSA signature will more or less for free recompute the top-level Merkle tree root hash, which is one of the pieces of the public key. So it's easy to compare them. If the two values differ, then either the private or public key doesn't match, or there's a bug in nettle, or there's some miscomputation, possibly caused by some fault injection attack. At least for some applications, it makes sense to always verify that a computed signature is valid before passing it on. This is pretty important, e.g., if using RSA in a setting where fault injection attacks are relevant, and some of Nettle' too many RSA signing functions have a check for that. As far as I understand, SLH-DSA is not that vulnerable to fault injection, but it may still be good practice to check that a computed signature is valid, in particular if one gets it for free when signing. So the options I see: 1. Keep assert, let it be caller's responsibilty to make sure that the public and private keys passed to the signing function are consistent. 2. Just delete the assert. 3. Drop the assert, but instead introduce a success/fail return value. Applications that care can check that; if one believes fault injection and the like isn't a relevant threat to one's application or to SLH-DSA in general, it seems fine to ignore the return value. 4. Have two flavors of signing functions, one with the assert, one with the return value. Any opinions? I'm currently leaning towards (3). In principle, changing return type from void to int is an ABI change, but I'm not aware of any platform where it actually is an ABI breakage. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

3 7

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

17 May '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 11

sntrup761
by Niels Möller 08 May '26

08 May '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 7

[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

The public key input for ed25519 sign
by Niels Möller 23 Mar '26

23 Mar '26

Hi, I've received a bug report pointing out that misuse of the public key input to ed25519_sha512_sign (and ed448_shake256_sign) is dangerous: If you sign the same message twice using the same private key, but the public key inputs differ, that can be exploited to recover the private key from the two signatures, similar to a classic DSA nonce reuse. If we compare to how others are dealing with this, a similar issue was considered a bug in a Rust library (see https://rustsec.org/advisories/RUSTSEC-2022-0093.html). On the other end, we have the Golang standard library that represents an ed25519 private key as 64 bytes where the first half are the private key according to RFC 8032, and the second half are the private key. This is motivated by performance, see https://pkg.go.dev/crypto/ed25519. Some options: 1. Document clearer that the public key argument *must* be the value produced by ed25519_sha512_public_key (e.g., immediately before the signing operation, or computed at key generation time and stored securely bundled with the private key). Pro: Small change, flexible. Cons: Leaves the possibility for applications to shoot themselves in the feet in this way. 2. Make ed25519_sha512_sign check that the signature is valid, essentially, adding an assert (ed25519_sha512_verify (...)) before returning. Pro: Could catch a range of potential bugs and attacks. Cons: Much worse signing performance. Also, avoiding the particular attack reported now depends on the verify operation enforcing canonical representation of the public key. 3. Drop the public key input argument, recompute it for each signing operation. Pro: Simpler interface, closer to RFC 8032. Cons: Much worse signing performance (but probably not as bad as option (2)). And one would have to think about backwards compatibility. Note that both (2) and (3) can be implemented as simple wrappers around the current signing function, for applications that are prepared to accept the performance penalty. Opinions? I'm leaning towards (1). Regards, /Niels PS. The reason this is an issue at all is that the public key is hashed together with the message in step 4 of the signing operation (see RFC 8032 5.1.6), but not in step 2. I imagine including the public key was considered to bring some subtle advantage in security; but maybe this should have been weighted differently against the additional api complexity in making an additional public key input highly desirable for performance. -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

2 7

Jump to page:

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