public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

* [Bitcoin-development] Electrum security model concerns
@ 2012-10-06 16:37 Gregory Maxwell
  2012-10-08 11:52 ` Mike Hearn
  2012-11-15 23:45 ` Gregory Maxwell
  0 siblings, 2 replies; 10+ messages in thread
From: Gregory Maxwell @ 2012-10-06 16:37 UTC (permalink / raw)
  To: Bitcoin Development, electrum.desktop

I'm concerned about how the particular security model of electrum is
being described; or rather— not being described.  The electrum website
appears to have no security discussion beyond platitudes like "Secure:
Your private keys are not shared with the server. You do not have to
trust the server with your money.", "No scripts: Electrum does not
download any script at runtime. A compromised server cannot compromise
your client."

Claims like "You do not have to trust the server with your money" are
factually incorrect.

What I would expect is a proper discussion, like "Understanding the
bitcoinj security model":
http://code.google.com/p/bitcoinj/wiki/SecurityModel  (which I don't
agree with completely— as it makes some claims which are known to be
false— wrt detecting double spends, but it does give a reasonable
overview),  and avoidance of broad claims which will result in
misunderstandings that result in users engaging in riskier behaviors
which they could avoid if they better understood the security of the
software they're running.



^ permalink raw reply	[flat|nested] 10+ messages in thread

