1.0.19

[jedisct1]

1.0.19

This release includes all the changes from 1.0.18-stable, as well as two additions:

• New AEADs: AEGIS-128L and AEGIS-256 are now available in the crypto_aead_aegis128l_*() and crypto_aead_aegis256_*() namespaces. AEGIS is a family of authenticated ciphers for high-performance applications, leveraging hardware AES acceleration on x86_64 and aarch64. In addition to performance, AEGIS ciphers have unique properties making them easier and safer to use than AES-GCM. They can also be used as high-performance MACs.
• The HKDF key derivation mechanism, required by many standard protocols, is now available in the crypto_kdf_hkdf_*() namespace. It is implemented for the SHA-256 and SHA-512 hash functions.
• The osx.sh build script was renamed to macos.sh.
• Support for android-mips was removed.

From 1.0.18-stable:

• Visual Studio: support for Windows/ARM64 builds has been added.
• Visual Studio: AVX512 implementations are enabled on supported CPUs.
• Visual Studio: an MSVC 2022 solution was added.
• Apple XCFramework: support for VisionOS was added.
• Apple XCFranework: support for Catalyst was added.
• Apple XCFramework: building the simulators is now optional.
• iOS: bitcode is not generated any more, as it was deprecated by Apple.
• watchOS: support for arm64 was added.
• The Zig toolchain can now be used as a modern build system to replace autoconf/automake/libtool/make/ccache and the compiler. This enables faster compilation times, easier cross compilation, and static libraries optimized for any CPU.
• The Zig toolchain is now the recommended way to compile libsodium to WebAssembly/WASI(X).
• libsodium can now be added as a dependency to Zig projects.
• Memory fences were added to remove some gadgets that could be used alongside speculative loads.
• The AES-GCM implementation was completely rewritten. It is now faster, and also available on aarch64, including Windows/ARM64.
• Compatibility with CET instrumentation / IBT / Shadow Stack was added.
• Emscripten: the crypto_pwhash_*() functions have been removed from Sumo builds, as they reserve a substantial amount of JavaScript memory, even when not used.
• Benchmarks now use CLOCK_MONOTONIC if possible.
• WebAssembly: tests can now run using Bun, WasmEdge, Wazero, wasm3 and wasmer-js. Support for WAVM and Lucet have been removed, as these projects have reached EOL.
• .NET: the minimum supported macOS version is now 1.0.15; this matches Microsoft guidelines.
• .NET: all the packages are now built using Zig, on all platforms. This allows us to easily match Microsoft's requirements, including supported glibc versions. However, on x86_64, targets are expected to support at least the AVX instruction set.
• .NET: packages for ARM64 are now available.
• C23 memset_explicit() is now used, when available.
• Compilation now uses -Ofast or -O3 instead of -O2 by default.
• Portability improvements to help compile libsodium to modern game consoles.
• JavaScript: a default unhandledRejection handler is not set any more.
• Slightly faster 25519 operations.
• OpenBSD: leverage MAP_CONCEAL.

---

This discussion was created from the release 1.0.19.

[cajus]

gcc on arm64 (debian bullseye / gcc 10.2.1) doesn't seem to be happy when trying to compile 1.0.19:

  CC       crypto_generichash/blake2b/ref/libsse41_la-blake2b-compress-sse41.lo
../../source_subfolder/src/libsodium/crypto_aead/aegis256/aegis256_armcrypto.c:24:9: error: pragma or attribute 'target("neon")' is not valid
   24 | #pragma GCC target("neon,crypto,aes")
      |         ^~~
../../source_subfolder/src/libsodium/crypto_aead/aegis128l/aegis128l_armcrypto.c:24:9: error: pragma or attribute 'target("neon")' is not valid
   24 | #pragma GCC target("neon,crypto,aes")
      |         ^~~

Is gcc too old, or is something else wrong here?

[jedisct1]

Hi,

And thanks for reporting this!

Since the 1.0.19 point release was just tagged, I'm going to remove it and replace it with the code that has a fix for that gcc issue.

[cajus]

Thanks, giving it a try! works!

[OoLunar]

Could we get an update on the Nuget feed please? Assuming the nuget package is intended to provide the libraries at runtime and NOT bindings, it'd be of great help to me!

[bfren]

I'd be happy to do a PR for libsodium-net once the libsodium Nuget package is updated to 1.0.19.

[samuel-lucas6]

It's on NuGet now.

[SunMar]

Hi, not sure if it's intended or not, but the libsodium-1.0.19.tar.gz asset extracts to libsodium-stable instead of libsodium-1.0.19 like previously releases did.

[cajus]

When compiling with android NDK r26, I'm running into:

/var/home/ciuser/.conan/data/android_ndk_installer/r26/foo/stable/package/b925f19ad6eb509f29bf6c0a5b52e2a00411ce69/toolchains/llvm/prebuilt/linux-x86_64/lib/clang/17/include/arm_neon.h:62829:32: error: always_inline function 'vget_high_p64' requires target feature 'crypto', but would be inlined into function 'vmull_high_p64' that is compiled without support for 'crypto'
  __ret = vmull_p64((poly64_t)(vget_high_p64(__p0)), (poly64_t)(vget_high_p64(__p1)));

Anyone seen something like that already? Looks a bit like some NDK mixup.

[jedisct1]

@cajus Are you using the supplied build script as documented here? (scroll down to "cross-compilation to Android").

[cajus]

No. I'm using conan for building all libraries. Will take a look at the script to see wether there's something special in it, which the conan recipe is missing.

[cajus]

Yey - the compile flags -march=armv8-a were missing for armv8 in the recipe. Wondering why it ever worked in earlier NDKs. It works now - thanks @jedisct1