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
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C4096F99
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 13 Jan 2018 06:11:18 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail148112.authsmtp.co.uk (outmail148112.authsmtp.co.uk
[62.13.148.112])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1950F14E
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 13 Jan 2018 06:11:17 +0000 (UTC)
Received: from mail-c245.authsmtp.com (mail-c245.authsmtp.com [62.13.128.245])
by punt24.authsmtp.com. (8.15.2/8.15.2) with ESMTP id w0D6BGFw079928;
Sat, 13 Jan 2018 06:11:16 GMT (envelope-from pete@petertodd.org)
Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com
[52.5.185.120]) (authenticated bits=0)
by mail.authsmtp.com (8.15.2/8.15.2) with ESMTPSA id w0D6BDon065958
(version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO);
Sat, 13 Jan 2018 06:11:14 GMT (envelope-from pete@petertodd.org)
Received: from [127.0.0.1] (localhost [127.0.0.1])
by petertodd.org (Postfix) with ESMTPSA id 620E040115;
Sat, 13 Jan 2018 06:11:13 +0000 (UTC)
Received: by localhost (Postfix, from userid 1000)
id BECDA20734; Sat, 13 Jan 2018 01:11:12 -0500 (EST)
Date: Sat, 13 Jan 2018 01:11:12 -0500
From: Peter Todd <pete@petertodd.org>
To: nullius <nullius@nym.zone>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20180113061112.GA14217@savin.petertodd.org>
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>
<bd9283ec34396d769a84664ac5ae9206@nym.zone>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="dDRMvlgZJXvWKvBx"
Content-Disposition: inline
In-Reply-To: <bd9283ec34396d769a84664ac5ae9206@nym.zone>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Server-Quench: 8fc50938-f828-11e7-9f3b-9cb654bb2504
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdwEUElQaAgsB Am4bW1JeUVx7WGY7 bghPaBtcak9QXgdq
T0pMXVMcUwUcB251 WUAeVBx7cg0IeXxy Y0IsViYIWURzdk5g
FEZWHXAHZDJndWlJ UxJFflAGdgZOLE1H b1B7GhFYa3VsNCMk
FAgyOXU9MCtqYBxR SxwWLFgWTA4nEzg9 ThoDGTQzDAVFfShh
ZycvNlkHHEcVO08p eUAsUkgVL31aEQ1X BUxBSDdDJkcIWydj
Dg5LFVUVEDBYTGY0
X-Authentic-SMTP: 61633532353630.1039:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 52.5.185.120/25
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
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
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 06:11:18 -0000
--dDRMvlgZJXvWKvBx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Jan 13, 2018 at 03:44:03AM +0000, nullius via bitcoin-dev wrote:
> (I think that next, I may start writing my disks with headers for LUKS,
> which I do not use...)
>=20
> Whereupon, I challenge plausible deniability designers to `dd` a 6TB disk
> with pseudorandom bytes, then try walking it across the U.S. border until=
it
> gets searched. What could possibly go wrong? Should you be ordered to
> decrypt it, the disk *could* be *plausibly* filled with pseudorandom byte=
s;
> and you would not be committing the crime of lying to an officer, when you
> truly state that in fact, it *is* filled with pseudorandom bytes.
It's very common for disks to be filled with pseudorandom data; this is not
suspicious at all. For example:
1) An encrypted partition that is filled, and later reformatted, will be le=
ft
full of random bytes. Even if you give border security your passphrase, the
unused space in the encrypted partition will be random data. (an exception
being most - but not all! - SSD's where TRIM has been used)
2) Modern drives (SSD and HD) often implement fast secure erasure with
encryption, which means that the actual data stored to disk or FLASH is
*always* encrypted. If such a drive is wiped, the encryption keys are repla=
ced,
which means whatever data was stored becomes random noise (the encrypted da=
ta
is usually not authenticated). This also means that such drives can arrive =
=66rom
the factory filled with random noise.
3) Software disk encryption schemes have the same property: reformatting
results in a drive filled with random noise.
The latter is particularly interesting with LUKS, as you can do all kinds of
things like erase the drive with luksErase, while keeping a backup of the L=
UKS
header elsewhere.
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
--dDRMvlgZJXvWKvBx
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJaWaL8AAoJECSBQD2l8JH7f5UIAK7uvIP8f9PuJGWFzo1El4EN
yqQtD5JjKxUwPc9TJQB000tGPAxpMH+Er+IKOBAF464tBwIJdXy4iJwUly+9olGD
1To/OaNrLoF1TIveXKpkAJJuaMDjoZePcV/DXbjCs+depRQRy7e9bzlo8IifVsNm
7b+J1QPDsVP8rHciLNljL2vBqMnmSpejuz5QrkCs5mO0wC7Ko9CAjN9lGG7m7gfq
R1N4OxXW9UNo2fhigh3JL9Jb6nXUrHU4PWz3+6exXsFHKx12V+tkWaYwPoBBZlHA
KjrH6xBnOnTvQeSYTTJxY957jTT+wt0Y0AhVFMN+4CP3/gw6xNwXaITo90ZqZ9I=
=n4n7
-----END PGP SIGNATURE-----
--dDRMvlgZJXvWKvBx--
|
