nettle-bugs

nettle-bugs@lists.lysator.liu.se

5 participants
2214 discussions

ANNOUNCE: nettle-4.0
by Niels Möller 15 Feb '26

15 Feb '26

I'm happy to announce a new major release of GNU Nettle, a low-level cryptographics library. This release includes a couple of API changes, a few of which are rather disruptive, as well as deletion of obsolete features. There's only one notable new feature: Support for SLH-DSA signatures (stateless hash-based digital signature algorithm). Please review NEWS (see below) carefully before upgrading. Since upgrading requires application code changes, nettle-3 (latest version 3.10.2) will get bug fix releases as needed to fix any severe bugs found, until the dust has settled and users, applications and distros have had reasonable time to upgrade. The Nettle home page can be found at https://www.lysator.liu.se/~nisse/nettle/, and the manual at https://www.lysator.liu.se/~nisse/nettle/nettle.html. The release can be downloaded from https://ftp.gnu.org/gnu/nettle/nettle-4.0.tar.gz https://www.lysator.liu.se/~nisse/archive/nettle-4.0.tar.gz Happy hacking, /Niels Möller NEWS for the Nettle 4.0 release This is a new major release. It includes one new feature, support for SLH-DSA. There are several changes to Nettle's API, as well as deletion of obsolete features. There are also several improvements to the ABI that leaves the API mostly unchanged, in particular, smaller context structs for several algorithms. The most disruptive API change is that the *_digest functions no longer takes the desired digest size as argument. Truncated hashes appeared to be an important use case decades ago when the previous interface was designed, but that is now rather obscure. Feedback on the new interfaces is appreciated, e.g., if the variable tag length for OCB and CCM should be supported differently, if additional types would benefit from larger alignment, or if there are remaining interface bugs or inconsistencies. Smaller additional API or ABI changes may be considered for the next release, Nettle-4.1, but after that, the intention is that both ABI and API should stay backwards compatible for a longer time. The shared library names are libnettle.so.9.0 and libhogweed.so.7.0, with new sonames libnettle.so.9 and libhogweed.so.7. Interface changes: * The _digest functions for hash algorithms, MACs and AEADs no longer take the desired digest size as argument, instead, they always produce the full-size digest. The typedef nettle_hash_digest_func has also been changed accordingly. There are two exceptions: CCM and OCB. These AEAD algorithms are specified with a variable tag length, which is not a mere truncation of the output. Their _digest functions (ccm_digest, ocb_digest, ccm_ae128_digest, ...) also have their length argument deleted, but they still produce a variable size digest. The number of octets to write (at most 16) is stored into the context struct by the corresponding _set_nonce function. * The functions to process complete messages using CCM AES now take a const cipher context as the first argument, e.g, first argument to ccm_aes128_encrypt_message is now a const struct aes128_ctx *. It used to be a struct ccm_aes128_ctx *, where everything but the underlying cipher context was ignored. * The SHA3 functions now use the same struct sha3_ctx for all flavors, and the same function sha3_init. Old names, e.g., sha3_256_ctx and sha3_256_init, are defined as preprocessor aliases, for backwards compatibility. * The dst_length argument to base16_decode_update and base64_decode_update is now both an input and output argument. On input it must now hold the size of the destination buffer, and decoding fails if that is not sufficient. Previously, dst_length was an output only, and it was required that the destination buffer was large enough for any input of the given src_length. Interface deletions: * Deleted the old struct aes_ctx, and all functions operating on it. Use the fixed key size interfaces instead, e.g., struct aes256_ctx, introduced in Nettle-3.0. * Deleted dsa-compat.h, and everything declared therein. Use the interface in dsa.h, introduced in Nettle-3.0. * Deleted old header sha.h. Use sha1.h or sha2.h instead, as appropriate. * Deleted the general HMAC interface, with functions like hmac_set_key that work with an arbitrary underlying hash function. Use the specific hmac functions instead, e.g., hmac_sha256_set_key, or the mac abstraction defined in nettle-meta.h, e.g, the nettle_hmac_sha256 instance. * Deleted the undocumented struct nettle_armor abstraction. * Deleted the undocumented function base64_encode_group. * Deleted md5-compat.h, and everything declared therein. Use the interface in md5.h instead (or even better, stop using md5). * Deleted pgp.h, and everything declared therein. This attempt to support openpgp formats was incomplete, undocumented, and mostly obsolete. * Delete all the *_DATA_SIZE compatibility aliases. Use corresponding *_BLOCK_SIZE constants instead, introduced in Nettle-3.0. * Deleted the obsolete functions _rsa_blind and _rsa_unblind. (Current RSA blinding in Nettle uses internal functions with a different interface). * Delete compatibility aliases salsa20_set_iv, SALSA20_IV_SIZE. These were renamed to salsa20_set_nonce and SALSA20_NONCE_SIZE in Nettle-3.0. * Deleted compatibility aliases _nettle_md5_compress, _nettle_sha1_compress. These internal functions were promoted to documented and supported functions in Nettle-3.9, with new names md5_compress and sha1_compress. * Deleted compatibility alias yarrow_force_reseed. Renamed to yarrow_slow_reseed in Nettle-2.0. ABI changes and improvements. * Introduce 16-byte alignment on certain types. Applied to union nettle_block16, and subkey arrays of AES and UMAC. This is intended to improve performance for SIMD load and store instructions, which on some platforms may be faster with proper alignment. The larger alignment is enabled only for platforms where the alignment of the uint64_t type is 8. * Size of struct gcm_key is reduced from 4096 bytes to 2048. * Size of the new sha3_ctx is considerable smaller, 216 bytes, than the previous types that included a buffer for a complete block. E.g., the largest one, for sha3_128_ctx (shake128), used to be 376 bytes. * Size of HMAC contexts have been reduced, by not including multiple block buffers. E.g, size of struct hmac_sha256_ctx reduced from 336 bytes to 192. This change has been discussed for a long time, with first attempt made by Dmitry Baryshkov years ago, but delayed, since it implies an ABI break. * For OCB block counters, use type uint32_t for blocks of associated data, and uint64_t for message blocks, instead of size_t. This makes the implementation limits the same for 32-bit and 64-bit platforms. Bug fixes: * Fix off-by-one bug in sexp parser, which could result in a one byte overread on invalid input. Also fix excessive recursion and stack usage for some inputs. Both problems reported via oss-fuzz. * Fix ed448_shake256_verify to check that the final signature octet is zero (previous versions completely ignored this somewhat redundant octet). Reported by Oren Yomtov. New features: * Support for SLH-DSA signatures (stateless hash-based digital signature algorithm). See the Nettle manual for details. * New public function drbg_ctr_aes256_update, to enable FIPS-compliant reseeding. Contributed by Daiki Ueno. Configure and build changes: * Support for at least C99 is required when building Nettle. In addition, support for alignof and alignas is required; these are part of C11, but intention is that this is the only required C11 feature. * The unusual configure options --with-lib-path and --with-include-path has been deleted. Use CFLAGS and LDFLAGS instead. This implies that Nettle's configure script no longer attempts to add rpath-related linker flags automagically; if any are needed, they must be passed in LDFLAGS. * The logic to sometimes change the default libdir has been deleted. Previously, configure tried to be helpful and change the default, e.g., to ${exec_prefix}/lib32 when you build 32-bit libraries on a system where ${exec_prefix}/lib is for 64-bit libraries. If you relied on this behavior, you now have to use the --libdir configure option. * Rearranged getopt files, now based on gnulib copies. -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

