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

keystore: pass private key to nonce_commit() and sign()

Public commit record

What the developer wrote

Authored by Marko Bencun

78/100 · Adequate
keystore: pass private key to nonce_commit() and sign()

End-goal: reduce the number of secure chip ops when signing a BTC
transaction, to reduce the chance of going over the Optiga chip's
"rate limit", which induces throttling.

With antiklepto, we derived the private key twice for each input that
is signed: once to commit to the nonce, and after that to sign.

This commit decouples the nonce commit and sign functions from the
underlying keystore, and allows reusing a private key instead of
re-deriving it, which requires secure chip operations.

This halves the number of secure chip ops needed per input when
signing a BTC transaction.

We do not reuse the privkey for the other instances of
antiklepto (signing a msg, signing an ETH tx), as there it's one
commit/sign pair only and unlikely to cause secure chip throttling.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit is a performance optimization for the BitBox02 hardware wallet. It changes how Bitcoin transaction signing uses the secure chip, so the device only derives a private key once per transaction input instead of twice. This reduces the chance of hitting the secure chip's rate limit and avoids throttling. The change does not appear to introduce a security flaw; it is a refactoring to reuse an already-derived key for two related signing steps.

Recommended action

No immediate action required. Reviewers should verify that all callers of keystore_secp256k1_sign() and keystore_secp256k1_nonce_commit() now perform keystore unlock checks and derive the private key securely before calling, and that the private key is zeroized promptly after use (e.g., the bitcoin/signtx.rs caller uses drop(private_key)).

Security signals we found

01

Removal of keystore_is_locked() check from keystore_secp256k1_sign()

02

Private key now passed by pointer into signing/nonce-commit functions instead of being derived inside them

03

Callers now responsible for key derivation and lock-state validation

04

Performance optimization to reduce Optiga secure chip operations, not a cryptographic change

Risk score

Why this scored 18/100

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