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--