From: Peter Todd <pete@petertodd•org>
To: nullius <nullius@nym•zone>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Plausible Deniability (Re: Satoshilabs secret shared private key scheme)
Date: Sat, 13 Jan 2018 01:11:12 -0500 [thread overview]
Message-ID: <20180113061112.GA14217@savin.petertodd.org> (raw)
In-Reply-To: <bd9283ec34396d769a84664ac5ae9206@nym.zone>
[-- Attachment #1: Type: text/plain, Size: 1829 bytes --]
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...)
>
> 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.
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 left
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 replaced,
which means whatever data was stored becomes random noise (the encrypted data
is usually not authenticated). This also means that such drives can arrive from
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 LUKS
header elsewhere.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
next prev parent reply other threads:[~2018-01-13 6:11 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
2018-01-13 6:11 ` Peter Todd [this message]
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=20180113061112.GA14217@savin.petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=nullius@nym$(echo .)zone \
/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