From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id BEEF9C013E for ; 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 ; 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 ; 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 ; Mon, 2 Mar 2020 19:45:18 +0000 (UTC) Received: by mail-ot1-f43.google.com with SMTP id i14so507359otp.5 for ; 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: In-Reply-To: From: Dustin Dettmer Date: Mon, 2 Mar 2020 11:45:02 -0800 Message-ID: To: Bitcoin Protocol Discussion , Marko 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
+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 w= ere included in the standard as well.

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

On Fri, Feb 28, 2020 at 9:51 AM Mark= o via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Thanks for starting this initiative; it has been a lo= ng 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 sam= e
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 thi= s
> 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 content= s
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/mail= man/listinfo/bitcoin-dev
--000000000000046a21059fe46d76--