CommitWatch RSS
AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 13 Bitcoin

external: add and use secp256k1-zkp directly, remove libwally-core

BBaa3703cd View source ↗
Public commit record

What the developer wrote

Authored by Marko Bencun

85/100 · Strong
external: add and use secp256k1-zkp directly, remove libwally-core

We currently use secp256k1-zkp as bundled by libwally-core. As we
remove libwally-core as dependency, and need to directly include
secp256k1-zkp.

We use a new branch of our fork rebased on current upstream master,
because they added CMake support.

This removes another ~6.4kB from the resulting multi binary.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This commit swaps out an internal cryptographic library dependency. The firmware previously used a library called libwally-core, which bundled a special version of the secp256k1 elliptic-curve code. The change removes libwally-core and uses secp256k1-zkp directly. This is a build-system and dependency refactor, not a fix for a known attack. It slightly reduces firmware size and changes how the code is compiled and linked. There is no direct evidence in the commit that this resolves a security vulnerability, but any change to core crypto code carries a small risk that build settings could alter behavior.

Recommended action

Treat this as a routine dependency refactor with low security urgency. Verify that the new secp256k1-zkp build options preserve the intended memory/performance trade-offs and that no libwally-core-specific functionality was silently lost. Run the existing cryptographic test suite and firmware integration tests. If a security advisory is later published for libwally-core or the old bundled secp256k1, reassess.

Security signals we found

01

Change to core elliptic-curve cryptography dependency (secp256k1)

02

Build configuration changes for secp256k1-zkp (ecmult window size, gen precision bits, module recovery)

03

Removal of libwally-core wrapper, which may have provided additional abstraction or hardening

04

No explicit security bug, CVE, or vulnerability description in commit or references

Risk score

Why this scored 13/100

Our methodology →
Potential impact 2/30
Exploitability 2/25
Stealth signal 1/15
Affected reach 3/15
Confidence 3/10
Evidence quality 2/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.

More from BitBox02 firmware

Related watches

Moderate 60 AI analysisMessage 90 · Strong
BB BitBoxBitBox02 firmware BitcoinHardware wallets

backup: validate decoded seed length

This update fixes a bug in how the BitBox02 hardware wallet reads backup files from an SD card. A tampered backup file could claim to contain a seed longer than the 32-byte limit, which previously caused the device to panic (crash) when li…

Out-of-bounds/panic condition in backup parsingMissing input validation on decoded protobuf fieldSD-card backup file could be attacker-controlled
80baf1eeby benma's agent+34−01 file
Vendor flagged security relevance
Open full analysis →Source commit ↗
Low 39 AI analysisMessage 73 · Adequate
BB BitBoxBitBox02 firmware BitcoinHardware wallets

rust: initialize C output buffers

This commit fixes a class of low-level memory-safety bugs where Rust code was given buffers containing uninitialized bytes. Rust's rules require every byte of a slice to be initialized, even if the function will overwrite them. Passing uni…

Undefined behavior at C/Rust FFI due to uninitialized buffers being treated as Rust slicesPotential optimizer-dependent behavior from violating Rust slice initialization rulesHardening of cryptographic output paths (SHA-256, HMAC-SHA256, HMAC-SHA512)
511018eaby benma's agent+52−2713 files
Vendor flagged security relevance
Open full analysis →Source commit ↗
High 74 AI analysisMessage 78 · Adequate
BB BitBoxBitBox02 firmware BitcoinHardware wallets

eth: limit EIP-712 recursion depth

This commit adds a hard limit on how deeply nested Ethereum typed-message (EIP-712) structures can be when the BitBox02 hardware wallet signs them. Without the limit, an attacker could craft a message type that refers to itself over and ov…

Adds explicit recursion-depth cap to attacker-controlled input parsingPre-validates schema roots before host callbacks or user confirmationProtects against stack exhaustion / denial-of-service from deeply nested EIP-712 types
4ccadcc0by benma's agent+196−451 file
No security note in commit
Open full analysis →Source commit ↗