public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Pedro Worcel <pedro@worcel•com>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Proposal to address Bitcoin malware
Date: Tue, 03 Feb 2015 10:02:13 +1300	[thread overview]
Message-ID: <54CFE5D5.2070908@worcel.com> (raw)
In-Reply-To: <4B53C1B0-A677-4460-8A69-C45506424D7F@gmail.com>

I think what he is saying is that there is no point in having three 
signatures if they are not segregated in a secure manner. This is to 
say, if you use your computer as one "factor", and a third party website 
as another, but you use the same computer to access the website, there 
is no gain in security.

Another example would be an android phone. If your computer is 
compromised and your browser is authenticated to your Google account, 
you could remotely install an "app" on your phone.

I don't know if I understood/explained myself correctly; I think two 
factor is better than one and there is a security gain if implemented 
securely.

Cheers!
Pedro

On 2/3/2015 8:58 AM, 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




  parent reply	other threads:[~2015-02-02 21:29 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-31 22:15 Brian Erdelyi
2015-01-31 22:38 ` Natanael
2015-01-31 23:04   ` Brian Erdelyi
2015-01-31 23:37     ` Natanael
2015-01-31 23:41       ` Natanael
2015-02-01 12:49         ` Brian Erdelyi
2015-02-01 13:31           ` Martin Habovštiak
2015-02-01 13:46             ` Mike Hearn
2015-02-01 13:54             ` Brian Erdelyi
2015-02-01 13:48           ` Mike Hearn
2015-02-01 14:28 ` mbde
2015-02-02 17:40   ` Brian Erdelyi
2015-02-02 17:54     ` Martin Habovštiak
2015-02-02 17:59       ` Mike Hearn
2015-02-02 18:02         ` Martin Habovštiak
2015-02-02 18:25           ` Mike Hearn
2015-02-02 18:35             ` Brian Erdelyi
2015-02-02 18:45               ` Eric Voskuil
2015-02-02 19:58                 ` Brian Erdelyi
2015-02-02 20:57                   ` Joel Joonatan Kaartinen
2015-02-02 21:03                     ` Brian Erdelyi
2015-02-02 21:09                       ` Pedro Worcel
2015-02-02 21:30                         ` devrandom
2015-02-02 21:49                           ` Brian Erdelyi
2015-02-02 21:42                         ` Brian Erdelyi
2015-02-02 21:02                   ` Pedro Worcel [this message]
2015-02-03  7:38                   ` Eric Voskuil
2015-02-02 18:10         ` Brian Erdelyi
2015-02-02 18:07       ` Brian Erdelyi
2015-02-02 18:05     ` Eric Voskuil
2015-02-02 18:53       ` Mike Hearn
2015-02-02 22:54         ` Eric Voskuil
2015-02-03  0:41           ` Eric Voskuil

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=54CFE5D5.2070908@worcel.com \
    --to=pedro@worcel$(echo .)com \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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