nettle-bugs September 2025

nettle-bugs@lists.lysator.liu.se

5 participants
4 discussions

Reasonable size of stack allocation?
by Niels Möller 27 Sep '25

27 Sep '25

Ideally, Nettle shouldn't allocate any storage. Some functions need temporary scratch space, then options are: 1. Allocate it on the stack. 2. Allocate it on the heap (done only for bigum-related functions, using the allocation functions that are configurable via gmp's mp_set_memory_functions). 3, Take a scratch input parameter. The convention is that there's a corresponding _itch function or macro that callers can use to determine the needed amount of scratch. One example I have in mind is the ecc signature functions. Internal functions use the itch/scratch interface. Top-level functions allocate the needed scratch on the heap. E.g., I think ed25519_sha512_sign needs 416 bytes of scratch space and ed25519_sha512_verify needs 2112 bytes. Is it reasonable to allocate this on the stack? Or should we extend itch/scratch to the public functions? Allocation would matter the most when writing code for a very constrained device where it's desirable to allocate needed storage statically, or where malloc/free simply isn't available. Stack size might also matter for highly threaded applications where per-thread stack could be quite small. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

1 0

base64_decode_update and base16_decode_update
by Niels Möller 27 Sep '25

27 Sep '25

The documentation of base64_decode_update says @var{dst} should point to an area of size at least BASE64_DECODE_LENGTH(@var{src_length}). The amount of data generated is returned in *@var{dst_length}. (and similarly for base16_decode_update). This is rather inconvenient when decoding a base64 blob which is expected to be of a fix size. E.g., base64 encoding of 32 octets is 44 characters (including padding), but BASE64_DECODE_LENGTH(44) is 33, so to decode using a single call to base16_decode_update according to the docs, one would need to allocate an extra byte. And more than one extra if input may contain white space in addition to the 44 base64 characters. Suggestion: Make dst_length an input parameter as well (similar to, e.g., the rsa_decrypt functions). If decoding would produce more bytes than there is space for, decoding fails. This way, if you expect a fix size or a fix maximum size, you need only allocate that and pass to base64_decode_update. And if you allocate according to BASE64_DECODE_LENGTH, then decoding will never fail due to missing output space. If we do this for nettle-4, then old code needs to be adjusted, not just recompiled. Unadjusted code will suffer random failures (from passing an uninitialized dst_length), but if it follows the docs on allocation of the dst area, there won't be any dangerous memory overwrites. Alternatively, one could introduce a new name for the new behavior. Opinions? Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

1 1

SLH-DSA status
by Niels Möller 27 Sep '25

27 Sep '25

Hi, I've now added support for slh-dsa-sha2-128s and slh-dsa-sha2-128f. Internal parameterization is done via two structs, one representing the parameters for s vs f, and one struct representing the underlying hash operations. I've also added docs, and I've made some other updates to the manual, reworking the public key intro. Review is appreciated. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

1 0

Nettle CI status
by Niels Möller 18 Sep '25

18 Sep '25

Hi, the Nettle CI has been running at the mirror repository https://gitlab.com/gnutls/nettle for several years. However, the automatic mirroring stopped working during summer, related to bureaucracy for gitlab's "open source" program. This makes this mirror and CI a lot less useful, and it might be removed at some point. Instead, CI has now been set up to run directly on git.lysator.liu.se. There's currently one runner serving the nettle project, managed by Simon, thanks! For now, I have disabled the remote/s390x job, since I've not been able to mark it as conditional depending account variables, and I haven't yet setup new keys (since I want to retire the key used at gitlab.com). If anyone here is more familiar with .gitlab-ci.yml, help is appreciated. I tried using rules: - if: $SSH_PRIVATE_KEY != "" && $S390X_ACCOUNT != "" but the job is started (and then fails) even though those variables are unset. The gnutls job is also disabled for now, let me know when there's a branch in the gnutls repo that aims to be compatible with nettle-4, and I'll reenable this job. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

5 8

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 September 2025