public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: nullius <nullius@nym.zone>
To: Peter Todd <pete@petertodd.org>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] Plausible Deniability (Re: Satoshilabs secret shared private key scheme)
Date: Fri, 12 Jan 2018 11:06:33 +0000	[thread overview]
Message-ID: <3b45c17a256326b6b183587d9d15690c@nym.zone> (raw)
In-Reply-To: <20180112095058.GA9175@savin.petertodd.org>

[-- Attachment #1: Type: text/plain, Size: 6466 bytes --]

On 2018-01-12 at 09:50:58 +0000, Peter Todd <pete@petertodd.org> wrote:
>On Tue, Jan 09, 2018 at 12:43:48PM +0000, Perry Gibson wrote:
>>>Trezor's "plausible deniability" scheme could very well result in you 
>>>going to jail for lying to border security, because it's so easy for 
>>>them to simply brute force alternate passwords based on your seeds.  
>>>With that, they have proof that you lied to customs, a serious 
>>>offense.
>>The passphrase scheme as I understand it allows a maximum of 50 
>>characters to be used.  Surely even with the HD seed, that search 
>>space is too large to brute force.  Or is there a weakness in the 
>>scheme I haven't clocked?
>
>While passphrases *can* be long, most user's aren't going to understand 
>the risk. For example, Trezors blog(1) doesn't make it clear that the 
>passphrases could be bruteforced and used as evidence against you, and 
>even suggests the contrary:  [...quote...]

I despise the term “plausible deniability”; and that’s really the wrong 
term to use in this discussion.

“Plausible deniability” is a transparent excuse for explaining away an 
indisputable fact which arouses suspicion—when you got some serious 
’splain’ to do.  This is usually used in the context of some pseudolegal 
argument about introducing “reasonable doubt”, or even making “probable 
cause” a wee bit less probable.

“Why yes, officer:  I was seen carrying an axe down the street near the 
site of an axe murder, at approximately the time of said axe murder.  
But I do have a fireplace; so it is plausible that I was simply out 
gathering wood.”

I rather suspect the concept of “plausible deniability” of having been 
invented by a detective or agent provocateur.  There are few concepts 
more useful for helping suspects shoot themselves in the foot, or 
frankly, for entrapping people.

One of the worst examples I have seen is in discussions of Monero, 
whereby I’ve seen proponents claim that even under the worst known 
active attacks, their mix scheme reduces transaction linking to a 
maximum of 20–40% probability.  “That’s not good enough to convince a 
jury!”  No, but it is certainly adequate for investigators to identify 
you as a person of interest.  Then, your (mis)deeds can be subjected to 
powerful confirmation attacks based on other data; blockchains do not 
exist in isolation.  I usually stay out of such discussions; for I have 
no interest in helping the sorts of people whose greatest concern in 
life is what story to foist on a jury.

In the context of devices such as Trezor, what is needed is not 
“plausible deniability”, but rather the ability to obviate any need to 
deny anything at all.  I must repeat, information does not exist in 
isolation.

If you are publicly known to be deepy involved in Bitcoin, then nobody 
will believe that your one-and-only wallet contains only 0.01 BTC.  
That’s not even “plausible”.  But if you have overall privacy practices 
which leave nobody knowing or suspecting that you have any Bitcoin at 
all, then there is nothing to “deny”; and should a Trezor with 
(supposedly) 0.01 BTC be found in your possession, that’s much better 
than “plausible”.  It’s completely unremarkable.

Whereas if you are known or believed to own large amounts of BTC, a 
realistic bad guy’s response to your “decoy” wallet could be, “I don’t 
believe you; and it costs me nothing to keep beating you with rubber 
hose until you tell me the *real* password.”

It could be worse, too.  In a kidnapping scenario, the bad guys could 
say, “I don’t believe you.  Hey, I also read Trezor’s website about 
‘plausible deniability’.  Now, I will maim your kid for life just to 
test whether you told me the *real* password.  And if you still don’t 
tell me the real password after you see that little Johnny can no longer 
walk, then I will kill him.”

The worst part is that you have no means of proving that you really 
*did* give the real password.  Indeed, it can be proved if you’re lying 
by finding a password which reveals a hidden wallet—but *you* have no 
means of affirmatively proving that you are telling the truth!  If the 
bad guys overestimated your riches (or if they’re in a bad mood), then 
little Johnny is dead either way.

In a legalistic scenario, if “authorities” believe you have 1000 BTC and 
you only reveal a password for 0.01 BTC, the likely response will not be 
to let you go.  Rather, “You will now sit in jail until you tell the 
*real* password.”  And again:  You have no means of proving that you did 
give the real password!

“Plausible deniability” schemes can backfire quite badly.

>Also note how this blog doesn't mention anti-forensics: the wallet 
>software itself may leave traces of the other wallets on the computer.  
>Have they really audited it sufficiently to be sure this isn't the 
>case?

What about data obtained via the network?  I don’t *only* refer to 
dragnet surveillance.  See for but one e.g., Goldfelder, et al., “When 
the cookie meets the blockchain:  Privacy risks of web payments via 
cryptocurrencies” https://arxiv.org/abs/1708.04748  Your identity can be 
tied to your wallet all sorts of ways, any of which could be used to 
prove that you have more Bitcoin than you’re revealing.  Do you know 
what databases of cross-correlated analysis data customs agents have 
immediate access to nowadays—or will, tomorrow?  I don’t.

In the scenario under discussion, that may not immediately prove “beyond 
a reasonable doubt” that you lied specifically about your Trezor.  But 
it could give plenty of cause to keep you locked up in a small room 
while your hard drive is examined for evidence that Trezor apps handled 
*addresses already known to be linked to you*.  Why even bother with 
bruteforce?  Low-hanging fruit abound.

>1) https://blog.trezor.io/hide-your-trezor-wallets-with-multiple-passphrases-f2e0834026eb

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

  reply	other threads:[~2018-01-12 11:07 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             ` nullius [this message]
2018-01-13  2:11               ` [bitcoin-dev] Plausible Deniability (Re: Satoshilabs secret shared private key scheme) Damian Williamson
2018-01-13  3:44                 ` nullius
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=3b45c17a256326b6b183587d9d15690c@nym.zone \
    --to=nullius@nym.zone \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=pete@petertodd.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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