From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YIOZZ-0005hD-3H for bitcoin-development@lists.sourceforge.net; Mon, 02 Feb 2015 21:30:21 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of niftybox.net designates 95.142.167.147 as permitted sender) client-ip=95.142.167.147; envelope-from=c1.sf-bitcoin@niftybox.net; helo=i3.hyper.to; Received: from i3.hyper.to ([95.142.167.147]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1YIOZS-00042y-0P for bitcoin-development@lists.sourceforge.net; Mon, 02 Feb 2015 21:30:18 +0000 Received: from localhost (localhost [127.0.0.1]) by i3.hyper.to (Postfix) with ESMTP id 681CBE01D2; Mon, 2 Feb 2015 22:30:07 +0100 (CET) Received: from i3.hyper.to ([127.0.0.1]) by localhost (i3.hyper.to [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id z36947-kLKvr; Mon, 2 Feb 2015 22:30:05 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by i3.hyper.to (Postfix) with ESMTP id CCAACE01D4; Mon, 2 Feb 2015 22:30:05 +0100 (CET) X-Virus-Scanned: amavisd-new at i3.hyper.to Received: from i3.hyper.to ([127.0.0.1]) by localhost (i3.hyper.to [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 73LmCbe1fXfZ; Mon, 2 Feb 2015 22:30:05 +0100 (CET) Received: from [10.1.10.188] (142-254-47-143.dsl.dynamic.sonic.net [142.254.47.143]) by i3.hyper.to (Postfix) with ESMTPSA id 05549E01D2; Mon, 2 Feb 2015 22:30:04 +0100 (CET) Message-ID: <54CFEC5B.3040008@niftybox.net> Date: Mon, 02 Feb 2015 13:30:03 -0800 From: devrandom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Pedro Worcel , bitcoin-development@lists.sourceforge.net References: <27395C55-CF59-4E65-83CA-73F903272C5F@gmail.com> <54CE3816.6020505@bitwatch.co> <68C03646-02E7-43C6-9B73-E4697F3AA5FD@gmail.com> <57186618-F010-42E6-A757-B617C4001B5B@gmail.com> <4B53C1B0-A677-4460-8A69-C45506424D7F@gmail.com> <54CFE780.1040400@worcel.com> In-Reply-To: <54CFE780.1040400@worcel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1YIOZS-00042y-0P Subject: Re: [Bitcoin-development] Proposal to address Bitcoin malware X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 21:30:21 -0000 There are a couple of attack vectors to consider: * The recipient's machine is compromised * The sender's machine is compromised BIP-70 and other ways of having the sender verify the destination on a second device will help protect against sender compromise. For a person-to-person situation, you could verify the address by voice. For the case where the recipient is compromised, you would want to verify the address with the recipient's multisig security service. Extending BIP-70 to allow multiple signatures would be one way to go about this. You would at least want to have a web page controlled by the security service where you can verify addresses. On 2015-02-02 01:09 PM, Pedro Worcel wrote: > Where would you verify that? >=20 > On 2/3/2015 10:03 AM, Brian Erdelyi wrote: >> Joel, >> >> The mobile device should show you the details of the transaction (i.e. >> amount and bitcoin address). Once you verify this is the intended >> recipient and amount you approve it on the mobile device. If the >> address was replaced, you should see this on the mobile device as it >> won=92t match where you were intending to send it. You can then not >> provide the second signature. >> >> Brian Erdelyi >> >>> On Feb 2, 2015, at 4:57 PM, Joel Joonatan Kaartinen >>> > wrote: >>> >>> If the attacker has your desktop computer but not the mobile that's >>> acting as an independent second factor, how are you then supposed to >>> be able to tell you're not signing the correct transaction on the >>> mobile? If the address was replaced with the attacker's address, >>> it'll look like everything is ok. >>> >>> - Joel >>> >>> On Mon, Feb 2, 2015 at 9:58 PM, Brian Erdelyi >>> > wrote: >>> >>> >>> > Confusing or not, the reliance on multiple signatures as >>> offering greater security than single relies on the independence >>> of multiple secrets. If the secrets cannot be shown to retain >>> independence in the envisioned threat scenario (e.g. a user's >>> compromised operating system) then the benefit reduces to making >>> the exploit more difficult to write, which, once written, reduces >>> to no benefit. Yet the user still suffers the reduced utility >>> arising from greater complexity, while being led to believe in a >>> false promise. >>> >>> Just trying to make sure I understand what you=92re saying. Are >>> you eluding to that if two of the three private keys get >>> compromised there is no gain in security? Although the >>> likelihood of this occurring is lower, it is possible. >>> >>> As more malware targets bitcoins I think the utility is evident.=20 >>> Given how final Bitcoin transactions are, I think it=92s worth >>> trying to find methods to help verify those transactions (if a >>> user deems it to be high-risk enough) before the transaction is >>> completed. The balance is trying to devise something that users >>> do not find too burdensome. >>> >>> Brian Erdelyi >>> -----------------------------------------------------------------= ------------- >>> Dive into the World of Parallel Programming. The Go Parallel Webs= ite, >>> sponsored by Intel and developed in partnership with Slashdot >>> Media, is your >>> hub for all things parallel software development, from weekly tho= ught >>> leadership blogs to news, videos, case studies, tutorials and >>> more. Take a >>> look and join the conversation now. >>> http://goparallel.sourceforge.net/ >>> _______________________________________________ >>> Bitcoin-development mailing list >>> Bitcoin-development@lists.sourceforge.net >>> >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >>> >>> >> >> >> >> ----------------------------------------------------------------------= -------- >> Dive into the World of Parallel Programming. The Go Parallel Website, >> sponsored by Intel and developed in partnership with Slashdot Media, i= s your >> hub for all things parallel software development, from weekly thought >> leadership blogs to news, videos, case studies, tutorials and more. Ta= ke a >> look and join the conversation now. http://goparallel.sourceforge.net/ >> >> >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >=20 >=20 >=20 > -----------------------------------------------------------------------= ------- > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is= your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Tak= e a > look and join the conversation now. http://goparallel.sourceforge.net/ >=20 >=20 >=20 > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >=20 --=20 devrandom / Miron