From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id EFA03109B for ; Fri, 12 Jan 2018 11:07:26 +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 E8DF1D0 for ; Fri, 12 Jan 2018 11:07:25 +0000 (UTC) Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241]) (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 0682C40F30; Fri, 12 Jan 2018 12:07:23 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter01.heinlein-hosting.de (spamfilter01.heinlein-hosting.de [80.241.56.115]) (amavisd-new, port 10030) with ESMTP id ezySTvC_qR6h; Fri, 12 Jan 2018 12:06:54 +0100 (CET) Date: Fri, 12 Jan 2018 11:06:33 +0000 From: nullius To: Peter Todd , Bitcoin Protocol Discussion Message-ID: <3b45c17a256326b6b183587d9d15690c@nym.zone> References: <20180109011335.GA22039@savin.petertodd.org> <274aad5c-4573-2fdd-f8b0-c6c2d662ab7c@gibsonic.org> <20180112095058.GA9175@savin.petertodd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6xrzrp434kdop5dw" Content-Disposition: inline In-Reply-To: <20180112095058.GA9175@savin.petertodd.org> X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, URIBL_BLACK autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 12 Jan 2018 14:58:27 +0000 Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 11:07:27 -0000 --6xrzrp434kdop5dw Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2018-01-12 at 09:50:58 +0000, Peter Todd 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=20 >>>going to jail for lying to border security, because it's so easy for=20 >>>them to simply brute force alternate passwords based on your seeds. =20 >>>With that, they have proof that you lied to customs, a serious=20 >>>offense. >>The passphrase scheme as I understand it allows a maximum of 50=20 >>characters to be used.=C2=A0 Surely even with the HD seed, that search=20 >>space is too large to brute force.=C2=A0 Or is there a weakness in the=20 >>scheme I haven't clocked? > >While passphrases *can* be long, most user's aren't going to understand=20 >the risk. For example, Trezors blog(1) doesn't make it clear that the=20 >passphrases could be bruteforced and used as evidence against you, and=20 >even suggests the contrary: [...quote...] I despise the term =E2=80=9Cplausible deniability=E2=80=9D; and that=E2=80= =99s really the wrong=20 term to use in this discussion. =E2=80=9CPlausible deniability=E2=80=9D is a transparent excuse for explain= ing away an=20 indisputable fact which arouses suspicion=E2=80=94when you got some serious= =20 =E2=80=99splain=E2=80=99 to do. This is usually used in the context of som= e pseudolegal=20 argument about introducing =E2=80=9Creasonable doubt=E2=80=9D, or even maki= ng =E2=80=9Cprobable=20 cause=E2=80=9D a wee bit less probable. =E2=80=9CWhy yes, officer: I was seen carrying an axe down the street near= the=20 site of an axe murder, at approximately the time of said axe murder. =20 But I do have a fireplace; so it is plausible that I was simply out=20 gathering wood.=E2=80=9D I rather suspect the concept of =E2=80=9Cplausible deniability=E2=80=9D of = having been=20 invented by a detective or agent provocateur. There are few concepts=20 more useful for helping suspects shoot themselves in the foot, or=20 frankly, for entrapping people. One of the worst examples I have seen is in discussions of Monero,=20 whereby I=E2=80=99ve seen proponents claim that even under the worst known= =20 active attacks, their mix scheme reduces transaction linking to a=20 maximum of 20=E2=80=9340% probability. =E2=80=9CThat=E2=80=99s not good en= ough to convince a=20 jury!=E2=80=9D No, but it is certainly adequate for investigators to ident= ify=20 you as a person of interest. Then, your (mis)deeds can be subjected to=20 powerful confirmation attacks based on other data; blockchains do not=20 exist in isolation. I usually stay out of such discussions; for I have=20 no interest in helping the sorts of people whose greatest concern in=20 life is what story to foist on a jury. In the context of devices such as Trezor, what is needed is not=20 =E2=80=9Cplausible deniability=E2=80=9D, but rather the ability to obviate = any need to=20 deny anything at all. I must repeat, information does not exist in=20 isolation. If you are publicly known to be deepy involved in Bitcoin, then nobody=20 will believe that your one-and-only wallet contains only 0.01 BTC. =20 That=E2=80=99s not even =E2=80=9Cplausible=E2=80=9D. But if you have overa= ll privacy practices=20 which leave nobody knowing or suspecting that you have any Bitcoin at=20 all, then there is nothing to =E2=80=9Cdeny=E2=80=9D; and should a Trezor w= ith=20 (supposedly) 0.01 BTC be found in your possession, that=E2=80=99s much bett= er=20 than =E2=80=9Cplausible=E2=80=9D. It=E2=80=99s completely unremarkable. Whereas if you are known or believed to own large amounts of BTC, a=20 realistic bad guy=E2=80=99s response to your =E2=80=9Cdecoy=E2=80=9D wallet= could be, =E2=80=9CI don=E2=80=99t=20 believe you; and it costs me nothing to keep beating you with rubber=20 hose until you tell me the *real* password.=E2=80=9D It could be worse, too. In a kidnapping scenario, the bad guys could=20 say, =E2=80=9CI don=E2=80=99t believe you. Hey, I also read Trezor=E2=80= =99s website about=20 =E2=80=98plausible deniability=E2=80=99. Now, I will maim your kid for lif= e just to=20 test whether you told me the *real* password. And if you still don=E2=80= =99t=20 tell me the real password after you see that little Johnny can no longer=20 walk, then I will kill him.=E2=80=9D The worst part is that you have no means of proving that you really=20 *did* give the real password. Indeed, it can be proved if you=E2=80=99re l= ying=20 by finding a password which reveals a hidden wallet=E2=80=94but *you* have = no=20 means of affirmatively proving that you are telling the truth! If the=20 bad guys overestimated your riches (or if they=E2=80=99re in a bad mood), t= hen=20 little Johnny is dead either way. In a legalistic scenario, if =E2=80=9Cauthorities=E2=80=9D believe you have= 1000 BTC and=20 you only reveal a password for 0.01 BTC, the likely response will not be=20 to let you go. Rather, =E2=80=9CYou will now sit in jail until you tell th= e=20 *real* password.=E2=80=9D And again: You have no means of proving that yo= u did=20 give the real password! =E2=80=9CPlausible deniability=E2=80=9D schemes can backfire quite badly. >Also note how this blog doesn't mention anti-forensics: the wallet=20 >software itself may leave traces of the other wallets on the computer. =20 >Have they really audited it sufficiently to be sure this isn't the=20 >case? What about data obtained via the network? I don=E2=80=99t *only* refer to= =20 dragnet surveillance. See for but one e.g., Goldfelder, et al., =E2=80=9CW= hen=20 the cookie meets the blockchain: Privacy risks of web payments via=20 cryptocurrencies=E2=80=9D https://arxiv.org/abs/1708.04748 Your identity c= an be=20 tied to your wallet all sorts of ways, any of which could be used to=20 prove that you have more Bitcoin than you=E2=80=99re revealing. Do you kno= w=20 what databases of cross-correlated analysis data customs agents have=20 immediate access to nowadays=E2=80=94or will, tomorrow? I don=E2=80=99t. In the scenario under discussion, that may not immediately prove =E2=80=9Cb= eyond=20 a reasonable doubt=E2=80=9D that you lied specifically about your Trezor. = But=20 it could give plenty of cause to keep you locked up in a small room=20 while your hard drive is examined for evidence that Trezor apps handled=20 *addresses already known to be linked to you*. Why even bother with=20 bruteforce? Low-hanging fruit abound. >1) https://blog.trezor.io/hide-your-trezor-wallets-with-multiple-passphras= es-f2e0834026eb --=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 --6xrzrp434kdop5dw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQSNOMR84IlYpr/EF5vEJ5MVn575SQUCWliWtwAKCRDEJ5MVn575 ScHjAQDhLmNjBs8rl5BOsGJ0aSgXAtbQFEPXkuPIn1iOqpjL/QEAyc3G4TDfqlto dnfZGFod+E7HLv7kk+7gexhC8EJEGQs= =hEh7 -----END PGP SIGNATURE----- --6xrzrp434kdop5dw--