summaryrefslogtreecommitdiff
path: root/4c/2fa9c4b3b6c7fb1e961b4b67b4b8564439dcda
blob: 34ad20d57ff4f1f54ee58976914e2fe7ae25c018 (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
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
Return-Path: <dustinpaystaxes@gmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 147CDC0177
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 24 Mar 2020 14:51:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id F194220353
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 24 Mar 2020 14:51:45 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 2JGU1DnYw74C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 24 Mar 2020 14:51:44 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com
 [209.85.210.53])
 by silver.osuosl.org (Postfix) with ESMTPS id C50FC20130
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 24 Mar 2020 14:51:44 +0000 (UTC)
Received: by mail-ot1-f53.google.com with SMTP id t28so17258230ott.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 24 Mar 2020 07:51:44 -0700 (PDT)
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=d5t1CC3OY82+eJr3LFKb7oijMWko8JYNCJYfk5p0M1Q=;
 b=ozSJ5uPtaafY1CFuPSaspEGV+OFhgZh2qGZcjo/xSF2jyt1Nof9nB5/G/fU8onpe8S
 DeMm0XTa4Amaqgbaod7bPhf1Oe0wgwBb3SHsYw6h39ZJNbwi94XJ7pQEkLzlRByeLri0
 lYOSYEtrrUyQZJ6Gh22HaOlJccI1wnjt019SbIYP1fnjYzk5jbC04pt1HUzyuTd78NKw
 zTDvRpkvyBKElNIdejBuhJSXIArWwQEn9Cfni1CyfI1meKFQgDzOTNMsj5F9M5chzlvQ
 T94FTprFGLYYFy0Rln4N8m3+7kNIFSCzbwe7dcXgL5DcfANIuSJucHBwo7uDtcyAGE9Q
 K2/A==
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=d5t1CC3OY82+eJr3LFKb7oijMWko8JYNCJYfk5p0M1Q=;
 b=Sh0mTM9FniU/SOTHU3PgWtnNv7/Mmf/IELrOh1FNQ82hp4xMOYfAOJYC5uvZ9AJaGm
 Y+HXIbM7PdivKKvOiDhn6FhwPNV3RuKcjO8JKzQvLZBxq7NQ0B8kSjY5/vkmDXqNGFd5
 xqqfxGJ6bAcWVHXfmM6c/2tRPZIg6vxwAUDoMs+1lFy1XGLhhHLVxFfjwlE9FyvlbUc6
 A/Xy3auJo+DabEUBvjd4IS5sEwdY4R8cvBo3sAM/fGZ3UWSr368hE7dk8a7fmhQ10SeP
 oDkMCwUkj5siS8PP8H+R3NEr7TlFTtv1RXakq4wXPaDy5fMgNcZ8s+UMr/vOpmg9/vfV
 cPcQ==
X-Gm-Message-State: ANhLgQ1PwycyGCJgXAiBveCzoXJYjeplklNOxbAN+Mxz8d2kTzPo9sHK
 s2FtYSL34s8O2e81NQEwESPGLiS/AzvVmfhaugQ=
X-Google-Smtp-Source: ADFU+vsek+n9c6MV+0JbX38RIMfAMELfYds4n+B9tBObq9HmFKfaiaSWNf/lkULQaHGhuwQwzJRaaGeR7tnvFVoD67M=
X-Received: by 2002:a05:6830:2428:: with SMTP id
 k8mr2436404ots.345.1585061503721; 
 Tue, 24 Mar 2020 07:51:43 -0700 (PDT)
MIME-Version: 1.0
References: <VZTbLR9RlkkyNg6mOOIxedh7H0g8NGlaCmgBfCVXZ4RNfW3axefgoTqZGXjAQZFEuekujVGjRMv8SifDIodZ6tRGaaXQ_R63rFa03SGS6rg=@wuille.net>
 <CABLeJxQsse99aw35DxSDOyVTruFCgi0hmZntvgbYtPLSRGQ+xA@mail.gmail.com>
 <c182227876c47f476000b0b54618dac73e45a03f.camel@timruffing.de>
In-Reply-To: <c182227876c47f476000b0b54618dac73e45a03f.camel@timruffing.de>
From: Dustin Dettmer <dustinpaystaxes@gmail.com>
Date: Tue, 24 Mar 2020 07:51:32 -0700
Message-ID: <CABLeJxT6aZxrFn4apHOrELcdo37iGhmwsLH-BJxNb4Sbhotbog@mail.gmail.com>
To: Tim Ruffing <crypto@timruffing.de>
Content-Type: multipart/alternative; boundary="000000000000e085ba05a19ae3e9"
X-Mailman-Approved-At: Tue, 24 Mar 2020 15:01:16 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Overview of anti-covert-channel signing techniques
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: Tue, 24 Mar 2020 14:51:46 -0000

--000000000000e085ba05a19ae3e9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Tim,

Hm, so what vectors is this supposed to mitigate? Leaking through the
> generated public keys? Anything else?


The main thing it=E2=80=99s protecting against is the stealing of your fund=
s by
malicious hardware & software. There are some side benefits as well though.

 - What are you trying to achieve? You seem to describe how you get
