Re: [bitcoin-dev] Nonce blinding protocol for hardware wallets and airgapped signers

[Marko <mbencun@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2102 bytes --]

Thanks for starting this initiative; it has been a long standing goal of
mine to implement and release this protocol. Your blog post on the topic
actually inspired me to pick up this work again a few months ago.

Jonas Nick has implemented the protocol in the secp256k1 library for
Schnorr sigs here: https://github.com/bitcoin-core/secp256k1/pull/590

I have backported the same scheme to ECDSA in the secp256k1 library
here, so it can be used also for current transactions:

https://github.com/bitcoin-core/secp256k1/pull/669

I also made proof of concepts for the BitBox02 hw wallet firmware and
BitBoxApp wallet to verify that the protocol also works well in practice.

The actual scheme used in those implementations is a generalized
sign-to-contract scheme, where the final nonce is computed as `k' = k +
H(k*G, n)` instead of `k'=k+n`, but otherwise it works mostly the same
for the anti nonce covert channel protocol. I suggest to use this scheme
in PSBT as well.

> We can either use proprietary fields [4] or define key-value pairs and add
> them to the BIP-174. Depends if anyone else is interested in using this
> protocol or not.

I'd definitely be interested in seeing widespread support for this, and
standardizing it would help with that.

With PSBT used with an air-gapped signer, there is increased danger in
implementing the protocol wrongly by relying on the contents of the PSBT
alone in the final verification step of a signature. The PSBT must be
verified carefully against state stored by the host for the PSBT.
Otherwise the signer can for example change or pre-fill the relevant
NONCE fields and leak the private keys anyway. Is there a current best
practice for how a PSBT can be identified by the host to store/retrieve
the state?

Are there other examples in PSBT where the host can't trust the contents
of the PSBT the signer returns (except of course for the parts the user
can verify themselves, like recipients, amounts, etc.)? In any case,
guidelines or conventions on how to avoid the pitfalls would be good.

Best, Marko


[-- Attachment #2: 0x67A2B160F74DB275.asc --]
[-- Type: application/pgp-keys, Size: 8841 bytes --]