summaryrefslogtreecommitdiff
path: root/a9/1d416dede76be99eb509a95f95f19df7dbbb52
blob: 0637b936c517880fe54ea09f07fc606f10bbb8e0 (plain)
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>&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--