1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
|
Return-Path: <snigirev.stepan@gmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 31514C0177
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 28 Feb 2020 14:41:04 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id 206B885F79
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 28 Feb 2020 14:41:04 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id paH7FaJzP_JQ
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 28 Feb 2020 14:41:03 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com
[209.85.210.44])
by fraxinus.osuosl.org (Postfix) with ESMTPS id 74B1C85F0A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 28 Feb 2020 14:41:03 +0000 (UTC)
Received: by mail-ot1-f44.google.com with SMTP id h9so2729789otj.11
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 28 Feb 2020 06:41:03 -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
:cc; bh=L1+n4/oSFNcBz10NwWr9QxNv7gs0U6imeEW/jZP0sHw=;
b=SZ/rSfGO96I42DS3hlcojeSZaeJkQQu6wrc9/jPOctqtFB99Zez8o/Cs7tEFgrdzFf
2pisgXjRDpRct0BXo2ams1UPNA+aI3yJ0ESp2W7B9B8b2fpXofFyeGTbdL4+c+dLYAKP
51Og4O6a7SfpZ4QxeuKY+qaIuIHUn3p6i1+uo0ksVcNep0nN7IeOIxiJjNRv9AUXh4lh
amt0si/CxWjnJvvyfQ+InQbKD9v8esmyUax3afh1CAfntXwgYqUmav/HR5eh6UCGZIHc
kBMytNgjfRLrfHt3y+37zb0FqbVNaYiLdvtCxAIg2RfqpyA+D7FvKmKtwmBymfCHHthq
SuJg==
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:cc;
bh=L1+n4/oSFNcBz10NwWr9QxNv7gs0U6imeEW/jZP0sHw=;
b=SYolDY22+f+qeySfOuUM1Xjr9vVCjRGcHU8+FtxLpE84VpyibgMq5Ym31iZNhphRno
GvU5GgwbCtfEkTZMAPvv01j5+dpKERiH1PFcXdb7c2mreIUbeoI6jX8dHqW6pcbw99Yd
j8la1wjdfQEZ+XcQioLgCPDBJgYBwLmvw1+Ehwi2yLPs9qZdUAQ5mQFOejps3hFt9p9t
VDh1XNGEwJNeR1rTavsterwZwGTvnhyiHOAsnnRW/YleQQXRSczxwGswD79S38uLPdzu
W7E3a46L1eqy7WT8uaQBcy6iqZLLBPcHr738HZ4pvbOKRIttCF4QQ25eiFzYQToEHSiI
ZJTg==
X-Gm-Message-State: APjAAAWTVdq2bG+37zY6T+O/vZTFawBnVE/9YHVAsJDIJGy8wItwz8us
RsLq8H+7c/N2RsCiken8DDmNpgJYq1/J25fiing=
X-Google-Smtp-Source: APXvYqycqU2d1Dsx+23tFG54Ayk9anvBFEej02DKYm3Chh3402A4glUt3WqRL0/5KH+InveDDFJUotp1wrhm/vQUo8A=
X-Received: by 2002:a05:6830:9a:: with SMTP id
a26mr3632417oto.273.1582900861691;
Fri, 28 Feb 2020 06:41:01 -0800 (PST)
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"
X-Mailman-Approved-At: Fri, 28 Feb 2020 14:44:16 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Fri, 28 Feb 2020 14:41:04 -0000
--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>>=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>>=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--
|
