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
151
152
153
154
155
156
157
158
159
160
161
162
163
164
|
Return-Path: <roconnor@blockstream.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 8A3E4C0177
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 26 Feb 2020 03:26:56 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 79AC486447
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 26 Feb 2020 03:26:56 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id EIce5kNhXZJe
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 26 Feb 2020 03:26:55 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-io1-f45.google.com (mail-io1-f45.google.com
[209.85.166.45])
by whitealder.osuosl.org (Postfix) with ESMTPS id 4106B85ADB
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 26 Feb 2020 03:26:55 +0000 (UTC)
Received: by mail-io1-f45.google.com with SMTP id c17so1744977ioc.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 25 Feb 2020 19:26:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockstream-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=1aWiMNfgQanO5E/gp57MKqEXn2Hg/UMOBOUqpDOIBEU=;
b=Z18bJ5ar25qa00+H6y8JjJ/TZLtt5uH8qPwCEBywTLLRp68hxhuR7sw+ioq9M7PDjz
eBOyKDvXxpulul/MjUOQ9bBtu7zjx9X332efO7PAHOUMxRfq5MB8tyqrTx5HjkOMmiaX
VGBGcKQMkgBxCgy9BX1uVvYgmvsP232SWLQmP84ksBcZcP/nsKKqYQ2cd/pRksCxJJnr
D1gcVzjAYRK+VKlcuz6xTTSvnVl1C7JrcACIABeETPbON9vqkdOoZQLELq4aZBp9Yo7j
7kP2Cu3sNz4u3m3ymHRzpeBLYMq7OJZM9VBb521a4J4TqeVIwWp60oY4z69y9vRIcyes
dXnA==
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=1aWiMNfgQanO5E/gp57MKqEXn2Hg/UMOBOUqpDOIBEU=;
b=n+qcZzOglquiX4L2bG6gryLceTaEybX+l046tG3T1aEPS3Ce1E2xxv9eLE7v3llYJr
DgmPEqu155im3uw28yWd/YXo0C+CqPedCiUL6bd8tyu4j5jjtFwOVk7v1SP8dyjoEIMj
mPTSQsTJ2i5MLGZ/7krcTPVxF7szIV7uzixfS5VzKJJ3v/U/AfT3jrhARgFGTEKGD4c6
1Sxs3n86MtY03ZsFqFZFhlLcbcc6BPCHRe7sjveTfdCXNqxFzzVKXYsVem8n94D3yPmL
BfFbLBReJyoiJsNeKMunYIhj0UPWxaZ0UywGL9g/PsY461sNHDLlfabOgkpt/WOs2gt+
4b+w==
X-Gm-Message-State: APjAAAUu11LMFczZqrPkxyJzE6UOGQWp8jFQSjdgysLI1GFLE3ldCQkM
yKvTETqv3FMrOrx+ECRUEj018t8+Xehi/sK9Lmr1uZ2h2YZxqw==
X-Google-Smtp-Source: APXvYqys/v5RkwOF3Gu8erDHA8L3o63/D5+ERH2O12Yn2eCYHgbgDmZ8HfdxCGhTiDb41/BFC4BsynlUNt9IHx792V4=
X-Received: by 2002:a6b:710f:: with SMTP id q15mr2072619iog.103.1582687614104;
Tue, 25 Feb 2020 19:26:54 -0800 (PST)
MIME-Version: 1.0
References: <CAPg+sBgxvRM5ncQAnbNLN=4bdkQrM+-DxibMoTG+6gqk7EY9hQ@mail.gmail.com>
<CAMZUoKkAebw6VzSco3F+wnLptNwsCiEw23t2pLj0xitiOSszMQ@mail.gmail.com>
In-Reply-To: <CAMZUoKkAebw6VzSco3F+wnLptNwsCiEw23t2pLj0xitiOSszMQ@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Tue, 25 Feb 2020 22:26:42 -0500
Message-ID: <CAMZUoK=RDkNZM=hSZu2OMoH1y=nrx57weefu1ow8ZnX7wSOErw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000007aec8059f722d96"
Subject: [bitcoin-dev] Fwd: BIP 340 updates: even pubkeys,
more secure nonce generation
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: Wed, 26 Feb 2020 03:26:56 -0000
--00000000000007aec8059f722d96
Content-Type: text/plain; charset="UTF-8"
On Sun, Feb 23, 2020 at 11:26 PM Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> 2. Nonce generation
>
> All other semantical changes are around more secure nonce generation
> in BIP 340, dealing with various failure cases:
>
> * To protect against fault injection attacks it is recommended to
> include actual signing-time randomness into the nonce generation
> process. This was mentioned already, but the update elaborates much
> more about this, and integrates this randomness into the standard
> signing process.
>
I do worry that standardizing on a non-deterministic nonce generation
scheme makes the problem of private key exfiltration a much bigger concern
in the application of hardware signing devices.
While sorely imperfect, with a deterministic nonce scheme, we at least have
the option of spot checking hardware devices to see if they are producing
signatures in accordance with their specified nonce scheme. But short of
providing some kind of certificate, we won't be able to do such checks
against hardware devices that use the proposed synthetic nonce. (Question:
can a hardware device safely output the random value 'a' it used its
"certificate"? AFAIU 'a' is not considered secret data; it just needs to
be not under attacker control. Should hardware wallets be encouraged to
return this value?)
The best way to mitigate this is to use the Nonce exfiltration protection
mentioned; however there are no references on how to do this. Ideally we'd
standardize this Nonce exfiltration protection scheme within this synthetic
nonce scheme. However, I don't think it is worth holding this BIP up on
that; it seems reasonable to introduce a new section to this BIP addressing
that problem in the future. Maybe instead we can get references to more
information about this Nonce exfiltration protection that is mentioned?
Really I just want to do whatever we reasonably can do to avoid a world
where we end up providing hardware signing devices with a hard to detect
underhanded communications channel.
--00000000000007aec8059f722d96
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sun, Feb 23, 2020 at 11:26 PM Pieter Wuille via bitcoin=
-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br><div class=
=3D"gmail_quote"><div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
rgb(204,204,204);padding-left:1ex"><br>
2. Nonce generation<br>
<br>
All other semantical changes are around more secure nonce generation<br>
in BIP 340, dealing with various failure cases:<br>
<br>
* To protect against fault injection attacks it is recommended to<br>
include actual signing-time randomness into the nonce generation<br>
process. This was mentioned already, but the update elaborates much<br>
more about this, and integrates this randomness into the standard<br>
signing process.<br></blockquote><div><br></div><div>I do worry that standa=
rdizing on a non-deterministic nonce generation scheme makes the problem of=
private key exfiltration a much bigger concern in the application of hardw=
are signing devices.</div><div>While sorely imperfect, with a deterministic=
nonce scheme, we at least have the option of spot checking hardware device=
s to see if they are producing signatures in accordance with their specifie=
d nonce scheme.=C2=A0 But short of providing some kind of certificate, we w=
on't be able to do such checks against hardware devices that use the pr=
oposed synthetic nonce. (Question: can a hardware device safely output the =
random value 'a' it used its "certificate"?=C2=A0 AFAIU &=
#39;a' is not considered secret data; it just needs to be not under att=
acker control.=C2=A0 Should hardware wallets be encouraged to return this v=
alue?)</div><div><br></div><div>The best way to mitigate this is to use the=
Nonce exfiltration protection mentioned; however there are no references o=
n how to do this.=C2=A0 Ideally we'd standardize this Nonce exfiltratio=
n protection scheme within this synthetic nonce scheme.=C2=A0 However, I do=
n't think it is worth holding this BIP up on that; it seems reasonable =
to introduce a new section to this BIP addressing that problem in the futur=
e.=C2=A0 Maybe instead we can get references to more information about this=
Nonce exfiltration protection that is mentioned?</div><div><br></div><div>=
Really I just want to do whatever we reasonably can do to avoid a world whe=
re we end up providing hardware signing devices with a hard to detect under=
handed communications channel.<br></div></div></div>
</div></div>
--00000000000007aec8059f722d96--
|
