From: Jonas Schnelli <dev@jonasschnelli•ch>
To: Eric Voskuil <eric@voskuil•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 151
Date: Tue, 28 Jun 2016 22:06:58 +0200 [thread overview]
Message-ID: <5772D8E2.6020007@jonasschnelli.ch> (raw)
In-Reply-To: <360EF9B8-A174-41CA-AFDD-2BC2C0B4DECB@voskuil.org>
[-- Attachment #1.1: Type: text/plain, Size: 7070 bytes --]
>> In my opinion, the question should be "why would you _not_ encrypt".
>
> 1) creation of a false sense of security
False sense of security is mostly a communication issue.
BIP151 does focus on encryption (not trust).
Are users aware of the fact that ISP/WiFi-Providers can track their
bitcoin spending (if they use SPV+BF) and link it with other internet
traffic or sell the data to anyone who is interested to do correlation?
Are node operators aware of the possibilities that ISPs/Data-Centers,
etc. can hold back peers, etc.?
If there is a false sense of security/anonymity, then we are already
deep into this territory.
BIP151 was designed as a puzzle-pice towards better security and better
censorship resistance. You shouldn't project all sorts of "false sense
of security" into BIP151. Is a stepping stone towards greater security.
> 2) as a tradeoff against anonymity
Can you point out the tradeoffs?
BIP151 does not introduce fingerprinting possibilities.
> 3) benefit does not justify cost
Can you elaborate the costs?
[Extremely simplified]: we need 300 lines of code from openssh
(ChaCha20-Poly1305@openssl) and some ECDH magic (already in
Bitcoin-Cores codebase) together with two or three (maybe payed)
cryptoanalysis once the implementation is done.
>> There are plenty of other options to solve this problem. stunnel,
>> Bernsteins CurveCP, VPN, etc. which are available since years.
>> But the reality has shown that most bitcoin traffic is still unencrypted.
>
> The question arises from concern over the security of the network in the case where encryption (and therefore authentication) is pervasive.
>
> As you point out, anyone can set up a private network of nodes today. These nodes must also connect to the permissionless network to maintain the chain. These nodes constitute a trust zone within Bitcoin. This zone of exclusion operates as a single logical node from the perspective of the Bitcoin security model (one entity controls the validation rules for all nodes).
>
> Widespread application of this model is potentially problematic. It is a non-trivial problem to design a distributed system that requires authentication but without identity and without central control. In fact this may be more challenging than Bitcoin itself. Trust on first use (TOFU) does not solve this problem.
Yes. There is no plan to adopt a TUFO scheme. Bip151 does not use TUFO
it does not cover "trust" (It just encrypt all traffic).
Imaging Bip151 together with a simple form of preshared EC key
authentication (nonce signing or similar). You could drastically
increase the security/censor-resistance-properties between nodes where
owners have preshared identity keys (with nodes I also mean SPV/wallet
nodes).
And I guess there are plenty of awesome identity management system ideas
tied or not tied to the Bitcoin blockchain out there.
This is also a reason to not cover trust/authentication/identity in BIP151.
It is possible to have multiple authentication schemes.
> In my opinion this question has not received sufficient consideration to warrant proceeding with a network encryption scheme (which concerns me as well, but as I consider it premature I won't comment).
Yes. I think nobody have started implementing BIP151. It's a draft BIP
and I think it's still okay and great that we have this discussion.
BIP151 hopefully has started some brainwork in how encryption and
authentication could work in Bitcoin and I'm happy to deprecate BIP151
if we have found a better solution or if we come to a point where we
agree that BIP151 does make the network security worse.
>> Example: IIRC non of the available SPV wallets can "speak" on of the
>> possible encryption techniques. Encrypting traffic below the application
>> layer is extremely hard to set up for non-experienced users.
>
> Bloom filters can (and IMO should) be isolated from the P2P protocol. Also, if the proposal creates an insecurity its ease of deployment is moot.
If we assume increasing amount of novice users starting with Bitcoin
every day, how should these users run wallets without increasing
centralization by using webwallets or client/central-server wallets?
(which is OT, but an interesting question)
>> On top of that, encryption allows us to drop the SHA256 checksum per p2p
>> message which should result in a better performance on the network layer
>> once BIP151 is deployed.
>
> I would not consider this a performance enhancing proposal. Simply dropping the checksum seems like a better option. But again, it is moot if it creates an insecurity.
>
>> I agree that BIP151 _must_ be deployed together with an authentication
>> scheme (I'm working on that) to protect again MITM during encryption
>> initialization.
>
> At a minimum I would propose that you modify BIP151 to declare a dependency on a future BIP, making BIP151 incomplete without it. I think we can agree that it would be unadvisable to deploy (and therefore to implement) encryption alone.
I think BIP151 does what it says: encryption and laying groundwork for
authentication.
You wouldn't probably say BIP32 is incomplete because it does not cover
a scheme how to recover funds (or BIP141 [SW consensus] is incomplete
because it does not cover p2p [BIP144]).
The missing MITM protection (solvable over auth) is prominent mentioned
in the BIP [1].
(from your other mail):
>> I don't see reasons why BIP151 could weaken the security of the P2P network. Can you point out some specific concerns?
>
> TOFU cannot prevent MITM attacks (the goal of the encryption). Authentication requires a secure (trusted) side channel by which to distribute public keys. This presents what I consider a significant problem. If widespread, control over this distribution network would constitute control over who can use Bitcoin.
> The effort to prevent censorship could actually enable it. I don't think it would get that far. Someone would point this out in the process of vetting the authentication BIP, and the result would be the scrapping of BIP151.
I agree that the secure trusted 2nd channel key-sharing problem can be
significant for large networks and/or connecting to unknown identities.
But as said, there could be multiple ways of sharing identity keys.
If you want to connect your node to serval other trusted nodes, you can
simply physically preshare keys or do it over GPG / Signal App, etc..
And if I have followed the news correctly, there are some clever guys
working on various internet of trust 2.0 proposals...
>>
>> BIP151 does not rely on identities. BIP151 does not use persisted keys
>> (only ephemeral keys).
>
> BIP 151 is incomplete without authentication.
I would agree if you would say, _trusted encryption_ is incomplete with
authentication. But IMO BIP151 is complete and should be deployed
together with one or multiple authentication schemes.
[1] https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki#risks
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2016-06-28 20:07 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-28 2:31 [bitcoin-dev] BIP 151 use of HMAC_SHA512 Rusty Russell
2016-06-28 7:17 ` [bitcoin-dev] BIP 151 Eric Voskuil
2016-06-28 8:26 ` Jonas Schnelli
2016-06-28 16:45 ` Eric Voskuil
2016-06-28 18:22 ` Peter Todd
2016-06-28 18:35 ` Eric Voskuil
2016-06-28 20:14 ` Peter Todd
2016-06-28 20:29 ` Eric Voskuil
2016-06-28 20:36 ` Peter Todd
2016-06-28 21:22 ` Eric Voskuil
2016-06-28 21:36 ` Gregory Maxwell
2016-06-28 21:40 ` Cameron Garnham
2016-06-28 22:07 ` Eric Voskuil
2016-06-28 22:33 ` Cameron Garnham
2016-06-28 23:29 ` Eric Voskuil
2016-06-29 0:06 ` Nick ODell
2016-06-28 21:59 ` Eric Voskuil
[not found] ` <CAAS2fgQ0Ocs8hF+pf+fWfkKKhQwxNKpY=JHpb_bwua7neVO8tg@mail.gmail.com>
2016-06-28 23:34 ` Eric Voskuil
2016-06-28 20:06 ` Jonas Schnelli [this message]
2016-06-28 23:31 ` Eric Voskuil
2016-06-29 11:17 ` Alfie John
2016-06-30 11:56 ` Eric Voskuil
2016-06-30 12:20 ` Jonas Schnelli
2016-06-30 12:27 ` Eric Voskuil
2016-06-30 12:43 ` Jonas Schnelli
2016-06-30 15:22 ` Eric Voskuil
2016-06-30 16:52 ` Peter Todd
2016-06-30 18:25 ` Eric Voskuil
2016-06-30 19:06 ` Peter Todd
2016-06-30 20:26 ` Eric Voskuil
2016-06-28 19:55 ` Gregory Maxwell
2016-06-28 23:33 ` Eric Voskuil
2016-06-29 1:01 ` Gregory Maxwell
2016-06-30 9:57 ` Eric Voskuil
2016-06-30 13:03 ` Pieter Wuille
2016-06-30 15:10 ` Eric Voskuil
2016-08-31 14:29 ` Pieter Wuille
2016-06-30 13:36 ` Erik Aronesty
2016-06-30 14:47 ` Alfie John
2016-07-02 9:44 ` Chris Priest
2016-06-28 12:13 ` Jonas Schnelli
2016-06-28 17:39 ` Eric Voskuil
2016-06-28 7:19 ` [bitcoin-dev] BIP 151 use of HMAC_SHA512 Jonas Schnelli
2016-06-28 8:31 ` Arthur Chen
2016-06-29 18:34 ` Jonas Schnelli
2016-06-29 20:13 ` Peter Todd
2016-06-29 20:31 ` Jonas Schnelli
2016-06-29 1:00 ` Rusty Russell
2016-06-29 1:38 ` Arthur Chen
2016-06-29 1:56 ` Ethan Heilman
2016-06-29 6:58 ` Pieter Wuille
2016-06-29 14:38 ` Ethan Heilman
2016-06-29 18:46 ` Jonas Schnelli
2016-07-01 3:25 ` Rusty Russell
2016-07-01 22:42 ` Zooko Wilcox
2016-07-04 1:23 ` Arthur Chen
2016-07-04 1:44 ` Arthur Chen
2016-07-04 6:47 ` Jonas Schnelli
2016-07-04 6:37 ` Jonas Schnelli
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=5772D8E2.6020007@jonasschnelli.ch \
--to=dev@jonasschnelli$(echo .)ch \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=eric@voskuil$(echo .)org \
/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