path: root/69/1fb35b6cca1a0787f5186e8735deb92e8cc2d8

Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 58411957
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  9 May 2017 23:11:27 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf0-f171.google.com (mail-pf0-f171.google.com
	[209.85.192.171])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5DCD9127
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  9 May 2017 23:11:26 +0000 (UTC)
Received: by mail-pf0-f171.google.com with SMTP id m17so6897956pfg.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 09 May 2017 16:11:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=voskuil-org.20150623.gappssmtp.com; s=20150623;
	h=subject:to:references:from:message-id:date:user-agent:mime-version
	:in-reply-to:content-transfer-encoding;
	bh=qnT3ynC02nGhniTqDmvdV/cekvTxrvNRmp94tQ81gKs=;
	b=vb0F5muQ+Ob0jpx0+eadDQ2fylGj3AS8fYXV15rtJbCiQM2C1Z5klpERwRXxQjTLPj
	XVERGrlmjsasy4wLbXyERpWGLqUKthM82Bn81rUPxNXBkQajAqIYs0ctcuq9Adbk00An
	nA77e3inyQUIoKjNkqhi3LJzszw+PG60j53FdxTcZc+P0AESxqgQ4IA++4vG7ToyiFNy
	MICvHJPSYwP8hNpJCB3q8VYgEOfCyOXV7AcH3wTiFUJMrbqPSQNuikjMFOO2Kt9r8gDe
	WaWR+006YysAyF2m6xN60sS78MIQhwoxnkX2a2O1MWtd1lx2zBcMBl9Dh+aM/v3AY+kD
	j3eQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:subject:to:references:from:message-id:date
	:user-agent:mime-version:in-reply-to:content-transfer-encoding;
	bh=qnT3ynC02nGhniTqDmvdV/cekvTxrvNRmp94tQ81gKs=;
	b=Oibj6JaGtOUq1Kt5iMa0ucmSePUocYcRtSfZvXf0ESwa2dnt0z6WEOD/Cngn/pfi/0
	v3Czqjzpv2NsY54yd1+mZM5gXnMVSBOHG7HydDSdPxRQaEl42ax8SHeUDGByFMfM9JV2
	S0QF4jAO049qdT3XVONK5BdqK4H1F9fSri5pE5ndLIDAjDK/9tlCSv6rLnQPFfz9piYP
	wZC2XEO34SQZatvg1a/p79lXAw9F4nKbsuZc05hnJUxaxpK25/c+EMtGLjaY0Fd1A0a3
	bllg+321yTQTPwGMxiY1TXD5S3H8xGUQxH4csdrRd7hhhGRwE7Rlt9XXwOxsgv1f2wLm
	fa4A==
X-Gm-Message-State: AODbwcAQeMDIj2YLj9D82WfZHTyvARWP5k+yX79Pr68hgQyZL7zaXhx3
	aXLW+/4OBrmAozBGV3Q=
X-Received: by 10.98.209.24 with SMTP id z24mr2739234pfg.200.1494371485713;
	Tue, 09 May 2017 16:11:25 -0700 (PDT)
Received: from ?IPv6:2601:600:9000:d69e:c1b1:4fd4:4f66:71bd?
	([2601:600:9000:d69e:c1b1:4fd4:4f66:71bd])
	by smtp.gmail.com with ESMTPSA id p68sm1727921pga.6.2017.05.09.16.11.24
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Tue, 09 May 2017 16:11:25 -0700 (PDT)
To: "Raystonn ." <raystonn@hotmail.com>,
	bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>,
	Libbitcoin Development <libbitcoin@lists.dyne.org>
References: <BN6PR18MB13483361D401D0A378BEBDCECDEF0@BN6PR18MB1348.namprd18.prod.outlook.com>
From: Eric Voskuil <eric@voskuil.org>
X-Enigmail-Draft-Status: N1110
Message-ID: <c78f6d0f-5eb4-31d2-1dbc-53eec5f70784@voskuil.org>
Date: Tue, 9 May 2017 16:11:31 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
	Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <BN6PR18MB13483361D401D0A378BEBDCECDEF0@BN6PR18MB1348.namprd18.prod.outlook.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 10 May 2017 00:28:44 +0000
Subject: Re: [bitcoin-dev] Network-layer attacks
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 09 May 2017 23:11:27 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/09/2017 09:09 AM, Raystonn . via bitcoin-dev wrote:
> This study was released last week, detailing some attacks at the
> network layer: https://btc-hijack.ethz.ch/files/btc_hijack.pdf.  Of
> the countermeasures discussed in the paper, the use of encryption 
> to secure communications between nodes looks like low hanging
> fruit.

I draw a very different conclusion.

The paper states:

“Our work underscores the importance of proposed modifications which
argue for encrypting Bitcoin traffic or traffic exchanged among miners.”

The phrase, “encrypting ... traffic exchanged among miners,” is not
merely about encryption, since if one cannot identify the peer as the
intended miner it could just as well be an attacker. This is about
(presumably encrypted) authenticated connections.

Indeed, encryption of traffic among miners is referred to again here:

“Finally, an attacker cannot intercept (possibly encrypted) private
connections, corresponding to peering agreements between mining pools.
- From the attacker’s point of view, these connections can be treated as
intra-pool connections and the corresponding pair of pools can be
considered as one larger pool.”

