path: root/6b/e7d15d29a7c6e9b2eb51a78bf3adc44feaa7c1

Return-Path: <dustinpaystaxes@gmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id BEEF9C013E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  2 Mar 2020 19:45:19 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id AB33A87852
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  2 Mar 2020 19:45:19 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id nDp22prAVzGg
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  2 Mar 2020 19:45:18 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com
 [209.85.210.43])
 by hemlock.osuosl.org (Postfix) with ESMTPS id B161387535
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  2 Mar 2020 19:45:18 +0000 (UTC)
Received: by mail-ot1-f43.google.com with SMTP id i14so507359otp.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 02 Mar 2020 11:45:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=dJ4gcB9TTpwzZ6QOGbHxuoVExREVKKSfL3IO5/IlAhM=;
 b=KlRyoN8G6i/xEOymrlxLih7OF0JHYthmOhjND7ocAM1+wUra2MGffcdtB/J6hEuqLC
 bhQLk+CL9+bmrk2dfI0yrp1vNFRkJjqk/F8lOfbd9GZCyWS0ZSdMfuUt66MkmgAytXCv
 UsVQQWBNKr/oUtl/Tq5c7GjcBN4EHybNuE9zaKEcYyVuggD6fABNcWzYIjCN+GO8ZFqk
 DjcmtIYmbXD58R5rW1PjKq9pF6eDQqqg0JecPf9daol+scHuLUvf/PY81iObG7RDzMre
 wxJ1EBd+hCX5c2MuzImo5E1SzK3Jv/UvTXJkFg83YSbpVg6XR8Pj1LpnT4NI25SRfPaA
 OWMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=dJ4gcB9TTpwzZ6QOGbHxuoVExREVKKSfL3IO5/IlAhM=;
 b=TqCvJUYEqODoJo3sQGN4thVoxzN/2MHr4YVv7kaKPtRBYX2G5BQd+E1c01L/JXb4nk
 tAjRlQBrRmNO1f0Lbjn77cYnLDK+HwLxCtJIoFCYD28Rs9yxyP4Xby3dGQQnCDb7kEI2
 cdu5suJkKowRisW8tAaih2ZuGkMhc7IGjPkO1qqMAdV22alpIq1f6CEEggmqe1p1eg5a
 tghZDKEksYsFRMUIyNmnW23rb7/cSSa8hjsoPKDlmQ2m2zRxZbqujPG2ph9ZkfqSvIuQ
 cCVyb+LWRTEuX5fujQ/8ENMuNvsgDSmVOmFBSAQxOVq7mFwdIR5FxS9F+Ls61KsIAe3P
 3SVw==
X-Gm-Message-State: ANhLgQ3YupE2x/Jeqam7qv02MpraIRIPzxezQG1TL82RQV6tK6F9A2aC
 6x6/rWURwFG10ieZUvv2GbAOW8a24UPAIbe5cugXKl5Q
X-Google-Smtp-Source: ADFU+vuaL2vCcu8nX9w2xMAtXGj7J1NM0m7q4PUnRvaF/FMUZkV6d0UyN7+On0jJVupseI1njDkU/rCUJIUziWnTaIo=
X-Received: by 2002:a9d:7d0c:: with SMTP id v12mr595244otn.171.1583178313619; 
 Mon, 02 Mar 2020 11:45:13 -0800 (PST)
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"
X-Mailman-Approved-At: Mon, 02 Mar 2020 19:55:42 +0000
Subject: Re: [bitcoin-dev] Nonce blinding protocol for hardware wallets and
 airgapped signers
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Mar 2020 19:45:19 -0000

--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--