From: nullius <nullius@nym•zone>
To: Damian Williamson <willtech@live•com.au>,
bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Plausible Deniability (Re: Satoshilabs secret shared private key scheme)
Date: Sat, 13 Jan 2018 03:44:03 +0000 [thread overview]
Message-ID: <bd9283ec34396d769a84664ac5ae9206@nym.zone> (raw)
In-Reply-To: <PS2P216MB01793245561CC130C6FEEC9A9D140@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
[-- Attachment #1: Type: text/plain, Size: 3931 bytes --]
Preface: As a longstanding policy, whenever I buy a new hard disk or
decommission an old one, I immediately `dd` it from start to end with a
pseudorandom byte stream. The result is indistinguishable from my disk
encryption setup, which leaves no apparent on-disk headers. I don’t do
this for “plausibility” reasons, but rather, 0. to assure that
immediately upon use, any sectors written with disk encryption cannot be
distinguished from unwritten sectors, and 1. to make things overall more
fun for potential cryptanalysts. I do realize the small problem that I
can’t affirmatively prove any particular disk in my possession to *not*
contain decryptable data; and many of them don’t!
(I think that next, I may start writing my disks with headers for LUKS,
which I do not use...)
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 bytes; 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.
Please, I want to see this “plausible deniability” theory in action.
You owe it to your users to test the theory empirically, in
circumstances in which users have here reported applying it.
Now, in reply:
On 2018-01-13 at 02:11:08 +0000, Damian Williamson
<willtech@live•com.au> wrote:
>The same problems exist for users of whole disk encrypted operating
>systems. Once the device (or, the initial password authentication) is
>found, the adversary knows that there is something to see.
Or PGP. Or in a broader sense, Tor. Or in the physical world, a
high-security safe bolted to your floor. Security systems attract
attention. Smart people develop appropriate threat models, keep their
security systems confidential where it is practical to do so (don’t brag
about your high-security safe), and work to increase the popularity of
network security systems (PGP, HTTPS, Tor...) to reduce how much they
stand out.
In the context of this discussion, it does help that Bitcoin is becoming
popular. It would help much more if Trezors and similar devices were as
commonplace as iGadgets. But when considering the potential threats to
any specific individual, the only “plausibility” shield is to not seem
like someone who is likely to have *much*. Of course, this is not a
problem specific to Bitcoin. Depending on the threat, the same danger
applies to owning a substantial amount of gold, cash, or even money in a
bank.
>The objective of plausible deniability is to present some acceptable
>(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
criminals may be fooled, or may not care if they can quickly grab
*something* of value and run away. But if your threat model may
potentially include any adversaries possessed of both brains and
patience, “plausible deniability” solves nothing. Such an adversary
will not likely be satisfied with the standard of “plausibility”. More
likely, the prevailing standard will be: “I wasn’t born yesterday, and
I *know* that you are hiding something.”
>[snip extended prior quotations]
--
nullius@nym•zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE)
“‘If you’re not doing anything wrong, you have nothing to hide.’
No! Because I do nothing wrong, I have nothing to show.” — nullius
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2018-01-13 3:44 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-08 4:22 [bitcoin-dev] Satoshilabs secret shared private key scheme Gregory Maxwell
2018-01-08 6:33 ` nullius
2018-01-08 12:39 ` Pavol Rusnak
2018-01-08 12:45 ` Peter Todd
2018-01-08 13:00 ` Pavol Rusnak
2018-01-08 19:37 ` Peter Todd
2018-01-08 22:26 ` Ben Kloester
2018-01-09 0:37 ` Peter Todd
2018-01-08 23:47 ` Gregory Maxwell
2018-01-09 0:40 ` Rhavar
2018-01-09 1:13 ` Peter Todd
2018-01-09 12:44 ` jens
[not found] ` <274aad5c-4573-2fdd-f8b0-c6c2d662ab7c@gibsonic.org>
2018-01-12 9:50 ` Peter Todd
2018-01-12 11:06 ` [bitcoin-dev] Plausible Deniability (Re: Satoshilabs secret shared private key scheme) nullius
2018-01-13 2:11 ` Damian Williamson
2018-01-13 3:44 ` nullius [this message]
2018-01-13 6:11 ` Peter Todd
2018-01-09 15:12 ` [bitcoin-dev] Satoshilabs secret shared private key scheme Pavol Rusnak
2018-01-10 20:28 ` Pavol Rusnak
2018-01-10 23:47 ` Gregory Maxwell
2018-01-11 9:55 ` Pavol Rusnak
2018-01-09 16:20 ` Russell O'Connor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bd9283ec34396d769a84664ac5ae9206@nym.zone \
--to=nullius@nym$(echo .)zone \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=willtech@live$(echo .)com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox