deps: update libsodium to 1.0.21 #408
Conversation
WalkthroughAdds Keccak-1600 core and multiple XOFs (SHAKE/TurboSHAKE), a pluggable IPcrypt framework with software and hardware backends (AES-NI, ARM Crypto), SoftAES key-schedule, many constant-time memory-fence and blocker hardenings, public header exports, utilities (IP address codecs), and version bump to 1.0.21. Changes
Sequence Diagram(s)sequenceDiagram
participant Caller
participant crypto_ipcrypt_api as crypto_ipcrypt API
participant impl_picker as _crypto_ipcrypt_pick_best_implementation
participant Backend as Chosen Backend
participant HW as Hardware/AES-NI or ARM Crypto (optional)
Caller->>crypto_ipcrypt_api: call crypto_ipcrypt_encrypt(...)
crypto_ipcrypt_api->>impl_picker: ensure implementation selected
impl_picker-->>crypto_ipcrypt_api: returns chosen backend pointer
crypto_ipcrypt_api->>Backend: delegate encrypt(...)
alt Backend is hardware-accelerated
Backend->>HW: use AES-NI / ARM Crypto intrinsics
HW-->>Backend: encrypted output
else Backend is software
Backend-->>crypto_ipcrypt_api: compute using SoftAES
end
Backend-->>crypto_ipcrypt_api: return result
crypto_ipcrypt_api-->>Caller: return
Estimated code review effort🎯 5 (Critical) | ⏱️ ~120 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
deps/sodium/src/libsodium/randombytes/internal/randombytes_internal_random.c (1)
1-648: Do not merge: libsodium version does not exist and contains critical cryptographic vulnerability.Version 1.0.21 does not exist; the latest stable release is 1.0.20 (May 25, 2024). Additionally, libsodium 1.0.20 contains a critical cryptographic validation vulnerability (CVE-2025-69277) affecting ed25519 point checking. Upgrade to a patched libsodium version released after December 30, 2025, or clarify the intended version number.
deps/sodium/src/libsodium/include/sodium.h (1)
31-36: Duplicate header includes detected.
crypto_kdf_hkdf_sha256.handcrypto_kdf_hkdf_sha512.hare included twice (lines 32-33 and again at lines 35-36). While include guards prevent compilation errors, this duplication should be cleaned up.Proposed fix
#include "sodium/crypto_kdf.h" #include "sodium/crypto_kdf_hkdf_sha256.h" #include "sodium/crypto_kdf_hkdf_sha512.h" #include "sodium/crypto_kdf_blake2b.h" -#include "sodium/crypto_kdf_hkdf_sha256.h" -#include "sodium/crypto_kdf_hkdf_sha512.h" #include "sodium/crypto_kx.h"
🤖 Fix all issues with AI agents
In @deps/sodium/src/libsodium/crypto_aead/aegis256/aegis256_armcrypto.c:
- Line 43: The AES_ENC macro is using vaeseq_u8 with operands reversed, causing
it to encrypt zero instead of the input; update AES_ENC to call vaeseq_u8 with
(A) as the data and vmovq_n_u8(0) as the round key (i.e., vaeseq_u8((A),
vmovq_n_u8(0))) before passing to vaesmcq_u8, and apply the same operand swap to
the analogous macro/usage in the aegis128l implementation so ARM NEON semantics
match AESNI/_mm_aesenc_si128.
In
@deps/sodium/src/libsodium/crypto_aead/aes256gcm/armcrypto/aead_aes256gcm_armcrypto.c:
- Around line 48-52: The AES intrinsics are called with operands reversed:
vaeseq_u8 expects (data, key) but the macros AES_XENCRYPT and AES_XENCRYPTLAST
pass (rkey, data); fix both macros to call vaeseq_u8 with the block vector first
(vreinterpretq_u8_u64(block_vec)) and the round key second (rkey), keeping the
surrounding vreinterpretq_u64_u8 and vaesmcq_u8 usages unchanged so AES_XENCRYPT
still applies vaeseq then vaesmcq and AES_XENCRYPTLAST only applies vaeseq.
In @deps/sodium/src/libsodium/crypto_xof/shake256/xof_shake256.c:
- Around line 23-30: The cast of unsigned long long inlen to size_t in
crypto_xof_shake256 is unsafe on platforms where size_t < 64 bits; before
calling shake256_ref, validate that inlen <= SIZE_MAX and return an error (e.g.,
-1) if it exceeds that limit, then cast and call shake256_ref normally; apply
the same bounds check pattern to crypto_xof_shake256_update and the equivalent
XOF functions (shake128, turboshake128, turboshake256 variants) to prevent
silent truncation when converting to size_t.
In
@deps/sodium/src/libsodium/randombytes/internal/randombytes_internal_random.c:
- Around line 12-14: The conditional include of threads.h is unused and can be
removed or explicitly justified: delete the block that includes <threads.h> (#if
!defined(__STDC_NO_THREADS__) && defined(HAVE_THREADS_H) ... #endif) since the
file uses the C11 keyword _Thread_local (see the thread-local variable at/around
the use of _Thread_local) and does not require threads.h; alternatively, if
upstream intends threads.h for a future API, replace the include with a brief
comment explaining why threads.h is retained and reference the use of
_Thread_local to avoid misleading maintainers.
In @deps/sodium/src/libsodium/sodium/codecs.c:
- Around line 535-610: In sodium_bin2ip, the IPv4 branch copies len+1U bytes
from the uninitialized stack buffer buf (reading buf[len]) which can trigger
sanitizer warnings; change the memcpy in the IPv4 path (inside sodium_bin2ip
where ipv4_mapped_prefix is handled) to copy only len bytes (memcpy(ip, buf,
len)) and then set ip[len]=0, matching the IPv6 path behavior to avoid reading
uninitialized memory.
🧹 Nitpick comments (6)
deps/sodium/src/libsodium/crypto_xof/shake256/xof_shake256.c (1)
27-50: Consider consolidating repeated compile-time assertions.The
COMPILER_ASSERTchecking state size compatibility appears on lines 27, 37, and 47. While this is harmless (compile-time only), the assertion could be moved to a single location or a shared initialization helper to reduce redundancy.deps/sodium/src/libsodium/crypto_xof/shake128/xof_shake128.c (1)
27-50: Repeated assertions pattern (same as SHAKE256).The duplicate
COMPILER_ASSERTpattern on lines 27, 37, and 47 mirrors the SHAKE256 implementation. While consistent across XOF implementations, the same optional consolidation opportunity applies.deps/sodium/src/libsodium/include/sodium/crypto_xof_shake256.h (1)
1-9: Minor inconsistency: Missing GCC long-long diagnostic pragma.Unlike
crypto_core_keccak1600.handcrypto_xof_shake128.h, this header lacks the#pragma GCC diagnostic ignored "-Wlong-long"within the C++ block. This is a minor stylistic inconsistency across the XOF headers in this PR.♻️ Suggested fix for consistency
#ifdef __cplusplus +# ifdef __GNUC__ +# pragma GCC diagnostic ignored "-Wlong-long" +# endif extern "C" { #endifdeps/sodium/src/libsodium/include/sodium/crypto_xof_turboshake128.h (1)
1-9: Minor: Missing GCC long-long diagnostic pragma.Similar to
crypto_xof_shake256.h, this header lacks the-Wlong-longdiagnostic pragma present incrypto_xof_shake128.handcrypto_core_keccak1600.h. This is a minor stylistic inconsistency.deps/sodium/src/libsodium/include/sodium/private/quirks.h (1)
3-4: Missing include guard definition.The
#ifndef quirks_Hcheck exists but there's no corresponding#define quirks_Hto prevent multiple inclusions. While the macro redefinitions are harmless (same values), this deviates from standard include guard practice.🔧 Suggested fix
#ifndef quirks_H +#define quirks_H #ifndef NO_QUIRKSdeps/sodium/src/libsodium/randombytes/randombytes.c (1)
92-92: Consider safer access pattern for the global crypto fallback.The direct reference to
cryptoon line 92 could throw aReferenceErrorif the globalcryptoobject doesn't exist. While the surrounding try-catch block (lines 100-112) handles this correctly, using atypeofcheck would make the intent more explicit and avoid relying on exception handling for control flow.♻️ Optional refactor for more explicit global check
- crypto_ = (crypto_ === undefined) ? crypto : crypto_; + crypto_ = (crypto_ === undefined && typeof crypto !== 'undefined') ? crypto : crypto_;Note: This code is part of the libsodium 1.0.21 dependency and matches the upstream implementation.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (85)
deps/sodium/.gitignoredeps/sodium/LICENSEdeps/sodium/src/libsodium/Makefile.amdeps/sodium/src/libsodium/crypto_aead/aegis128l/aead_aegis128l.cdeps/sodium/src/libsodium/crypto_aead/aegis128l/aegis128l_armcrypto.cdeps/sodium/src/libsodium/crypto_aead/aegis128l/aegis128l_common.hdeps/sodium/src/libsodium/crypto_aead/aegis128l/aegis128l_soft.hdeps/sodium/src/libsodium/crypto_aead/aegis256/aead_aegis256.cdeps/sodium/src/libsodium/crypto_aead/aegis256/aegis256_armcrypto.cdeps/sodium/src/libsodium/crypto_aead/aegis256/aegis256_common.hdeps/sodium/src/libsodium/crypto_aead/aegis256/aegis256_soft.cdeps/sodium/src/libsodium/crypto_aead/aegis256/aegis256_soft.hdeps/sodium/src/libsodium/crypto_aead/aes256gcm/aead_aes256gcm.cdeps/sodium/src/libsodium/crypto_aead/aes256gcm/aesni/aead_aes256gcm_aesni.cdeps/sodium/src/libsodium/crypto_aead/aes256gcm/armcrypto/aead_aes256gcm_armcrypto.cdeps/sodium/src/libsodium/crypto_aead/chacha20poly1305/aead_chacha20poly1305.cdeps/sodium/src/libsodium/crypto_aead/xchacha20poly1305/aead_xchacha20poly1305.cdeps/sodium/src/libsodium/crypto_core/ed25519/ref10/ed25519_ref10.cdeps/sodium/src/libsodium/crypto_core/keccak1600/keccak1600.cdeps/sodium/src/libsodium/crypto_core/keccak1600/ref/keccak1600_ref.cdeps/sodium/src/libsodium/crypto_core/keccak1600/ref/keccak1600_ref.hdeps/sodium/src/libsodium/crypto_core/softaes/softaes.cdeps/sodium/src/libsodium/crypto_ipcrypt/crypto_ipcrypt.cdeps/sodium/src/libsodium/crypto_ipcrypt/implementations.hdeps/sodium/src/libsodium/crypto_ipcrypt/ipcrypt_aesni.cdeps/sodium/src/libsodium/crypto_ipcrypt/ipcrypt_aesni.hdeps/sodium/src/libsodium/crypto_ipcrypt/ipcrypt_armcrypto.cdeps/sodium/src/libsodium/crypto_ipcrypt/ipcrypt_armcrypto.hdeps/sodium/src/libsodium/crypto_ipcrypt/ipcrypt_soft.cdeps/sodium/src/libsodium/crypto_ipcrypt/ipcrypt_soft.hdeps/sodium/src/libsodium/crypto_kdf/hkdf/kdf_hkdf_sha256.cdeps/sodium/src/libsodium/crypto_kdf/hkdf/kdf_hkdf_sha512.cdeps/sodium/src/libsodium/crypto_onetimeauth/poly1305/sse2/poly1305_sse2.cdeps/sodium/src/libsodium/crypto_pwhash/argon2/argon2-fill-block-ref.cdeps/sodium/src/libsodium/crypto_pwhash/argon2/argon2.hdeps/sodium/src/libsodium/crypto_pwhash/scryptsalsa208sha256/crypto_scrypt-common.cdeps/sodium/src/libsodium/crypto_scalarmult/curve25519/sandy2x/curve25519_sandy2x.cdeps/sodium/src/libsodium/crypto_scalarmult/curve25519/sandy2x/sandy2x.Sdeps/sodium/src/libsodium/crypto_scalarmult/curve25519/scalarmult_curve25519.hdeps/sodium/src/libsodium/crypto_secretbox/crypto_secretbox_easy.cdeps/sodium/src/libsodium/crypto_secretbox/xchacha20poly1305/secretbox_xchacha20poly1305.cdeps/sodium/src/libsodium/crypto_secretbox/xsalsa20poly1305/secretbox_xsalsa20poly1305.cdeps/sodium/src/libsodium/crypto_secretstream/xchacha20poly1305/secretstream_xchacha20poly1305.cdeps/sodium/src/libsodium/crypto_stream/salsa20/xmm6/salsa20_xmm6-asm.Sdeps/sodium/src/libsodium/crypto_verify/verify.cdeps/sodium/src/libsodium/crypto_xof/shake128/ref/shake128_ref.cdeps/sodium/src/libsodium/crypto_xof/shake128/ref/shake128_ref.hdeps/sodium/src/libsodium/crypto_xof/shake128/xof_shake128.cdeps/sodium/src/libsodium/crypto_xof/shake256/ref/shake256_ref.cdeps/sodium/src/libsodium/crypto_xof/shake256/ref/shake256_ref.hdeps/sodium/src/libsodium/crypto_xof/shake256/xof_shake256.cdeps/sodium/src/libsodium/crypto_xof/turboshake128/ref/turboshake128_ref.cdeps/sodium/src/libsodium/crypto_xof/turboshake128/ref/turboshake128_ref.hdeps/sodium/src/libsodium/crypto_xof/turboshake128/xof_turboshake128.cdeps/sodium/src/libsodium/crypto_xof/turboshake256/ref/turboshake256_ref.cdeps/sodium/src/libsodium/crypto_xof/turboshake256/ref/turboshake256_ref.hdeps/sodium/src/libsodium/crypto_xof/turboshake256/xof_turboshake256.cdeps/sodium/src/libsodium/include/Makefile.amdeps/sodium/src/libsodium/include/sodium.hdeps/sodium/src/libsodium/include/sodium/crypto_core_ed25519.hdeps/sodium/src/libsodium/include/sodium/crypto_core_keccak1600.hdeps/sodium/src/libsodium/include/sodium/crypto_hash_sha256.hdeps/sodium/src/libsodium/include/sodium/crypto_hash_sha512.hdeps/sodium/src/libsodium/include/sodium/crypto_ipcrypt.hdeps/sodium/src/libsodium/include/sodium/crypto_stream.hdeps/sodium/src/libsodium/include/sodium/crypto_stream_chacha20.hdeps/sodium/src/libsodium/include/sodium/crypto_stream_salsa20.hdeps/sodium/src/libsodium/include/sodium/crypto_stream_salsa2012.hdeps/sodium/src/libsodium/include/sodium/crypto_stream_salsa208.hdeps/sodium/src/libsodium/include/sodium/crypto_stream_xchacha20.hdeps/sodium/src/libsodium/include/sodium/crypto_stream_xsalsa20.hdeps/sodium/src/libsodium/include/sodium/crypto_xof_shake128.hdeps/sodium/src/libsodium/include/sodium/crypto_xof_shake256.hdeps/sodium/src/libsodium/include/sodium/crypto_xof_turboshake128.hdeps/sodium/src/libsodium/include/sodium/crypto_xof_turboshake256.hdeps/sodium/src/libsodium/include/sodium/private/common.hdeps/sodium/src/libsodium/include/sodium/private/implementations.hdeps/sodium/src/libsodium/include/sodium/private/quirks.hdeps/sodium/src/libsodium/include/sodium/private/softaes.hdeps/sodium/src/libsodium/include/sodium/utils.hdeps/sodium/src/libsodium/include/sodium/version.hdeps/sodium/src/libsodium/randombytes/internal/randombytes_internal_random.cdeps/sodium/src/libsodium/randombytes/randombytes.cdeps/sodium/src/libsodium/sodium/codecs.cdeps/sodium/src/libsodium/sodium/utils.c
💤 Files with no reviewable changes (1)
- deps/sodium/src/libsodium/sodium/utils.c
🧰 Additional context used
🧠 Learnings (9)
📚 Learning: 2025-12-03T14:31:54.774Z
Learnt from: CR
Repo: nodesource/nsolid PR: 0
File: deps/grpc/src/core/lib/address_utils/GEMINI.md:0-0
Timestamp: 2025-12-03T14:31:54.774Z
Learning: Applies to deps/grpc/src/core/lib/address_utils/**/parse_address.{h,cc} : Use `parse_address.h` / `parse_address.cc` for parsing string representations of network addresses into `grpc_resolved_address` structures
Applied to files:
deps/sodium/src/libsodium/sodium/codecs.c
📚 Learning: 2025-12-03T14:31:59.979Z
Learnt from: CR
Repo: nodesource/nsolid PR: 0
File: deps/grpc/src/core/lib/address_utils/GEMINI.md:0-0
Timestamp: 2025-12-03T14:31:59.979Z
Learning: Applies to deps/grpc/src/core/lib/address_utils/**/*parse_address.{h,cc} : Parse string representations of network addresses into `grpc_resolved_address` structures using functions from `parse_address.h`/`parse_address.cc`
Applied to files:
deps/sodium/src/libsodium/sodium/codecs.c
📚 Learning: 2025-12-03T14:31:58.078Z
Learnt from: CR
Repo: nodesource/nsolid PR: 0
File: deps/grpc/src/core/lib/address_utils/GEMINI.md:0-0
Timestamp: 2025-12-03T14:31:58.078Z
Learning: Applies to deps/grpc/src/core/lib/address_utils/**/*address*.{h,cc} : Design address utility functions to be efficient and avoid common pitfalls when working with network addresses
Applied to files:
deps/sodium/src/libsodium/sodium/codecs.c
📚 Learning: 2025-12-03T14:31:58.078Z
Learnt from: CR
Repo: nodesource/nsolid PR: 0
File: deps/grpc/src/core/lib/address_utils/GEMINI.md:0-0
Timestamp: 2025-12-03T14:31:58.078Z
Learning: Applies to deps/grpc/src/core/lib/address_utils/**/{parse_address.h,parse_address.cc} : Use `parse_address.h` and `parse_address.cc` for parsing string representations of network addresses into `grpc_resolved_address` structures
Applied to files:
deps/sodium/src/libsodium/sodium/codecs.c
📚 Learning: 2025-12-03T14:31:59.979Z
Learnt from: CR
Repo: nodesource/nsolid PR: 0
File: deps/grpc/src/core/lib/address_utils/GEMINI.md:0-0
Timestamp: 2025-12-03T14:31:59.979Z
Learning: Applies to deps/grpc/src/core/lib/address_utils/**/*sockaddr_utils.{h,cc} : Work with `sockaddr` structures using functions from `sockaddr_utils.h`/`sockaddr_utils.cc`, including converting to/from string representations and comparing for equality
Applied to files:
deps/sodium/src/libsodium/sodium/codecs.c
📚 Learning: 2025-12-03T14:31:54.774Z
Learnt from: CR
Repo: nodesource/nsolid PR: 0
File: deps/grpc/src/core/lib/address_utils/GEMINI.md:0-0
Timestamp: 2025-12-03T14:31:54.774Z
Learning: Applies to deps/grpc/src/core/lib/address_utils/**/sockaddr_utils.{h,cc} : Use `sockaddr_utils.h` / `sockaddr_utils.cc` for working with `sockaddr` structures, including converting them to/from string representations and comparing them for equality
Applied to files:
deps/sodium/src/libsodium/sodium/codecs.c
📚 Learning: 2025-12-03T14:31:58.078Z
Learnt from: CR
Repo: nodesource/nsolid PR: 0
File: deps/grpc/src/core/lib/address_utils/GEMINI.md:0-0
Timestamp: 2025-12-03T14:31:58.078Z
Learning: Applies to deps/grpc/src/core/lib/address_utils/**/{sockaddr_utils.h,sockaddr_utils.cc} : Use `sockaddr_utils.h` and `sockaddr_utils.cc` for working with `sockaddr` structures, including converting them to and from string representations, and comparing them for equality
Applied to files:
deps/sodium/src/libsodium/sodium/codecs.c
📚 Learning: 2025-12-03T14:35:14.525Z
Learnt from: CR
Repo: nodesource/nsolid PR: 0
File: deps/grpc/src/core/tsi/alts/GEMINI.md:0-0
Timestamp: 2025-12-03T14:35:14.525Z
Learning: Perform cryptographic operations using code in the `crypt/` directory
Applied to files:
deps/sodium/src/libsodium/include/sodium.hdeps/sodium/src/libsodium/Makefile.amdeps/sodium/src/libsodium/crypto_ipcrypt/crypto_ipcrypt.c
📚 Learning: 2025-12-03T14:31:30.011Z
Learnt from: CR
Repo: nodesource/nsolid PR: 0
File: deps/grpc/src/core/handshaker/GEMINI.md:0-0
Timestamp: 2025-12-03T14:31:30.011Z
Learning: Applies to deps/grpc/src/core/handshaker/security/**/*.{h,cc} : Implement security handshakers responsible for performing TLS and ALTS handshakes in the security/ subdirectory
Applied to files:
deps/sodium/src/libsodium/Makefile.am
🧬 Code graph analysis (24)
deps/sodium/src/libsodium/crypto_xof/shake256/xof_shake256.c (1)
deps/sodium/src/libsodium/crypto_xof/shake256/ref/shake256_ref.c (5)
shake256_ref(112-122)shake256_ref_init(20-24)shake256_ref_init_with_domain(9-18)shake256_ref_update(26-52)shake256_ref_squeeze(84-110)
deps/sodium/src/libsodium/include/sodium/private/implementations.h (1)
deps/sodium/src/libsodium/crypto_ipcrypt/crypto_ipcrypt.c (1)
_crypto_ipcrypt_pick_best_implementation(179-198)
deps/sodium/src/libsodium/crypto_xof/turboshake256/ref/turboshake256_ref.h (1)
deps/sodium/src/libsodium/crypto_xof/turboshake256/ref/turboshake256_ref.c (5)
turboshake256_ref(112-122)turboshake256_ref_init(20-24)turboshake256_ref_init_with_domain(9-18)turboshake256_ref_update(26-52)turboshake256_ref_squeeze(84-110)
deps/sodium/src/libsodium/crypto_xof/turboshake256/ref/turboshake256_ref.c (1)
deps/sodium/src/libsodium/crypto_core/keccak1600/keccak1600.c (4)
crypto_core_keccak1600_init(10-14)crypto_core_keccak1600_permute_12(38-42)crypto_core_keccak1600_xor_bytes(16-22)crypto_core_keccak1600_extract_bytes(24-30)
deps/sodium/src/libsodium/crypto_core/keccak1600/ref/keccak1600_ref.h (1)
deps/sodium/src/libsodium/crypto_core/keccak1600/ref/keccak1600_ref.c (5)
keccak1600_ref_init(424-428)keccak1600_ref_xor_bytes(430-439)keccak1600_ref_extract_bytes(441-447)keccak1600_ref_permute_24(390-405)keccak1600_ref_permute_12(407-422)
deps/sodium/src/libsodium/crypto_kdf/hkdf/kdf_hkdf_sha512.c (1)
deps/sodium/src/libsodium/sodium/utils.c (1)
sodium_memzero(122-154)
deps/sodium/src/libsodium/crypto_xof/shake256/ref/shake256_ref.h (1)
deps/sodium/src/libsodium/crypto_xof/shake256/ref/shake256_ref.c (5)
shake256_ref(112-122)shake256_ref_init(20-24)shake256_ref_init_with_domain(9-18)shake256_ref_update(26-52)shake256_ref_squeeze(84-110)
deps/sodium/src/libsodium/crypto_ipcrypt/ipcrypt_soft.c (3)
deps/sodium/src/libsodium/crypto_ipcrypt/ipcrypt_aesni.c (22)
expand_key(43-68)aes_encrypt(70-82)aes_decrypt(84-100)tweak_expand(102-108)aes_encrypt_with_tweak(110-124)aes_decrypt_with_tweak(126-145)aes_xex_tweak(147-159)aes_xex_encrypt(161-175)aes_xex_decrypt(177-195)encrypt(197-204)decrypt(206-213)nd_encrypt(215-223)nd_decrypt(225-232)ndx_encrypt(234-260)ndx_decrypt(262-287)is_ipv4_mapped(289-295)pfx_get_bit(297-301)pfx_set_bit(303-314)pfx_shift_left(316-325)pfx_pad_prefix(327-338)pfx_encrypt(340-408)pfx_decrypt(410-480)deps/sodium/src/libsodium/crypto_ipcrypt/ipcrypt_armcrypto.c (22)
expand_key(70-95)aes_encrypt(97-110)aes_decrypt(112-129)tweak_expand(131-135)aes_encrypt_with_tweak(137-152)aes_decrypt_with_tweak(154-174)aes_xex_tweak(176-189)aes_xex_encrypt(191-206)aes_xex_decrypt(208-227)encrypt(229-236)decrypt(238-245)nd_encrypt(247-255)nd_decrypt(257-264)ndx_encrypt(266-292)ndx_decrypt(294-319)is_ipv4_mapped(321-327)pfx_get_bit(329-333)pfx_set_bit(335-346)pfx_shift_left(348-358)pfx_pad_prefix(360-371)pfx_encrypt(373-443)pfx_decrypt(445-517)deps/sodium/src/libsodium/crypto_core/softaes/softaes.c (2)
softaes_expand_key128(49-78)softaes_invert_key_schedule128(178-186)
deps/sodium/src/libsodium/crypto_xof/shake128/ref/shake128_ref.h (1)
deps/sodium/src/libsodium/crypto_xof/shake128/ref/shake128_ref.c (5)
shake128_ref(112-122)shake128_ref_init(20-24)shake128_ref_init_with_domain(9-18)shake128_ref_update(26-52)shake128_ref_squeeze(84-110)
deps/sodium/src/libsodium/crypto_xof/shake128/xof_shake128.c (1)
deps/sodium/src/libsodium/crypto_xof/shake128/ref/shake128_ref.c (5)
shake128_ref(112-122)shake128_ref_init(20-24)shake128_ref_init_with_domain(9-18)shake128_ref_update(26-52)shake128_ref_squeeze(84-110)
deps/sodium/src/libsodium/include/sodium/crypto_core_keccak1600.h (1)
deps/sodium/src/libsodium/crypto_core/keccak1600/keccak1600.c (5)
crypto_core_keccak1600_statebytes(4-8)crypto_core_keccak1600_init(10-14)crypto_core_keccak1600_xor_bytes(16-22)crypto_core_keccak1600_extract_bytes(24-30)crypto_core_keccak1600_permute_24(32-36)
deps/sodium/src/libsodium/include/sodium/crypto_xof_shake128.h (1)
deps/sodium/src/libsodium/crypto_xof/shake128/xof_shake128.c (8)
crypto_xof_shake128_blockbytes(5-9)crypto_xof_shake128_statebytes(11-15)crypto_xof_shake128_domain_standard(17-21)crypto_xof_shake128(23-30)crypto_xof_shake128_init(32-40)crypto_xof_shake128_init_with_domain(42-50)crypto_xof_shake128_update(52-60)crypto_xof_shake128_squeeze(62-68)
deps/sodium/src/libsodium/crypto_xof/turboshake256/xof_turboshake256.c (1)
deps/sodium/src/libsodium/crypto_xof/turboshake256/ref/turboshake256_ref.c (5)
turboshake256_ref(112-122)turboshake256_ref_init(20-24)turboshake256_ref_init_with_domain(9-18)turboshake256_ref_update(26-52)turboshake256_ref_squeeze(84-110)
deps/sodium/src/libsodium/crypto_xof/shake256/ref/shake256_ref.c (1)
deps/sodium/src/libsodium/crypto_core/keccak1600/keccak1600.c (4)
crypto_core_keccak1600_init(10-14)crypto_core_keccak1600_permute_24(32-36)crypto_core_keccak1600_xor_bytes(16-22)crypto_core_keccak1600_extract_bytes(24-30)
deps/sodium/src/libsodium/crypto_core/keccak1600/keccak1600.c (1)
deps/sodium/src/libsodium/crypto_core/keccak1600/ref/keccak1600_ref.c (5)
keccak1600_ref_init(424-428)keccak1600_ref_xor_bytes(430-439)keccak1600_ref_extract_bytes(441-447)keccak1600_ref_permute_24(390-405)keccak1600_ref_permute_12(407-422)
deps/sodium/src/libsodium/include/sodium/crypto_xof_shake256.h (1)
deps/sodium/src/libsodium/crypto_xof/shake256/xof_shake256.c (8)
crypto_xof_shake256_blockbytes(5-9)crypto_xof_shake256_statebytes(11-15)crypto_xof_shake256_domain_standard(17-21)crypto_xof_shake256(23-30)crypto_xof_shake256_init(32-40)crypto_xof_shake256_init_with_domain(42-50)crypto_xof_shake256_update(52-60)crypto_xof_shake256_squeeze(62-68)
deps/sodium/src/libsodium/include/sodium/private/softaes.h (1)
deps/sodium/src/libsodium/crypto_core/softaes/softaes.c (13)
softaes_expand_key128(49-78)softaes_expand_key256(80-119)softaes_inv_mix_columns(167-176)softaes_invert_key_schedule128(178-186)softaes_invert_key_schedule256(188-196)softaes_block_encrypt(339-395)softaes_block_encrypt(608-646)softaes_block_decrypt(416-452)softaes_block_decrypt(667-703)softaes_block_encryptlast(454-482)softaes_block_encryptlast(705-800)softaes_block_decryptlast(484-517)softaes_block_decryptlast(802-835)
deps/sodium/src/libsodium/crypto_xof/turboshake128/ref/turboshake128_ref.c (1)
deps/sodium/src/libsodium/crypto_core/keccak1600/keccak1600.c (4)
crypto_core_keccak1600_init(10-14)crypto_core_keccak1600_permute_12(38-42)crypto_core_keccak1600_xor_bytes(16-22)crypto_core_keccak1600_extract_bytes(24-30)
deps/sodium/src/libsodium/crypto_xof/turboshake128/xof_turboshake128.c (1)
deps/sodium/src/libsodium/crypto_xof/turboshake128/ref/turboshake128_ref.c (5)
turboshake128_ref(112-122)turboshake128_ref_init(20-24)turboshake128_ref_init_with_domain(9-18)turboshake128_ref_update(26-52)turboshake128_ref_squeeze(84-110)
deps/sodium/src/libsodium/include/sodium/crypto_xof_turboshake256.h (1)
deps/sodium/src/libsodium/crypto_xof/turboshake256/xof_turboshake256.c (8)
crypto_xof_turboshake256_blockbytes(5-9)crypto_xof_turboshake256_statebytes(11-15)crypto_xof_turboshake256_domain_standard(17-21)crypto_xof_turboshake256(23-30)crypto_xof_turboshake256_init(32-40)crypto_xof_turboshake256_init_with_domain(42-51)crypto_xof_turboshake256_update(53-61)crypto_xof_turboshake256_squeeze(63-70)
deps/sodium/src/libsodium/include/sodium/crypto_xof_turboshake128.h (1)
deps/sodium/src/libsodium/crypto_xof/turboshake128/xof_turboshake128.c (8)
crypto_xof_turboshake128_blockbytes(5-9)crypto_xof_turboshake128_statebytes(11-15)crypto_xof_turboshake128_domain_standard(17-21)crypto_xof_turboshake128(23-30)crypto_xof_turboshake128_init(32-40)crypto_xof_turboshake128_init_with_domain(42-51)crypto_xof_turboshake128_update(53-61)crypto_xof_turboshake128_squeeze(63-70)
deps/sodium/src/libsodium/include/sodium/private/quirks.h (5)
deps/sodium/src/libsodium/crypto_core/keccak1600/ref/keccak1600_ref.c (5)
keccak1600_ref_extract_bytes(441-447)keccak1600_ref_init(424-428)keccak1600_ref_permute_12(407-422)keccak1600_ref_permute_24(390-405)keccak1600_ref_xor_bytes(430-439)deps/sodium/src/libsodium/crypto_xof/shake128/ref/shake128_ref.c (5)
shake128_ref(112-122)shake128_ref_init(20-24)shake128_ref_init_with_domain(9-18)shake128_ref_squeeze(84-110)shake128_ref_update(26-52)deps/sodium/src/libsodium/crypto_xof/shake256/ref/shake256_ref.c (5)
shake256_ref(112-122)shake256_ref_init(20-24)shake256_ref_init_with_domain(9-18)shake256_ref_squeeze(84-110)shake256_ref_update(26-52)deps/sodium/src/libsodium/crypto_xof/turboshake128/ref/turboshake128_ref.c (5)
turboshake128_ref(112-122)turboshake128_ref_init(20-24)turboshake128_ref_init_with_domain(9-18)turboshake128_ref_squeeze(84-110)turboshake128_ref_update(26-52)deps/sodium/src/libsodium/crypto_xof/turboshake256/ref/turboshake256_ref.c (5)
turboshake256_ref(112-122)turboshake256_ref_init(20-24)turboshake256_ref_init_with_domain(9-18)turboshake256_ref_squeeze(84-110)turboshake256_ref_update(26-52)
deps/sodium/src/libsodium/include/sodium/crypto_ipcrypt.h (1)
deps/sodium/src/libsodium/crypto_ipcrypt/crypto_ipcrypt.c (23)
crypto_ipcrypt_bytes(23-27)crypto_ipcrypt_keybytes(29-33)crypto_ipcrypt_nd_keybytes(35-39)crypto_ipcrypt_nd_tweakbytes(41-45)crypto_ipcrypt_nd_inputbytes(47-51)crypto_ipcrypt_nd_outputbytes(53-57)crypto_ipcrypt_ndx_keybytes(59-63)crypto_ipcrypt_ndx_tweakbytes(65-69)crypto_ipcrypt_ndx_inputbytes(71-75)crypto_ipcrypt_ndx_outputbytes(77-81)crypto_ipcrypt_pfx_keybytes(83-87)crypto_ipcrypt_pfx_bytes(89-93)crypto_ipcrypt_keygen(95-99)crypto_ipcrypt_ndx_keygen(101-105)crypto_ipcrypt_pfx_keygen(107-111)crypto_ipcrypt_encrypt(113-119)crypto_ipcrypt_decrypt(121-127)crypto_ipcrypt_nd_encrypt(129-136)crypto_ipcrypt_nd_decrypt(138-144)crypto_ipcrypt_ndx_encrypt(146-153)crypto_ipcrypt_ndx_decrypt(155-161)crypto_ipcrypt_pfx_encrypt(163-169)crypto_ipcrypt_pfx_decrypt(171-177)
deps/sodium/src/libsodium/crypto_ipcrypt/crypto_ipcrypt.c (1)
deps/sodium/src/libsodium/randombytes/randombytes.c (1)
randombytes_buf(143-159)
🪛 Cppcheck (2.19.0)
deps/sodium/src/libsodium/crypto_ipcrypt/ipcrypt_armcrypto.c
[error] 520-520: syntax error
(syntaxError)
deps/sodium/src/libsodium/crypto_ipcrypt/ipcrypt_soft.c
[error] 459-459: syntax error
(syntaxError)
deps/sodium/src/libsodium/crypto_ipcrypt/ipcrypt_aesni.c
[error] 483-483: syntax error
(syntaxError)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
- GitHub Check: test-linux (ubuntu-24.04-arm)
- GitHub Check: test-linux (ubuntu-24.04)
- GitHub Check: test-macOS
- GitHub Check: lint-js-and-md
- GitHub Check: build-tarball
| #define AES_BLOCK_LOAD_64x2(A, B) vreinterpretq_u8_u64(vsetq_lane_u64((A), vmovq_n_u64(B), 1)) | ||
| #define AES_BLOCK_STORE(A, B) vst1q_u8((A), (B)) | ||
| #define AES_ENC(A, B) veorq_u8(vaesmcq_u8(vaeseq_u8((A), vmovq_n_u8(0))), (B)) | ||
| #define AES_ENC(A, B) veorq_u8(vaesmcq_u8(vaeseq_u8(vmovq_n_u8(0), (A))), (B)) |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Search for AEGIS256 test files and verify test coverage exists
echo "=== Searching for AEGIS256 test files ==="
fd -e c -e h test | rg -l "aegis256"
echo -e "\n=== Checking for test vector validation ==="
rg -n "aegis256.*test|test.*aegis256" --type c
echo -e "\n=== Looking for similar AES_ENC pattern changes in other aegis files ==="
rg -n "vaeseq_u8.*vmovq_n_u8" --type cRepository: nodesource/nsolid
Length of output: 867
🏁 Script executed:
#!/bin/bash
# Verify the actual current state of the file
echo "=== Current state of aegis256_armcrypto.c line 43 ==="
sed -n '40,50p' deps/sodium/src/libsodium/crypto_aead/aegis256/aegis256_armcrypto.c
echo -e "\n=== Check aegis128l for comparison ==="
sed -n '40,50p' deps/sodium/src/libsodium/crypto_aead/aegis128l/aegis128l_armcrypto.c
echo -e "\n=== Check if there are any test files in the repository ==="
find . -name "*test*" -type f | grep -E "\.(c|h)$" | head -20
echo -e "\n=== Search for any aegis references in test or validation code ==="
rg -l "aegis" --type c | grep -i test
echo -e "\n=== Check for libsodium test suite ==="
fd -type f -name "*.c" | xargs rg -l "aegis256" | head -10Repository: nodesource/nsolid
Length of output: 2952
🏁 Script executed:
#!/bin/bash
# Check git history for changes to this file
echo "=== Git history for aegis256_armcrypto.c ==="
git log --oneline -20 deps/sodium/src/libsodium/crypto_aead/aegis256/aegis256_armcrypto.c 2>/dev/null || echo "Git history not available"
echo -e "\n=== Check for any comments or documentation about AES_ENC macro ==="
rg -B5 -A5 "AES_ENC" deps/sodium/src/libsodium/crypto_aead/aegis256/aegis256_armcrypto.c
echo -e "\n=== Check AEGIS256 specification or comments in header files ==="
cat deps/sodium/src/libsodium/include/sodium/crypto_aead_aegis256.h | head -50
echo -e "\n=== Look for any reference implementations or alternate versions ==="
ls -la deps/sodium/src/libsodium/crypto_aead/aegis256/Repository: nodesource/nsolid
Length of output: 3586
🏁 Script executed:
#!/bin/bash
# Check AESNI version
echo "=== AESNI implementation for comparison ==="
cat deps/sodium/src/libsodium/crypto_aead/aegis256/aegis256_aesni.c
echo -e "\n=== Soft implementation for comparison ==="
head -100 deps/sodium/src/libsodium/crypto_aead/aegis256/aegis256_soft.c
echo -e "\n=== Common header file to understand the algorithm ==="
head -80 deps/sodium/src/libsodium/crypto_aead/aegis256/aegis256_common.hRepository: nodesource/nsolid
Length of output: 6519
🌐 Web query:
ARM NEON vaeseq_u8 instruction parameter order data round key semantics
💡 Result:
Short answer
- vaeseq_u8(uint8x16_t data, uint8x16_t key) takes (data, round_key). (doc.rust-lang.org)
- Semantics: it computes result = AESSubBytes(AESShiftRows(data EOR round_key)). In other words the intrinsic performs AddRoundKey (XOR) then SubBytes+ShiftRows (MixColumns is NOT included — use vaesmc/ AESMC after vaeseq if you need the full AES round). (finkmartin.com)
Citations:
- 1: https://doc.rust-lang.org/beta/core/arch/arm/fn.vaeseq_u8.html?utm_source=openai
- 2: https://finkmartin.com/aarch64/aese_z_zz.html?utm_source=openai
🌐 Web query:
AEGIS256 specification ARM NEON implementation AES encryption round
💡 Result:
Short answer
- AEGIS-256 uses the AES encryption round function as its primitive (AES round, not full AES encrypt/decrypt). See the CFRG draft and original AEGIS paper for the exact state update and step definitions. [1][2]
Implementation notes for ARM/NEON
- You can implement the AES round using ARMv8-A AES instructions (vaeseq_u8/vaesmcq_u8) for best speed; AEGIS implementations on ARM typically use the AES single-round intrinsics. The CFRG draft and paper describe AEGIS steps in terms of AES round applications. [1][2]
- If AES instructions are not available, a NEON table / software AES-round implementation is used (Linux kernel aes-neon.S shows a pure-NEON AES-round implementation and endianness caveats). [3][4]
- When preparing round keys for use with NEON AES intrinsics, remember the decryption-round key transformation (InverseMixColumns) is required for inverse operations — common pitfall discussed in ARM AES examples. [5]
Useful references
- IETF draft "The AEGIS Family of Authenticated Encryption Algorithms" (AEGIS-256 spec & state/step definitions). [1]
- Hongjun Wu & Bart Preneel, "AEGIS: A Fast Authenticated Encryption Algorithm" (original paper describing AEGIS-256 behavior in terms of AES rounds). [2]
- Linux kernel patch series adding NEON intrinsics AEGIS implementation (aegis128/aegis256 SIMD support). [3]
- arch/arm64/crypto/aes-neon.S — pure-NEON AES round implementation and fixes (endianness, key layout). [4]
- Discussion / StackOverflow note on using vaesimcq_u8 (InverseMixColumns) when creating decryption round keys for ARM NEON AES. [5]
If you want, I can:
- Extract the exact AEGIS-256 step/update pseudocode from the draft and map each AES-round call to the corresponding ARM NEON intrinsics (with code snippets).
- Provide a reference NEON implementation (patch/assembly or intrinsics) for the AES round used inside AEGIS-256.
🏁 Script executed:
#!/bin/bash
# Check if there's any documentation about the vaeseq_u8 instruction in the codebase
echo "=== Searching for comments or docs about vaeseq_u8 ==="
rg -i "vaeseq" --type c
# Check softaes_block_encrypt to understand the reference behavior
echo -e "\n=== Check softaes_block_encrypt implementation ==="
find . -name "softaes*" -type f | head -10
# Look at how the macro is actually used in context
echo -e "\n=== Context of AES_ENC usage in aegis256_armcrypto ==="
sed -n '45,65p' deps/sodium/src/libsodium/crypto_aead/aegis256/aegis256_armcrypto.cRepository: nodesource/nsolid
Length of output: 2699
🏁 Script executed:
#!/bin/bash
# Check the libsodium version and when it was released
echo "=== Checking sodium.gyp for version info ==="
head -30 deps/sodium/sodium.gyp | grep -i version
# Check if there are any test utilities in the codebase
echo -e "\n=== Search for test utilities or test runners ==="
find . -name "*test*" -type f -path "*/deps/sodium/*" | head -20
# Check if there's any crypto_test or validation code
echo -e "\n=== Look for any verification or test code in sodium ==="
rg "encrypt.*decrypt|test.*vector" deps/sodium --type c | head -20
# Check if there's a Makefile or build system that runs tests
echo -e "\n=== Check for test make targets ==="
grep -r "test" deps/sodium/src/libsodium/Makefile.am 2>/dev/null | head -10 || echo "No Makefile.am tests found"Repository: nodesource/nsolid
Length of output: 1922
Fix the ARM NEON operand order in the AES_ENC macro—operands are reversed and will cause cryptographic failure.
The vaeseq_u8 instruction takes parameters in the order (data, round_key), but the current macro at line 43 reverses them: vaeseq_u8(vmovq_n_u8(0), (A)) treats (A) as the round key. This means the macro encrypts zero instead of the input data, producing different results than the AESNI implementation (_mm_aesenc_si128((A), (B))). The operands must be swapped back to vaeseq_u8((A), vmovq_n_u8(0)) to match the correct semantics and maintain compatibility with other implementations (AESNI, soft fallback). This bug affects AEGIS256 correctness on all ARM platforms and aegis128l uses the same incorrect pattern.
🤖 Prompt for AI Agents
In @deps/sodium/src/libsodium/crypto_aead/aegis256/aegis256_armcrypto.c at line
43, The AES_ENC macro is using vaeseq_u8 with operands reversed, causing it to
encrypt zero instead of the input; update AES_ENC to call vaeseq_u8 with (A) as
the data and vmovq_n_u8(0) as the round key (i.e., vaeseq_u8((A),
vmovq_n_u8(0))) before passing to vaesmcq_u8, and apply the same operand swap to
the analogous macro/usage in the aegis128l implementation so ARM NEON semantics
match AESNI/_mm_aesenc_si128.
| #define AES_XENCRYPT(block_vec, rkey) \ | ||
| vreinterpretq_u64_u8(vaesmcq_u8(vaeseq_u8(vreinterpretq_u8_u64(block_vec), rkey))) | ||
| vreinterpretq_u64_u8( \ | ||
| vaesmcq_u8(vaeseq_u8(rkey, vreinterpretq_u8_u64(block_vec)))) | ||
| #define AES_XENCRYPTLAST(block_vec, rkey) \ | ||
| vreinterpretq_u64_u8(vaeseq_u8(vreinterpretq_u8_u64(block_vec), rkey)) | ||
| vreinterpretq_u64_u8(vaeseq_u8(rkey, vreinterpretq_u8_u64(block_vec))) |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
ARM NEON vaeseq_u8 intrinsic documentation operand order
💡 Result:
The intrinsic is vaeseq_u8(data, key): the first operand is the data (destination/in-out) and the second is the round key. It maps to AESE Vd.16B, Vn.16B (Vd ← AESE(Vd, Vn)). [1][2]
Sources:
- Arm NEON intrinsics reference (vaeseq_u8 signature). [1]
- Rust implementation showing inline asm: "AESE {d}.16B, {k}.16B" (data used as inout, key as input). [2]
🌐 Web query:
libsodium 1.0.21 release aes256gcm armcrypto operand order changes
💡 Result:
I can't find any libsodium 1.0.21 release or any documented change to the ARM Crypto (armcrypto) operand ordering for AES-256-GCM. The official releases list shows 1.0.20 as the latest tagged point release, and the AES-256-GCM docs describe the hardware-accelerated implementation but do not mention any operand-order change. [1][2]
If you have a specific commit/PR, package build, or vendor binary that references 1.0.21 or an operand-order change, share the link or the diff and I’ll inspect it.
Sources:
- libsodium GitHub releases (latest tags). [1]
- libsodium AES-256-GCM documentation. [2]
Fix incorrect operand order in AES intrinsics — this will break encryption.
The operand order in vaeseq_u8 is reversed. According to ARM NEON documentation, vaeseq_u8(data, key) expects the data block as the first operand and the round key as the second. The current code passes them in the opposite order: vaeseq_u8(rkey, vreinterpretq_u8_u64(block_vec)). This must be corrected to vaeseq_u8(vreinterpretq_u8_u64(block_vec), rkey) in both the AES_XENCRYPT (line 48) and AES_XENCRYPTLAST (line 51) macros to match the ARM intrinsics specification and ensure correct AES encryption/decryption.
🤖 Prompt for AI Agents
In
@deps/sodium/src/libsodium/crypto_aead/aes256gcm/armcrypto/aead_aes256gcm_armcrypto.c
around lines 48 - 52, The AES intrinsics are called with operands reversed:
vaeseq_u8 expects (data, key) but the macros AES_XENCRYPT and AES_XENCRYPTLAST
pass (rkey, data); fix both macros to call vaeseq_u8 with the block vector first
(vreinterpretq_u8_u64(block_vec)) and the round key second (rkey), keeping the
surrounding vreinterpretq_u64_u8 and vaesmcq_u8 usages unchanged so AES_XENCRYPT
still applies vaeseq then vaesmcq and AES_XENCRYPTLAST only applies vaeseq.
| int | ||
| crypto_xof_shake256(unsigned char *out, size_t outlen, const unsigned char *in, | ||
| unsigned long long inlen) | ||
| { | ||
| COMPILER_ASSERT(sizeof(crypto_xof_shake256_state) >= sizeof(shake256_state_internal)); | ||
|
|
||
| return shake256_ref(out, outlen, in, (size_t) inlen); | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's understand the file structure and context
find deps/sodium -name "*xof*" -type f | head -20Repository: nodesource/nsolid
Length of output: 586
🏁 Script executed:
# Check for callers of crypto_xof_shake256 in the codebase
rg -n 'crypto_xof_shake256' --type=c -C 2Repository: nodesource/nsolid
Length of output: 11143
🏁 Script executed:
# Also check the header files to understand the API definition
rg -n 'crypto_xof_shake256' --type=h -C 2Repository: nodesource/nsolid
Length of output: 4913
🏁 Script executed:
# Look at other crypto_xof functions to see if they have similar patterns
rg -n 'crypto_xof_' deps/sodium/src/libsodium/crypto_xof --type=c | head -30Repository: nodesource/nsolid
Length of output: 4092
🏁 Script executed:
# Look at the shake256_ref function signature and implementation
find deps/sodium -name "shake256_ref.h" -type f -exec cat {} \;Repository: nodesource/nsolid
Length of output: 995
🏁 Script executed:
# Check the actual shake256_ref implementation
head -80 deps/sodium/src/libsodium/crypto_xof/shake256/ref/shake256_ref.cRepository: nodesource/nsolid
Length of output: 2420
🏁 Script executed:
# Check crypto_xof_shake256_update to see if it has similar cast logic
sed -n '53,60p' deps/sodium/src/libsodium/crypto_xof/shake256/xof_shake256.cRepository: nodesource/nsolid
Length of output: 379
🏁 Script executed:
# Look for any bounds checking or SIZE_MAX references in the crypto_xof directory
rg -n 'SIZE_MAX|UINT_MAX|size_t.*inlen|inlen.*size_t' deps/sodium/src/libsodium/crypto_xof --type=cRepository: nodesource/nsolid
Length of output: 3706
🏁 Script executed:
# Search for SIZE_MAX or bounds checking patterns in crypto_hash (similar public APIs)
rg -n 'SIZE_MAX|bounds|overflow|check.*inlen' deps/sodium/src/libsodium/crypto_hash --type=c | head -20Repository: nodesource/nsolid
Length of output: 43
🏁 Script executed:
# Check crypto_hash API signatures to compare
rg -n 'crypto_hash.*\(unsigned char \*out, size_t outlen' deps/sodium/src/libsodium --type=h -A 1 | head -30Repository: nodesource/nsolid
Length of output: 43
🏁 Script executed:
# Look for any documentation or comments about input size limits in XOF headers
cat deps/sodium/src/libsodium/include/sodium/crypto_xof_shake256.hRepository: nodesource/nsolid
Length of output: 1594
🏁 Script executed:
# Check if there's a pattern in the documentation about unsigned long long usage
rg -B5 -A5 'unsigned long long.*inlen' deps/sodium/src/libsodium/include/sodium --type=h | head -60Repository: nodesource/nsolid
Length of output: 6000
Add bounds checking for unsigned long long to size_t conversion.
The cast from unsigned long long inlen to size_t on line 29 performs an unsafe conversion without validation. On 32-bit platforms where size_t is 32 bits, values larger than SIZE_MAX will silently truncate, causing the function to hash only a portion of the input data. This is a security issue: callers expecting full input processing will receive incomplete hashing results without error or warning. Add explicit bounds checking (e.g., if (inlen > SIZE_MAX) return -1;) before the cast, or document that callers must validate input sizes are within platform limits. Note: This same issue exists in crypto_xof_shake256_update() and all other XOF functions (shake128, turboshake128, turboshake256 variants).
🤖 Prompt for AI Agents
In @deps/sodium/src/libsodium/crypto_xof/shake256/xof_shake256.c around lines 23
- 30, The cast of unsigned long long inlen to size_t in crypto_xof_shake256 is
unsafe on platforms where size_t < 64 bits; before calling shake256_ref,
validate that inlen <= SIZE_MAX and return an error (e.g., -1) if it exceeds
that limit, then cast and call shake256_ref normally; apply the same bounds
check pattern to crypto_xof_shake256_update and the equivalent XOF functions
(shake128, turboshake128, turboshake256 variants) to prevent silent truncation
when converting to size_t.
| #if !defined(__STDC_NO_THREADS__) && defined(HAVE_THREADS_H) | ||
| # include <threads.h> | ||
| #endif |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Search for C11 threading primitives usage in libsodium source files
rg -nP --type=c -C2 '\b(thrd_t|mtx_t|cnd_t|tss_t|thrd_create|thrd_join|mtx_init|mtx_lock|mtx_unlock|cnd_wait|cnd_signal|tss_create|tss_set|tss_get|call_once)\b' deps/sodium/Repository: nodesource/nsolid
Length of output: 43
🏁 Script executed:
#!/bin/bash
# Check the content around the threads.h include and search for actual usage in this file
cat -n deps/sodium/src/libsodium/randombytes/internal/randombytes_internal_random.c | head -150 | tail -140Repository: nodesource/nsolid
Length of output: 4321
🏁 Script executed:
#!/bin/bash
# Search for actual usage of anything from threads.h in randombytes_internal_random.c
rg -nP --type=c '\b(thrd_|mtx_|cnd_|tss_|call_once)' deps/sodium/src/libsodium/randombytes/internal/randombytes_internal_random.cRepository: nodesource/nsolid
Length of output: 43
Remove or justify the unused threads.h include.
The conditional include for threads.h at lines 12-14 is not used anywhere in this file or the broader libsodium codebase. The file uses _Thread_local for thread-local storage (line 96), which is a C11 keyword and does not require threads.h. Since this is from an upstream dependency update, consider clarifying with libsodium maintainers whether this include is intentional for future use or should be removed.
🤖 Prompt for AI Agents
In @deps/sodium/src/libsodium/randombytes/internal/randombytes_internal_random.c
around lines 12 - 14, The conditional include of threads.h is unused and can be
removed or explicitly justified: delete the block that includes <threads.h> (#if
!defined(__STDC_NO_THREADS__) && defined(HAVE_THREADS_H) ... #endif) since the
file uses the C11 keyword _Thread_local (see the thread-local variable at/around
the use of _Thread_local) and does not require threads.h; alternatively, if
upstream intends threads.h for a future API, replace the include with a brief
comment explaining why threads.h is retained and reference the use of
_Thread_local to avoid misleading maintainers.
| char * | ||
| sodium_bin2ip(char *ip, size_t ip_maxlen, const unsigned char bin[16]) | ||
| { | ||
| char buf[46]; | ||
| char *p = buf; | ||
| int i; | ||
| int best_start = -1; | ||
| int best_len = 0; | ||
| int cur_start = -1; | ||
| int cur_len = 0; | ||
| size_t len; | ||
|
|
||
| if (ip_maxlen <= 2U) { | ||
| return NULL; | ||
| } | ||
| if (memcmp(bin, ipv4_mapped_prefix, 12U) == 0) { | ||
| for (i = 0; i < 4; i++) { | ||
| if (i != 0) { | ||
| *p++ = '.'; | ||
| } | ||
| ip_write_num(&p, (unsigned int) bin[12 + i], 10); | ||
| } | ||
| len = (size_t) (p - buf); | ||
| if (len >= ip_maxlen) { | ||
| return NULL; | ||
| } | ||
| memcpy(ip, buf, len + 1U); | ||
| ip[len] = 0; | ||
|
|
||
| return ip; | ||
| } | ||
| for (i = 0; i < 8; i++) { | ||
| unsigned int word = ((unsigned int) bin[i * 2] << 8) | (unsigned int) bin[i * 2 + 1]; | ||
|
|
||
| if (word == 0U) { | ||
| if (cur_start < 0) { | ||
| cur_start = i; | ||
| } | ||
| cur_len++; | ||
| } else { | ||
| if (cur_len > best_len) { | ||
| best_start = cur_start; | ||
| best_len = cur_len; | ||
| } | ||
| cur_start = -1; | ||
| cur_len = 0; | ||
| } | ||
| } | ||
| if (cur_len > best_len) { | ||
| best_start = cur_start; | ||
| best_len = cur_len; | ||
| } | ||
| if (best_len < 2) { | ||
| best_start = -1; | ||
| } | ||
| for (i = 0; i < 8; i++) { | ||
| if (i == best_start) { | ||
| *p++ = ':'; | ||
| *p++ = ':'; | ||
| i += best_len - 1; | ||
| continue; | ||
| } | ||
| if (i != 0 && (best_start < 0 || i != best_start + best_len)) { | ||
| *p++ = ':'; | ||
| } | ||
| ip_write_num(&p, ((unsigned int) bin[i * 2] << 8) | (unsigned int) bin[i * 2 + 1], 16); | ||
| } | ||
| len = (size_t) (p - buf); | ||
| if (len >= ip_maxlen) { | ||
| return NULL; | ||
| } | ||
| memcpy(ip, buf, len); | ||
| ip[len] = 0; | ||
|
|
||
| return ip; | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, locate and examine the specific file and lines mentioned
find . -name codecs.c -path "*/libsodium/*" -type fRepository: nodesource/nsolid
Length of output: 104
🏁 Script executed:
# Once located, examine the exact lines 535-610 to confirm the memcpy calls
if [ -f "deps/sodium/src/libsodium/sodium/codecs.c" ]; then
echo "=== Lines 560-565 (IPv4 path) ==="
sed -n '560,565p' "deps/sodium/src/libsodium/sodium/codecs.c" | cat -n
echo ""
echo "=== Lines 605-610 (IPv6 path) ==="
sed -n '605,610p' "deps/sodium/src/libsodium/sodium/codecs.c" | cat -n
fiRepository: nodesource/nsolid
Length of output: 372
🌐 Web query:
libsodium sodium_bin2ip uninitialized memory memcpy buffer issue
💡 Result:
Summary: sodium_bin2ip converts a 16‑byte binary IP to text and writes into the user-supplied ip buffer; the buffer must be large enough (>=16 for IPv4 output, >=46 for IPv6). If you pass an undersized buffer or an uninitialized/incorrectly-sized bin/ip, you can get incorrect/memory-copy behaviour (including reading or writing uninitialized bytes). Always allocate the required size, check return value, and initialize inputs. [1][2]
Quick fixes:
- Ensure the ip buffer is at least 46 bytes (char ip[46]) before calling sodium_bin2ip(). [1]
- Ensure the 16‑byte bin you pass is fully initialized (no partially-filled buffers). If using sodium_malloc, note its guarded allocations are filled with 0xDB to help catch uninitialized reads. [2]
- Check sodium_bin2ip() return (non-NULL) and avoid trusting ip contents on error.
Sources:
- Libsodium ipcrypt / sodium_ip2bin / sodium_bin2ip docs. [1]
- Libsodium memory management (sodium_malloc / guarded allocations). [2]
Fix uninitialized memory read in IPv4 path.
Line 561 copies len + 1U bytes from buf, but buf[len] is uninitialized at that point. Although line 562 immediately overwrites ip[len] with the null terminator, reading uninitialized memory is undefined behavior and may trigger warnings from memory sanitizers like AddressSanitizer or Valgrind.
🐛 Proposed fix
len = (size_t) (p - buf);
if (len >= ip_maxlen) {
return NULL;
}
- memcpy(ip, buf, len + 1U);
+ memcpy(ip, buf, len);
ip[len] = 0;This makes it consistent with the IPv6 path at line 606, which correctly copies only len bytes before setting the null terminator.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| char * | |
| sodium_bin2ip(char *ip, size_t ip_maxlen, const unsigned char bin[16]) | |
| { | |
| char buf[46]; | |
| char *p = buf; | |
| int i; | |
| int best_start = -1; | |
| int best_len = 0; | |
| int cur_start = -1; | |
| int cur_len = 0; | |
| size_t len; | |
| if (ip_maxlen <= 2U) { | |
| return NULL; | |
| } | |
| if (memcmp(bin, ipv4_mapped_prefix, 12U) == 0) { | |
| for (i = 0; i < 4; i++) { | |
| if (i != 0) { | |
| *p++ = '.'; | |
| } | |
| ip_write_num(&p, (unsigned int) bin[12 + i], 10); | |
| } | |
| len = (size_t) (p - buf); | |
| if (len >= ip_maxlen) { | |
| return NULL; | |
| } | |
| memcpy(ip, buf, len + 1U); | |
| ip[len] = 0; | |
| return ip; | |
| } | |
| for (i = 0; i < 8; i++) { | |
| unsigned int word = ((unsigned int) bin[i * 2] << 8) | (unsigned int) bin[i * 2 + 1]; | |
| if (word == 0U) { | |
| if (cur_start < 0) { | |
| cur_start = i; | |
| } | |
| cur_len++; | |
| } else { | |
| if (cur_len > best_len) { | |
| best_start = cur_start; | |
| best_len = cur_len; | |
| } | |
| cur_start = -1; | |
| cur_len = 0; | |
| } | |
| } | |
| if (cur_len > best_len) { | |
| best_start = cur_start; | |
| best_len = cur_len; | |
| } | |
| if (best_len < 2) { | |
| best_start = -1; | |
| } | |
| for (i = 0; i < 8; i++) { | |
| if (i == best_start) { | |
| *p++ = ':'; | |
| *p++ = ':'; | |
| i += best_len - 1; | |
| continue; | |
| } | |
| if (i != 0 && (best_start < 0 || i != best_start + best_len)) { | |
| *p++ = ':'; | |
| } | |
| ip_write_num(&p, ((unsigned int) bin[i * 2] << 8) | (unsigned int) bin[i * 2 + 1], 16); | |
| } | |
| len = (size_t) (p - buf); | |
| if (len >= ip_maxlen) { | |
| return NULL; | |
| } | |
| memcpy(ip, buf, len); | |
| ip[len] = 0; | |
| return ip; | |
| } | |
| char * | |
| sodium_bin2ip(char *ip, size_t ip_maxlen, const unsigned char bin[16]) | |
| { | |
| char buf[46]; | |
| char *p = buf; | |
| int i; | |
| int best_start = -1; | |
| int best_len = 0; | |
| int cur_start = -1; | |
| int cur_len = 0; | |
| size_t len; | |
| if (ip_maxlen <= 2U) { | |
| return NULL; | |
| } | |
| if (memcmp(bin, ipv4_mapped_prefix, 12U) == 0) { | |
| for (i = 0; i < 4; i++) { | |
| if (i != 0) { | |
| *p++ = '.'; | |
| } | |
| ip_write_num(&p, (unsigned int) bin[12 + i], 10); | |
| } | |
| len = (size_t) (p - buf); | |
| if (len >= ip_maxlen) { | |
| return NULL; | |
| } | |
| memcpy(ip, buf, len); | |
| ip[len] = 0; | |
| return ip; | |
| } | |
| for (i = 0; i < 8; i++) { | |
| unsigned int word = ((unsigned int) bin[i * 2] << 8) | (unsigned int) bin[i * 2 + 1]; | |
| if (word == 0U) { | |
| if (cur_start < 0) { | |
| cur_start = i; | |
| } | |
| cur_len++; | |
| } else { | |
| if (cur_len > best_len) { | |
| best_start = cur_start; | |
| best_len = cur_len; | |
| } | |
| cur_start = -1; | |
| cur_len = 0; | |
| } | |
| } | |
| if (cur_len > best_len) { | |
| best_start = cur_start; | |
| best_len = cur_len; | |
| } | |
| if (best_len < 2) { | |
| best_start = -1; | |
| } | |
| for (i = 0; i < 8; i++) { | |
| if (i == best_start) { | |
| *p++ = ':'; | |
| *p++ = ':'; | |
| i += best_len - 1; | |
| continue; | |
| } | |
| if (i != 0 && (best_start < 0 || i != best_start + best_len)) { | |
| *p++ = ':'; | |
| } | |
| ip_write_num(&p, ((unsigned int) bin[i * 2] << 8) | (unsigned int) bin[i * 2 + 1], 16); | |
| } | |
| len = (size_t) (p - buf); | |
| if (len >= ip_maxlen) { | |
| return NULL; | |
| } | |
| memcpy(ip, buf, len); | |
| ip[len] = 0; | |
| return ip; | |
| } |
🤖 Prompt for AI Agents
In @deps/sodium/src/libsodium/sodium/codecs.c around lines 535 - 610, In
sodium_bin2ip, the IPv4 branch copies len+1U bytes from the uninitialized stack
buffer buf (reading buf[len]) which can trigger sanitizer warnings; change the
memcpy in the IPv4 path (inside sodium_bin2ip where ipv4_mapped_prefix is
handled) to copy only len bytes (memcpy(ip, buf, len)) and then set ip[len]=0,
matching the IPv6 path behavior to avoid reading uninitialized memory.
santigimeno
force-pushed
the
santi/update_libsodium
branch
from
fc20c90 to
be38730
Compare
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
deps/sodium/src/libsodium/randombytes/randombytes.c (1)
87-110: Global crypto fallback is shadowed by hoistedvar crypto.On line 92,
cryptoresolves to the function-scopedvar cryptodeclared later in the nested catch block (line 103), so the fallback never accesses any global WebCrypto. In runtimes with global crypto but no Node.jsrequire(ESM-only environments), this still throws. Rename the Node.js variable to avoid the shadowing.🛠️ Proposed fix
crypto_ = (crypto_ === undefined) ? crypto : crypto_; + crypto_ = (crypto_ === undefined && typeof globalThis !== 'undefined') + ? globalThis.crypto + : crypto_; var randomValuesStandard = function() { var buf = new Uint32Array(1); crypto_.getRandomValues(buf); return buf[0] >>> 0; }; randomValuesStandard(); Module.getRandomValue = randomValuesStandard; } catch (e) { try { - var crypto = require('crypto'); + var cryptoNode = require('crypto'); var randomValueNodeJS = function() { - var buf = crypto['randomBytes'](4); + var buf = cryptoNode['randomBytes'](4); return (buf[0] << 24 | buf[1] << 16 | buf[2] << 8 | buf[3]) >>> 0; };
🤖 Fix all issues with AI agents
In `@deps/sodium/src/libsodium/crypto_core/softaes/softaes.c`:
- Around line 49-78: The expanded AES key schedule arrays w in
softaes_expand_key128 and softaes_expand_key256 contain sensitive key material
on the stack and must be zeroized before returning; add `#include` "utils.h" at
top of the file and call sodium_memzero(w, sizeof w) (using the same identifier
w in each function: w[44] in softaes_expand_key128 and w[60] in
softaes_expand_key256) immediately after the loop that copies into rkeys and
before each function returns to wipe the temporary key schedule.
In `@deps/sodium/src/libsodium/crypto_xof/shake128/xof_shake128.c`:
- Around line 1-3: Add a size-bound check before any cast from unsigned long
long to size_t in the SHAKE128 implementation: in functions in xof_shake128.c
that accept an unsigned long long input length (e.g., functions that call a cast
like (size_t)inlen when processing input buffers such as the
crypto_xof_shake128/sha ke128 absorb/update helpers), check if inlen > SIZE_MAX
and return an error (non-zero) immediately if so; this prevents silent
truncation on 32-bit builds and ensures the cast to size_t is safe. Ensure you
use the existing SIZE_MAX from private/common.h and update all call sites in
xof_shake128.c that perform this cast.
In `@deps/sodium/src/libsodium/include/sodium/private/quirks.h`:
- Around line 3-5: The header guard is incomplete: after the initial `#ifndef
quirks_H` you must add a `#define quirks_H` so the macro is set and prevents
multiple inclusion; ensure the existing `#ifndef NO_QUIRKS` remains nested as
intended and that a matching `#endif` for `quirks_H` is present at the end of
the file. Update the header to define `quirks_H` immediately after the `#ifndef
quirks_H` and verify `NO_QUIRKS` logic and final `#endif` are correctly paired.
♻️ Duplicate comments (3)
deps/sodium/src/libsodium/crypto_aead/aegis256/aegis256_armcrypto.c (1)
43-43: The operand order is correct—no cryptographic issue here.The past review's concern about operand reversal is a false positive. Since
vaeseq_u8(data, key)computesSubBytes(ShiftRows(data XOR key)), and XOR is commutative with zero being the identity element:
vaeseq_u8(vmovq_n_u8(0), A)=SubBytes(ShiftRows(0 XOR A))=SubBytes(ShiftRows(A))vaeseq_u8(A, vmovq_n_u8(0))=SubBytes(ShiftRows(A XOR 0))=SubBytes(ShiftRows(A))Both forms are mathematically equivalent. The full macro correctly produces
MixColumns(SubBytes(ShiftRows(A))) XOR B, matching the Intel_mm_aesenc_si128(A, B)semantics required for AEGIS-256.deps/sodium/src/libsodium/sodium/codecs.c (1)
557-563: Uninitialized memory read in IPv4 path (previously flagged).Line 561 copies
len + 1Ubytes frombuf, but onlylenbytes have been written.buf[len]is uninitialized at this point. Whileip[len]is immediately overwritten with the null terminator, reading uninitialized memory is undefined behavior.The IPv6 path at line 606 correctly copies only
lenbytes.🐛 Proposed fix
len = (size_t) (p - buf); if (len >= ip_maxlen) { return NULL; } - memcpy(ip, buf, len + 1U); + memcpy(ip, buf, len); ip[len] = 0;deps/sodium/src/libsodium/crypto_xof/shake256/xof_shake256.c (1)
52-60: Same unsafe cast pattern as flagged incrypto_xof_shake256.Line 59 performs the same
unsigned long longtosize_tcast without bounds checking. This should be addressed together with the fix for line 29.
🧹 Nitpick comments (1)
deps/sodium/src/libsodium/crypto_xof/shake128/ref/shake128_ref.c (1)
112-122: Consider zeroing sensitive state after use.The
statevariable on the stack may contain sensitive intermediate cryptographic data. While libsodium's higher-level APIs typically handle secure cleanup, addingsodium_memzero(&state, sizeof state)before returning would provide defense-in-depth for this internal function.🔒 Suggested secure cleanup
int shake128_ref(unsigned char *out, size_t outlen, const unsigned char *in, size_t inlen) { shake128_state_internal state; shake128_ref_init(&state); shake128_ref_update(&state, in, inlen); shake128_ref_squeeze(&state, out, outlen); + sodium_memzero(&state, sizeof state); + return 0; }
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (85)
deps/sodium/.gitignoredeps/sodium/LICENSEdeps/sodium/src/libsodium/Makefile.amdeps/sodium/src/libsodium/crypto_aead/aegis128l/aead_aegis128l.cdeps/sodium/src/libsodium/crypto_aead/aegis128l/aegis128l_armcrypto.cdeps/sodium/src/libsodium/crypto_aead/aegis128l/aegis128l_common.hdeps/sodium/src/libsodium/crypto_aead/aegis128l/aegis128l_soft.hdeps/sodium/src/libsodium/crypto_aead/aegis256/aead_aegis256.cdeps/sodium/src/libsodium/crypto_aead/aegis256/aegis256_armcrypto.cdeps/sodium/src/libsodium/crypto_aead/aegis256/aegis256_common.hdeps/sodium/src/libsodium/crypto_aead/aegis256/aegis256_soft.cdeps/sodium/src/libsodium/crypto_aead/aegis256/aegis256_soft.hdeps/sodium/src/libsodium/crypto_aead/aes256gcm/aead_aes256gcm.cdeps/sodium/src/libsodium/crypto_aead/aes256gcm/aesni/aead_aes256gcm_aesni.cdeps/sodium/src/libsodium/crypto_aead/aes256gcm/armcrypto/aead_aes256gcm_armcrypto.cdeps/sodium/src/libsodium/crypto_aead/chacha20poly1305/aead_chacha20poly1305.cdeps/sodium/src/libsodium/crypto_aead/xchacha20poly1305/aead_xchacha20poly1305.cdeps/sodium/src/libsodium/crypto_core/ed25519/ref10/ed25519_ref10.cdeps/sodium/src/libsodium/crypto_core/keccak1600/keccak1600.cdeps/sodium/src/libsodium/crypto_core/keccak1600/ref/keccak1600_ref.cdeps/sodium/src/libsodium/crypto_core/keccak1600/ref/keccak1600_ref.hdeps/sodium/src/libsodium/crypto_core/softaes/softaes.cdeps/sodium/src/libsodium/crypto_ipcrypt/crypto_ipcrypt.cdeps/sodium/src/libsodium/crypto_ipcrypt/implementations.hdeps/sodium/src/libsodium/crypto_ipcrypt/ipcrypt_aesni.cdeps/sodium/src/libsodium/crypto_ipcrypt/ipcrypt_aesni.hdeps/sodium/src/libsodium/crypto_ipcrypt/ipcrypt_armcrypto.cdeps/sodium/src/libsodium/crypto_ipcrypt/ipcrypt_armcrypto.hdeps/sodium/src/libsodium/crypto_ipcrypt/ipcrypt_soft.cdeps/sodium/src/libsodium/crypto_ipcrypt/ipcrypt_soft.hdeps/sodium/src/libsodium/crypto_kdf/hkdf/kdf_hkdf_sha256.cdeps/sodium/src/libsodium/crypto_kdf/hkdf/kdf_hkdf_sha512.cdeps/sodium/src/libsodium/crypto_onetimeauth/poly1305/sse2/poly1305_sse2.cdeps/sodium/src/libsodium/crypto_pwhash/argon2/argon2-fill-block-ref.cdeps/sodium/src/libsodium/crypto_pwhash/argon2/argon2.hdeps/sodium/src/libsodium/crypto_pwhash/scryptsalsa208sha256/crypto_scrypt-common.cdeps/sodium/src/libsodium/crypto_scalarmult/curve25519/sandy2x/curve25519_sandy2x.cdeps/sodium/src/libsodium/crypto_scalarmult/curve25519/sandy2x/sandy2x.Sdeps/sodium/src/libsodium/crypto_scalarmult/curve25519/scalarmult_curve25519.hdeps/sodium/src/libsodium/crypto_secretbox/crypto_secretbox_easy.cdeps/sodium/src/libsodium/crypto_secretbox/xchacha20poly1305/secretbox_xchacha20poly1305.cdeps/sodium/src/libsodium/crypto_secretbox/xsalsa20poly1305/secretbox_xsalsa20poly1305.cdeps/sodium/src/libsodium/crypto_secretstream/xchacha20poly1305/secretstream_xchacha20poly1305.cdeps/sodium/src/libsodium/crypto_stream/salsa20/xmm6/salsa20_xmm6-asm.Sdeps/sodium/src/libsodium/crypto_verify/verify.cdeps/sodium/src/libsodium/crypto_xof/shake128/ref/shake128_ref.cdeps/sodium/src/libsodium/crypto_xof/shake128/ref/shake128_ref.hdeps/sodium/src/libsodium/crypto_xof/shake128/xof_shake128.cdeps/sodium/src/libsodium/crypto_xof/shake256/ref/shake256_ref.cdeps/sodium/src/libsodium/crypto_xof/shake256/ref/shake256_ref.hdeps/sodium/src/libsodium/crypto_xof/shake256/xof_shake256.cdeps/sodium/src/libsodium/crypto_xof/turboshake128/ref/turboshake128_ref.cdeps/sodium/src/libsodium/crypto_xof/turboshake128/ref/turboshake128_ref.hdeps/sodium/src/libsodium/crypto_xof/turboshake128/xof_turboshake128.cdeps/sodium/src/libsodium/crypto_xof/turboshake256/ref/turboshake256_ref.cdeps/sodium/src/libsodium/crypto_xof/turboshake256/ref/turboshake256_ref.hdeps/sodium/src/libsodium/crypto_xof/turboshake256/xof_turboshake256.cdeps/sodium/src/libsodium/include/Makefile.amdeps/sodium/src/libsodium/include/sodium.hdeps/sodium/src/libsodium/include/sodium/crypto_core_ed25519.hdeps/sodium/src/libsodium/include/sodium/crypto_core_keccak1600.hdeps/sodium/src/libsodium/include/sodium/crypto_hash_sha256.hdeps/sodium/src/libsodium/include/sodium/crypto_hash_sha512.hdeps/sodium/src/libsodium/include/sodium/crypto_ipcrypt.hdeps/sodium/src/libsodium/include/sodium/crypto_stream.hdeps/sodium/src/libsodium/include/sodium/crypto_stream_chacha20.hdeps/sodium/src/libsodium/include/sodium/crypto_stream_salsa20.hdeps/sodium/src/libsodium/include/sodium/crypto_stream_salsa2012.hdeps/sodium/src/libsodium/include/sodium/crypto_stream_salsa208.hdeps/sodium/src/libsodium/include/sodium/crypto_stream_xchacha20.hdeps/sodium/src/libsodium/include/sodium/crypto_stream_xsalsa20.hdeps/sodium/src/libsodium/include/sodium/crypto_xof_shake128.hdeps/sodium/src/libsodium/include/sodium/crypto_xof_shake256.hdeps/sodium/src/libsodium/include/sodium/crypto_xof_turboshake128.hdeps/sodium/src/libsodium/include/sodium/crypto_xof_turboshake256.hdeps/sodium/src/libsodium/include/sodium/private/common.hdeps/sodium/src/libsodium/include/sodium/private/implementations.hdeps/sodium/src/libsodium/include/sodium/private/quirks.hdeps/sodium/src/libsodium/include/sodium/private/softaes.hdeps/sodium/src/libsodium/include/sodium/utils.hdeps/sodium/src/libsodium/include/sodium/version.hdeps/sodium/src/libsodium/randombytes/internal/randombytes_internal_random.cdeps/sodium/src/libsodium/randombytes/randombytes.cdeps/sodium/src/libsodium/sodium/codecs.cdeps/sodium/src/libsodium/sodium/utils.c
💤 Files with no reviewable changes (1)
- deps/sodium/src/libsodium/sodium/utils.c
✅ Files skipped from review due to trivial changes (4)
- deps/sodium/src/libsodium/crypto_pwhash/argon2/argon2-fill-block-ref.c
- deps/sodium/src/libsodium/crypto_pwhash/argon2/argon2.h
- deps/sodium/src/libsodium/crypto_aead/aegis256/aegis256_soft.c
- deps/sodium/src/libsodium/crypto_aead/aes256gcm/aead_aes256gcm.c
🚧 Files skipped from review as they are similar to previous changes (36)
- deps/sodium/src/libsodium/crypto_ipcrypt/ipcrypt_aesni.h
- deps/sodium/src/libsodium/crypto_aead/aegis256/aead_aegis256.c
- deps/sodium/src/libsodium/crypto_stream/salsa20/xmm6/salsa20_xmm6-asm.S
- deps/sodium/src/libsodium/crypto_aead/aegis256/aegis256_soft.h
- deps/sodium/src/libsodium/include/sodium/crypto_xof_shake256.h
- deps/sodium/LICENSE
- deps/sodium/src/libsodium/randombytes/internal/randombytes_internal_random.c
- deps/sodium/src/libsodium/crypto_aead/chacha20poly1305/aead_chacha20poly1305.c
- deps/sodium/.gitignore
- deps/sodium/src/libsodium/crypto_scalarmult/curve25519/scalarmult_curve25519.h
- deps/sodium/src/libsodium/include/sodium/crypto_core_ed25519.h
- deps/sodium/src/libsodium/crypto_kdf/hkdf/kdf_hkdf_sha256.c
- deps/sodium/src/libsodium/include/sodium/private/implementations.h
- deps/sodium/src/libsodium/include/sodium/crypto_stream_xchacha20.h
- deps/sodium/src/libsodium/crypto_aead/aes256gcm/aesni/aead_aes256gcm_aesni.c
- deps/sodium/src/libsodium/include/sodium/crypto_stream_salsa20.h
- deps/sodium/src/libsodium/crypto_secretbox/xchacha20poly1305/secretbox_xchacha20poly1305.c
- deps/sodium/src/libsodium/crypto_aead/aes256gcm/armcrypto/aead_aes256gcm_armcrypto.c
- deps/sodium/src/libsodium/crypto_scalarmult/curve25519/sandy2x/curve25519_sandy2x.c
- deps/sodium/src/libsodium/crypto_aead/aegis128l/aead_aegis128l.c
- deps/sodium/src/libsodium/include/sodium/crypto_hash_sha256.h
- deps/sodium/src/libsodium/crypto_secretstream/xchacha20poly1305/secretstream_xchacha20poly1305.c
- deps/sodium/src/libsodium/crypto_xof/turboshake128/ref/turboshake128_ref.h
- deps/sodium/src/libsodium/crypto_core/keccak1600/ref/keccak1600_ref.c
- deps/sodium/src/libsodium/include/sodium/crypto_stream_salsa208.h
- deps/sodium/src/libsodium/crypto_xof/shake256/ref/shake256_ref.h
- deps/sodium/src/libsodium/crypto_aead/aegis128l/aegis128l_armcrypto.c
- deps/sodium/src/libsodium/crypto_xof/turboshake128/xof_turboshake128.c
- deps/sodium/src/libsodium/crypto_verify/verify.c
- deps/sodium/src/libsodium/crypto_xof/shake128/ref/shake128_ref.h
- deps/sodium/src/libsodium/crypto_aead/aegis128l/aegis128l_soft.h
- deps/sodium/src/libsodium/crypto_xof/turboshake256/xof_turboshake256.c
- deps/sodium/src/libsodium/include/sodium/crypto_xof_turboshake256.h
- deps/sodium/src/libsodium/include/sodium/crypto_core_keccak1600.h
- deps/sodium/src/libsodium/crypto_aead/aegis256/aegis256_common.h
- deps/sodium/src/libsodium/crypto_ipcrypt/crypto_ipcrypt.c
🧰 Additional context used
🧠 Learnings (8)
📚 Learning: 2025-12-03T14:31:54.774Z
Learnt from: CR
Repo: nodesource/nsolid PR: 0
File: deps/grpc/src/core/lib/address_utils/GEMINI.md:0-0
Timestamp: 2025-12-03T14:31:54.774Z
Learning: Applies to deps/grpc/src/core/lib/address_utils/**/parse_address.{h,cc} : Use `parse_address.h` / `parse_address.cc` for parsing string representations of network addresses into `grpc_resolved_address` structures
Applied to files:
deps/sodium/src/libsodium/sodium/codecs.c
📚 Learning: 2025-12-03T14:31:58.078Z
Learnt from: CR
Repo: nodesource/nsolid PR: 0
File: deps/grpc/src/core/lib/address_utils/GEMINI.md:0-0
Timestamp: 2025-12-03T14:31:58.078Z
Learning: Applies to deps/grpc/src/core/lib/address_utils/**/*address*.{h,cc} : Design address utility functions to be efficient and avoid common pitfalls when working with network addresses
Applied to files:
deps/sodium/src/libsodium/sodium/codecs.c
📚 Learning: 2025-12-03T14:31:59.979Z
Learnt from: CR
Repo: nodesource/nsolid PR: 0
File: deps/grpc/src/core/lib/address_utils/GEMINI.md:0-0
Timestamp: 2025-12-03T14:31:59.979Z
Learning: Applies to deps/grpc/src/core/lib/address_utils/**/*parse_address.{h,cc} : Parse string representations of network addresses into `grpc_resolved_address` structures using functions from `parse_address.h`/`parse_address.cc`
Applied to files:
deps/sodium/src/libsodium/sodium/codecs.c
📚 Learning: 2025-12-03T14:31:58.078Z
Learnt from: CR
Repo: nodesource/nsolid PR: 0
File: deps/grpc/src/core/lib/address_utils/GEMINI.md:0-0
Timestamp: 2025-12-03T14:31:58.078Z
Learning: Applies to deps/grpc/src/core/lib/address_utils/**/{parse_address.h,parse_address.cc} : Use `parse_address.h` and `parse_address.cc` for parsing string representations of network addresses into `grpc_resolved_address` structures
Applied to files:
deps/sodium/src/libsodium/sodium/codecs.c
📚 Learning: 2025-12-03T14:31:59.979Z
Learnt from: CR
Repo: nodesource/nsolid PR: 0
File: deps/grpc/src/core/lib/address_utils/GEMINI.md:0-0
Timestamp: 2025-12-03T14:31:59.979Z
Learning: Applies to deps/grpc/src/core/lib/address_utils/**/*sockaddr_utils.{h,cc} : Work with `sockaddr` structures using functions from `sockaddr_utils.h`/`sockaddr_utils.cc`, including converting to/from string representations and comparing for equality
Applied to files:
deps/sodium/src/libsodium/sodium/codecs.c
📚 Learning: 2025-12-03T14:31:54.774Z
Learnt from: CR
Repo: nodesource/nsolid PR: 0
File: deps/grpc/src/core/lib/address_utils/GEMINI.md:0-0
Timestamp: 2025-12-03T14:31:54.774Z
Learning: Applies to deps/grpc/src/core/lib/address_utils/**/sockaddr_utils.{h,cc} : Use `sockaddr_utils.h` / `sockaddr_utils.cc` for working with `sockaddr` structures, including converting them to/from string representations and comparing them for equality
Applied to files:
deps/sodium/src/libsodium/sodium/codecs.c
📚 Learning: 2025-12-03T14:35:14.525Z
Learnt from: CR
Repo: nodesource/nsolid PR: 0
File: deps/grpc/src/core/tsi/alts/GEMINI.md:0-0
Timestamp: 2025-12-03T14:35:14.525Z
Learning: Perform cryptographic operations using code in the `crypt/` directory
Applied to files:
deps/sodium/src/libsodium/crypto_ipcrypt/ipcrypt_soft.cdeps/sodium/src/libsodium/include/sodium.hdeps/sodium/src/libsodium/Makefile.am
📚 Learning: 2025-12-03T14:31:30.011Z
Learnt from: CR
Repo: nodesource/nsolid PR: 0
File: deps/grpc/src/core/handshaker/GEMINI.md:0-0
Timestamp: 2025-12-03T14:31:30.011Z
Learning: Applies to deps/grpc/src/core/handshaker/security/**/*.{h,cc} : Implement security handshakers responsible for performing TLS and ALTS handshakes in the security/ subdirectory
Applied to files:
deps/sodium/src/libsodium/Makefile.am
🧬 Code graph analysis (13)
deps/sodium/src/libsodium/crypto_core/keccak1600/ref/keccak1600_ref.h (1)
deps/sodium/src/libsodium/crypto_core/keccak1600/ref/keccak1600_ref.c (5)
keccak1600_ref_init(424-428)keccak1600_ref_xor_bytes(430-439)keccak1600_ref_extract_bytes(441-447)keccak1600_ref_permute_24(390-405)keccak1600_ref_permute_12(407-422)
deps/sodium/src/libsodium/crypto_xof/shake256/xof_shake256.c (1)
deps/sodium/src/libsodium/crypto_xof/shake256/ref/shake256_ref.c (5)
shake256_ref(112-122)shake256_ref_init(20-24)shake256_ref_init_with_domain(9-18)shake256_ref_update(26-52)shake256_ref_squeeze(84-110)
deps/sodium/src/libsodium/crypto_xof/turboshake128/ref/turboshake128_ref.c (1)
deps/sodium/src/libsodium/crypto_core/keccak1600/keccak1600.c (4)
crypto_core_keccak1600_init(10-14)crypto_core_keccak1600_permute_12(38-42)crypto_core_keccak1600_xor_bytes(16-22)crypto_core_keccak1600_extract_bytes(24-30)
deps/sodium/src/libsodium/crypto_xof/shake128/ref/shake128_ref.c (1)
deps/sodium/src/libsodium/crypto_core/keccak1600/keccak1600.c (4)
crypto_core_keccak1600_init(10-14)crypto_core_keccak1600_permute_24(32-36)crypto_core_keccak1600_xor_bytes(16-22)crypto_core_keccak1600_extract_bytes(24-30)
deps/sodium/src/libsodium/crypto_ipcrypt/ipcrypt_soft.c (2)
deps/sodium/src/libsodium/crypto_ipcrypt/ipcrypt_aesni.c (22)
expand_key(43-68)aes_encrypt(70-82)aes_decrypt(84-100)tweak_expand(102-108)aes_encrypt_with_tweak(110-124)aes_decrypt_with_tweak(126-145)aes_xex_tweak(147-159)aes_xex_encrypt(161-175)aes_xex_decrypt(177-195)encrypt(197-204)decrypt(206-213)nd_encrypt(215-223)nd_decrypt(225-232)ndx_encrypt(234-260)ndx_decrypt(262-287)is_ipv4_mapped(289-295)pfx_get_bit(297-301)pfx_set_bit(303-314)pfx_shift_left(316-325)pfx_pad_prefix(327-338)pfx_encrypt(340-408)pfx_decrypt(410-480)deps/sodium/src/libsodium/crypto_ipcrypt/ipcrypt_armcrypto.c (22)
expand_key(70-95)aes_encrypt(97-110)aes_decrypt(112-129)tweak_expand(131-135)aes_encrypt_with_tweak(137-152)aes_decrypt_with_tweak(154-174)aes_xex_tweak(176-189)aes_xex_encrypt(191-206)aes_xex_decrypt(208-227)encrypt(229-236)decrypt(238-245)nd_encrypt(247-255)nd_decrypt(257-264)ndx_encrypt(266-292)ndx_decrypt(294-319)is_ipv4_mapped(321-327)pfx_get_bit(329-333)pfx_set_bit(335-346)pfx_shift_left(348-358)pfx_pad_prefix(360-371)pfx_encrypt(373-443)pfx_decrypt(445-517)
deps/sodium/src/libsodium/crypto_xof/turboshake256/ref/turboshake256_ref.h (1)
deps/sodium/src/libsodium/crypto_xof/turboshake256/ref/turboshake256_ref.c (5)
turboshake256_ref(112-122)turboshake256_ref_init(20-24)turboshake256_ref_init_with_domain(9-18)turboshake256_ref_update(26-52)turboshake256_ref_squeeze(84-110)
deps/sodium/src/libsodium/include/sodium/private/quirks.h (5)
deps/sodium/src/libsodium/crypto_core/keccak1600/ref/keccak1600_ref.c (5)
keccak1600_ref_extract_bytes(441-447)keccak1600_ref_init(424-428)keccak1600_ref_permute_12(407-422)keccak1600_ref_permute_24(390-405)keccak1600_ref_xor_bytes(430-439)deps/sodium/src/libsodium/crypto_xof/shake128/ref/shake128_ref.c (5)
shake128_ref(112-122)shake128_ref_init(20-24)shake128_ref_init_with_domain(9-18)shake128_ref_squeeze(84-110)shake128_ref_update(26-52)deps/sodium/src/libsodium/crypto_xof/shake256/ref/shake256_ref.c (5)
shake256_ref(112-122)shake256_ref_init(20-24)shake256_ref_init_with_domain(9-18)shake256_ref_squeeze(84-110)shake256_ref_update(26-52)deps/sodium/src/libsodium/crypto_xof/turboshake128/ref/turboshake128_ref.c (5)
turboshake128_ref(112-122)turboshake128_ref_init(20-24)turboshake128_ref_init_with_domain(9-18)turboshake128_ref_squeeze(84-110)turboshake128_ref_update(26-52)deps/sodium/src/libsodium/crypto_xof/turboshake256/ref/turboshake256_ref.c (5)
turboshake256_ref(112-122)turboshake256_ref_init(20-24)turboshake256_ref_init_with_domain(9-18)turboshake256_ref_squeeze(84-110)turboshake256_ref_update(26-52)
deps/sodium/src/libsodium/crypto_xof/turboshake256/ref/turboshake256_ref.c (1)
deps/sodium/src/libsodium/crypto_core/keccak1600/keccak1600.c (4)
crypto_core_keccak1600_init(10-14)crypto_core_keccak1600_permute_12(38-42)crypto_core_keccak1600_xor_bytes(16-22)crypto_core_keccak1600_extract_bytes(24-30)
deps/sodium/src/libsodium/include/sodium/crypto_ipcrypt.h (1)
deps/sodium/src/libsodium/crypto_ipcrypt/crypto_ipcrypt.c (23)
crypto_ipcrypt_bytes(23-27)crypto_ipcrypt_keybytes(29-33)crypto_ipcrypt_nd_keybytes(35-39)crypto_ipcrypt_nd_tweakbytes(41-45)crypto_ipcrypt_nd_inputbytes(47-51)crypto_ipcrypt_nd_outputbytes(53-57)crypto_ipcrypt_ndx_keybytes(59-63)crypto_ipcrypt_ndx_tweakbytes(65-69)crypto_ipcrypt_ndx_inputbytes(71-75)crypto_ipcrypt_ndx_outputbytes(77-81)crypto_ipcrypt_pfx_keybytes(83-87)crypto_ipcrypt_pfx_bytes(89-93)crypto_ipcrypt_keygen(95-99)crypto_ipcrypt_ndx_keygen(101-105)crypto_ipcrypt_pfx_keygen(107-111)crypto_ipcrypt_encrypt(113-119)crypto_ipcrypt_decrypt(121-127)crypto_ipcrypt_nd_encrypt(129-136)crypto_ipcrypt_nd_decrypt(138-144)crypto_ipcrypt_ndx_encrypt(146-153)crypto_ipcrypt_ndx_decrypt(155-161)crypto_ipcrypt_pfx_encrypt(163-169)crypto_ipcrypt_pfx_decrypt(171-177)
deps/sodium/src/libsodium/include/sodium/crypto_xof_shake128.h (1)
deps/sodium/src/libsodium/crypto_xof/shake128/xof_shake128.c (8)
crypto_xof_shake128_blockbytes(5-9)crypto_xof_shake128_statebytes(11-15)crypto_xof_shake128_domain_standard(17-21)crypto_xof_shake128(23-30)crypto_xof_shake128_init(32-40)crypto_xof_shake128_init_with_domain(42-50)crypto_xof_shake128_update(52-60)crypto_xof_shake128_squeeze(62-68)
deps/sodium/src/libsodium/crypto_xof/shake256/ref/shake256_ref.c (1)
deps/sodium/src/libsodium/crypto_core/keccak1600/keccak1600.c (4)
crypto_core_keccak1600_init(10-14)crypto_core_keccak1600_permute_24(32-36)crypto_core_keccak1600_xor_bytes(16-22)crypto_core_keccak1600_extract_bytes(24-30)
deps/sodium/src/libsodium/include/sodium/crypto_xof_turboshake128.h (1)
deps/sodium/src/libsodium/crypto_xof/turboshake128/xof_turboshake128.c (8)
crypto_xof_turboshake128_blockbytes(5-9)crypto_xof_turboshake128_statebytes(11-15)crypto_xof_turboshake128_domain_standard(17-21)crypto_xof_turboshake128(23-30)crypto_xof_turboshake128_init(32-40)crypto_xof_turboshake128_init_with_domain(42-51)crypto_xof_turboshake128_update(53-61)crypto_xof_turboshake128_squeeze(63-70)
deps/sodium/src/libsodium/crypto_xof/shake128/xof_shake128.c (1)
deps/sodium/src/libsodium/crypto_xof/shake128/ref/shake128_ref.c (5)
shake128_ref(112-122)shake128_ref_init(20-24)shake128_ref_init_with_domain(9-18)shake128_ref_update(26-52)shake128_ref_squeeze(84-110)
🪛 Cppcheck (2.19.0)
deps/sodium/src/libsodium/crypto_ipcrypt/ipcrypt_aesni.c
[error] 483-483: syntax error
(syntaxError)
deps/sodium/src/libsodium/crypto_ipcrypt/ipcrypt_soft.c
[error] 459-459: syntax error
(syntaxError)
deps/sodium/src/libsodium/crypto_ipcrypt/ipcrypt_armcrypto.c
[error] 520-520: syntax error
(syntaxError)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
- GitHub Check: lint-js-and-md
- GitHub Check: test-linux (ubuntu-24.04)
- GitHub Check: test-linux (ubuntu-24.04-arm)
- GitHub Check: build-tarball
- GitHub Check: test-macOS
🔇 Additional comments (89)
deps/sodium/src/libsodium/include/sodium/crypto_hash_sha512.h (1)
4-6: Doc-only cleanup looks good.Punctuation fix is clear and has no behavioral impact.
deps/sodium/src/libsodium/crypto_aead/xchacha20poly1305/aead_xchacha20poly1305.c (1)
115-116: Fence placement looks correct.The ACQUIRE_FENCE insertion on the success path after MAC verification is consistent with hardened decrypt patterns and doesn’t change functional behavior.
deps/sodium/src/libsodium/crypto_pwhash/scryptsalsa208sha256/crypto_scrypt-common.c (1)
172-175: Null buffer guard looks good.Early return on
buf == NULLaligns with the existing size checks and avoids unsafe use.deps/sodium/src/libsodium/crypto_scalarmult/curve25519/sandy2x/sandy2x.S (1)
12-30: LGTM — CET GNU property note is correctly scoped.The ELF note block is properly guarded and doesn’t affect code generation beyond metadata.
deps/sodium/src/libsodium/include/sodium/crypto_stream_salsa2012.h (1)
39-43: LGTM — nonnull contract is now more precise.The updated
nonnull(1, 4, 5)attribute correctly reflects that the message pointerm(parameter 2) may be NULL for keystream-only generation, while the output bufferc, noncen, and keykremain mandatory. This is a standard and valid pattern for stream cipher XOR APIs in libsodium.deps/sodium/src/libsodium/crypto_kdf/hkdf/kdf_hkdf_sha512.c (1)
24-32: Good security fix: correct memory zeroing of the full state structure.The change from
sizeof(state)tosizeof *stateis an important bug fix. Previously, only the pointer-sized portion (4 or 8 bytes) was being zeroed instead of the entirecrypto_kdf_hkdf_sha512_statestructure, leaving sensitive HMAC intermediate values in memory after the function completed.deps/sodium/src/libsodium/crypto_secretbox/crypto_secretbox_easy.c (1)
104-104: LGTM! Security hardening via memory barrier.The
ACQUIRE_FENCEis correctly placed after MAC verification passes (line 97) and the NULL-check early return (lines 101-103), but before any decryption operations begin. This ensures proper memory ordering and acts as a defense-in-depth measure against speculation-based attacks. This is consistent with the broader pattern of fence insertions across other crypto modules in this libsodium 1.0.21 update.deps/sodium/src/libsodium/crypto_onetimeauth/poly1305/sse2/poly1305_sse2.c (2)
197-198: LGTM! Constant-time optimization blocker.This
static volatilevariable is a well-known constant-time hardening pattern. Thevolatilequalifier prevents the compiler from optimizing away operations involving this variable, even though its value is always zero. This ensures the carry computation at line 750 remains timing-invariant regardless of compiler optimization level.
750-754: LGTM! Hardened constant-time conditional selection.The modified carry calculation
(((g2 >> 61) ^ optblocker_u64) >> 2) - 1is mathematically equivalent to the original(g2 >> 63) - 1, but the volatile XOR prevents the compiler from optimizing the expression in ways that could introduce timing side-channels. The subsequent masking operations (lines 752-754) remain constant-time, ensuring the Poly1305 finalization is timing-invariant.deps/sodium/src/libsodium/include/sodium/crypto_stream.h (1)
45-49: LGTM!The refined
nonnull(1, 4, 5)attribute correctly specifies that only the output bufferc, noncen, and keykare required to be non-null. Allowingmto be null (whenmlenis 0) is a valid upstream API refinement that enables keystream-only generation use cases.deps/sodium/src/libsodium/include/sodium/crypto_stream_xsalsa20.h (1)
40-51: LGTM!Both attribute refinements are correct:
crypto_stream_xsalsa20_xor:nonnull(1, 4, 5)correctly marksc,n,kas requiredcrypto_stream_xsalsa20_xor_ic:nonnull(1, 4, 6)correctly accounts foricbeing auint64_t(not a pointer) at position 5, markingc,n,kas requiredThis aligns with the pattern applied across other crypto_stream headers in this PR.
deps/sodium/src/libsodium/include/sodium/crypto_stream_chacha20.h (2)
42-53: LGTM!The original ChaCha20 variant attribute refinements are correct:
crypto_stream_chacha20_xor:nonnull(1, 4, 5)forc,n,kcrypto_stream_chacha20_xor_ic:nonnull(1, 4, 6)correctly skipsic(uint64_t) at position 5
79-90: LGTM!The IETF ChaCha20 variant attribute refinements follow the same correct pattern:
crypto_stream_chacha20_ietf_xor:nonnull(1, 4, 5)forc,n,kcrypto_stream_chacha20_ietf_xor_ic:nonnull(1, 4, 6)correctly skipsic(uint32_t) at position 5All nonnull refinements across the three files are consistent with upstream libsodium 1.0.21 and correctly allow the message parameter to be null while ensuring output buffer, nonce, and key remain required.
deps/sodium/src/libsodium/crypto_aead/aegis128l/aegis128l_common.h (2)
35-41: LGTM! Fixed-width types improve cross-platform correctness.The change from
size_ttouint64_tforadlenandmlenensures consistent 64-bit length handling across all platforms. This prevents potential overflow in the<< 3bit-length computation on 32-bit systems and aligns with the AEGIS specification's 64-bit length encoding.
244-251: LGTM! Security hardening against speculative execution attacks.The
ACQUIRE_FENCEmemory barrier on the success path prevents speculative execution past the MAC verification, mitigating Spectre-style side-channel attacks that could leak plaintext before authentication completes. The explicit early return on failure with conditionalmclearing is clean and correctly handles the case wheremis NULL (authentication-only mode).deps/sodium/src/libsodium/include/sodium/utils.h (2)
96-101: New IP codec APIs look well-designed.The new
sodium_ip2binandsodium_bin2ipfunctions are properly declared with:
warn_unused_resultonsodium_ip2binto ensure callers check for parse errorsnonnullattributes to enable compiler diagnostics for null pointer misuse- Fixed-size array notation
[16]for documentation clarity
103-107: LGTM on the updated memory-locking declarations.Adding
__attribute__((nonnull))tosodium_mlockandsodium_munlockimproves compile-time null-pointer detection, which is appropriate for these security-sensitive functions.deps/sodium/src/libsodium/sodium/codecs.c (5)
338-348: Hex digit parsing is correct.The function properly handles '0'-'9', 'a'-'f', and 'A'-'F' using the
| 32Utrick for case-insensitive letter matching.
350-381: IPv4 parsing implementation is correct.The function properly validates:
- Exactly 4 octets separated by dots
- Each octet has 1-3 digits and value ≤ 255
- No trailing characters
383-474: IPv6 parsing follows established inet_pton patterns.The implementation correctly handles:
- Leading
::(lines 401-407)- Mid-address
::compression with memmove expansion (lines 458-466)- Embedded IPv4 suffix (lines 434-440)
- Hex group validation with 4-digit limit
476-512:sodium_ip2bincorrectly handles IPv4, IPv6, and zone IDs.Good design choices:
- IPv4 addresses stored as IPv4-mapped IPv6 (
::ffff:x.x.x.x) for uniform 16-byte output- Zone ID (
%) parsing with validation (no whitespace, non-empty)- Early termination on null byte within
ip_lenbounds
566-610: IPv6 formatting with zero compression is correctly implemented.The algorithm:
- Finds the longest run of zero words (minimum 2) for
::compression (lines 566-589)- Outputs with proper colon placement and compression (lines 590-601)
- Uses a 46-byte buffer matching
INET6_ADDRSTRLENdeps/sodium/src/libsodium/include/sodium/version.h (1)
7-10: I'm ready to assist, but I don't have a review comment to rewrite. Please provide:
- The review comment (within
<review_comment>tags)- Any relevant context (file paths, code snippets, repository structure)
Once provided, I will verify the comment and output the rewritten version in the required format.
deps/sodium/src/libsodium/crypto_core/ed25519/ref10/ed25519_ref10.c (5)
291-292: Constant-time hardening viaoptblocker_u8looks correct.The
static volatile unsigned char optblocker_u8pattern is a well-established technique in cryptographic code to prevent compilers from optimizing away constant-time operations. The volatile qualifier ensures the compiler cannot assume its value (always 0 at runtime) and must generate code that appears to depend on it.
568-601: Architecture-specific constant-time implementations look correct.The
equal()andnegative()functions now have optimized inline assembly for x86_64 and aarch64, with correct portable fallbacks:
- equal portable (line 583):
((y >> 29) ^ optblocker_u8) >> 2correctly returns 1 when equal (y=0xFFFFFFFF → 7 → 1) and 0 otherwise- negative portable (line 599):
((x >> 5) ^ optblocker_u8) >> 2correctly extracts the sign bit (bit 7) via two shiftsThe inline assembly implementations are appropriate for their respective architectures and avoid timing side-channels.
1047-1053: Improved subgroup check is a correctness enhancement.The identity point in extended coordinates satisfies X=0, Y=Z, T=0. The previous check only verified
X=0, while the new code additionally verifiesY-Z=0(i.e., Y=Z). This is a more complete verification that the point after scalar multiplication by the group order L is indeed the identity element.
325-325: Sign/high-bit extraction pattern is consistent and correct.All three locations use the same constant-time bit extraction pattern
(((byte >> 5) ^ optblocker_u8) >> 2)to extract bit 7:
- Line 325: Extracts sign bit from encoded point for
ge25519_frombytes- Line 2635: Extracts bit for field element adjustment in
ge25519_from_hash- Line 2695: Checks high bit for canonicality in
ristretto255_is_canonicalThe two-shift approach (
>>5then>>2) correctly isolates bit 7 while the XOR withoptblocker_u8prevents compiler optimization.Also applies to: 2635-2635, 2695-2695
42-42: Header reference update is consistent with the PR.The comment correctly reflects the header file rename from
private/curve25519_ref10.htoprivate/ed25519_ref10.h.deps/sodium/src/libsodium/include/Makefile.am (1)
21-68: Public header exports look consistent.The new headers are exported and will be installed via SODIUM_EXPORT/EXTRA_SRC as expected.
deps/sodium/src/libsodium/include/sodium/private/common.h (2)
5-16: Warning text tweaks are fine.
33-70: MSVC rotation intrinsics: please verify toolchain coverage.Please confirm MSVC (x86/x64/ARM64) builds still resolve
_rotl/_rotr/_rotl64/_rotr64with the current includes in CI.deps/sodium/src/libsodium/crypto_secretbox/xsalsa20poly1305/secretbox_xsalsa20poly1305.c (1)
5-43: Fence-after-MAC hardening looks good.deps/sodium/src/libsodium/crypto_xof/turboshake128/ref/turboshake128_ref.c (4)
9-24: Initialization flow is clean and consistent.
27-52: Absorb/update loop looks correct.
54-110: Finalize + squeeze sequence looks solid.
112-121: One-shot helper is straightforward.deps/sodium/src/libsodium/crypto_xof/turboshake256/ref/turboshake256_ref.h (1)
1-36: Header additions look consistent and complete.deps/sodium/src/libsodium/crypto_ipcrypt/implementations.h (1)
1-20: LGTM!The implementation structure is clean and follows appropriate patterns. The asymmetric signatures (encrypt with tweak, decrypt without) align with standard non-deterministic encryption schemes where the tweak is embedded in the ciphertext.
deps/sodium/src/libsodium/crypto_xof/shake256/ref/shake256_ref.c (1)
1-122: LGTM!The SHAKE-256 reference implementation correctly follows the sponge construction pattern with proper padding, phase management, and chunked processing. The 24-round Keccak permutation is appropriately used for SHAKE-256.
deps/sodium/src/libsodium/crypto_xof/shake256/xof_shake256.c (1)
32-50: LGTM!The init functions properly use COMPILER_ASSERT to ensure state size compatibility and correctly delegate to the reference implementation.
deps/sodium/src/libsodium/crypto_xof/turboshake256/ref/turboshake256_ref.c (1)
1-122: LGTM!The TurboSHAKE256 implementation correctly uses 12-round Keccak permutation while maintaining the same sponge construction as SHAKE-256. The reduced-round variant is properly implemented.
deps/sodium/src/libsodium/crypto_core/keccak1600/ref/keccak1600_ref.h (1)
1-20: LGTM!The header is clean and well-structured. Include guard follows libsodium conventions, and all function declarations align with the implementations in
keccak1600_ref.c. The use ofvoid *stateprovides flexibility for the opaque state pattern used throughout libsodium.deps/sodium/src/libsodium/crypto_xof/shake128/ref/shake128_ref.c (3)
9-24: LGTM!Initialization functions are straightforward. The delegation pattern using
crypto_xof_shake128_DOMAIN_STANDARDfor the default init keeps the API clean while allowing domain customization for TurboSHAKE variants.
32-35: Verify: Non-standard XOF state transition allows absorbing after squeezing.This logic resets the state to absorbing phase if
updateis called after squeezing has begun. Standard SHAKE128 doesn't permit absorbing after the squeeze phase starts. If this is intentional (e.g., for re-keying or incremental patterns), consider documenting the behavior.
54-82: LGTM!The finalization padding logic correctly implements SHAKE128 domain separation. The special case handling when
offset == SHAKE128_RATE - 1(combining domain and 0x80 into a single byte) is correctly implemented.deps/sodium/src/libsodium/crypto_core/keccak1600/keccak1600.c (1)
1-42: LGTM!Clean wrapper implementation following libsodium's opaque state pattern. All functions correctly delegate to the reference implementation via
state->opaque, maintaining a consistent public API surface while allowing internal implementation flexibility.deps/sodium/src/libsodium/include/sodium/crypto_xof_turboshake128.h (1)
1-54: LGTM!Well-structured public header for TurboSHAKE-128 XOF. The constants are correct (168-byte block size for 128-bit security, 0x1F domain separator), and the
nonnullattributes appropriately allow NULL input for empty-message cases while requiring valid state and output pointers.deps/sodium/src/libsodium/include/sodium/crypto_ipcrypt.h (1)
1-128: LGTM!Comprehensive public header for IPcrypt with multiple variants (basic, ND, NDX, PFX). The asymmetric API for ND/NDX variants (encrypt takes tweak, decrypt doesn't) is correct by design—the non-deterministic modes embed the tweak in the expanded ciphertext output (ND: 24 = 16 + 8, NDX: 32 = 16 + 16), allowing decrypt to extract it automatically.
deps/sodium/src/libsodium/crypto_ipcrypt/ipcrypt_soft.h (1)
1-8: LGTM!Clean header with proper include guard and extern declaration for the software IPcrypt backend implementation.
deps/sodium/src/libsodium/crypto_ipcrypt/ipcrypt_armcrypto.h (1)
1-8: LGTM!Consistent header structure with the software backend, properly exposing the ARM Crypto implementation.
deps/sodium/src/libsodium/crypto_ipcrypt/ipcrypt_soft.c (10)
1-12: LGTM!Proper includes for the software AES implementation using the SoftAES primitives.
13-27: LGTM!Correct AES-128 round count and clean macro abstractions over SoftAES primitives.
29-67: LGTM!Core AES-128 encrypt/decrypt operations follow the standard round structure with proper key schedule handling.
69-119: LGTM!Tweaked AES operations correctly expand the 8-byte tweak and apply it throughout the rounds, with proper handling of the inverted tweak in decryption.
121-171: LGTM!XEX mode implementation correctly applies the encrypted tweak at input and output of the main AES operation.
173-208: LGTM!High-level wrappers properly handle key expansion and the ND (nonce-derived) format.
210-263: LGTM!NDX variants correctly implement dual-key XEX mode with appropriate fallback handling for degenerate key cases where the middle round keys collide.
265-314: LGTM!Prefix helper functions implement proper constant-time bit operations. The inline assembly barrier in
pfx_set_bit(line 287) is an appropriate defense against compiler optimizations that could introduce timing side channels.
316-456: LGTM!Prefix-preserving encryption correctly implements a bit-by-bit format-preserving scheme for IP addresses, with proper handling of IPv4-mapped addresses.
458-463: LGTM!The implementation structure correctly wires all eight function pointers. The Cppcheck syntax error is a false positive—
SODIUM_C99is a libsodium macro that provides C99/C89 designated initializer compatibility.deps/sodium/src/libsodium/crypto_ipcrypt/ipcrypt_armcrypto.c (7)
1-29: LGTM!Proper conditional compilation setup for ARM Crypto extensions with appropriate feature macros and compiler pragmas.
30-56: LGTM!NEON intrinsic macros correctly wrap ARM crypto instructions, accounting for the different operand ordering compared to AES-NI.
58-95: LGTM!Key expansion correctly emulates the x86
AESKEYGENASSISTbehavior using ARM crypto intrinsics with appropriate byte shuffling.
97-129: LGTM!ARM AES encrypt/decrypt correctly account for the instruction semantics where the key XOR occurs before the SubBytes/ShiftRows operations.
131-227: LGTM!Tweaked and XEX mode variants correctly implemented using NEON intrinsics, maintaining algorithmic consistency with the software backend.
229-517: LGTM!High-level functions and prefix operations maintain consistency with the software backend while leveraging NEON vector operations for acceleration, including proper constant-time measures.
519-530: LGTM!Implementation structure correctly wired with proper pragma cleanup. The Cppcheck syntax error is a false positive due to the
SODIUM_C99macro.deps/sodium/src/libsodium/crypto_ipcrypt/ipcrypt_aesni.c (7)
1-22: LGTM!Proper conditional compilation setup for AES-NI with AVX support and appropriate compiler pragmas.
23-68: LGTM!Standard AES-NI intrinsic wrappers and correct AES-128 key expansion using
AESKEYGENASSIST.
70-100: LGTM!Standard AES-NI encrypt/decrypt with proper round structure and inverse key handling.
102-145: LGTM!Tweak expansion using
_mm_shuffle_epi8correctly unpacks the 8-byte tweak, and the tweaked encryption variants maintain consistency with other backends.
147-195: LGTM!XEX mode correctly implemented with standard tweak encryption and application.
197-480: LGTM!High-level functions and prefix operations maintain consistency with other backends. The
pfx_shift_leftcleverly uses_mm_add_epi8(v,v)for vectorized left shift with proper carry propagation.
482-493: LGTM!Implementation structure correctly wired with proper pragma cleanup. The Cppcheck syntax error is a false positive due to the
SODIUM_C99macro.deps/sodium/src/libsodium/include/sodium.h (1)
21-21: Confirm intended public exposure for new headers.
Please verify these new includes are meant to be part of the default public API (including minimal builds, if applicable) and won’t introduce unintended symbol exposure or missing guards.Also applies to: 30-30, 58-61
deps/sodium/src/libsodium/crypto_xof/shake128/xof_shake128.c (3)
5-21: Accessor wrappers are clean and consistent.
No issues spotted; simple passthroughs to constants.
32-50: Init wrappers are fine.
Casting and size assertions look consistent with the reference implementation.
62-67: Squeeze wrapper is OK.
Straight passthrough to the reference implementation.deps/sodium/src/libsodium/include/sodium/crypto_xof_shake128.h (1)
1-55: Public header looks consistent with libsodium patterns.
Constants, opaque state, and API declarations are clear and consistent.deps/sodium/src/libsodium/Makefile.am (2)
30-33: Build wiring for new core/XOF sources looks good.
Sources are correctly added to the libsodium build inputs.Also applies to: 49-52, 106-117, 124-124
258-260: Verify HW‑specific IPcrypt sources are properly gated.
Please confirm the new ARM Crypto and AES‑NI sources are only built when the corresponding feature flags/toolchain support are enabled, to avoid cross‑platform build failures.Also applies to: 270-272
deps/sodium/src/libsodium/include/sodium/private/softaes.h (1)
15-23: New helper declarations look good.No concerns with the added prototypes; they align with the new SoftAES helpers.
deps/sodium/src/libsodium/crypto_core/softaes/softaes.c (7)
9-35: Confirm wasm policy for forcingFAVOR_PERFORMANCE.This unconditionally selects the LUT-based path for WebAssembly; please confirm it aligns with your constant‑time/side‑channel policy for wasm builds.
36-47: Helper transforms and GF operations look correct.The word transforms and GF(2^8) helpers are clean and consistent.
Also applies to: 121-176
178-196: Key‑schedule inversion bounds look right.Loop ranges align with AES round‑key layouts.
198-395: LUT stride setup and T‑table encrypt path look consistent.Default stride plus LUT0‑3 indexing is coherent with the table layout.
397-517: Please confirm KAT coverage for new encrypt/decrypt helpers.Given the new public helpers, add/verify AES‑128/256 known‑answer tests for both
FAVOR_PERFORMANCEand non‑FAVOR_PERFORMANCEbuilds to ensure parity across paths.Also applies to: 648-835
520-553: Non‑FAVOR_PERFORMANCELUT table looks fine.No issues noted with the table definition.
581-583: Inline‑asm fence placement looks appropriate.Barrier is correctly scoped to the table block.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
| void | ||
| softaes_expand_key128(SoftAesBlock rkeys[11], const uint8_t key[16]) | ||
| { | ||
| uint32_t w[44]; | ||
| size_t i; | ||
|
|
||
| w[0] = (uint32_t) key[0] | ((uint32_t) key[1] << 8) | ((uint32_t) key[2] << 16) | | ||
| ((uint32_t) key[3] << 24); | ||
| w[1] = (uint32_t) key[4] | ((uint32_t) key[5] << 8) | ((uint32_t) key[6] << 16) | | ||
| ((uint32_t) key[7] << 24); | ||
| w[2] = (uint32_t) key[8] | ((uint32_t) key[9] << 8) | ((uint32_t) key[10] << 16) | | ||
| ((uint32_t) key[11] << 24); | ||
| w[3] = (uint32_t) key[12] | ((uint32_t) key[13] << 8) | ((uint32_t) key[14] << 16) | | ||
| ((uint32_t) key[15] << 24); | ||
|
|
||
| for (i = 4; i < 44; i++) { | ||
| uint32_t temp = w[i - 1]; | ||
| if (i % 4 == 0) { | ||
| temp = sub_word(rot_word(temp)) ^ ((uint32_t) RCON[i / 4]); | ||
| } | ||
| w[i] = w[i - 4] ^ temp; | ||
| } | ||
|
|
||
| for (i = 0; i < 11; i++) { | ||
| rkeys[i].w0 = w[i * 4 + 0]; | ||
| rkeys[i].w1 = w[i * 4 + 1]; | ||
| rkeys[i].w2 = w[i * 4 + 2]; | ||
| rkeys[i].w3 = w[i * 4 + 3]; | ||
| } | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find . -path "*deps/sodium/src/libsodium/crypto_core/softaes/softaes.c" -type fRepository: nodesource/nsolid
Length of output: 118
🏁 Script executed:
cat -n deps/sodium/src/libsodium/crypto_core/softaes/softaes.c | sed -n '1,130p'Repository: nodesource/nsolid
Length of output: 6060
🏁 Script executed:
# Search for sodium_memzero function definition
rg "sodium_memzero" --type c -A 2 | head -50Repository: nodesource/nsolid
Length of output: 3453
🏁 Script executed:
# Check for other key expansion functions in the file that might need the same fix
rg "softaes_expand" deps/sodium/src/libsodium/crypto_core/softaes/softaes.cRepository: nodesource/nsolid
Length of output: 198
🏁 Script executed:
cat -n deps/sodium/src/libsodium/private/common.h | head -50Repository: nodesource/nsolid
Length of output: 135
🏁 Script executed:
# Check if sodium_memzero is exported or available
cat -n deps/sodium/src/libsodium/include/sodium/utils.hRepository: nodesource/nsolid
Length of output: 7568
🏁 Script executed:
# Look for sodium_memzero usage in similar softaes or crypto_core files
find deps/sodium/src/libsodium/crypto_core -name "*.c" -exec grep -l "sodium_memzero" {} \;Repository: nodesource/nsolid
Length of output: 121
🏁 Script executed:
# Find where common.h actually is located
find . -path "*private*" -name "common.h" -type fRepository: nodesource/nsolid
Length of output: 120
🏁 Script executed:
# Check what headers are in the private directory
ls -la deps/sodium/src/libsodium/private/ 2>/dev/null || ls -la deps/sodium/src/libsodium/crypto_core/softaes/Repository: nodesource/nsolid
Length of output: 234
🏁 Script executed:
# Check if softaes.h includes sodium/utils.h or sodium_memzero
cat deps/sodium/src/libsodium/private/softaes.h 2>/dev/null || find . -name "softaes.h" -exec cat {} \;Repository: nodesource/nsolid
Length of output: 2076
🏁 Script executed:
# Check ed25519 to see how it uses sodium_memzero
grep -B 5 -A 5 "sodium_memzero" deps/sodium/src/libsodium/crypto_core/ed25519/core_ed25519.c | head -30Repository: nodesource/nsolid
Length of output: 304
🏁 Script executed:
cat deps/sodium/src/libsodium/include/sodium/private/common.h | head -80Repository: nodesource/nsolid
Length of output: 2138
🏁 Script executed:
# Search for sodium_memzero definition or declaration in common.h
rg "sodium_memzero" deps/sodium/src/libsodium/include/sodium/private/common.hRepository: nodesource/nsolid
Length of output: 43
🏁 Script executed:
# Check what common.h includes
head -30 deps/sodium/src/libsodium/include/sodium/private/common.hRepository: nodesource/nsolid
Length of output: 1160
🏁 Script executed:
# Check what ed25519 file includes
head -20 deps/sodium/src/libsodium/crypto_core/ed25519/core_ed25519.cRepository: nodesource/nsolid
Length of output: 549
🏁 Script executed:
# Check all includes in common.h - full file
wc -l deps/sodium/src/libsodium/include/sodium/private/common.h && tail -100 deps/sodium/src/libsodium/include/sodium/private/common.hRepository: nodesource/nsolid
Length of output: 2287
🏁 Script executed:
# Search for sodium_memzero in common.h or its includes
rg "define.*sodium_memzero|include.*utils" deps/sodium/src/libsodium/include/sodium/private/common.hRepository: nodesource/nsolid
Length of output: 43
🏁 Script executed:
# Check if sodium/utils.h is indirectly included anywhere in the chain
grep -r "sodium_memzero" deps/sodium/src/libsodium/crypto_core/ --include="*.h" | head -5Repository: nodesource/nsolid
Length of output: 43
🏁 Script executed:
# Check exact includes in softaes.c
head -20 deps/sodium/src/libsodium/crypto_core/softaes/softaes.cRepository: nodesource/nsolid
Length of output: 1025
🏁 Script executed:
# Look for how other crypto_core functions use sodium_memzero
find deps/sodium/src/libsodium/crypto_core -name "*.c" -exec grep -l "sodium_memzero" {} \;Repository: nodesource/nsolid
Length of output: 121
🏁 Script executed:
# Check the ed25519 includes again - note it has utils.h
grep -n "#include" deps/sodium/src/libsodium/crypto_core/ed25519/core_ed25519.c | head -10Repository: nodesource/nsolid
Length of output: 232
🏁 Script executed:
# Check if utils.h is in the include path for softaes
find deps/sodium/src/libsodium -name "utils.h" | head -5Repository: nodesource/nsolid
Length of output: 109
🏁 Script executed:
# Check if other functions in softaes.c have similar key material that needs cleanup
grep -n "uint32_t w\[" deps/sodium/src/libsodium/crypto_core/softaes/softaes.cRepository: nodesource/nsolid
Length of output: 106
🏁 Script executed:
# Verify the second function mentioned (lines 80-119)
sed -n '80,119p' deps/sodium/src/libsodium/crypto_core/softaes/softaes.cRepository: nodesource/nsolid
Length of output: 1651
Add zeroization of expanded-key material after use in key expansion functions.
Both softaes_expand_key128 and softaes_expand_key256 allocate stack buffers (w[44] and w[60]) containing the expanded AES key schedule. These must be wiped after copying to rkeys to avoid leaving sensitive key material on the stack. Add #include "utils.h" to access sodium_memzero(), then zeroize each w buffer before returning.
Proposed fix
`#include` <stddef.h>
`#include` <stdint.h>
`#include` <stdlib.h>
`#include` <string.h>
`#include` "private/common.h"
`#include` "private/softaes.h"
+#include "utils.h"
`#if` defined(__wasm__) && !defined(FAVOR_PERFORMANCE) for (i = 0; i < 11; i++) {
rkeys[i].w0 = w[i * 4 + 0];
rkeys[i].w1 = w[i * 4 + 1];
rkeys[i].w2 = w[i * 4 + 2];
rkeys[i].w3 = w[i * 4 + 3];
}
+ sodium_memzero(w, sizeof w);
} for (i = 0; i < 15; i++) {
rkeys[i].w0 = w[i * 4 + 0];
rkeys[i].w1 = w[i * 4 + 1];
rkeys[i].w2 = w[i * 4 + 2];
rkeys[i].w3 = w[i * 4 + 3];
}
+ sodium_memzero(w, sizeof w);
}🤖 Prompt for AI Agents
In `@deps/sodium/src/libsodium/crypto_core/softaes/softaes.c` around lines 49 -
78, The expanded AES key schedule arrays w in softaes_expand_key128 and
softaes_expand_key256 contain sensitive key material on the stack and must be
zeroized before returning; add `#include` "utils.h" at top of the file and call
sodium_memzero(w, sizeof w) (using the same identifier w in each function: w[44]
in softaes_expand_key128 and w[60] in softaes_expand_key256) immediately after
the loop that copies into rkeys and before each function returns to wipe the
temporary key schedule.
| #include "crypto_xof_shake128.h" | ||
| #include "private/common.h" | ||
| #include "ref/shake128_ref.h" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find . -name "xof_shake128.c" -type fRepository: nodesource/nsolid
Length of output: 123
🏁 Script executed:
cat -n "./deps/sodium/src/libsodium/crypto_xof/shake128/xof_shake128.c"Repository: nodesource/nsolid
Length of output: 2364
🏁 Script executed:
find ./deps/sodium -name "*xof*" -type f | grep -E "\.(c|h)$" | head -20Repository: nodesource/nsolid
Length of output: 602
🏁 Script executed:
grep -r "SIZE_MAX\|stdint.h" ./deps/sodium/src/libsodium/private/common.h | head -20Repository: nodesource/nsolid
Length of output: 138
🏁 Script executed:
find ./deps/sodium -name "common.h" -type fRepository: nodesource/nsolid
Length of output: 120
🏁 Script executed:
cat -n "./deps/sodium/src/libsodium/include/sodium/private/common.h" | head -50Repository: nodesource/nsolid
Length of output: 1905
🏁 Script executed:
find ./deps/sodium -name "*shake128_ref*" -type fRepository: nodesource/nsolid
Length of output: 348
🏁 Script executed:
cat -n "./deps/sodium/src/libsodium/crypto_xof/shake128/ref/shake128_ref.c" | head -100Repository: nodesource/nsolid
Length of output: 3687
🏁 Script executed:
cat -n "./deps/sodium/src/libsodium/crypto_xof/shake128/ref/shake128_ref.c" | tail -50Repository: nodesource/nsolid
Length of output: 1762
Guard against inlen truncation on 32‑bit systems.
Casting unsigned long long to size_t can silently truncate values on 32‑bit builds. Add bounds checks to return an error when inlen > SIZE_MAX before casting, preventing incorrect hash computations.
Note: SIZE_MAX is already available via <stdint.h> included through private/common.h, so adding an explicit #include <stdint.h> is unnecessary.
🛠️ Proposed fix
`#include` "crypto_xof_shake128.h"
`#include` "private/common.h"
`#include` "ref/shake128_ref.h"
int
crypto_xof_shake128(unsigned char *out, size_t outlen, const unsigned char *in,
unsigned long long inlen)
{
COMPILER_ASSERT(sizeof(crypto_xof_shake128_state) >= sizeof(shake128_state_internal));
+ if (inlen > SIZE_MAX) {
+ return -1;
+ }
return shake128_ref(out, outlen, in, (size_t) inlen);
}
int
crypto_xof_shake128_update(crypto_xof_shake128_state *state,
const unsigned char *in,
unsigned long long inlen)
{
shake128_state_internal *st = (shake128_state_internal *) (void *) state;
+ if (inlen > SIZE_MAX) {
+ return -1;
+ }
return shake128_ref_update(st, in, (size_t) inlen);
}🤖 Prompt for AI Agents
In `@deps/sodium/src/libsodium/crypto_xof/shake128/xof_shake128.c` around lines 1
- 3, Add a size-bound check before any cast from unsigned long long to size_t in
the SHAKE128 implementation: in functions in xof_shake128.c that accept an
unsigned long long input length (e.g., functions that call a cast like
(size_t)inlen when processing input buffers such as the crypto_xof_shake128/sha
ke128 absorb/update helpers), check if inlen > SIZE_MAX and return an error
(non-zero) immediately if so; this prevents silent truncation on 32-bit builds
and ensures the cast to size_t is safe. Ensure you use the existing SIZE_MAX
from private/common.h and update all call sites in xof_shake128.c that perform
this cast.
| #ifndef quirks_H | ||
| #ifndef NO_QUIRKS | ||
|
|
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n deps/sodium/src/libsodium/include/sodium/private/quirks.hRepository: nodesource/nsolid
Length of output: 1979
Missing header guard definition.
The #ifndef quirks_H guard on line 3 is never followed by #define quirks_H, so this header is not protected against multiple inclusion. Without defining the guard macro, each include will reprocess all the macro definitions, causing redefinition warnings.
🔧 Proposed fix
`#ifndef` quirks_H
+#define quirks_H
`#ifndef` NO_QUIRKS🤖 Prompt for AI Agents
In `@deps/sodium/src/libsodium/include/sodium/private/quirks.h` around lines 3 -
5, The header guard is incomplete: after the initial `#ifndef quirks_H` you must
add a `#define quirks_H` so the macro is set and prevents multiple inclusion;
ensure the existing `#ifndef NO_QUIRKS` remains nested as intended and that a
matching `#endif` for `quirks_H` is present at the end of the file. Update the
header to define `quirks_H` immediately after the `#ifndef quirks_H` and verify
`NO_QUIRKS` logic and final `#endif` are correctly paired.
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
✏️ Tip: You can customize this high-level summary in your review settings.