Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.223.175 as permitted sender)
	client-ip=209.85.223.175; envelope-from=gmaxwell@gmail.com;
	helo=mail-ie0-f175.google.com; 
MIME-Version: 1.0
In-Reply-To: <CANEZrP0bx7c1sm+9o6iXx_OnSdRH6a0jRNQcRb2Z3qbf0KFKiw@mail.gmail.com>
References: <CAAS2fgTVp7PhdJMfz-huyOsp=6Ca9wH6cVkedMgntXnK+ZpDXg@mail.gmail.com>
	<CANEZrP0bx7c1sm+9o6iXx_OnSdRH6a0jRNQcRb2Z3qbf0KFKiw@mail.gmail.com>
Date: Mon, 8 Oct 2012 23:22:01 -0400
Message-ID: <CAAS2fgQjeSBJGOr+qH7PQpTB5cx1rdaPCC2e=2J7OG=5Pby5GA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>,
	electrum.desktop@gmail.com
Subject: Re: [Bitcoin-development] Electrum security model concerns
Precedence: list

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=E2=80=94 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=E2=80=94 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=E2=80=94  It seems some people believe Electr=
um
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=E2=80=94 it connect to one at a ti=
me.
(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=E2=80=94  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=E2=80=94 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=E2=80=94 but I don't agree that it will be due to thos=
e
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?