[bitcoin-dev] BIP 151
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I haven't seen much discussion here on the rationale behind BIP 151. Apologies if I missed it. I'm trying to understand why libbitcoin (or any node) would want to support it. I understand the use, when coupled with a yet-to-be-devised identity system, with Bloom filter features. Yet these features are client-server in nature. Libbitcoin (for example) supports client-server features on an independent port (and implements a variant of CurveCP for encryption and identity). My concern arises with application of identity to the P2P protocol (excluding Bloom filter features). It seems to me that the desire to secure against the weaknesses of BF is being casually generalized to the P2P network. That generalization may actually weaken the security of the P2P protocol. One might consider the proper resolution is to move the BF features to a client-server protocol. The BIP does not make a case for other scenarios, or contemplate the significant problems associated with key distribution in any identity system. Given that the BIP relies on identity, these considerations should be fully vetted before heading down another blind alley. e -BEGIN PGP SIGNATURE- Version: oPenGP 6.0 on iOS iQEVAwUBV3IkYjzYwH8LXOFOAQg+iggAkFShi/ibZXiVv3A3z1a1SMd+4ar0kiZk mCkBBZaatoW8tXVZmuv5xzLnj3ali9Y4jp/3h2nUJ1B4ov2kcB0kZIKE/a1DTFwb 4X3uSzgu0lEAqSZormOvt7Op46NPn6KJ+/wTtP4lUFU72lSd7qrVKMlCVc88VE7/ pMloKSc69nAeFIkyWbOUi/zDzefu/5tarfif85jumooYjPmAwJnkgiPCqpqBbuga 5lBdS1r47KK+SaDFl6Cbn4i/c6tBPLTnu+TR7TEKOW5vwVA7eUqb6SOK7pETWJGK 0Ii4ZWYt7MOPSEda381CMjWEwtsCNp0eI4GPZAAz+jNLo4G1+PAbaw== =Balw -END PGP SIGNATURE- ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
> To quote: > >> HMAC_SHA512(key=ecdh_secret|cipher-type,msg="encryption key"). >> >> K_1 must be the left 32bytes of the HMAC_SHA512 hash. >> K_2 must be the right 32bytes of the HMAC_SHA512 hash. > > This seems a weak reason to introduce SHA512 to the mix. Can we just > make: > > K_1 = HMAC_SHA256(key=ecdh_secret|cipher-type,msg="header encryption key") > K_2 = HMAC_SHA256(key=ecdh_secret|cipher-type,msg="body encryption key") SHA512_HMAC is used by BIP32 [1] and I guess most clients will somehow make use of bip32 features. I though a single SHA512_HMAC operation is cheaper and simpler then two SHA256_HMAC. AFAIK, sha256_hmac is also not used by the current p2p & consensus layer. Bitcoin-Core uses it for HTTP RPC auth and Tor control. I don't see big pros/cons for SHA512_HMAC over SHA256_HMAC. [1] https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#child-key-derivation-ckd-functions signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151
Hi Eric > I haven't seen much discussion here on the rationale behind BIP 151. > Apologies if I missed it. I'm trying to understand why libbitcoin (or any > node) would want to support it. > > I understand the use, when coupled with a yet-to-be-devised identity system, > with Bloom filter features. Yet these features are client-server in nature. > Libbitcoin (for example) supports client-server features on an independent > port (and implements a variant of CurveCP for encryption and identity). My > concern arises with application of identity to the P2P protocol (excluding > Bloom filter features). > > It seems to me that the desire to secure against the weaknesses of BF is > being casually generalized to the P2P network. That generalization may > actually weaken the security of the P2P protocol. One might consider the > proper resolution is to move the BF features to a client-server protocol. > > The BIP does not make a case for other scenarios, or contemplate the > significant problems associated with key distribution in any identity system. > Given that the BIP relies on identity, these considerations should be fully > vetted before heading down another blind alley. In my opinion, the question should be "why would you _not_ encrypt". 1) Transaction censorship ISPs, WIFI provider or any other MITM, can holdback/censor unconfirmed transactions. Regardless if you are a miner or a validation/wallet node. 2) Peer censorship MITM can remove or add entries from a "addr" message. 3) Fingerprinting ISPs or any other MITM can intercept/inject fingerprinting relevant messages like "mempool" to analyze the bitcoin network. 4) SPV For obvious reasons regarding BF (see BIP or above). 5) Goundwork for a "client-server" model over the P2P channel Fee estimation, bloom-filters, or any other message type that requires authentication. I would not reduce BIP151 to only solve the BF privacy/censorship problem. If we agree that censorship-resistance is one of the main properties of Bitcoin, then we should definitively use a form of end-to-end encryption between nodes. Built into the network layer. 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. 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. 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 agree that BIP151 _must_ be deployed together with an authentication scheme (I'm working on that) to protect again MITM during encryption initialization. --- signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
Based on previous crypto analysis result, the actual security of SHA512 is not significantly higher than SHA256. maybe we should consider SHA3? On Tue, Jun 28, 2016 at 3:19 PM, Jonas Schnelli via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > To quote: > > > >> HMAC_SHA512(key=ecdh_secret|cipher-type,msg="encryption key"). > >> > >> K_1 must be the left 32bytes of the HMAC_SHA512 hash. > >> K_2 must be the right 32bytes of the HMAC_SHA512 hash. > > > > This seems a weak reason to introduce SHA512 to the mix. Can we just > > make: > > > > K_1 = HMAC_SHA256(key=ecdh_secret|cipher-type,msg="header encryption > key") > > K_2 = HMAC_SHA256(key=ecdh_secret|cipher-type,msg="body encryption key") > > SHA512_HMAC is used by BIP32 [1] and I guess most clients will somehow > make use of bip32 features. I though a single SHA512_HMAC operation is > cheaper and simpler then two SHA256_HMAC. > > AFAIK, sha256_hmac is also not used by the current p2p & consensus layer. > Bitcoin-Core uses it for HTTP RPC auth and Tor control. > > I don't see big pros/cons for SHA512_HMAC over SHA256_HMAC. > > > > [1] > > https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#child-key-derivation-ckd-functions > > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > -- Xuesong (Arthur) Chen Senior Principle Engineer BlockChain Technologist BTCC ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151
Hi Eric Sorry for not directly addressing your points. I try to be more precise in this follow up email: > I understand the use, when coupled with a yet-to-be-devised identity system, > with Bloom filter features. Yet these features are client-server in nature. > Libbitcoin (for example) supports client-server features on an independent > port (and implements a variant of CurveCP for encryption and identity). My > concern arises with application of identity to the P2P protocol (excluding > Bloom filter features). I think the bloom filter SPV usecase is not "pure client-server". SPV clients could request from/broadcast to multiple "trusted nodes". Trusted nodes could be nodes where the operators have shared identities/keys in advance over a different channel. Further private p2p extensions (lets say a p2p form of the estimatefee command) are something which needs to be discussed first and not something that is encouraged or outlined in BIP151. > It seems to me that the desire to secure against the weaknesses of BF is > being casually generalized to the P2P network. That generalization may > actually weaken the security of the P2P protocol. One might consider the > proper resolution is to move the BF features to a client-server protocol. I don't see reasons why BIP151 could weaken the security of the P2P network. Can you point out some specific concerns? > The BIP does not make a case for other scenarios, or contemplate the > significant problems associated with key distribution in any identity system. > Given that the BIP relies on identity, these considerations should be fully > vetted before heading down another blind alley. BIP151 does not rely on identities. BIP151 does not use persisted keys (only ephemeral keys). The authentication/identity system needs to be described in a another BIP. But correct, BIP151 without a form of authentication/identity management is vulnerable to all sorts of MITM attacks and that's why I think BIP151 must be deployed together with an p2p authentication scheme. Scope creeping and the risks of overspecifying is the main reason to focus on the "pure encryption part" in BIP151. Thanks --- signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Code Review: The Consensus Critical Parts of Segwit by Peter Todd
Thanks for Peter Todd’s detailed report: https://petertodd.org/2016/segwit-consensus-critical-code-review I have the following response. >Since the reserve value is only a single, 32-byte value, we’re setting >ourselves up for the same problem again7. Please note that unlimited space has been reserved after the witness commitment: block.vtx[0].vout[o].scriptPubKey.size() >= 38 Which means anything after 38 bytes has no consensus meaning. Any new consensus critical commitments/metadata could be put there. Anyway, there is no efficient way to add a new commitment with softfork. > the fact that we do this has a rather odd result: a transaction spending a > witness output with an unknown version is valid even if the transaction > doesn’t have any witnesses! I don’t see any reason to have such check. We simply leave unknown witness program as any-one-can-spend without looking at the witness, as described in BIP141. > Bizzarely segwit has an additonal pay-to-witness-pubkey-hashP2WPKH that lets > you use a 160-bit (20 byte) commitment…… Since ~90% of current transactions are P2PKH, we expect many people will keep using this type of transaction in the future. P2WPKH gives the same level of security as P2PKH, and smaller scriptPubKey. >give users the option instead to choose to accept the less secure 160-bit >commitment if their use-case doesn’t need the full 256-bit security level This is actually discussed on the mailing list. P2WSH with multi-sig is subject to birthday attack, and therefore 256-bit is used to provide 128-bit security. P2WPKH is used as single sig and therefore 160-bit is enough. >Secondly, if you are going to give a 160-bit commitment option, you don’t need >the extra level of indirection in the P2SH case: just make the segwit >redeemScript be: Something wrong here? In P2WPKH, the witness is >The only downside is the serialized witness script is constrained to 520 bytes >max 520 is the original limit. BIP141 tries to mimic the existing behaviour as much as possible. Anyway, normally nothing in the current scripts should use a push with more than 75 bytes >we haven’t explicitly ensured that signatures for the new signature hash can’t >be reused for the old signature hash How could that be? That’d be a hash collision. signature.asc Description: Message signed with OpenPGP using GPGMail ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151
Hi Jonas, I'll follow up in your second reply as well. Responses inline: > On Jun 28, 2016, at 10:26 AM, Jonas Schnelli via bitcoin-dev > wrote: > > Hi Eric > >> I haven't seen much discussion here on the rationale behind BIP 151. >> Apologies if I missed it. I'm trying to understand why libbitcoin (or any >> node) would want to support it. >> >> I understand the use, when coupled with a yet-to-be-devised identity system, >> with Bloom filter features. Yet these features are client-server in nature. >> Libbitcoin (for example) supports client-server features on an independent >> port (and implements a variant of CurveCP for encryption and identity). My >> concern arises with application of identity to the P2P protocol (excluding >> Bloom filter features). >> >> It seems to me that the desire to secure against the weaknesses of BF is >> being casually generalized to the P2P network. That generalization may >> actually weaken the security of the P2P protocol. One might consider the >> proper resolution is to move the BF features to a client-server protocol. >> >> The BIP does not make a case for other scenarios, or contemplate the >> significant problems associated with key distribution in any identity >> system. Given that the BIP relies on identity, these considerations should >> be fully vetted before heading down another blind alley. > In my opinion, the question should be "why would you _not_ encrypt". 1) creation of a false sense of security 2) as a tradeoff against anonymity 3) benefit does not justify cost > 1) Transaction censorship > ISPs, WIFI provider or any other MITM, can holdback/censor unconfirmed > transactions. Regardless if you are a miner or a validation/wallet node. > > 2) Peer censorship > MITM can remove or add entries from a "addr" message. > > 3) Fingerprinting > ISPs or any other MITM can intercept/inject fingerprinting relevant > messages like "mempool" to analyze the bitcoin network. Encryption alone cannot protect against a MITM attack in an anonymous and permissionless network. This is accepted in the BIP (and your follow-up reply). > 4) SPV > For obvious reasons regarding BF (see BIP or above). > > 5) Goundwork for a "client-server" model over the P2P channel > Fee estimation, bloom-filters, or any other message type that requires > authentication. I do not challenge the usefulness and appropriateness of encryption with authentication in a client-server blockchain protocol. > I would not reduce BIP151 to only solve the BF privacy/censorship problem. > > If we agree that censorship-resistance is one of the main properties of > Bitcoin, We do. > then we should definitively use a form of end-to-end encryption between > nodes. Built into the network layer. This is the assumption that I'm questioning. > 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. 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). > 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. > 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 decla
Re: [bitcoin-dev] BIP 151
continued from previous post... > On Jun 28, 2016, at 2:13 PM, Jonas Schnelli via bitcoin-dev > wrote: > > Hi Eric > > Sorry for not directly addressing your points. No problem. Thanks for the detailed replies. > I try to be more precise in this follow up email: > >> I understand the use, when coupled with a yet-to-be-devised identity system, >> with Bloom filter features. Yet these features are client-server in nature. >> Libbitcoin (for example) supports client-server features on an independent >> port (and implements a variant of CurveCP for encryption and identity). My >> concern arises with application of identity to the P2P protocol (excluding >> Bloom filter features). > > I think the bloom filter SPV usecase is not "pure client-server". SPV > clients could request from/broadcast to multiple "trusted nodes". I have referred to the Bloom filters messages. These are clearly asymmetric in nature. Despite being possible it is not a valid use case for a full node to make BF requests to another node. One client to multiple servers is still client-server for the sake of this discussion. The nature of the P2P protocol is synchronization of content between all nodes/peers. If the protocol is asymmetric the semantics, and therefore use cases, are different. FWIW posting a transaction to the network can be done using the P2P protocol, connecting for a short period of time. But this is also a client-server scenario and is a hack when done (full disclosure, bx provides both P2P and client-server commands for tx posting). Broadcasting is naturally the behavior of a full node. > Trusted nodes could be nodes where the operators have shared identities/keys > in advance over a different channel. Yes, this is necessarily the case in order to prevent a MITM attack. This is the basis of my concern. > Further private p2p extensions (lets say a p2p form of the estimatefee > command) are something which needs to be discussed first and not > something that is encouraged or outlined in BIP151. Sure, but then let us not make assumptions about it in the context of this discussion. Libbitcoin provides fee estimation by monitoring broadcast penetration using a client-server protocol with an optional subscription mechanism. >> It seems to me that the desire to secure against the weaknesses of BF is >> being casually generalized to the P2P network. That generalization may >> actually weaken the security of the P2P protocol. One might consider the >> proper resolution is to move the BF features to a client-server protocol. > > 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. >> The BIP does not make a case for other scenarios, or contemplate the >> significant problems associated with key distribution in any identity >> system. Given that the BIP relies on identity, these considerations should >> be fully vetted before heading down another blind alley. > > BIP151 does not rely on identities. BIP151 does not use persisted keys > (only ephemeral keys). BIP 151 is incomplete without authentication. > The authentication/identity system needs to be described in a another BIP. > But correct, BIP151 without a form of authentication/identity management > is vulnerable to all sorts of MITM attacks and that's why I think BIP151 > must be deployed together with an p2p authentication scheme. Agree, but my problem is that I do not believe we can assume this is a solvable problem. > Scope creeping and the risks of overspecifying is the main reason to > focus on the "pure encryption part" in BIP151. Understood, yet this is the basis of my blind alley comment. e > Thanks > --- > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151
On Tue, Jun 28, 2016 at 06:45:58PM +0200, Eric Voskuil via bitcoin-dev wrote: > > 1) Transaction censorship > > ISPs, WIFI provider or any other MITM, can holdback/censor unconfirmed > > transactions. Regardless if you are a miner or a validation/wallet node. > > > > 2) Peer censorship > > MITM can remove or add entries from a "addr" message. > > > > 3) Fingerprinting > > ISPs or any other MITM can intercept/inject fingerprinting relevant > > messages like "mempool" to analyze the bitcoin network. > > Encryption alone cannot protect against a MITM attack in an anonymous and > permissionless network. This is accepted in the BIP (and your follow-up > reply). Being able to easily detect MITM attacks is a _huge_ step forward that shouldn't be underestimated; even if 99% of users aren't in a position to detect the MITM you only need a small subset of users that do the necessary checks to alert the wider community, who can then respond with stronger security measures. Those measures are likely to be more costly - authenticated systems are significantly harder than not - so better to save your efforts until the need for them is more obvious. Also the fact that an attack has a reasonable probability of detection is a big disincentive for many types of attackers - note how one of the things revealed in the Snowden leaks was the fact that the NSA generally tries quite hard to avoid tipping off targets to the fact that they're being surveilled, with a myriad of carefully scripted policies to control when and how exploits are used against targets. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151
Hi Peter, What in this BIP makes a MITM attack easier (or easy) to detect, or increases the probability of one being detected? e > On Jun 28, 2016, at 8:22 PM, Peter Todd wrote: > > On Tue, Jun 28, 2016 at 06:45:58PM +0200, Eric Voskuil via bitcoin-dev wrote: >>> 1) Transaction censorship >>> ISPs, WIFI provider or any other MITM, can holdback/censor unconfirmed >>> transactions. Regardless if you are a miner or a validation/wallet node. >>> >>> 2) Peer censorship >>> MITM can remove or add entries from a "addr" message. >>> >>> 3) Fingerprinting >>> ISPs or any other MITM can intercept/inject fingerprinting relevant >>> messages like "mempool" to analyze the bitcoin network. >> >> Encryption alone cannot protect against a MITM attack in an anonymous and >> permissionless network. This is accepted in the BIP (and your follow-up >> reply). > > Being able to easily detect MITM attacks is a _huge_ step forward that > shouldn't be underestimated; even if 99% of users aren't in a position to > detect the MITM you only need a small subset of users that do the necessary > checks to alert the wider community, who can then respond with stronger > security measures. Those measures are likely to be more costly - authenticated > systems are significantly harder than not - so better to save your efforts > until the need for them is more obvious. > > Also the fact that an attack has a reasonable probability of detection is a > big > disincentive for many types of attackers - note how one of the things revealed > in the Snowden leaks was the fact that the NSA generally tries quite hard to > avoid tipping off targets to the fact that they're being surveilled, with a > myriad of carefully scripted policies to control when and how exploits are > used > against targets. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151
> I understand the use, when coupled with a yet-to-be-devised identity system, > with Bloom filter features. Yet these features This is a bit of a strawman, you've selected a single narrow usecase which isn't proposed by the BIP and then argue it is worthless. I agree that example doesn't have much value (and I believe that eventually the BIP37 bloom filters should be removed from the protocol). Without something like BIP151 network participants cannot have privacy for the transactions they originate within the protocol against network observers. Even if, through some extraordinary effort, their own first hop is encrypted, unencrypted later hops would rapidly expose significant information about transaction origins in the network. Without something like BIP151 authenticated links are not possible, so manually curated links (addnode/connect) cannot be counted on to provide protection against partitioning sybils. Along the way BIP151 appears that it will actually make the protocol faster. > Given that the BIP relies on identity This is untrue. The proposal is an ephemerally keyed opportunistic encryption system. The privacy against a network observer does not depend on authentication, much less "identity". And when used with authentication at all it makes interception strongly detectable after the fact. > The BIP does not [...] contemplate the significant problems associated with > key distribution in any identity system Because it does not propose any "identity system" or authorization (also, I object to your apparent characterization of authentication as as an 'identity system'-- do you also call Bitcoin addresses an identity system?). That said, manually maintaining adds nodes to your own and somewhat trusted nodes is a recommend best practice for miners and other high value systems which is rendered much less effective due to a lack of authentication, there is no significant key distribution problem in that case, and I expect the future auth BIP (Jonas had one before, but it was put aside for now to first focus on the link layer encryption) to address that case quite well. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151
>> 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
Re: [bitcoin-dev] BIP 151
On Tue, Jun 28, 2016 at 08:35:26PM +0200, Eric Voskuil wrote: > Hi Peter, > > What in this BIP makes a MITM attack easier (or easy) to detect, or increases > the probability of one being detected? BIP151 gives users the tools to detect a MITM attack. It's kinda like PGP in that way: lots of PGP users don't properly check keys, so an attacker won't have a hard time MITM attacking those users. But some users do check keys, a labor intensive manual process, but not a process that requires any real cryptographic sophistication, let alone writing any code. It's very difficult for widescale attackers to distinguish the users who do check keys from the ones that don't, so if you MITM attack _any_ user you run the risk of running into one of the few that does check, and those users can alert everyone else. The key thing, is we need to get everyones communications encrypted first: if we don't the MITM attacker can intercept 99% of the communications with 0% risk of detection, because the non-sophisticated users are trivially distinguishable from the sophisticated users: just find the users with unencrypted communications! -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151
> On Jun 28, 2016, at 10:14 PM, Peter Todd wrote: > >> On Tue, Jun 28, 2016 at 08:35:26PM +0200, Eric Voskuil wrote: >> Hi Peter, >> >> What in this BIP makes a MITM attack easier (or easy) to detect, or >> increases the probability of one being detected? > > BIP151 gives users the tools to detect a MITM attack. > > It's kinda like PGP in that way: lots of PGP users don't properly check keys, PGP requires a secure side channel for transmission of public keys. How does one "check" a key of an anonymous peer? I know you well enough to know you wouldn't trust a PGP key received over an insecure channel. All you can prove is that you are talking to a peer and that communications in the session remain with that peer. The peer can be the attacker. As Jonas has acknowledged, authentication is required to actually guard against MITM attacks. > so an attacker won't have a hard time MITM attacking those users. But some > users do check keys, a labor intensive manual process, but not a process that > requires any real cryptographic sophistication, let alone writing any code. > It's very difficult for widescale attackers to distinguish the users who do > check keys from the ones that don't, so if you MITM attack _any_ user you run > the risk of running into one of the few that does check, and those users can > alert everyone else. > > The key thing, is we need to get everyones communications encrypted first: if > we don't the MITM attacker can intercept 99% of the communications with 0% > risk > of detection, because the non-sophisticated users are trivially > distinguishable from the sophisticated users: just find the users with > unencrypted > communications! > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151
On Tue, Jun 28, 2016 at 10:29:54PM +0200, Eric Voskuil wrote: > > > > On Jun 28, 2016, at 10:14 PM, Peter Todd wrote: > > > >> On Tue, Jun 28, 2016 at 08:35:26PM +0200, Eric Voskuil wrote: > >> Hi Peter, > >> > >> What in this BIP makes a MITM attack easier (or easy) to detect, or > >> increases the probability of one being detected? > > > > BIP151 gives users the tools to detect a MITM attack. > > > > It's kinda like PGP in that way: lots of PGP users don't properly check > > keys, > > PGP requires a secure side channel for transmission of public keys. How does > one "check" a key of an anonymous peer? I know you well enough to know you > wouldn't trust a PGP key received over an insecure channel. > > All you can prove is that you are talking to a peer and that communications > in the session remain with that peer. The peer can be the attacker. As Jonas > has acknowledged, authentication is required to actually guard against MITM > attacks. Easy: anonymous peers aren't always actually anonymous. A MITM attacker can't easily distinguish communications between two nodes that randomly picked their peers, and nodes that are connected because their operators manually used -addnode to peer; in the latter case the operators can check whether or not they're being attacked with an out-of-band key check. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151
> On Jun 28, 2016, at 10:36 PM, Peter Todd wrote: > >> On Tue, Jun 28, 2016 at 10:29:54PM +0200, Eric Voskuil wrote: >> >> On Jun 28, 2016, at 10:14 PM, Peter Todd wrote: On Tue, Jun 28, 2016 at 08:35:26PM +0200, Eric Voskuil wrote: Hi Peter, What in this BIP makes a MITM attack easier (or easy) to detect, or increases the probability of one being detected? >>> >>> BIP151 gives users the tools to detect a MITM attack. >>> >>> It's kinda like PGP in that way: lots of PGP users don't properly check >>> keys, >> >> PGP requires a secure side channel for transmission of public keys. How does >> one "check" a key of an anonymous peer? I know you well enough to know you >> wouldn't trust a PGP key received over an insecure channel. >> >> All you can prove is that you are talking to a peer and that communications >> in the session remain with that peer. The peer can be the attacker. As Jonas >> has acknowledged, authentication is required to actually guard against MITM >> attacks. > > Easy: anonymous peers aren't always actually anonymous. > > A MITM attacker can't easily distinguish communications between two nodes that > randomly picked their peers, and nodes that are connected because their > operators manually used -addnode to peer; in the latter case the operators can > check whether or not they're being attacked with an out-of-band key check. An "out of band key check" is not part of BIP151. It requires a secure channel and is authentication. So BIP151 doesn't provide the tools to detect an attack, that requires authentication. A general requirement for authentication is the issue I have raised. e ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151
On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev wrote: > An "out of band key check" is not part of BIP151. It has a session ID for this purpose. > It requires a secure channel and is authentication. So BIP151 doesn't provide > the tools to detect an attack, that requires authentication. A general > requirement for authentication is the issue I have raised. One might wonder how you ever use a Bitcoin address, or even why we might guess these emails from "you" aren't actually coming from the NSA. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151
Unauthenticated link level encryption is wonderful! MITM attacks are overrated; as they require an active attacker. Stopping passive attacks is the low hanging fruit. This should be taken first. Automated and secure peer authentication in a mesh network is a huge topic. One of the unsolved problems in computer science. A simple 'who is that' by asking for the fingerprint of your peers from your other peers is a very simple way to get 'some' authentication. Semi-trusted index nodes also is a low hanging fruit for authentication. However, let's first get unauthenticated encryption. Force the attackers to use active attacks. (That are thousands times more costly to couduct). Sent from my iPhone > On 29 Jun 2016, at 00:36, Gregory Maxwell via bitcoin-dev > wrote: > > On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev > wrote: >> An "out of band key check" is not part of BIP151. > > It has a session ID for this purpose. > >> It requires a secure channel and is authentication. So BIP151 doesn't >> provide the tools to detect an attack, that requires authentication. A >> general requirement for authentication is the issue I have raised. > > One might wonder how you ever use a Bitcoin address, or even why we > might guess these emails from "you" aren't actually coming from the > NSA. > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151
> On Jun 28, 2016, at 11:36 PM, Gregory Maxwell wrote: > > On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev > wrote: >> An "out of band key check" is not part of BIP151. > > It has a session ID for this purpose. Passing the session ID out of band is authentication. As this is explicitly not part of BIP151 it cannot be that BIP151 provides the tools to detect a attack (the point at issue). >> It requires a secure channel and is authentication. So BIP151 doesn't >> provide the tools to detect an attack, that requires authentication. A >> general requirement for authentication is the issue I have raised. > > One might wonder how you ever use a Bitcoin address, or even why we might > guess these emails from "you" aren't actually coming from the NSA. The sarcasm is counterproductive Greg. By the same token I could ask how you ever use Bitcoin given that the P2P protocol is not encrypted or authenticated. It doesn't matter who I am, maybe I am the NSA. I don't argue from a position of authority. Signing my emails while traveling on holiday with only my phone gets a little tedious. The blockchain and mempool are a cache of public data. Transmission of a payment address to a payer is not a comparable scenario. The possibility that authentication may become required to participate in this trustless network is a legitimate concern, and one that has not been addressed. e ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151
Hi Cameron, good to hear from you! > On Jun 28, 2016, at 11:40 PM, Cameron Garnham wrote: > > Unauthenticated link level encryption is wonderful! MITM attacks are > overrated; as they require an active attacker. This is not really the case with Bitcoin. A MITM attack does not require that the attacker find a way to inject traffic into the communication between nodes. Peers will connect to the attacker directly, or accept connections directly from it. Such attacks can be easier than even passive attacks. > Stopping passive attacks is the low hanging fruit. This should be taken first. > > Automated and secure peer authentication in a mesh network is a huge topic. > One of the unsolved problems in computer science. > > A simple 'who is that' by asking for the fingerprint of your peers from your > other peers is a very simple way to get 'some' authentication. Semi-trusted > index nodes also is a low hanging fruit for authentication. It is the implication of widespread authentication that is at issue. Clearly there are ways to implement it using a secure side channels. > However, let's first get unauthenticated encryption. Force the attackers to > use active attacks. (That are thousands times more costly to couduct). > > Sent from my iPhone > >> On 29 Jun 2016, at 00:36, Gregory Maxwell via bitcoin-dev >> wrote: >> >> On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev >> wrote: >>> An "out of band key check" is not part of BIP151. >> >> It has a session ID for this purpose. >> >>> It requires a secure channel and is authentication. So BIP151 doesn't >>> provide the tools to detect an attack, that requires authentication. A >>> general requirement for authentication is the issue I have raised. >> >> One might wonder how you ever use a Bitcoin address, or even why we >> might guess these emails from "you" aren't actually coming from the >> NSA. >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151
There are two different topics mixed up here. 1. Link-level security (secure connection to the node we intended to connect to). 2. Node-level security (aka; don't connect to a 'evil node'). The fist requires link-level encryption and authentication. The second requires identity authentication. You described the 'evil node' attack; that indeed needs an identity system to stop. However BIP151 doesn't intend to protect against connecting to evil Bitcoin Nodes. It is important not to mixup link-level authentication and node-level authentication. When your client picks random nodes to connect to, you are not considered whom in particular runs them. (Rather that you have a good random sample of the network). If you manually add a friends node; at this point you wish to have node-level authentication. However, this may (and probably should) happen out-of-band. Sent from my iPhone > On 29 Jun 2016, at 01:07, Eric Voskuil wrote: > > Hi Cameron, good to hear from you! > >> On Jun 28, 2016, at 11:40 PM, Cameron Garnham wrote: >> >> Unauthenticated link level encryption is wonderful! MITM attacks are >> overrated; as they require an active attacker. > > This is not really the case with Bitcoin. A MITM attack does not require that > the attacker find a way to inject traffic into the communication between > nodes. Peers will connect to the attacker directly, or accept connections > directly from it. Such attacks can be easier than even passive attacks. > >> Stopping passive attacks is the low hanging fruit. This should be taken >> first. >> >> Automated and secure peer authentication in a mesh network is a huge topic. >> One of the unsolved problems in computer science. >> >> A simple 'who is that' by asking for the fingerprint of your peers from your >> other peers is a very simple way to get 'some' authentication. Semi-trusted >> index nodes also is a low hanging fruit for authentication. > > It is the implication of widespread authentication that is at issue. Clearly > there are ways to implement it using a secure side channels. > >> However, let's first get unauthenticated encryption. Force the attackers to >> use active attacks. (That are thousands times more costly to couduct). >> >> Sent from my iPhone >> >>> On 29 Jun 2016, at 00:36, Gregory Maxwell via bitcoin-dev >>> wrote: >>> >>> On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev >>> wrote: An "out of band key check" is not part of BIP151. >>> >>> It has a session ID for this purpose. >>> It requires a secure channel and is authentication. So BIP151 doesn't provide the tools to detect an attack, that requires authentication. A general requirement for authentication is the issue I have raised. >>> >>> One might wonder how you ever use a Bitcoin address, or even why we >>> might guess these emails from "you" aren't actually coming from the >>> NSA. >>> ___ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151
Your description of the two scenarios reduces to one. They both require authentication, and if you intend to connect to potentially evil nodes you aren't securing anything with link level security except the knowledge that your potentially evil node connection remains so. e > On Jun 29, 2016, at 12:33 AM, Cameron Garnham wrote: > > > There are two different topics mixed up here. > > 1. Link-level security (secure connection to the node we intended to connect > to). > > 2. Node-level security (aka; don't connect to a 'evil node'). > > The fist requires link-level encryption and authentication. > > The second requires identity authentication. > > You described the 'evil node' attack; that indeed needs an identity system to > stop. However BIP151 doesn't intend to protect against connecting to evil > Bitcoin Nodes. > > It is important not to mixup link-level authentication and node-level > authentication. > > When your client picks random nodes to connect to, you are not considered > whom in particular runs them. (Rather that you have a good random sample of > the network). > > If you manually add a friends node; at this point you wish to have node-level > authentication. However, this may (and probably should) happen out-of-band. > > > Sent from my iPhone > >> On 29 Jun 2016, at 01:07, Eric Voskuil wrote: >> >> Hi Cameron, good to hear from you! >> >>> On Jun 28, 2016, at 11:40 PM, Cameron Garnham wrote: >>> >>> Unauthenticated link level encryption is wonderful! MITM attacks are >>> overrated; as they require an active attacker. >> >> This is not really the case with Bitcoin. A MITM attack does not require >> that the attacker find a way to inject traffic into the communication >> between nodes. Peers will connect to the attacker directly, or accept >> connections directly from it. Such attacks can be easier than even passive >> attacks. >> >>> Stopping passive attacks is the low hanging fruit. This should be taken >>> first. >>> >>> Automated and secure peer authentication in a mesh network is a huge topic. >>> One of the unsolved problems in computer science. >>> >>> A simple 'who is that' by asking for the fingerprint of your peers from >>> your other peers is a very simple way to get 'some' authentication. >>> Semi-trusted index nodes also is a low hanging fruit for authentication. >> >> It is the implication of widespread authentication that is at issue. Clearly >> there are ways to implement it using a secure side channels. >> >>> However, let's first get unauthenticated encryption. Force the attackers to >>> use active attacks. (That are thousands times more costly to couduct). >>> >>> Sent from my iPhone >>> On 29 Jun 2016, at 00:36, Gregory Maxwell via bitcoin-dev wrote: On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev wrote: > An "out of band key check" is not part of BIP151. It has a session ID for this purpose. > It requires a secure channel and is authentication. So BIP151 doesn't > provide the tools to detect an attack, that requires authentication. A > general requirement for authentication is the issue I have raised. One might wonder how you ever use a Bitcoin address, or even why we might guess these emails from "you" aren't actually coming from the NSA. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151
On Jun 28, 2016, at 10:06 PM, Jonas Schnelli wrote: >>> 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? The relevant question would be to ask whether encryption would prevent an ISP from doing so (which it would not). This is a good example of false sense of security. > 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. FWIW I was just answering your question comprehensively. Relationship to BIP151 is incidental (though apparently applicable). Keep in mind my specific concern is not with the design of BIP151, it is with the implication of its dependency on an unspecified authentication proposal. >> 2) as a tradeoff against anonymity > > Can you point out the tradeoffs? > BIP151 does not introduce fingerprinting possibilities. The security tradeoff would arise from widespread deployment of authentication - which is necessary to make encryption useful against envisioned MITM attacks. See my previous discussion of trust zones below. >> 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. Simply put, any code that is unnecessary does not justify its cost. >>> 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). TOFU (trust on first use) was a reference to what was discussed on IRC as a potential solution to the (deferred) authentication problem. I didn't mean to imply that it was part of BIP151. > 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). This is a restatement of what I have accepted as a premise - that authentication, and as such, key distribution, will be a necessary part of making any encryption scheme effective. "Preshared" implies a secure side channel for key distribution. > 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. Whether or not there are multiple schemes is not relevant to the point I have raised. The issue is that authentication is necessary. >> 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 > ha
Re: [bitcoin-dev] BIP 151
On Jun 28, 2016, at 9:55 PM, Gregory Maxwell via bitcoin-dev wrote: >> I understand the use, when coupled with a yet-to-be-devised identity system, >> with Bloom filter features. Yet these features > > This is a bit of a strawman, you've selected a single narrow usecase which > isn't proposed by the BIP and then argue it is worthless. I agree that > example doesn't have much value (and I believe that > eventually the BIP37 bloom filters should be removed from the protocol). I don't follow this comment. The BIP aims quite clearly at "SPV" wallets as its justifying scenario. > Without something like BIP151 network participants cannot have privacy for > the transactions they originate within the protocol against network observers. And they won't get it with BIP151 either. Being a peer is easier than observing the network. If one can observe the encrypted traffic one can certainly use a timing attack to determine what the node has sent. > Even if, through some extraordinary effort, their own first hop is encrypted, > unencrypted later hops would rapidly > expose significant information about transaction origins in the network. As will remain the case until all connections are encrypted and authenticated, and all participants are known to be good guys. Starting to sound like PKI? > Without something like BIP151 authenticated links are not possible, so > manually curated links (addnode/connect) cannot be counted on to provide > protection against partitioning sybils. If we trust the manual links we don't need/want the other links. In fact retaining the other links enables the attack you described above. Of course there is no need to worry about Sybil attacks when all of your peers are authenticated. But again, let us not ignore the problems of requiring all peers on the network be authenticated. > Along the way BIP151 appears that it will actually make the protocol faster. > >> Given that the BIP relies on identity > > This is untrue. The proposal is an ephemerally keyed opportunistic > encryption system. The privacy against a network observer does not depend on > authentication, much less "identity". And when used with authentication at > all it makes interception strongly detectable after the fact. Maybe I was insufficiently explicit. By "relies on identity" I meant that the BIP is not effective without it. I did not mean to imply that the BIP itself implements an identity scheme. I thought this was clear from the context. >> The BIP does not [...] contemplate the significant problems associated with >> key distribution in any identity system > > Because it does not propose any "identity system" or authorization (also, I > object to your apparent characterization of authentication as as an 'identity > system'-- do you also call Bitcoin addresses an identity system?). Please read more carefully what I wrote. I did not characterize authentication as an identity system. I proposed that key distribution has significant problems, and used identity systems as an example of systems with such problems. I could just have easily written "authentication systems", (and probably should have). > That said, manually maintaining adds nodes to your own and somewhat trusted > nodes is a recommend best practice for miners and other high value systems > which is rendered much less effective due to a lack of > authentication, there is no significant key distribution problem in that case This is the only legitimate scenario that I am aware of. Doing this by IP address (as we do) is weak if there is no VPN. Yet this scenario is very different than general authentication. This scenario is a set of nodes that is essentially a single logical node from the perspective of the Bitcoin security model. One entity controls the validation rules, or is collaborating with another entity to do so. My concern is that a general authentication requirement expands this single logical node and gives control over if to the entity that controls key distribution - the hard problem that hasn't been addressed. If there is no such entity restricting access to the network (which hopefully we can assume) then there is no reason to expect any effective improvement, since nodes will necessarily have to connect with anonymous peers. Anyone with a node and the ability to monitor traffic should remain very effective. > and I expect the future auth BIP (Jonas had one before, but it was put aside > for now to first focus on the link layer encryption) > to address that case quite well. Defining an auth implementation is not a hard problem, nor is it the concern I have raised. e ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151
>> On Jun 29, 2016, at 12:22 AM, Gregory Maxwell wrote: >> >> On Tue, Jun 28, 2016 at 9:59 PM, Eric Voskuil wrote: >> Passing the session ID out of band is authentication. As this is explicitly >> not part of BIP151 it cannot be that BIP151 provides the tools to detect a >> attack (the point at issue). > > It provides the ID, the rest is meat. The rest is "authentication". > Users can compare session IDs > via whatever communications channels they already use after the fact > and discover if they were or are being MITMed. > It requires a secure channel and is authentication. So BIP151 doesn't provide the tools to detect an attack, that requires authentication. A general requirement for authentication is the issue I have raised. >>> >>> One might wonder how you ever use a Bitcoin address, or even why we might >>> guess these emails from "you" aren't actually coming from the NSA. >> >> The sarcasm is counterproductive Greg. By the same token I could ask how you >> ever use Bitcoin given that the P2P protocol is not encrypted or >> authenticated. > > I think I was unclear. A bitcoin address needs to be sent over a secure > channel, which we do not provide. Yet sending funds to addresses instead of > anyone_can_spend is pretty useful. > > Similarly, I can guess that messages claiming to you are probably from you > when many people can independently check, even if they don't usually. The > fact tampered messages might be detected is a big disincentive from trying. You were perfectly clear. Did I give some indication that I did not understand what you meant? >> The blockchain and mempool are a cache of public data. Transmission of a >> payment address to a payer is not a comparable scenario. > > The precise timing and ordering of transactions being relayed is _not_ > public data. Posting txs to the network is a client-server scenario. The set of txs arriving at an arbitrary node, including the order of arrival, is by definition public information. The only possible way it could be considered private is if the entire network was private. So where does the private timing become public? First hop, second, third? Encryption and authentication cannot prevent timing attacks against a person posting txs to the network unless the entire network is "secured". That is not possible without centralized access control. Encrypting the P2P network doesn't resolve this problem, nor does authentication, nor does Tor. I would prefer we advance an actual solution to this significant problem than advance a false sense of security while creating both complexity and the likely evolution of node identity. e ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151
>They both require authentication, Yeah, but not the same *sort* of authentication. As a trivial example, you could have ten servers that sign long-term keys for nodes. All that they need to check is that the node requesting a signature owns the corresponding IP address. On the other hand, 'evil nodes' is a subjective quality that is hard to assess automatically. >and if you intend to connect to potentially evil nodes you aren't securing >anything Bitcoin is designed with the assumption that some of the nodes you connect to might be evil. Sure, if 100% of the nodes you're connected to are evil, you're screwed. However, we shouldn't avoid protecting people from someone on the same coffee-shop network, just because the same mitigation won't work against a nation-state. On Tue, Jun 28, 2016 at 5:29 PM, Eric Voskuil via bitcoin-dev wrote: > Your description of the two scenarios reduces to one. They both require > authentication, and if you intend to connect to potentially evil nodes you > aren't securing anything with link level security except the knowledge that > your potentially evil node connection remains so. > > e > > On Jun 29, 2016, at 12:33 AM, Cameron Garnham wrote: > > > There are two different topics mixed up here. > > 1. Link-level security (secure connection to the node we intended to connect > to). > > 2. Node-level security (aka; don't connect to a 'evil node'). > > The fist requires link-level encryption and authentication. > > The second requires identity authentication. > > You described the 'evil node' attack; that indeed needs an identity system > to stop. However BIP151 doesn't intend to protect against connecting to evil > Bitcoin Nodes. > > It is important not to mixup link-level authentication and node-level > authentication. > > When your client picks random nodes to connect to, you are not considered > whom in particular runs them. (Rather that you have a good random sample of > the network). > > If you manually add a friends node; at this point you wish to have > node-level authentication. However, this may (and probably should) happen > out-of-band. > > > Sent from my iPhone > > On 29 Jun 2016, at 01:07, Eric Voskuil wrote: > > Hi Cameron, good to hear from you! > > On Jun 28, 2016, at 11:40 PM, Cameron Garnham wrote: > > Unauthenticated link level encryption is wonderful! MITM attacks are > overrated; as they require an active attacker. > > > This is not really the case with Bitcoin. A MITM attack does not require > that the attacker find a way to inject traffic into the communication > between nodes. Peers will connect to the attacker directly, or accept > connections directly from it. Such attacks can be easier than even passive > attacks. > > Stopping passive attacks is the low hanging fruit. This should be taken > first. > > Automated and secure peer authentication in a mesh network is a huge topic. > One of the unsolved problems in computer science. > > A simple 'who is that' by asking for the fingerprint of your peers from your > other peers is a very simple way to get 'some' authentication. Semi-trusted > index nodes also is a low hanging fruit for authentication. > > > It is the implication of widespread authentication that is at issue. Clearly > there are ways to implement it using a secure side channels. > > However, let's first get unauthenticated encryption. Force the attackers to > use active attacks. (That are thousands times more costly to couduct). > > Sent from my iPhone > > On 29 Jun 2016, at 00:36, Gregory Maxwell via bitcoin-dev > wrote: > > On Tue, Jun 28, 2016 at 9:22 PM, Eric Voskuil via bitcoin-dev > wrote: > > An "out of band key check" is not part of BIP151. > > > It has a session ID for this purpose. > > It requires a secure channel and is authentication. So BIP151 doesn't > provide the tools to detect an attack, that requires authentication. A > general requirement for authentication is the issue I have raised. > > > One might wonder how you ever use a Bitcoin address, or even why we > might guess these emails from "you" aren't actually coming from the > NSA. > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151
On Tue, Jun 28, 2016 at 11:33 PM, Eric Voskuil wrote: > I don't follow this comment. The BIP aims quite clearly at "SPV" wallets as > its justifying scenario. It cites SPV as an example, doesn't mention bloom filters.. and sure-- sounds like the bip text should make the >> Without something like BIP151 network participants cannot have privacy for >> the transactions they originate within the protocol against network >> observers. > > And they won't get it with BIP151 either. Being a peer is easier than > observing the network. Not passively, undetectable, and against thousands of users at once at low cost. > If one can observe the encrypted traffic one can certainly use a timing > attack to determine what the node has sent. Not against Bitcoin Core, transactions are batched and relayed in sorted order. (obviously there are limits at what this provides; ironically, the lack of link encryption has been used to argue against privacy preserving relay behavior) >> Even if, through some extraordinary effort, their own first hop is >> encrypted, unencrypted later hops would rapidly >> expose significant information about transaction origins in the network. > > As will remain the case until all connections are encrypted and > authenticated, and all participants are known to be good guys. Starting to > sound like PKI? Huh? The first and subsequent hops obscures the origin and timing. >> Without something like BIP151 authenticated links are not possible, so >> manually curated links (addnode/connect) cannot be counted on to provide >> protection against partitioning sybils. > > If we trust the manual links we don't need/want the other links. In fact > retaining the other links enables the attack you described above. Of course > there is no need to worry about Sybil attacks when all of your peers are > authenticated. But again, let us not ignore the problems of requiring all > peers on the network be authenticated. Don't need and want them for what? For _partitioning_ resistance, you are not partitioned if you have one honest connection to the functional network. Additional peers purely reduce your partition vulnerability-- so long as an active network attacker isn't itercepting all your connections out. For privacy, you have improve transaction privacy so long as your transaction isn't initially relayed to a malicious peer-- but malicious peers can lie further out because transit nodes obscure the order of message creation. Bitcoin Core currently relays transactions first and more frequently to outbound and whitelisted peers. > Maybe I was insufficiently explicit. By "relies on identity" I meant that the > BIP is not effective without it. I did not mean to imply that the BIP itself > implements an identity scheme. I thought this was clear from the context. I understood that, but my point was that Bitcoin cannot be used at all_unless users have secure communication channels to share addresses. > then there is no reason to expect any effective improvement, since nodes will > necessarily have to connect with anonymous peers. They're not required to _only_ connect with anonymous peers. And partition resistance requires that you have any one good link. > Anyone with a node and the ability to monitor traffic should remain very > effective. Not via passive observation. > Defining an auth implementation is not a hard problem, nor is it the concern > I have raised. Glad you agree. We seem to be looping now. Feel free to not implement this proposal, no one suggests making it mandatory. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
Jonas Schnelli writes: >> To quote: >> >>> HMAC_SHA512(key=ecdh_secret|cipher-type,msg="encryption key"). >>> >>> K_1 must be the left 32bytes of the HMAC_SHA512 hash. >>> K_2 must be the right 32bytes of the HMAC_SHA512 hash. >> >> This seems a weak reason to introduce SHA512 to the mix. Can we just >> make: >> >> K_1 = HMAC_SHA256(key=ecdh_secret|cipher-type,msg="header encryption key") >> K_2 = HMAC_SHA256(key=ecdh_secret|cipher-type,msg="body encryption key") > > SHA512_HMAC is used by BIP32 [1] and I guess most clients will somehow > make use of bip32 features. I though a single SHA512_HMAC operation is > cheaper and simpler then two SHA256_HMAC. Good point; I would argue that mistake has already been made. But I was looking at appropriating your work for lightning inter-node comms, and adding another hash algo seemed unnecessarily painful. > AFAIK, sha256_hmac is also not used by the current p2p & consensus layer. > Bitcoin-Core uses it for HTTP RPC auth and Tor control. It's also not clear to me why the HMAC, vs just SHA256(key|cipher-type|mesg). But that's probably just my crypto ignorance... Thanks! Rusty. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
HMAC has proven security property. It is still secure even when underlying crypto hashing function has collision resistant weakness. For example, MD5 is considered completely insecure now, but HMAC-MD5 is still considered secure. When in doubt, we should always use HMAC for MAC(Message Authentication Code) rather than custom construction On Wed, Jun 29, 2016 at 9:00 AM, Rusty Russell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Jonas Schnelli writes: > >> To quote: > >> > >>> HMAC_SHA512(key=ecdh_secret|cipher-type,msg="encryption key"). > >>> > >>> K_1 must be the left 32bytes of the HMAC_SHA512 hash. > >>> K_2 must be the right 32bytes of the HMAC_SHA512 hash. > >> > >> This seems a weak reason to introduce SHA512 to the mix. Can we just > >> make: > >> > >> K_1 = HMAC_SHA256(key=ecdh_secret|cipher-type,msg="header encryption > key") > >> K_2 = HMAC_SHA256(key=ecdh_secret|cipher-type,msg="body encryption key") > > > > SHA512_HMAC is used by BIP32 [1] and I guess most clients will somehow > > make use of bip32 features. I though a single SHA512_HMAC operation is > > cheaper and simpler then two SHA256_HMAC. > > Good point; I would argue that mistake has already been made. But I was > looking at appropriating your work for lightning inter-node comms, and > adding another hash algo seemed unnecessarily painful. > > > AFAIK, sha256_hmac is also not used by the current p2p & consensus layer. > > Bitcoin-Core uses it for HTTP RPC auth and Tor control. > > It's also not clear to me why the HMAC, vs just > SHA256(key|cipher-type|mesg). But that's probably just my crypto > ignorance... > > Thanks! > Rusty. > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- Xuesong (Arthur) Chen Senior Principle Engineer BlockChain Technologist BTCC ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
>It's also not clear to me why the HMAC, vs just SHA256(key|cipher-type|mesg). >But that's probably just my crypto ignorance... SHA256(key|cipher-type|mesg) is an extremely insecure MAC because of the length extension property of SHA256. If I have a tag y = SHA256(key|cipher-type|mesg), I can without knowing key or msg compute a value y' such that y' = SHA256(key|cipher-type|mesg|any values I want). Thus, an attacker can trivially forge a tag protected by SHA256(key|cipher-type|mesg). For more details see: https://web.archive.org/web/20141029080820/http://vudang.com/2012/03/md5-length-extension-attack/ On Tue, Jun 28, 2016 at 9:00 PM, Rusty Russell via bitcoin-dev wrote: > Jonas Schnelli writes: >>> To quote: >>> HMAC_SHA512(key=ecdh_secret|cipher-type,msg="encryption key"). K_1 must be the left 32bytes of the HMAC_SHA512 hash. K_2 must be the right 32bytes of the HMAC_SHA512 hash. >>> >>> This seems a weak reason to introduce SHA512 to the mix. Can we just >>> make: >>> >>> K_1 = HMAC_SHA256(key=ecdh_secret|cipher-type,msg="header encryption key") >>> K_2 = HMAC_SHA256(key=ecdh_secret|cipher-type,msg="body encryption key") >> >> SHA512_HMAC is used by BIP32 [1] and I guess most clients will somehow >> make use of bip32 features. I though a single SHA512_HMAC operation is >> cheaper and simpler then two SHA256_HMAC. > > Good point; I would argue that mistake has already been made. But I was > looking at appropriating your work for lightning inter-node comms, and > adding another hash algo seemed unnecessarily painful. > >> AFAIK, sha256_hmac is also not used by the current p2p & consensus layer. >> Bitcoin-Core uses it for HTTP RPC auth and Tor control. > > It's also not clear to me why the HMAC, vs just > SHA256(key|cipher-type|mesg). But that's probably just my crypto > ignorance... > > Thanks! > Rusty. > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 151 use of HMAC_SHA512
On Jun 29, 2016 07:05, "Ethan Heilman via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > > >It's also not clear to me why the HMAC, vs just SHA256(key|cipher-type|mesg). But that's probably just my crypto ignorance... > > SHA256(key|cipher-type|mesg) is an extremely insecure MAC because of > the length extension property of SHA256. This property does technically not apply here, as the output of the hash is kept secret, and the possible messages are constants (which are presumably chosen in such a way that one is never an extension of another). However, this is a good example of why you can't generically use a hash function in places where you want a MAC (aka "a hash with a shared secret"). Furthermore, if you already have a hash function anyway, HMAC is very easy construct on top of it. -- Pieter ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
