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: <nullius@nym.zone>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 85DBD1061
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 13 Jan 2018 03:44:35 +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 E955D124
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 13 Jan 2018 03:44:32 +0000 (UTC)
Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240])
(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 03BEF40FB6;
Sat, 13 Jan 2018 04:44:30 +0100 (CET)
X-Virus-Scanned: amavisd-new at heinlein-support.de
Received: from smtp1.mailbox.org ([80.241.60.240])
by gerste.heinlein-support.de (gerste.heinlein-support.de
[91.198.250.173]) (amavisd-new, port 10030)
with ESMTP id 03FeVrax8WOl; Sat, 13 Jan 2018 04:44:24 +0100 (CET)
Date: Sat, 13 Jan 2018 03:44:03 +0000
From: nullius <nullius@nym.zone>
To: Damian Williamson <willtech@live.com.au>,
bitcoin-dev@lists.linuxfoundation.org
Message-ID: <bd9283ec34396d769a84664ac5ae9206@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>
<3b45c17a256326b6b183587d9d15690c@nym.zone>
<PS2P216MB01793245561CC130C6FEEC9A9D140@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="lu6dihf52vl5bwhz"
Content-Disposition: inline
In-Reply-To: <PS2P216MB01793245561CC130C6FEEC9A9D140@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 13 Jan 2018 04:18:29 +0000
Subject: Re: [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: Sat, 13 Jan 2018 03:44:35 -0000
--lu6dihf52vl5bwhz
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Preface: As a longstanding policy, whenever I buy a new hard disk or=20
decommission an old one, I immediately `dd` it from start to end with a=20
pseudorandom byte stream. The result is indistinguishable from my disk=20
encryption setup, which leaves no apparent on-disk headers. I don=E2=80=99=
t do=20
this for =E2=80=9Cplausibility=E2=80=9D reasons, but rather, 0. to assure t=
hat=20
immediately upon use, any sectors written with disk encryption cannot be=20
distinguished from unwritten sectors, and 1. to make things overall more=20
fun for potential cryptanalysts. I do realize the small problem that I=20
can=E2=80=99t affirmatively prove any particular disk in my possession to *=
not*=20
contain decryptable data; and many of them don=E2=80=99t!
(I think that next, I may start writing my disks with headers for LUKS,=20
which I do not use...)
Whereupon, I challenge plausible deniability designers to `dd` a 6TB=20
disk with pseudorandom bytes, then try walking it across the U.S. border=20
until it gets searched. What could possibly go wrong? Should you be=20
ordered to decrypt it, the disk *could* be *plausibly* filled with=20
pseudorandom bytes; and you would not be committing the crime of lying=20
to an officer, when you truly state that in fact, it *is* filled with=20
pseudorandom bytes.
Please, I want to see this =E2=80=9Cplausible deniability=E2=80=9D theory i=
n action. =20
You owe it to your users to test the theory empirically, in=20
circumstances in which users have here reported applying it.
Now, in reply:
On 2018-01-13 at 02:11:08 +0000, Damian Williamson=20
<willtech@live.com.au> wrote:
>The same problems exist for users of whole disk encrypted operating=20
>systems. Once the device (or, the initial password authentication) is=20
>found, the adversary knows that there is something to see.
Or PGP. Or in a broader sense, Tor. Or in the physical world, a=20
high-security safe bolted to your floor. Security systems attract=20
attention. Smart people develop appropriate threat models, keep their=20
security systems confidential where it is practical to do so (don=E2=80=99t=
brag=20
about your high-security safe), and work to increase the popularity of=20
network security systems (PGP, HTTPS, Tor...) to reduce how much they=20
stand out.
In the context of this discussion, it does help that Bitcoin is becoming=20
popular. It would help much more if Trezors and similar devices were as=20
commonplace as iGadgets. But when considering the potential threats to=20
any specific individual, the only =E2=80=9Cplausibility=E2=80=9D shield is =
to not seem=20
like someone who is likely to have *much*. Of course, this is not a=20
problem specific to Bitcoin. Depending on the threat, the same danger=20
applies to owning a substantial amount of gold, cash, or even money in a=20
bank.
>The objective of plausible deniability is to present some acceptable=20
>(plausible) alternative while keeping the actual hidden (denied).
>
>If the adversary does not believe you, you do indeed risk everything.
And therein lies the trick. Unsophisticated adversaries such as common=20
criminals may be fooled, or may not care if they can quickly grab=20
*something* of value and run away. But if your threat model may=20
potentially include any adversaries possessed of both brains and=20
patience, =E2=80=9Cplausible deniability=E2=80=9D solves nothing. Such an =
adversary=20
will not likely be satisfied with the standard of =E2=80=9Cplausibility=E2=
=80=9D. More=20
likely, the prevailing standard will be: =E2=80=9CI wasn=E2=80=99t born ye=
sterday, and=20
I *know* that you are hiding something.=E2=80=9D
>[snip extended prior quotations]
--=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
--lu6dihf52vl5bwhz
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iHUEARYKAB0WIQSNOMR84IlYpr/EF5vEJ5MVn575SQUCWlmAgQAKCRDEJ5MVn575
SbJmAQCc8GnRjGkpPczqM1UWnBnBjBTMSnKhA33Nz6vhhGY5igD/bkdxeFxp2xsM
n6zBki5+Q0FGON6EOdc0bkS0rNYqog8=
=gQF+
-----END PGP SIGNATURE-----
--lu6dihf52vl5bwhz--
|
