MIME-Version: 1.0
References: <CACL8y1vNEOfATJvkYTOV3pZQA5uac3hbTe9Onfz-38zJUzL_Ug@mail.gmail.com>
 <Uq2NsrNplL04Cy7WTEEE7Yumjd2l2hqzYlbC31GnRajh8218N-1zeHvFZ6oxdYa-gDpbGHUGH6FvKbkZokzQygz_jRkIKt3sZe0HC2WmqT4=@protonmail.com>
In-Reply-To: <Uq2NsrNplL04Cy7WTEEE7Yumjd2l2hqzYlbC31GnRajh8218N-1zeHvFZ6oxdYa-gDpbGHUGH6FvKbkZokzQygz_jRkIKt3sZe0HC2WmqT4=@protonmail.com>
From: Stepan Snigirev <snigirev.stepan@gmail.com>
Date: Fri, 28 Feb 2020 15:40:21 +0100
Message-ID: <CACL8y1sgMDMZpnfa86sRpejSdO3ieVKGvq3NqZ+oe0wr6tk1kw@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000936c8e059fa3d3e0"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Nonce blinding protocol for hardware wallets and
 airgapped signers
Precedence: list

--000000000000936c8e059fa3d3e0
Content-Type: text/plain; charset="UTF-8"

Dear ZmnSCPxj,

> I think it would be unsafe to use a deterministic scheme, that takes as
input the message m and the privkey only.

Yes, using only the message and the private key is unsafe. Signer should
use all the data coming from the host, so f(sha256(n), m, privkey) is a
good candidate. If more than one blinding factor is sent - all of them
should be used as well.

> Otherwise a completely-random `k` would be much better, but the signer
might not have enough resources to gather sufficient entropy.

I am not a big fan of pure RNG-generated nonces, so I would suggest to use
this entropy only as additional data for a deterministic scheme.
For example, Yubikey had a problem with RNG initialization that caused
leakage of the private key [1].
If the signer has any source of entropy, even if it is not a very good one,
the entropy from this source can be mixed into the nonce generation
function:
f(sha256(n),m,privkey,entropy).

Another issue is that deterministic nonce generation is vulnerable to
glitch attacks - if I ask the wallet to sign the same message twice but
after nonce generation I glitch and flip a bit in the message, I will get
two signatures with the same nonce but with different messages - from these
signatures I can calculate the private key.
So I would recommend to include a monotonic counter into the nonce
generation function as well: f(sha256(n), m, privkey, entropy, counter)
As usual, counter should be increased _before_ signing.

Ref: [1]
https://www.yubico.com/support/security-advisories/ysa-2019-02/#technical-details

Best,
Stepan

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

<div dir=3D"ltr"><div>Dear ZmnSCPxj,</div><div><br></div><div>&gt;=C2=A0I t=
hink it would be unsafe to use a deterministic scheme, that takes as input =
the message m and the privkey only.</div><div><br></div><div>Yes, using onl=
y the message and the private key is unsafe. Signer should use all the data=
 coming from the host, so f(sha256(n), m, privkey) is a good candidate. If =
more than one blinding factor is sent - all of them should be used as well.=
</div><div><br></div><div>&gt;=C2=A0Otherwise a completely-random `k` would=
 be much better, but the signer might not have enough resources to gather s=
ufficient entropy.</div><div><br></div><div>I am not a big fan of pure RNG-=
generated nonces, so I would suggest to use this entropy only as additional=
 data for a deterministic scheme.</div><div>For example, Yubikey had a prob=
lem with RNG initialization that caused leakage of the private key [1].</di=
v><div>If the signer has any source of entropy, even if it is not a very go=
od one, the entropy from this source can be mixed into the nonce generation=
 function:</div><div>f(sha256(n),m,privkey,entropy).</div><div><br></div><d=
iv>Another issue is that deterministic nonce generation is vulnerable to gl=
itch attacks - if I ask the wallet to sign the same message twice but after=
 nonce generation  I glitch and flip a bit in the message, I will get two s=
ignatures with the same nonce but with different messages - from these sign=
atures I can calculate the private key.=C2=A0</div><div>So I would recommen=
d to include a monotonic counter into the nonce generation function as well=
:=C2=A0f(sha256(n), m, privkey, entropy, counter)</div><div>As usual, count=
er should be increased _before_ signing.</div><div><br></div><div>Ref: [1]=
=C2=A0<a href=3D"https://www.yubico.com/support/security-advisories/ysa-201=
9-02/#technical-details">https://www.yubico.com/support/security-advisories=
/ysa-2019-02/#technical-details</a></div><div><br></div><div>Best,</div><di=
v>Stepan</div></div>

--000000000000936c8e059fa3d3e0--