So the encryption-based defense for miners is to use authentication to
create, “one larger pool,” consisting of, “private connections.”

Additionally it states, “we show that hijacking fewer than 100
prefixes is enough to isolate a large amount of the mining power due
to Bitcoin’s centralization.”

In other words the proposed solution, to what is largely a problem of
miner centralization, is to create one miner. The paper doesn’t
attempt to investigate the downside to that apparent centralization
spiral.

The paper investigates routing attacks on the p2p protocol,
specifically partitioning and delay. Regarding traffic encryption it
*stresses* the caution:

“Yet, we stress that not all routing attacks will be solved by such
measures since attackers can still disrupt connectivity and isolate
nodes by dropping Bitcoin packets instead of modifying them.”

In other words it recognizes that encryption is both centralizing and
ineffective. Along these lines it also observes:

* A smaller set of nodes will be easier to isolate for extended periods.
* All incoming connection slots can be occupied by connections from
attacker nodes.
* Outgoing connections can be biased via a traditional eclipse attack.

Notice that none of these issues are mitigated by encryption, since in
each case the encrypted connection may just as easily be the attacker.
The presumed powerful attacker (one with the ability to modify
Internet routing tables) is not deterred by encryption. Instead of
modifying or dropping packets he can simply redirect traffic to his
own node(s) and carry on the attack on an encrypted connection with
the victim. As such all calls for encryption in the P2P protocol
ultimately end in calls for authentication.

It is true that if all connections are authenticated these attacks are
mitigated. But as the “one larger pool” discussion shows, this is
simply a regression to a private network.

As for the two scenarios analyzed, the summary on delay attacks includes
:

* Delay attackers intercepting 50% of a node’s connection can waste
63% of its mining power.
* Due to pools multi-homing, Bitcoin (as a whole) is not vulnerable to
delay attackers, even powerful ones.
* Even a small degree of multi-homing is enough to protect Bitcoin
from powerful attackers.

Furthermore, the delay attack scenario explicitly relies on, “the fact
that a [Core] Bitcoin node waits for 20 minutes after having requested
a block from a peer before requesting it again from another peer.” The
waste of mining power above is a function of that delay. So delay is
not a material concern for the entire network, and there are
mitigations that hang much lower than making the network private.

Regarding partitioning, clearly neither encryption nor authentication
can ensure that one is seeing the strongest chain unless the network
is fully private (and trustworthy). The paper states, “Increase
partition persistence: ... Intuitively, the attacker needs to suppress
the effect of churn in order to keep the victim nodes isolated.” In
other words, simply rotating connections is presumed to be effective.

There are other useful countermeasures listed in the paper:

* Increase the diversity of node connections
* Select Bitcoin peers while taking routing into account
* Monitor round-trip time (RTT)
* Monitor additional statistics
* Embrace churn
* Use gateways in different ASes
* Prefer peers hosted in the same AS and in /24 prefixes
* Use distinct control and data channels
* Use UDP heartbeats
* Request a block on multiple connections

The single recommendation that includes encryption is heavily qualified:

* Encrypt Bitcoin Communication and/or adopt MAC
"While encrypting Bitcoin connections would not prevent adversaries
from dropping packets, it would prevent them from eavesdropping
connections and modifying key messages. Alternatively, using a Message
Authentication Code (MAC) to validate that the content of each message
has not been changed would make delay attacks much more difficult."

First, it should be widely understood that eavesdropping on the relay
of public information is not an attack. Secondly, the paper clearly
states, “attackers can still disrupt connectivity and isolate nodes by
dropping Bitcoin packets instead of modifying them.” So the
distinction between dropping and modifying messages is immaterial. And
thirdly, the paper recognizes that eclipse attacks remain effective
short of authentication.

Taken alongside the risk of centralization though the widespread use
of authentication, which the paper does not contemplate, encryption is
anything but low hanging fruit. Several of the other above mitigations
are described as effective, and it is the case that some nodes already
employ some of them. Libbitcoin for example embraces churn by
providing both configurable and partially-randomized connection
timeout and a configurable block withholding timeout.

The paper is a valuable contribution in assessing risks to the P2P
network and individual nodes, and suggesting mitigations, but it is
not comprehensive. As with block size, the most obvious answer is not
always the right answer. Bitcoin is a public cache of independently
verifiable information shared anonymously over a P2P network. The
primary threat is centralization. Authentication is a necessary aspect
of centralizing the network.

e
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBCAAGBQJZEkyWAAoJEDzYwH8LXOFOwW4H/2icvGAiKmSSI8+TtiI52hDC
SouctpRXE/R0BSs1+KkSnj8c6nwNDqwpWWzKyDLVHT53FBk5cbUkUnTCev+MxZvm
srk63/nnI12/7RpEVoPVEiHXYd60hzNjN2Fod1ox+lN7Ln3nf22f+3ZP2evv8ETd
jZSnjVlOcnRrx/s67iE+n+IYPAtAENcxQhzZtGY1vLLgRrX7YbKlgjI8DNuSOgvZ
VugTU3NeahUpGJQ5tvBWt0eHE0StzvcoCpts58Eozs4rnp7FWWDNYH9dtyzgqM6/
qONC0MEHtO63PQ09DriHpAAUDw9xXCGOyv6aJ1TErzkJEXmkHn0QxUg/sYknL18=
=jAkv
-----END PGP SIGNATURE-----