Re: [bitcoin-dev] p2p authentication and encryption BIPs
On Wednesday, March 23, 2016 3:24:12 PM Jonas Schnelli via bitcoin-dev wrote: > I have just PRed a draft version of two BIPs I recently wrote. > https://github.com/bitcoin/bips/pull/362 In the future, please submit BIP drafts to the mailing list for comment and initial peer review before opening a pull request (or requesting a BIP number assignment), per BIP 1. > Each peer that supports p2p authentication, must provide two user editable > databases (can be a simple record-per-line file). As long as the format of these databases is not standardised, it seems inappropriate to define *any* of this implementation detail in a BIP. > A peer can send an authenticate message by wrapping the desired message into > an auth-message-wrapper to the remote peer. How does a peer know what messages the other peer requires to be authenticated? > 33bytes || identity-pubkey || comp.-pubkey || The identity pubkey of the > requesting peer Seems a waste to include this with every single [authenticated] message... > 8bytes || auth-msg-id || int64 || up-counting auth-msg-id (0 to INT64MAX) Is this required to persist across connections/restarts/possibly complete reinstalls? Can the same auth-msg-id be used for multiple peers, so a message can be signed once and sent to all N peers? > Responding peers must ignore (banning would lead to fingerprinting) the > requesting peer after 5 unsuccessfully authentication tries to avoid > resource attacks. How does banning in this specific case enable fingerprinting as opposed to any other banning? > The peers should display the identity-pubkey as a identity-address to the > users, which is a base58-check encoded ripemd160(sha256) hash. If this is going to become a general-purpose identity system, I think more is needed than a simple EC keypair. At the very least, it should probably use a HD chain and use a new key for every signature (notice you already have auth- msg-id to use with this!). > This proposal is backward compatible. Non supporting peers will ignore the > auth message. ... and not process it at all? How is that backward compatible? > Encrypting traffic between peers is already possible with VPN, tor, stunnel, > curveCP or any other encryption mechanism on a deeper OSI level, however, > most mechanism are not practical for SPV or other DHCP/NAT environment and > will require significant knowhow in how to setup a secure channel. I don't see how Tor fails this criteria... > The responding peer will set a session timeout time-interval. The default > must be 1'800 seconds. What default? Is the timeout field optional? Why not simply require it? > This proposal is backward compatible. Non supporting peers will ignore the > enc* messages. How should the supporting peer handle the message being ignored? Luke ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] p2p authentication and encryption BIPs
It seems that every message must be signed (the protocols lacks MACs). This can be very resource consuming in terms of CPU and bandwidth since most p2p messages are small. On Wed, Mar 23, 2016 at 5:36 PM, Tom via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Wednesday 23 Mar 2016 16:24:12 Jonas Schnelli via bitcoin-dev wrote: > > Hi > > > > I have just PRed a draft version of two BIPs I recently wrote. > > https://github.com/bitcoin/bips/pull/362 > > I suggest running a spellchecker ;) > > Some questions; > > * why would you not allow encryption on non-pre-approved connections? > * we just removed (ssl) encryption from the JSON interface, how do you > suggest > this encryption to be implemented without openSSL? > * What is the reason for using the p2p code to connect a wallet to a node? > I suggest using one of the other connection methods to connect to the node. > This avoids a change in the bitcoin protocol for a very specific usecase. > * Why do you want to do a per-message encryption (wrapping the original)? > Smaller messages that contain predictable content and are able to be > matched > to the unencrypted versions on the wire send to other nodes will open this > scheme up to various old statistical attacks. > > > Responding peers must ignore (banning would lead to fingerprinting) the > requesting peer after 5 unsuccessfully authentication tries to avoid > resource > attacks. > > Any implementation of that kind would itself again be open to resource > attacks. > Why 5? Do you want to allow a node to make a typo? > > > > To ensure that no message was dropped or blocked, the complete > communication > must be hashed (sha256). Both peers keep the SHA256 context of the > encryption > session. The complete enc message (leaving out the hash > itself) > must be added to the hash-context by both parties. Before sending a > enc command, the sha256 context will be copied and finalized. > > You write "the complete communication must be hashed" and every message > has a > hash of the state until it is at that point. > I think you need to explain how that works specifically. > > > ___ > 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] p2p authentication and encryption BIPs
>> I have just PRed a draft version of two BIPs I recently wrote. >> https://github.com/bitcoin/bips/pull/362 > > I suggest running a spellchecker ;) Thanks. Will do. > * why would you not allow encryption on non-pre-approved connections? The encryption should be optional. The proposed authentication scheme does take care of the identity-management and therefor prevent MITM attacks. Without the identity management, you might not detect sending/receiving encrypted data from/to a MITM. > * we just removed (ssl) encryption from the JSON interface, how do you > suggest > this encryption to be implemented without openSSL? The proposed encryption schema is based on ECDSA/ECDH (implemented in libsecp256k1) and AES256CBC (implementation is on the way see https://github.com/bitcoin/bitcoin/pull/7689). OpenSSL is not required. > * What is the reason for using the p2p code to connect a wallet to a node? > I suggest using one of the other connection methods to connect to the node. > This avoids a change in the bitcoin protocol for a very specific usecase. Most known use-case: SPV. > * Why do you want to do a per-message encryption (wrapping the original)? > Smaller messages that contain predictable content and are able to be matched > to the unencrypted versions on the wire send to other nodes will open this > scheme up to various old statistical attacks. It's probably extremely inefficient to create a constant time stream. Even most SSL/SSH application leak information because of the communication message characteristics. The current wrapping message proposal is not very efficient. I will change it so that the p2p message header will contain the encryption metadata. This should lead to a tiny overhead. > >> Responding peers must ignore (banning would lead to fingerprinting) the > requesting peer after 5 unsuccessfully authentication tries to avoid resource > attacks. > > Any implementation of that kind would itself again be open to resource > attacks. > Why 5? Do you want to allow a node to make a typo? Good point. Maybe one false try should lead to ignoring the peer. > > >> To ensure that no message was dropped or blocked, the complete communication > must be hashed (sha256). Both peers keep the SHA256 context of the encryption > session. The complete enc message (leaving out the hash itself) > must be added to the hash-context by both parties. Before sending a > enc command, the sha256 context will be copied and finalized. > > You write "the complete communication must be hashed" and every message has a > hash of the state until it is at that point. > I think you need to explain how that works specifically. This is a relative simple concept and does not require rehashing the whole communication. You just append the "new data". Some pseudocode: SHA256CTX ctx; // first com SHA256CTX_Update(ctx, 1stmessage); // copy context SHA256CTX ctxnew = ctx; // finalize the copied context sha256hash = SHA256CTX_Finalize(ctxnew); //use as checksum hash next message SHA256CTX_Update(ctx, 2ndmessage); // copy context SHA256CTX ctxnew = ctx; // finalize the copied context sha256hash = SHA256CTX_Finalize(ctxnew); //use as checksum hash ... etc. 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] p2p authentication and encryption BIPs
On 03/23/2016 01:36 PM, Tom via bitcoin-dev wrote: > On Wednesday 23 Mar 2016 16:24:12 Jonas Schnelli via bitcoin-dev wrote: > * why would you not allow encryption on non-pre-approved connections? Agree > * we just removed (ssl) encryption from the JSON interface, how do you > suggest > this encryption to be implemented without openSSL? CurveCP > * What is the reason for using the p2p code to connect a wallet to a node? > I suggest using one of the other connection methods to connect to the node. > This avoids a change in the bitcoin protocol for a very specific usecase. Agree, P2P and client-server protocols are distinct use-cases. Missing this distinction is the root cause of problems with the bloom filters feature. > * Why do you want to do a per-message encryption (wrapping the original)? > Smaller messages that contain predictable content and are able to be matched > to the unencrypted versions on the wire send to other nodes will open this > scheme up to various old statistical attacks. Privacy cannot currently be achieved unless the server is trusted. In most wallet scenarios that's not a reasonable assumption unless one controls the full node. So this is only useful in the case where the wallet is trusting a remote server, and as you point out - message encryption is weak in this case. In a trustless server scenario encryption would be unnecessary overhead. >> Responding peers must ignore (banning would lead to fingerprinting) the > requesting peer after 5 unsuccessfully authentication tries to avoid resource > attacks. > > Any implementation of that kind would itself again be open to resource > attacks. > Why 5? Do you want to allow a node to make a typo? Agree, denial of service protection can and should be much more flexible than this. It's not necessary to incorporate DoS protection into a protocol. I think maybe this stems from the ill-advised attempt at messaging reliability. >> To ensure that no message was dropped or blocked, the complete communication > must be hashed (sha256). Both peers keep the SHA256 context of the encryption > session. The complete enc message (leaving out the hash itself) > must be added to the hash-context by both parties. Before sending a > enc command, the sha256 context will be copied and finalized. > > You write "the complete communication must be hashed" and every message has a > hash of the state until it is at that point. > I think you need to explain how that works specifically. Also, this gets into the area of messaging reliability. This is certainly not something I would recommend for a P2P protocol optimized for maintaining a cache of public data. e 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] p2p authentication and encryption BIPs
On Wednesday 23 Mar 2016 16:24:12 Jonas Schnelli via bitcoin-dev wrote: > Hi > > I have just PRed a draft version of two BIPs I recently wrote. > https://github.com/bitcoin/bips/pull/362 I suggest running a spellchecker ;) Some questions; * why would you not allow encryption on non-pre-approved connections? * we just removed (ssl) encryption from the JSON interface, how do you suggest this encryption to be implemented without openSSL? * What is the reason for using the p2p code to connect a wallet to a node? I suggest using one of the other connection methods to connect to the node. This avoids a change in the bitcoin protocol for a very specific usecase. * Why do you want to do a per-message encryption (wrapping the original)? Smaller messages that contain predictable content and are able to be matched to the unencrypted versions on the wire send to other nodes will open this scheme up to various old statistical attacks. > Responding peers must ignore (banning would lead to fingerprinting) the requesting peer after 5 unsuccessfully authentication tries to avoid resource attacks. Any implementation of that kind would itself again be open to resource attacks. Why 5? Do you want to allow a node to make a typo? > To ensure that no message was dropped or blocked, the complete communication must be hashed (sha256). Both peers keep the SHA256 context of the encryption session. The complete enc message (leaving out the hash itself) must be added to the hash-context by both parties. Before sending a enc command, the sha256 context will be copied and finalized. You write "the complete communication must be hashed" and every message has a hash of the state until it is at that point. I think you need to explain how that works specifically. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] p2p authentication and encryption BIPs
There is probably not much loss due to per message encryption. Even if a MITM determined that a message was an inv message (or bloom filter message), it wouldn't be able to extract much information. Since the hashes in those messages are fixed size, there is very little leakage. You could make it so that the the encryption messages effectively create a second data stream and break/weaken the link between message size and wrapped message size. This requires state though, so there is a complexity tradeoff. There is no real need to include an IV, since you are including a 32 byte context hash. The first 16 bytes of the context hash could be used as IV. In terms of generating the context hash, it would be easier to make it linear. context_hash_n = SHA256(context_hash_(n-1) | message_(n-1)) As the session gets longer, both nodes would have to do more and more hashing to compute the hash of the entire conversation. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] p2p authentication and encryption BIPs
Hi I have just PRed a draft version of two BIPs I recently wrote. https://github.com/bitcoin/bips/pull/362 Two BIPs that addresses the problem of decoupling wallets/clients from nodes while assuming a user (or a group) know the remote peer. Authentication would be necessary to selective allow bloom filtering of transactions, encryption or any other node service that might lead to fingerprinting or resource attacks. Authentication would also be a pre-requirement for certificate free encryption-handshakes that is (enough?) resistant to MITM attacks. Encryption is highly recommended if you connect a SPV node to a trusted node. Authentication would allow accessing private p2p extensions from a remote SPV peer (example: fee estimation). I'm aware of other methods to increase privacy and integrity (tor, VPN, stunnel, etc.), however I think authentication and a basic communication encryption should be part of the protocol and its setup should be complete hassle-free. Thanks for your feeback. /jonas signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
