keystore: pass private key to nonce_commit() and sign() #1534
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
Beerosagos
reviewed
Aug 19, 2025
| @@ -98,7 +98,10 @@ pub async fn process( | |||
| // Engage in the anti-klepto protocol if the host sends a host nonce commitment. | |||
| Some(pb::AntiKleptoHostNonceCommitment { ref commitment }) => { | |||
| let signer_commitment = keystore::secp256k1_nonce_commit( | |||
| keypath, | |||
| crate::keystore::secp256k1_get_private_key(keypath)? | |||
There was a problem hiding this comment.
Would it make sense to zeroize the privkey here and in the other places?
There was a problem hiding this comment.
The return type of secp256k1_get_private_key is zeroize::Zeroizing<Vec<u8>>, so it should zeroize automatically at the end of the statement.
There was a problem hiding this comment.
Aha! I missed that, sorry :)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.