> from the setup to the goal in four steps but I don't understand what
> the setup is or what the goal is. (What's a storage solution?)


=E2=80=9CStorage solution=E2=80=9D is however you=E2=80=99re storing bitcoi=
ns today. Could be 12
words on some paper plus a computer running electrum. Could be a Ledger +
computer. Point is this technique works regardless of how you=E2=80=99re st=
oring
your bitcoin.

 - "all SW being compromised" do you mean "SW and HW compromised"? Note
> that SW and HW are parties in Pieter's writeup, not just abbreviations
> for software and hardware.


Yeah =E2=80=94 if you split the SW party into two, =E2=80=9Cgenerator=E2=80=
=9D and =E2=80=9Cvalidator=E2=80=9D some
interesting and useful security properties emerge.

 - Where are the two stages? You mention four steps.


=E2=80=9CGenerator=E2=80=9D and =E2=80=9Cvalidator=E2=80=9D. The generator =
creates and passes on receiving
addresses and withdrawal transactions (while remaining offline). The
validator double checks everything the generator did..

It works best if the validator is written entirely independently of the
generator.

 - Where do you run the external software? On a second SW? Is this the
> second stage?


Yes

 - Do you use unhardened derivation?


It=E2=80=99s an open ended solution =E2=80=94 it would work with a (presuma=
bly
non-trivial/random) unhardened derivation just fine.

 - What's a k commitment?


It is one of the proposed solutions presented (collected?) by Peter in this
thread. As I understand it k is used to generate R in the signature. By
committing to some k value the hardware wallet can=E2=80=99t =E2=80=9Csneak=
 out=E2=80=9D your
private key(s) in the R value.

Best,
Dustin

>

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

<div><div dir=3D"auto">Hi Tim,</div></div><div dir=3D"auto"><br></div><div>=
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hm, so what vecto=
rs is this supposed to mitigate? Leaking through the<br>
generated public keys? Anything else?</blockquote><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">The main thing it=E2=80=99s protecting against is the =
stealing of your funds by malicious hardware &amp; software. There are some=
 side benefits as well though.<br></div><div dir=3D"auto"><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">=C2=A0- What are you trying to achieve? You seem to=
 describe how you get<br>
from the setup to the goal in four steps but I don&#39;t understand what<br=
>
the setup is or what the goal is. (What&#39;s a storage solution?)</blockqu=
ote><div dir=3D"auto"><br></div><div dir=3D"auto">=E2=80=9CStorage solution=
=E2=80=9D is however you=E2=80=99re storing bitcoins today. Could be 12 wor=
ds on some paper plus a computer running electrum. Could be a Ledger + comp=
uter. Point is this technique works regardless of how you=E2=80=99re storin=
g your bitcoin.</div><div dir=3D"auto"><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">
=C2=A0- &quot;all SW being compromised&quot; do you mean &quot;SW and HW co=
mpromised&quot;? Note<br>
that SW and HW are parties in Pieter&#39;s writeup, not just abbreviations<=
br>
for software and hardware. </blockquote><div dir=3D"auto"><br></div><div di=
r=3D"auto">Yeah =E2=80=94 if you split the SW party into two, =E2=80=9Cgene=
rator=E2=80=9D and =E2=80=9Cvalidator=E2=80=9D some interesting and useful =
security properties emerge.</div><div dir=3D"auto"><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
=C2=A0- Where are the two stages? You mention four steps.</blockquote><div =
dir=3D"auto"><br></div><div dir=3D"auto">=E2=80=9CGenerator=E2=80=9D and =
=E2=80=9Cvalidator=E2=80=9D. The generator creates and passes on receiving =
addresses and withdrawal transactions (while remaining offline). The valida=
tor double checks everything the generator did..</div><div dir=3D"auto"><br=
></div><div dir=3D"auto">It works best if the validator is written entirely=
 independently of the generator.</div><div dir=3D"auto"><br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">
=C2=A0- Where do you run the external software? On a second SW? Is this the=
<br>
second stage?</blockquote><div dir=3D"auto"><br></div><div dir=3D"auto">Yes=
</div><div dir=3D"auto"><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
=C2=A0- Do you use unhardened derivation?</blockquote><div dir=3D"auto"><br=
></div><div dir=3D"auto">It=E2=80=99s an open ended solution =E2=80=94 it w=
ould work with a (presumably non-trivial/random) unhardened derivation just=
 fine.</div><div dir=3D"auto"><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
=C2=A0- What&#39;s a k commitment?</blockquote><div dir=3D"auto"><br></div>=
<div dir=3D"auto">It is one of the proposed solutions presented (collected?=
) by Peter in this thread. As I understand it k is used to generate R in th=
e signature. By committing to some k value the hardware wallet can=E2=80=99=
t =E2=80=9Csneak out=E2=80=9D your private key(s) in the R value.</div><div=
 dir=3D"auto"><br></div><div dir=3D"auto">Best,</div><div dir=3D"auto">Dust=
in</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div>

--000000000000e085ba05a19ae3e9--