• * Re: [Bitcoin-development] Electrum security model concerns
    2012-10-06 16:37 [Bitcoin-development] Electrum security model concerns Gregory Maxwell
  @ 2012-10-08 11:52 ` Mike Hearn
    2012-10-09  3:22   ` Gregory Maxwell
    2012-11-15 23:45 ` Gregory Maxwell
    1 sibling, 1 reply; 10+ messages in thread
  From: Mike Hearn @ 2012-10-08 11:52 UTC (permalink / raw)
    To: Gregory Maxwell; +Cc: Bitcoin Development, electrum.desktop
  
  > What I would expect is a proper discussion, like "Understanding the
  > bitcoinj security model":
  > http://code.google.com/p/bitcoinj/wiki/SecurityModel
  
  That page was old, it stated that pending transactions aren't provided
  to the app which hasn't been true for a long time.
  
  I've rewritten and extended it. You may still not like what it says ;)
  but it should at least be more thorough now. It also links to the ETH
  paper.
  
  Re: Electrum. In fairness the electrum page is designed for end users
  and the bitcoinj page is designed for app developers. As far as I
  know, there are no bitcoinj based clients that try to explain
  transaction confidence to end users.
  
  I don't think it's worth worrying about this too much right now. In
  future the software end users and merchants use will diverge
  significantly. At that time it'll be easier to tailor the
  documentation to each user demographic. And I think Electrum type
  services will go away once we do more optimizations like bloom
  filtering and better peer selection logic, as the speed of SPV clients
  will be comparable to Electrum/BCCAPI type clients but without the
  need for a specific server operator.
  
  
  
  ^ permalink raw reply	[flat|nested] 10+ messages in thread

• • * Re: [Bitcoin-development] Electrum security model concerns
      2012-10-08 11:52 ` Mike Hearn
    @ 2012-10-09  3:22   ` Gregory Maxwell
      2012-10-10 11:19     ` Mike Hearn
      0 siblings, 1 reply; 10+ messages in thread
    From: Gregory Maxwell @ 2012-10-09  3:22 UTC (permalink / raw)
      To: Mike Hearn; +Cc: Bitcoin Development, electrum.desktop
    
    On Mon, Oct 8, 2012 at 7:52 AM, Mike Hearn <mike@plan99•net> wrote:
    > I don't think it's worth worrying about this too much right now. In
    > future the software end users and merchants use will diverge
    > significantly.
    
    Electrum also has a daemon for merchants. Considering the dislike of
    Java that exist reflexively in much of the non-java community and the
    greater ease of deployment and the integration of type-2 split key
    management,  I wouldn't be surprised if it became quite popular
    quickly especially if the status quo of failing to disclose and
    discuss the security limitations of the client continues.
    
    What I've found is that even fairly sophisticated bitcoin participants
    are actually unaware of the security implications— not just of thin
    clients architecturally but of electrum specifically.  I think even
    you may find my findings of the latter a bit surprising.
    
    Generally for thin clients— a lying server can make clients think
    they've received confirmed payments they haven't, and unless the
    client is constructed to be a bit less thin a lying server can lie
    about input values and cause think clients to spend large values to
    fees. Servers can also monitor clients and deanonymize them and
    selectively deny service to particular clients or transactions. Thin
    clients must trust their servers to be available, and to not perform
    these attacks. Users can use tools like tor to reduce the privacy
    attacks, but doing so inhibits having a trust relationship to protect
    against the other attacks. And none of these attacks leave
    cryptographic proof of their existence, so a victim can't convince the
    public of a server's treachery. Us experts know about these risks, but
    I don't think the general users do.
    
    But thats not the limit of it—  It seems some people believe Electrum
    does majority quorum between servers, complicating attacks arising
    from the fact that today users virtually never have a reason to trust
    their server operators.  This isn't true— it connect to one at a time.
    (And sibyl attacks would make that pretty weak protection even if it
    did that, as someone could use a a botnet to run tens of thousands of
    'servers' (really proxies)).
    
    Beyond that the protocol between the clients and servers is
    unauthenticated cleartext JSON in TCP.  So any network advisory with
    access to the network near the server has the same power to attack as
    the server operator... and one near the client has the same power to
    attack as the sum of all the server operators.  A passive attacker
    near the client has full deanonymization power.
    
    But I don't even know if any of these limitations matter much—  The
    electrum client instantly displays unconfirmed transactions and allows
    users to spend them.  The default user interface gives _no_ indication
    that the payment is unconfirmed. There is a "pro" mode, that shows
    'processing' for unconfirmed transactions... but it looks as final as
    it ever will be once it gets a single confirm. Only the most cautious
    and well informed users would open the pro interface and right click
    and select details to see the count— and even then there is no
    guidance on what numbers are good (beyond '1').  So I suspect people
    can probably rob typical electrum users (including electrum running
    merchants) without actually using any of the above.
    
    When a thin client is willing to provide arbitrary features like
    showing unconfirmed payments and simplified UI without regard to
    security it removes the functional advantage of running more secure
    software like SPV and various degrees of full node... the only
    motivation is security, and it's not much of a motivation when the
    risks aren't even disclosed.
    
    ...and I haven't even gotten into delving into what kind of attacks
    are possible due to deeper implementation specifics.
    
    But I do share your view that people will migrate to stronger client
    models in the future— but I don't agree that it will be due to those
    clients improving (though they will improve), it will be because
    people will know that they provide better security and will choose
    them for that reason.
    
    My only question is will they know this because we as a community and
    the authors of the thin clients provided clear explanations and
    appropriate caution, or will it be because they're getting robbed
    blind, producing a bunch of bad press for thin clients in particular
    and Bitcoin generally?
    
    
    
    ^ permalink raw reply	[flat|nested] 10+ messages in thread

  • • * Re: [Bitcoin-development] Electrum security model concerns
        2012-10-09  3:22   ` Gregory Maxwell
      @ 2012-10-10 11:19     ` Mike Hearn
        2012-10-10 14:06       ` Gary Rowe
        2012-10-10 15:23       ` Gregory Maxwell
        0 siblings, 2 replies; 10+ messages in thread
      From: Mike Hearn @ 2012-10-10 11:19 UTC (permalink / raw)
        To: Gregory Maxwell; +Cc: Bitcoin Development, electrum.desktop
      
      +gary
      
      > Electrum also has a daemon for merchants.
      
      Well, I suggest taking it up with Thomas directly. A thread here won't do much.
      
      > Considering the dislike of
      > Java that exist reflexively in much of the non-java community and the
      > greater ease of deployment and the integration of type-2 split key
      > management
      
      I'm hoping that MultiBit Merchant will provide something similar based
      on bcj, ie, you don't have to actually be a Java developer to use it,
      it can just talk to your app via POSTs and GETs.
      
      WRT deterministic wallets, yes, right now that's indeed a competitive
      advantage of Electrum. So much code to write, so little time.
      
      > Generally for thin clients— a lying server can make clients think
      > they've received confirmed payments they haven't, and unless the
      > client is constructed to be a bit less thin a lying server can lie
      > about input values and cause thin clients to spend large values to
      > fees.
      
      Yes indeed. This also gives [hacked] server operators a way to steal
      money from users without private keys, they can get clients to create
      some very high fee transactions and then provide them directly to a
      miner who promises to cut them in (or they can mine themselves, of
      course).
      
      > Beyond that the protocol between the clients and servers is
      > unauthenticated cleartext JSON in TCP.
      
      I thought it used SSL. Maybe I'm thinking of BCCAPI which is a similar approach.
      
      > that the payment is unconfirmed. There is a "pro" mode, that shows
      > 'processing' for unconfirmed transactions
      
      I think communicating transaction confidence to users is something of
      an open UI design problem right now. I agree that hiding it entirely
      seems suboptimal, but in reality explaining what the risks are for a
      given number confirmations is difficult. Given the lack of actually
      reported double-spends against unconfirmed transactions, I can
      understand this choice, even if I wouldn't recommend it.
      
      > My only question is will they know this because we as a community and
      > the authors of the thin clients provided clear explanations and
      > appropriate caution
      
      Well, I pushed for English-text explanations of clients on bitcoin.org
      rather than a feature matrix, for this kind of reason :) Unfortunately
      the current texts are too small to really give a detailed explanation
      of the security models involved. It may be worth adding one-liners
      that link to a page explaining different security models (full, SPV,
      superlight).
      
      One thing I'm really hoping we can find and get agreement on is
      somebody clueful and trustworthy to work on the bitcoin.org website.
      Bitcoin, the project, needs a stronger voice than it currently has,
      partly to speak about such issues. For instance, an FAQ that isn't on
      the wiki would be good. And a simple "Welcome to Bitcoin" flow on the
      bitcoin.org website that guides people to appropriate clients, teaches
      them the security basics, etc, would be excellent.
      
      
      
      ^ permalink raw reply	[flat|nested] 10+ messages in thread

    • • * Re: [Bitcoin-development] Electrum security model concerns
          2012-10-10 11:19     ` Mike Hearn
        @ 2012-10-10 14:06       ` Gary Rowe
          2012-10-10 15:23       ` Gregory Maxwell
          1 sibling, 0 replies; 10+ messages in thread
        From: Gary Rowe @ 2012-10-10 14:06 UTC (permalink / raw)
          To: Mike Hearn; +Cc: Bitcoin Development, electrum.desktop
        
        [-- Attachment #1: Type: text/plain, Size: 4546 bytes --]
        
        Just to chime in on the MultiBit Merchant aspect. The architecture is that
        MBM is a Java backend, but executes as a simple command line:
        
        java -jar mbm.jar server config.yml
        
        As Mike expects, MBM offers a RESTful API using HAL+JSON. It provides a
        comprehensive set of order and invoice processing, accounting,
        inventory/delivery management and customer account handling facilities for
        use with a wide variety of online business models.
        
        There will be a variety of front ends, one of which is an online shop. They
        also have the same startup command structure.
        
        Since most folks are shy of using any technology, it is likely that MBM+<x
        client> will be offered as part of a SaaS type solution. This allows anyone
        who doesn't have the knowledge to configure it for themselves to make use
        of it.
        
        MBM will use BitcoinJ and will depend on a bucket of public keys for
        transactions until the HD support is in place to allow generation of public
        keys without private keys being present. This removes the need for private
        keys to be present on the servers, and allows consumers of the SaaS model
        to provide their own transaction keys.
        
        The code is released under MIT license so anyone, anywhere can use it to
        build the Bitcoin economy.
        
        More info:
        https://github.com/gary-rowe/MultiBitMerchant/wiki/Introduction
        http://gary-rowe.com/agilestack/2012/06/06/multibit-merchant-genesis/
        
        On 10 October 2012 12:19, Mike Hearn <mike@plan99•net> wrote:
        
        > +gary
        >
        > > Electrum also has a daemon for merchants.
        >
        > Well, I suggest taking it up with Thomas directly. A thread here won't do
        > much.
        >
        > > Considering the dislike of
        > > Java that exist reflexively in much of the non-java community and the
        > > greater ease of deployment and the integration of type-2 split key
        > > management
        >
        > I'm hoping that MultiBit Merchant will provide something similar based
        > on bcj, ie, you don't have to actually be a Java developer to use it,
        > it can just talk to your app via POSTs and GETs.
        >
        > WRT deterministic wallets, yes, right now that's indeed a competitive
        > advantage of Electrum. So much code to write, so little time.
        >
        > > Generally for thin clients— a lying server can make clients think
        > > they've received confirmed payments they haven't, and unless the
        > > client is constructed to be a bit less thin a lying server can lie
        > > about input values and cause thin clients to spend large values to
        > > fees.
        >
        > Yes indeed. This also gives [hacked] server operators a way to steal
        > money from users without private keys, they can get clients to create
        > some very high fee transactions and then provide them directly to a
        > miner who promises to cut them in (or they can mine themselves, of
        > course).
        >
        > > Beyond that the protocol between the clients and servers is
        > > unauthenticated cleartext JSON in TCP.
        >
        > I thought it used SSL. Maybe I'm thinking of BCCAPI which is a similar
        > approach.
        >
        > > that the payment is unconfirmed. There is a "pro" mode, that shows
        > > 'processing' for unconfirmed transactions
        >
        > I think communicating transaction confidence to users is something of
        > an open UI design problem right now. I agree that hiding it entirely
        > seems suboptimal, but in reality explaining what the risks are for a
        > given number confirmations is difficult. Given the lack of actually
        > reported double-spends against unconfirmed transactions, I can
        > understand this choice, even if I wouldn't recommend it.
        >
        > > My only question is will they know this because we as a community and
        > > the authors of the thin clients provided clear explanations and
        > > appropriate caution
        >
        > Well, I pushed for English-text explanations of clients on bitcoin.org
        > rather than a feature matrix, for this kind of reason :) Unfortunately
        > the current texts are too small to really give a detailed explanation
        > of the security models involved. It may be worth adding one-liners
        > that link to a page explaining different security models (full, SPV,
        > superlight).
        >
        > One thing I'm really hoping we can find and get agreement on is
        > somebody clueful and trustworthy to work on the bitcoin.org website.
        > Bitcoin, the project, needs a stronger voice than it currently has,
        > partly to speak about such issues. For instance, an FAQ that isn't on
        > the wiki would be good. And a simple "Welcome to Bitcoin" flow on the
        > bitcoin.org website that guides people to appropriate clients, teaches
        > them the security basics, etc, would be excellent.
        >
        
        [-- Attachment #2: Type: text/html, Size: 5667 bytes --]
        
        ^ permalink raw reply	[flat|nested] 10+ messages in thread

      • * Re: [Bitcoin-development] Electrum security model concerns
          2012-10-10 11:19     ` Mike Hearn
          2012-10-10 14:06       ` Gary Rowe
        @ 2012-10-10 15:23       ` Gregory Maxwell
          2012-10-10 15:55         ` Mike Hearn
          1 sibling, 1 reply; 10+ messages in thread
        From: Gregory Maxwell @ 2012-10-10 15:23 UTC (permalink / raw)
          To: Mike Hearn; +Cc: Bitcoin Development, electrum.desktop
        
        On Wed, Oct 10, 2012 at 7:19 AM, Mike Hearn <mike@plan99•net> wrote:
        > +gary
        >
        >> Electrum also has a daemon for merchants.
        >
        > Well, I suggest taking it up with Thomas directly. A thread here won't do much.
        
        I tried in IRC and got no response. These messages are copying the
        only contact email address I could find.
        
        
        > I thought it used SSL. Maybe I'm thinking of BCCAPI which is a similar approach.
        
        Yes, so do a lot of people. It doesn't.
        
        > I think communicating transaction confidence to users is something of
        > an open UI design problem right now. I agree that hiding it entirely
        > seems suboptimal, but in reality explaining what the risks are for a
        
        There is a middle ground: You can not hide it without explaining it.
        AFAICT we don't see ~any questions about the reference client waiting
        for six confirmations before saying confirmed.
        
        > given number confirmations is difficult. Given the lack of actually
        > reported double-spends against unconfirmed transactions, I can
        > understand this choice, even if I wouldn't recommend it.
        
        There have been a great many circulated on the network. People don't
        report all losses— e.g. we've never seen a report from those who've
        burned hundreds of bitcoins in fees on transactions.
        
        > of the security models involved. It may be worth adding one-liners
        > that link to a page explaining different security models (full, SPV,
        > superlight).
        
        Perhaps.
        
        > One thing I'm really hoping we can find and get agreement on is
        > somebody clueful and trustworthy to work on the bitcoin.org website.
        
        I think this is very hard because this matter is rapidly politicized.
        There are some in the community who will instantly allege misconduct
        when there is a mis-agreement.
        
        Basically: No one sane should want the job, and anyone who wants
        should on no account be allowed to have it.
        
        At this point I think we also will get better results communicating
        among technical people in order to get the development focus adjusted
        in a way that mitigates those risks that can be mitigated and those
        cautions that can be offered offered.
        
        After all, if the Electrum project is _unwilling_ to disclose the
        limitations of their implementation and security model on their own
        site, even after having them pointed out then someone updating
        Bitcoin.org to include them will be politically contentious.  I want
        to make sure that we've followed all reasonable avenues before going
        that route— first I attempted informally on IRC, now I've brought the
        discussion here... instead of, e.g. starting the process to remove it
        from the bitcoin.org clients page.
        
        > Bitcoin, the project, needs a stronger voice than it currently has,
        > partly to speak about such issues. For instance, an FAQ that isn't on
        
        I agree, thats why I started this thread.
        
        
        
        ^ permalink raw reply	[flat|nested] 10+ messages in thread

      • • * Re: [Bitcoin-development] Electrum security model concerns
            2012-10-10 15:23       ` Gregory Maxwell
          @ 2012-10-10 15:55         ` Mike Hearn
            0 siblings, 0 replies; 10+ messages in thread
          From: Mike Hearn @ 2012-10-10 15:55 UTC (permalink / raw)
            To: Gregory Maxwell; +Cc: Bitcoin Development, electrum.desktop
          
          > I tried in IRC and got no response. These messages are copying the
          > only contact email address I could find.
          
          Forum private message may work better.
          
          > I think this is very hard because this matter is rapidly politicized.
          > There are some in the community who will instantly allege misconduct
          > when there is a mis-agreement.
          
          Yeah, but that's only an issue if it ends up being an intractable
          disagreement between the people who are reviewing changes to the core
          site. The clients page itself was contentious but we still arrived at
          something reasonably professional looking and moved on.
          
          > discussion here... instead of, e.g. starting the process to remove it
          > from the bitcoin.org clients page.
          
          I don't think it should be removed. At most the description should be
          updated to point to a discussion of the tradeoffs of that class of
          apps (same for BitcoinSpinner).
          
          
          
          ^ permalink raw reply	[flat|nested] 10+ messages in thread

• * Re: [Bitcoin-development] Electrum security model concerns
    2012-10-06 16:37 [Bitcoin-development] Electrum security model concerns Gregory Maxwell
    2012-10-08 11:52 ` Mike Hearn
  @ 2012-11-15 23:45 ` Gregory Maxwell
    2012-11-16 15:59   ` Mike Hearn
    1 sibling, 1 reply; 10+ messages in thread
  From: Gregory Maxwell @ 2012-11-15 23:45 UTC (permalink / raw)
    To: Bitcoin Development
  
  On Sat, Oct 6, 2012 at 12:37 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
  > I'm concerned about how the particular security model of electrum is
  > being described; or rather— not being described.
  
  Just to close the loop on this: I finally got in touch with Thomas on
  IRC and walked over the security issues I brought up here, plus a
  number of other ones.
  
  He took the concerns seriously and rapidly redesigned big swaths of
  electrum to eliminate the issues structurally.  Electrum no longer a
  classical thin client it is now a slightly watered down
  simplified-payment-validation node with generally the same security
  properties as other SPV nodes. Its network behavior leaves it somewhat
  more vulnerable to isolation and compromise by a high hash power
  attacker, because it does not (yet) make an effort to make sure it's
  really on the longest chain. It is also more vulnerable to transaction
  hiding (a DOS attack) for similar reasons.  But this is still a
  massive improvement.  The UI was also changed and the confirmation
  status of payments is no longer hidden.
  
  There are still things to improve— both in the client and the security
  communication to users. But I wanted to leave a note that it's come a
  long way and that I now feel confident that any remaining issues will
  be resolved.
  
  
  
  ^ permalink raw reply	[flat|nested] 10+ messages in thread

