Jonas Schnelli [ARCHIVE] on Nostr: 📅 Original date posted:2016-06-28 📝 Original message:>> In my opinion, the ...
📅 Original date posted:2016-06-28
📝 Original message:>> 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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160628/3748c989/attachment.sig>;
📝 Original message:>> 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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160628/3748c989/attachment.sig>;