2 2

sntrup761
by Niels Möller 12 Feb '26

12 Feb '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.

2 1

Re: Nettle 4.0
by Niels Möller 10 Feb '26

10 Feb '26

Niels Möller <nisse(a)lysator.liu.se> writes: > João Gomes writes: > >> In file included from nettle-meta.h:37:0, from non-nettle.h:38, >> from non-nettle.c:43: >> nettle-types.h:70:3: error: expected specifier-qualifier-list before ‘_Alignas’ >> In file included from ocb.h:38:0, >> from non-nettle.h:39, >> from non-nettle.c:43: >> aes.h:71:3: error: expected specifier-qualifier-list before ‘_Alignas’ >> aes.h:92:3: error: expected specifier-qualifier-list before ‘_Alignas’ >> aes.h:113:3: error: expected specifier-qualifier-list before ‘_Alignas’ >> make[1]: *** [Makefile:322: non-nettle.o] Error 1 > > Related to this note in NEWS: > > In addition, support for alignof and alignas is required; these are > part of C11, but intention is that this is the only required C11 > feature. > >> For your information, I can compile it without any errors on x86-x64, but not on ARM anymore. > > Which compiler and compiler options did you have this problem with? It's > somewhat odd that you appear to have stdalign.h, and a macro alignas > expanding to _Alignas, but the latter not working as expected. Apparently, this was with gcc-4.5.3, used in some build framework for embedded systems. This version was released in April 2011. I think support for stdalign.h was added in to GCC in version 4.7.0, released one year later, March 2012. I'm not that surprised that people doing embedded systems are sometimes using pretty old tool chains. I'm also told that Microsoft's C compiler didn't get stdalign.h until 2019. So my questions is: Are there others who are stuck with older compilers and getting trouble with Nettle's use of alignas/alignof? Is it somewhat common, or rather obscure? It's possible to add a --disable-align configure option, but it would get a bit complex since that option must control what goes into the installed header files. So I wonder if that's worth the effort? Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

3 3

Re: ANNOUNCE: nettle-4.0
by foo apr 06 Feb '26

06 Feb '26

Hi, It seems the 4.0 tags are not pushed to https://github.com/gnutls/nettle/tags, can you please take a look? /Foolbar

2 1

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

base64_decode_update and base16_decode_update
by Niels Möller 15 Dec '25

15 Dec '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.

2 5

Some typos to fix
by Amos Jeffries 14 Nov '25

14 Nov '25

Updating Squid to the latest base64 I have found these: * "fucntion" in base64.h and ChangeLog documentation * base64-decode.c copyright states that it is "base64-encode.c" Cheers Amos

2 1

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