• • * Re: [Bitcoin-development] Electrum security model concerns
      2012-11-15 23:45 ` Gregory Maxwell
    @ 2012-11-16 15:59   ` Mike Hearn
      2012-11-16 17:44     ` Mike Hearn
      0 siblings, 1 reply; 10+ messages in thread
    From: Mike Hearn @ 2012-11-16 15:59 UTC (permalink / raw)
      To: Gregory Maxwell; +Cc: Bitcoin Development
    
    [-- Attachment #1: Type: text/plain, Size: 20 bytes --]
    
    Great to hear that.
    
    [-- Attachment #2: Type: text/html, Size: 20 bytes --]
    
    ^ permalink raw reply	[flat|nested] 10+ messages in thread

  • • * Re: [Bitcoin-development] Electrum security model concerns
        2012-11-16 15:59   ` Mike Hearn
      @ 2012-11-16 17:44     ` Mike Hearn
        0 siblings, 0 replies; 10+ messages in thread
      From: Mike Hearn @ 2012-11-16 17:44 UTC (permalink / raw)
        To: Gregory Maxwell; +Cc: Bitcoin Development
      
      [-- Attachment #1: Type: text/plain, Size: 855 bytes --]
      
      BTW have you checked the code? I took a quick look and didn't see things I
      was expecting to see. In particular I couldn't find any code that manages
      wallet state in the presence of re-orgs. It appears to check that
      transactions appeared in the block chain, but if there's a chain switch
      it's not clear to me the wallet will be in the right state.
      
      I saw a message from Thomas on his thread saying something like "can't
      spend coins bug happens when there's a re-org and the server gives you the
      wrong histories, to fix it reset your wallet and switch to a new server"
      .... which to me rather implies there's no re-org handling at all.
      
      If Electrum does end up doing all SPV work correctly, how is it different
      to MultiBit? Just the deterministic wallet seeding?
      
      
      On Fri, Nov 16, 2012 at 4:59 PM, Mike Hearn <mike@plan99•net> wrote:
      
      > Great to hear that.
      
      [-- Attachment #2: Type: text/html, Size: 1218 bytes --]
      
      ^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2012-11-16 17:44 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-10-06 16:37 [Bitcoin-development] Electrum security model concerns Gregory Maxwell
2012-10-08 11:52 ` Mike Hearn
2012-10-09  3:22   ` Gregory Maxwell
2012-10-10 11:19     ` Mike Hearn
2012-10-10 14:06       ` Gary Rowe
2012-10-10 15:23       ` Gregory Maxwell
2012-10-10 15:55         ` Mike Hearn
2012-11-15 23:45 ` Gregory Maxwell
2012-11-16 15:59   ` Mike Hearn
2012-11-16 17:44     ` Mike Hearn

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox