AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 32 Bitcoin

hsmtool: change hsm_secret struct to have length awareness

Public commit record

What the developer wrote

Authored by Sangbida Chaudhuri

73/100 · Adequate
hsmtool: change hsm_secret struct to have length awareness

This commit is updating hsmtool and exposesecrets to use the new pattern for storing the secret, which is the secret_data and secret_len, to support both 64 byte and 32 byte seeds.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit refactors how Core Lightning stores the wallet's master secret so the code can cleanly handle both old 32-byte seeds and new 64-byte mnemonic-based seeds. It removes a legacy fixed-size 'secret' field from the in-memory structure and makes callers use a length-aware 'secret_data' pointer instead. The change itself is a structural cleanup, not an obvious security bug, but it touches sensitive key-handling code and changes how memory is locked against swapping to disk. There is no vendor statement that this fixes a vulnerability.

Recommended action

Treat as a normal code-review item. Verify that sodium_mlock/sodium_munlock pairs remain balanced after the move to tal-allocated hsm_secret, that all callers now check secret_data length before use, and that no code path still assumes a fixed 32-byte secret. No urgent patch is indicated by the commit alone.

Security signals we found

01

Refactor of HSM secret storage to support variable-length seeds (32 vs 64 bytes)

02

Removal of legacy fixed-size secret field from struct hsm_secret

03

Global hsm_secret in hsmd changed from static struct to tal-allocated pointer

04

sodium_mlock call moved from init_hsm to load_hsm, now locks the full secret_data length

05

libhsmd key derivation now uses first 32 bytes of bip32_seed instead of a separate 32-byte mirror

06

BIP86 derivation checks now use tal_bytelen(bip32_seed) instead of a stored length field

07

No explicit security relevance, CVE, or researcher attribution in commit message

Risk score

Why this scored 32/100

Our methodology →
Potential impact 8/30
Exploitability 5/25
Stealth signal 4/15
Affected reach 6/15
Confidence 6/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.