From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YIO3S-0004tT-Ts for bitcoin-development@lists.sourceforge.net; Mon, 02 Feb 2015 20:57:10 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.180 as permitted sender) client-ip=209.85.214.180; envelope-from=joel.kaartinen@gmail.com; helo=mail-ob0-f180.google.com; Received: from mail-ob0-f180.google.com ([209.85.214.180]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YIO3R-0001ZE-LW for bitcoin-development@lists.sourceforge.net; Mon, 02 Feb 2015 20:57:10 +0000 Received: by mail-ob0-f180.google.com with SMTP id vb8so18712638obc.11 for ; Mon, 02 Feb 2015 12:57:04 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.92.5 with SMTP id ci5mr13107309oeb.26.1422910624188; Mon, 02 Feb 2015 12:57:04 -0800 (PST) Received: by 10.202.197.141 with HTTP; Mon, 2 Feb 2015 12:57:04 -0800 (PST) In-Reply-To: <4B53C1B0-A677-4460-8A69-C45506424D7F@gmail.com> 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> Date: Mon, 2 Feb 2015 22:57:04 +0200 Message-ID: From: Joel Joonatan Kaartinen To: Brian Erdelyi Content-Type: multipart/alternative; boundary=047d7b33d9744d4f43050e213200 X-Spam-Score: -0.6 (/) 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (joel.kaartinen[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1YIO3R-0001ZE-LW Cc: Bitcoin Dev 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 20:57:11 -0000 --047d7b33d9744d4f43050e213200 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 th= e > reduced utility arising from greater complexity, while being led to belie= ve > in a false promise. > > Just trying to make sure I understand what you=E2=80=99re saying. Are yo= u 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=E2=80=99s 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 > --047d7b33d9744d4f43050e213200 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If the attacker has your desktop computer but not the mobi= le that's acting as an independent second factor, how are you then supp= osed to be able to tell you're not signing the correct transaction on t= he mobile? If the address was replaced with the attacker's address, it&= #39;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 grea= ter security than single relies on the independence of multiple secrets. If= the secrets cannot be shown to retain independence in the envisioned threa= t scenario (e.g. a user's compromised operating system) then the benefi= t reduces to making the exploit more difficult to write, which, once writte= n, reduces to no benefit. Yet the user still suffers the reduced utility ar= ising from greater complexity, while being led to believe in a false promis= e.

Just trying to make sure I understand what you=E2=80=99re saying.=C2= =A0 Are you eluding to that if two of the three private keys get compromise= d there is no gain in security?=C2=A0 Although the likelihood of this occur= ring is lower, it is possible.

As more malware targets bitcoins I think the utility is evident.=C2=A0 Give= n how final Bitcoin transactions are, I think it=E2=80=99s worth trying to = find methods to help verify those transactions (if a user deems it to be hi= gh-risk enough) before the transaction is completed.=C2=A0 The balance is t= rying 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 you= r
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a<= br> look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--047d7b33d9744d4f43050e213200--