MIME-Version: 1.0
References: <CACL8y1vNEOfATJvkYTOV3pZQA5uac3hbTe9Onfz-38zJUzL_Ug@mail.gmail.com>
 <c6709c19-a6b2-37a8-0d58-4800126f145f@gmail.com>
In-Reply-To: <c6709c19-a6b2-37a8-0d58-4800126f145f@gmail.com>
From: Dustin Dettmer <dustinpaystaxes@gmail.com>
Date: Mon, 2 Mar 2020 11:45:02 -0800
Message-ID: <CABLeJxQHav=3itLiWCjHGhuEk84JA=WFmLSE4iTa_Cv5cDYizg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Marko <mbencun@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000046a21059fe46d76"
Subject: Re: [bitcoin-dev] Nonce blinding protocol for hardware wallets and
 airgapped signers
Precedence: list

--000000000000046a21059fe46d76
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

+1 love that progress is being made on this. Excited to implement it once
it=E2=80=99s ready.

Would love if things like the incrementing number were included in the
standard as well.

Cheers! =F0=9F=8D=BB

On Fri, Feb 28, 2020 at 9:51 AM Marko via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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' =3D k +
> H(k*G, n)` instead of `k'=3Dk+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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000046a21059fe46d76
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div><div dir=3D"auto">+1 love that progress is being made on this. Excited=
 to implement it once it=E2=80=99s ready.</div></div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">Would love if things like the incrementing number w=
ere included in the standard as well.</div><div dir=3D"auto"><br></div><div=
 dir=3D"auto">Cheers! =F0=9F=8D=BB</div><div><br><div class=3D"gmail_quote"=
><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Feb 28, 2020 at 9:51 AM Mark=
o via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.o=
rg">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">Thanks for starting this initiative; it has been a lo=
ng standing goal of<br>
mine to implement and release this protocol. Your blog post on the topic<br=
>
actually inspired me to pick up this work again a few months ago.<br>
<br>
Jonas Nick has implemented the protocol in the secp256k1 library for<br>
Schnorr sigs here: <a href=3D"https://github.com/bitcoin-core/secp256k1/pul=
l/590" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin-core=
/secp256k1/pull/590</a><br>
<br>
I have backported the same scheme to ECDSA in the secp256k1 library<br>
here, so it can be used also for current transactions:<br>
<br>
<a href=3D"https://github.com/bitcoin-core/secp256k1/pull/669" rel=3D"noref=
errer" target=3D"_blank">https://github.com/bitcoin-core/secp256k1/pull/669=
</a><br>
<br>
I also made proof of concepts for the BitBox02 hw wallet firmware and<br>
BitBoxApp wallet to verify that the protocol also works well in practice.<b=
r>
<br>
The actual scheme used in those implementations is a generalized<br>
sign-to-contract scheme, where the final nonce is computed as `k&#39; =3D k=
 +<br>
H(k*G, n)` instead of `k&#39;=3Dk+n`, but otherwise it works mostly the sam=
e<br>
for the anti nonce covert channel protocol. I suggest to use this scheme<br=
>
in PSBT as well.<br>
<br>
&gt; We can either use proprietary fields [4] or define key-value pairs and=
 add<br>
&gt; them to the BIP-174. Depends if anyone else is interested in using thi=
s<br>
&gt; protocol or not.<br>
<br>
I&#39;d definitely be interested in seeing widespread support for this, and=
<br>
standardizing it would help with that.<br>
<br>
With PSBT used with an air-gapped signer, there is increased danger in<br>
implementing the protocol wrongly by relying on the contents of the PSBT<br=
>
alone in the final verification step of a signature. The PSBT must be<br>
verified carefully against state stored by the host for the PSBT.<br>
Otherwise the signer can for example change or pre-fill the relevant<br>
NONCE fields and leak the private keys anyway. Is there a current best<br>
practice for how a PSBT can be identified by the host to store/retrieve<br>
the state?<br>
<br>
Are there other examples in PSBT where the host can&#39;t trust the content=
s<br>
of the PSBT the signer returns (except of course for the parts the user<br>
can verify themselves, like recipients, amounts, etc.)? In any case,<br>
guidelines or conventions on how to avoid the pitfalls would be good.<br>
<br>
Best, Marko<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>

--000000000000046a21059fe46d76--