From: Gregory Maxwell <gmaxwell@gmail•com>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>,
electrum.desktop@gmail•com
Subject: Re: [Bitcoin-development] Electrum security model concerns
Date: Mon, 8 Oct 2012 23:22:01 -0400 [thread overview]
Message-ID: <CAAS2fgQjeSBJGOr+qH7PQpTB5cx1rdaPCC2e=2J7OG=5Pby5GA@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP0bx7c1sm+9o6iXx_OnSdRH6a0jRNQcRb2Z3qbf0KFKiw@mail.gmail.com>
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?
next prev parent reply other threads:[~2012-10-09 3:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-06 16:37 Gregory Maxwell
2012-10-08 11:52 ` Mike Hearn
2012-10-09 3:22 ` Gregory Maxwell [this message]
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
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='CAAS2fgQjeSBJGOr+qH7PQpTB5cx1rdaPCC2e=2J7OG=5Pby5GA@mail.gmail.com' \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=electrum.desktop@gmail$(echo .)com \
--cc=mike@plan99$(echo .)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