public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

From: Marko <mbencun@gmail•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Nonce blinding protocol for hardware wallets and airgapped signers
Date: Fri, 28 Feb 2020 18:42:15 +0100	[thread overview]
Message-ID: <c6709c19-a6b2-37a8-0d58-4800126f145f@gmail.com> (raw)
In-Reply-To: <CACL8y1vNEOfATJvkYTOV3pZQA5uac3hbTe9Onfz-38zJUzL_Ug@mail.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 --]

next prev parent reply	other threads:[~2020-02-28 17:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-27  2:59 Stepan Snigirev
2020-02-28 13:31 ` ZmnSCPxj
2020-02-28 14:40   ` Stepan Snigirev
2020-02-28 17:42 ` Marko [this message]
2020-03-02 19:45   ` Dustin Dettmer
2020-03-02 20:01 ` Dustin Dettmer
2020-02-27  3:26 freedom

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c6709c19-a6b2-37a8-0d58-4800126f145f@gmail.com \
    --to=mbencun@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox