nettle-bugs January 2026

nettle-bugs@lists.lysator.liu.se

3 participants
4 discussions

Nettle-4.0rc1
by Niels Möller 03 Feb '26

03 Feb '26

Hi, I've prepared a tarball for the first nettle-4.0 release candidate. See https://www.lysator.liu.se/~nisse/archive/nettle-4.0rc1.tar.gz, https://www.lysator.liu.se/~nisse/archive/nettle-4.0rc1.tar.gz.sig NEWS file at https://git.lysator.liu.se/nettle/nettle/-/blob/master/NEWS All testing and feedback appreciated. I plan to get the release out next weekend. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

2 4

reseeding drbg-ctr-aes256
by Daiki Ueno 01 Feb '26

01 Feb '26

Hello, I was trying to replace our own implementation of CTR_DRBG in GnuTLS[1] with the one provided by Nettle. It is, however, blocked as it is currently not possible to reseed an already initialized instance without re-initializing it, which is needed for FIPS 140-3 compliance. I would suggest either: - making drbg_ctr_aes256_output internally do reseeding based on the interval defined in SP800 90A - exposing drbg_ctr_aes256_update as a public function, so applications (e.g., GnuTLS) can implement the reseeding logic I've filed an MR for the latter[2]. Could you take a look? Footnotes: [1] https://gitlab.com/gnutls/gnutls/-/blob/master/lib/nettle/int/drbg-aes.c?re… [2] https://git.lysator.liu.se/nettle/nettle/-/merge_requests/69 Regards, -- Daiki Ueno

2 3

Nettle CI status
by Niels Möller 17 Jan '26

17 Jan '26

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 16

Length argument for ocb_digest and ccm_digest
by Niels Möller 14 Jan '26

14 Jan '26

I'm having a second look at dealing with the length argument to ocb_digest and ccm_digest, which I left as is when deleting all other digest size arguments a while ago. The alternative I see is to have the _set_nonce function store the intended digest size in the context, and use that at _digest time. That makes the digest functions a bit more consistent with the rest of nettle, and it also makes it harder to use inconsistent digest size to the two calls. One drawback is that the size becomes less obvious from the _digest call site. I'm trying this out in the branch https://git.lysator.liu.se/nettle/nettle/-/tree/delete-ocb-ccm-digest-size-… Some questions related to this: 1. For both functions, I would like to minimize the risk of large memory overwrites in the case of bugs, say the tag_length member has been clobbered by bugs elsewhere. Currently, I have an assert (ctx->tag_length <= 16); just prior to the call (memxor3 or ctr_crypt, respectively) that writes to digest. Which should be safe when asserts are enabled. A different option not depending on asserts would be an explicit clamping, say unsigned length = 1 + ((15 & (ctx->tag_length - 1))); Maybe that is overly defensive; after all, if there's random memory clobber bugs, one could just as well get random large lengths for the _encrypt or _decrypt calls. Regardless of the level of defensive programming, the intention is that if you don't know locally at the _digest call site which tag_length was used, it should always be correct to call _digest with an output buffer of size 16, and extract the tag of appropriate size later. 2. For CCM, I also put in some more checks on the tag_length, which according to RFC 3610 is limited to 4, 6, 8, 10, 12, 14, 16 (maybe 2 would also work technically). But then I had to delete one test, labeled "From IEEE 802.15.4-2011 ... C.2.2 MAC data frame", which uses tag_length 0. Are there relevant usecases for CCM with no authentication tag (which I think boils down to CTR mode with some special way to assign initial counter)? 3. For OCB, size of both plaintext and the auxilliary authenticated data is "unlimited", according to RFC 7253. Currently, Nettle uses a size_t to count number of blocks for each input, which will wrap around and produce out-of-spec output when size exceeds 2^36 bytes (with 32-bit size_t) or 2^68 bytes (with 64-bit size_t). It would make some sense to replace size_t with uint64_t, to get the same limit regardless of platform. If we go to 64-bit counts, I also wonder if it makes sense to steal 4 of the high bits to store the tag_length (otherwise, due to padding, an extra struct field for the tag_length increases the ocb_ctx from 80 bytes to 96 (on a 64-bit platform). 4. The reason I was looking into this now, is that I'm thinking about adding support for blake2 (RFC 7693), which also similarly has variable digest size, and that size encoded into a parameter word at init time. All opinions welcome. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

1 1

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