What changed, and why it matters
This commit fixes a build error in the 'cyperpunk' firmware variant by replacing a likely-undefined variable `len` with `seedLen` in two function calls that handle Zcash cryptographic key derivation. The change appears to be a straightforward compile fix rather than a security patch, but the use of the wrong variable could theoretically have led to reading an incorrect seed length if `len` had a different meaning or value.
Verify that `seedLen` is the canonical, validated seed length and that no other build configurations still use `len` for these calls. Review `derive_zcash_ufvk` and `rust_derive_iv_from_seed` for length assumptions, and add explicit length checks before the calls if absent.
Security signals we found
Variable substitution in cryptographic key derivation input
Potential use of incorrect seed length in Zcash UFVK and IV derivation
No explicit bounds/length validation added in patch
Commit message frames change as build fix, not security fix
Evidence from the diff
In src/crypto/account_public_info.c, the commit changes two calls from using len to seedLen as the seed-length argument for derive_zcash_ufvk() and rust_derive_iv_from_seed(). The commit message says only ‘fix cyperpunk build’, implying len was not in scope or was the wrong identifier for this build configuration. If len were in scope but held a different value than seedLen, the previous code could pass an incorrect buffer length to Rust-side key-derivation routines, potentially causing out-of-bounds reads or incorrect key/IV material. The patch is minimal (2 lines) and does not add validation or bounds checks.
Changed components
src/crypto/account_public_info.cZcash unified full viewing key (UFVK) derivationSeed-based IV derivationInspect captured patch +2 / −2
diff --git a/src/crypto/account_public_info.c b/src/crypto/account_public_info.c
index 00caefa..1018952 100644
--- a/src/crypto/account_public_info.c
+++ b/src/crypto/account_public_info.c
@@ -922,10 +922,10 @@ int32_t AccountPublicSavePublicInfo(uint8_t accountIndex, const char *password,
if (g_chainTable[i].cryptoKey == ZCASH_UFVK_ENCRYPTED) {
char* zcashUfvk = NULL;
SimpleResponse_c_char *zcash_ufvk_response = NULL;
- zcash_ufvk_response = derive_zcash_ufvk(seed, len, g_chainTable[i].path);
+ zcash_ufvk_response = derive_zcash_ufvk(seed, seedLen, g_chainTable[i].path);
CHECK_AND_FREE_XPUB(zcash_ufvk_response)
zcashUfvk = zcash_ufvk_response->data;
- SimpleResponse_u8 *iv_response = rust_derive_iv_from_seed(seed, len);
+ SimpleResponse_u8 *iv_response = rust_derive_iv_from_seed(seed, seedLen);
//iv_response won't fail
uint8_t iv_bytes[16];
memcpy_s(iv_bytes, 16, iv_response->data, 16);
Why this scored 25/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.