Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YIOMo-0007a9-EE for bitcoin-development@lists.sourceforge.net; Mon, 02 Feb 2015 21:17:10 +0000 X-ACL-Warn: Received: from mail-ie0-f171.google.com ([209.85.223.171]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YIOMm-0007Q6-Se for bitcoin-development@lists.sourceforge.net; Mon, 02 Feb 2015 21:17:10 +0000 Received: by mail-ie0-f171.google.com with SMTP id tr6so20537162ieb.2 for ; Mon, 02 Feb 2015 13:17:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=9ibKguJO7B9UVBywE99rcVEytTy6IsYo313qpbhF2lI=; b=DX+8D8dJO94A3vJY2wQsN4Yx2X4tJ3Tsdgzn+Wmd4T1pGzjx98v5s98hQBA+vEij9l xKzfQLYctB3Av91OcvcKYXC1vNPOT5LgGB2X2kr9egjQLZ3+TDn6/0OM7eAewqQoCxzK nwBjQRotlyPmC5Ci0RXPEJ1zuF6B2e7L/+1fSoq2Q8xApfYPL+Xg47kRGeL+/Rz11kFp VkQN0k/UDi11f0rYKpDvdEndwCQkhRaNXqXzJiFvobWKjPMgDvL/s4qu7xzpFRVaMciq kue9UxQMC+T5vefNuQra2neFMupEBPjFrbr52GF+JpEuk1cL6oleeB3u8FiaQK56dZzk XdvQ== X-Gm-Message-State: ALoCoQne0Xbe8REqahy+2/TWG/g8tj6TBoIJz5NYa7OOADnmcb1qe6ZNa+psC1T493IziSLmebDP X-Received: by 10.107.150.67 with SMTP id y64mr24647172iod.22.1422911364890; Mon, 02 Feb 2015 13:09:24 -0800 (PST) Received: from [192.168.20.101] (203-97-255-117.cable.telstraclear.net. [203.97.255.117]) by mx.google.com with ESMTPSA id c8sm6745546igx.9.2015.02.02.13.09.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Feb 2015 13:09:23 -0800 (PST) Message-ID: <54CFE780.1040400@worcel.com> Date: Tue, 03 Feb 2015 10:09:20 +1300 From: Pedro Worcel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: 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> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020205080508020906070404" X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1YIOMm-0007Q6-Se 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:17:10 -0000 This is a multi-part message in MIME format. --------------020205080508020906070404 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Where would you verify that? 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’t 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’re 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. >> Given how final Bitcoin transactions are, I think it’s 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 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. 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, is your > hub for all things parallel software development, from weekly thought > 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 --------------020205080508020906070404 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Where would you verify that?

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’t 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 <joel.kaartinen@gmail.com> 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 <brian.erdelyi@gmail.com> 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’re 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.  Given how final Bitcoin transactions are, I think it’s 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 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. 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, is your
hub for all things parallel software development, from weekly thought
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

--------------020205080508020906070404--