summaryrefslogtreecommitdiff
path: root/ab/bf650b1df7e1ee76f436104c32547d6fd68ed8
blob: 71b15d911d3b0c902f6e62ac913a6dbb2da8e23c (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
215
216
217
218
219
220
221
222
223
224
225
226
227
Return-Path: <nullius@nym.zone>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id EFA03109B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 12 Jan 2018 11:07:26 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mx2.mailbox.org (mx2.mailbox.org [80.241.60.215])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E8DF1D0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 12 Jan 2018 11:07:25 +0000 (UTC)
Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mx2.mailbox.org (Postfix) with ESMTPS id 0682C40F30;
	Fri, 12 Jan 2018 12:07:23 +0100 (CET)
X-Virus-Scanned: amavisd-new at heinlein-support.de
Received: from smtp2.mailbox.org ([80.241.60.241])
	by spamfilter01.heinlein-hosting.de (spamfilter01.heinlein-hosting.de
	[80.241.56.115]) (amavisd-new, port 10030)
	with ESMTP id ezySTvC_qR6h; Fri, 12 Jan 2018 12:06:54 +0100 (CET)
Date: Fri, 12 Jan 2018 11:06:33 +0000
From: nullius <nullius@nym.zone>
To: Peter Todd <pete@petertodd.org>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <3b45c17a256326b6b183587d9d15690c@nym.zone>
References: <CAAS2fgR-or=zksQ929Muvgr=sgzNSugGp669ZWYC6YkvEG=H5w@mail.gmail.com>
	<ae570ccf-3a2c-a11c-57fa-6dad78cfb1a5@satoshilabs.com>
	<CAAS2fgRQvpa8VXE8YAYSfugDvCu=1+5ANsGk1V_OXtHPGD=Ltw@mail.gmail.com>
	<vJsDz9YdeNQQ_PZRf5HP1W0FmcWyKHIuwN9QeNgN-WXCdQcRmXLtkQ3wfTO7YUCgG6AFgOkKeU6fdsGTKkGcnk-_OOY_jyNlfWkFQ31d2ZU=@protonmail.com>
	<20180109011335.GA22039@savin.petertodd.org>
	<274aad5c-4573-2fdd-f8b0-c6c2d662ab7c@gibsonic.org>
	<20180112095058.GA9175@savin.petertodd.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="6xrzrp434kdop5dw"
Content-Disposition: inline
In-Reply-To: <20180112095058.GA9175@savin.petertodd.org>
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,
	URIBL_BLACK autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 12 Jan 2018 14:58:27 +0000
Subject: [bitcoin-dev] Plausible Deniability (Re: Satoshilabs secret shared
 private key scheme)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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, 12 Jan 2018 11:07:27 -0000


--6xrzrp434kdop5dw
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2018-01-12 at 09:50:58 +0000, Peter Todd <pete@petertodd.org> wrote:
>On Tue, Jan 09, 2018 at 12:43:48PM +0000, Perry Gibson wrote:
>>>Trezor's "plausible deniability" scheme could very well result in you=20
>>>going to jail for lying to border security, because it's so easy for=20
>>>them to simply brute force alternate passwords based on your seeds. =20
>>>With that, they have proof that you lied to customs, a serious=20
>>>offense.
>>The passphrase scheme as I understand it allows a maximum of 50=20
>>characters to be used.=C2=A0 Surely even with the HD seed, that search=20
>>space is too large to brute force.=C2=A0 Or is there a weakness in the=20
>>scheme I haven't clocked?
>
>While passphrases *can* be long, most user's aren't going to understand=20
>the risk. For example, Trezors blog(1) doesn't make it clear that the=20
>passphrases could be bruteforced and used as evidence against you, and=20
>even suggests the contrary:  [...quote...]

I despise the term =E2=80=9Cplausible deniability=E2=80=9D; and that=E2=80=
=99s really the wrong=20
term to use in this discussion.

=E2=80=9CPlausible deniability=E2=80=9D is a transparent excuse for explain=
ing away an=20
indisputable fact which arouses suspicion=E2=80=94when you got some serious=
=20
=E2=80=99splain=E2=80=99 to do.  This is usually used in the context of som=
e pseudolegal=20
argument about introducing =E2=80=9Creasonable doubt=E2=80=9D, or even maki=
ng =E2=80=9Cprobable=20
cause=E2=80=9D a wee bit less probable.

=E2=80=9CWhy yes, officer:  I was seen carrying an axe down the street near=
 the=20
site of an axe murder, at approximately the time of said axe murder. =20
But I do have a fireplace; so it is plausible that I was simply out=20
gathering wood.=E2=80=9D

I rather suspect the concept of =E2=80=9Cplausible deniability=E2=80=9D of =
having been=20
invented by a detective or agent provocateur.  There are few concepts=20
more useful for helping suspects shoot themselves in the foot, or=20
frankly, for entrapping people.

One of the worst examples I have seen is in discussions of Monero,=20
whereby I=E2=80=99ve seen proponents claim that even under the worst known=
=20
active attacks, their mix scheme reduces transaction linking to a=20
maximum of 20=E2=80=9340% probability.  =E2=80=9CThat=E2=80=99s not good en=
ough to convince a=20
jury!=E2=80=9D  No, but it is certainly adequate for investigators to ident=
ify=20
you as a person of interest.  Then, your (mis)deeds can be subjected to=20
powerful confirmation attacks based on other data; blockchains do not=20
exist in isolation.  I usually stay out of such discussions; for I have=20
no interest in helping the sorts of people whose greatest concern in=20
life is what story to foist on a jury.

In the context of devices such as Trezor, what is needed is not=20
=E2=80=9Cplausible deniability=E2=80=9D, but rather the ability to obviate =
any need to=20
deny anything at all.  I must repeat, information does not exist in=20
isolation.

If you are publicly known to be deepy involved in Bitcoin, then nobody=20
will believe that your one-and-only wallet contains only 0.01 BTC. =20
That=E2=80=99s not even =E2=80=9Cplausible=E2=80=9D.  But if you have overa=
ll privacy practices=20
which leave nobody knowing or suspecting that you have any Bitcoin at=20
all, then there is nothing to =E2=80=9Cdeny=E2=80=9D; and should a Trezor w=
ith=20
(supposedly) 0.01 BTC be found in your possession, that=E2=80=99s much bett=
er=20
than =E2=80=9Cplausible=E2=80=9D.  It=E2=80=99s completely unremarkable.

Whereas if you are known or believed to own large amounts of BTC, a=20
realistic bad guy=E2=80=99s response to your =E2=80=9Cdecoy=E2=80=9D wallet=
 could be, =E2=80=9CI don=E2=80=99t=20
believe you; and it costs me nothing to keep beating you with rubber=20
hose until you tell me the *real* password.=E2=80=9D

It could be worse, too.  In a kidnapping scenario, the bad guys could=20
say, =E2=80=9CI don=E2=80=99t believe you.  Hey, I also read Trezor=E2=80=
=99s website about=20
=E2=80=98plausible deniability=E2=80=99.  Now, I will maim your kid for lif=
e just to=20
test whether you told me the *real* password.  And if you still don=E2=80=
=99t=20
tell me the real password after you see that little Johnny can no longer=20
walk, then I will kill him.=E2=80=9D

The worst part is that you have no means of proving that you really=20
*did* give the real password.  Indeed, it can be proved if you=E2=80=99re l=
ying=20
by finding a password which reveals a hidden wallet=E2=80=94but *you* have =
no=20
means of affirmatively proving that you are telling the truth!  If the=20
bad guys overestimated your riches (or if they=E2=80=99re in a bad mood), t=
hen=20
little Johnny is dead either way.

In a legalistic scenario, if =E2=80=9Cauthorities=E2=80=9D believe you have=
 1000 BTC and=20
you only reveal a password for 0.01 BTC, the likely response will not be=20
to let you go.  Rather, =E2=80=9CYou will now sit in jail until you tell th=
e=20
*real* password.=E2=80=9D  And again:  You have no means of proving that yo=
u did=20
give the real password!

=E2=80=9CPlausible deniability=E2=80=9D schemes can backfire quite badly.

>Also note how this blog doesn't mention anti-forensics: the wallet=20
>software itself may leave traces of the other wallets on the computer. =20
>Have they really audited it sufficiently to be sure this isn't the=20
>case?

What about data obtained via the network?  I don=E2=80=99t *only* refer to=
=20
dragnet surveillance.  See for but one e.g., Goldfelder, et al., =E2=80=9CW=
hen=20
the cookie meets the blockchain:  Privacy risks of web payments via=20
cryptocurrencies=E2=80=9D https://arxiv.org/abs/1708.04748  Your identity c=
an be=20
tied to your wallet all sorts of ways, any of which could be used to=20
prove that you have more Bitcoin than you=E2=80=99re revealing.  Do you kno=
w=20
what databases of cross-correlated analysis data customs agents have=20
immediate access to nowadays=E2=80=94or will, tomorrow?  I don=E2=80=99t.

In the scenario under discussion, that may not immediately prove =E2=80=9Cb=
eyond=20
a reasonable doubt=E2=80=9D that you lied specifically about your Trezor.  =
But=20
it could give plenty of cause to keep you locked up in a small room=20
while your hard drive is examined for evidence that Trezor apps handled=20
*addresses already known to be linked to you*.  Why even bother with=20
bruteforce?  Low-hanging fruit abound.

>1) https://blog.trezor.io/hide-your-trezor-wallets-with-multiple-passphras=
es-f2e0834026eb

--=20
nullius@nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG)  (PGP RSA: 0x36EBB4AB699A10EE)
=E2=80=9C=E2=80=98If you=E2=80=99re not doing anything wrong, you have noth=
ing to hide.=E2=80=99
No!  Because I do nothing wrong, I have nothing to show.=E2=80=9D =E2=80=94=
 nullius

--6xrzrp434kdop5dw
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQSNOMR84IlYpr/EF5vEJ5MVn575SQUCWliWtwAKCRDEJ5MVn575
ScHjAQDhLmNjBs8rl5BOsGJ0aSgXAtbQFEPXkuPIn1iOqpjL/QEAyc3G4TDfqlto
dnfZGFod+E7HLv7kk+7gexhC8EJEGQs=
=hEh7
-----END PGP SIGNATURE-----

--6xrzrp434kdop5dw--