Add p2p layer encryption with ECDH/ChaCha20Poly1305#14032
Add p2p layer encryption with ECDH/ChaCha20Poly1305#14032jonasschnelli wants to merge 21 commits intobitcoin:masterfrom
Conversation
src/net.cpp
Outdated
There was a problem hiding this comment.
Nit: Should this be ”envelope” instead of ”envelop”? If so, change applies throughout this PR and also the BIP.
src/init.cpp
Outdated
There was a problem hiding this comment.
If I’m reading the logic correct then this should be ”every 10 seconds or after 10kb of data”?
src/net.cpp
Outdated
src/net_encryption.cpp
Outdated
src/net_message.h
Outdated
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
e654fd6 to
4e4aedd
Compare
|
Fixed @practicalswift points. |
|
Great work! Although optimized crypto is certainly out of scope, we do want to be mindful of making any protocol decisions that would preclude using them. :) |
4e4aedd to
603490f
Compare
|
Note to reviewers: please review...
|
603490f to
c9b3c58
Compare
|
What is the point of |
This has now been discussed on IRC: |
c9b3c58 to
93f64ad
Compare
src/net_encryption.cpp
Outdated
bdc9b75 to
39bf10f
Compare
| Needs rebase |
| CNetMessage& msg = vRecvMsg.back(); | ||
| if (vRecvMsg.empty() || vRecvMsg.back()->Complete()) { | ||
| if (m_encryption_handler && m_encryption_handler->ShouldCryptMsg()) { | ||
| vRecvMsg.emplace_back(MakeUnique<NetV2Message>(m_encryption_handler, Params().MessageStart(), SER_NETWORK, INIT_PROTO_VERSION)); |
…ate key 8794a4b QA: add test for HKDF HMAC_SHA256 L32 (Jonas Schnelli) 551d489 Add HKDF HMAC_SHA256 L=32 implementations (Jonas Schnelli) 3b64f85 QA: add test for CKey::Negate() (Jonas Schnelli) 463921b CKey: add method to negate the key (Jonas Schnelli) Pull request description: This adds a limited implementation of `HKDF` (defined by rfc5869) that supports only HMAC-SHA256 and length output of 32 bytes (will be required for v2 transport protocol). This PR also includes a method to negate a private key which is useful to enforce public keys starting with 0x02 (or 0x03) (a requirement for the v2 transport protocol). The new `CKey::Negate()` method is pretty much a wrapper around `secp256k1_ec_privkey_negate()`. Including tests. This is a subset of bitcoin#14032 and a pre-requirement for the v2 transport protocol. ACKs for commit 8794a4: Tree-SHA512: 5341929dfa29f5da766ec3612784baec6a3ad69972f08b5a985a8aafdae4dae36f104a2b888d1f5d1f33561456bd111f960d7e32c2cc4fd18e48358468f26c1a
|
My understanding is that someone else is helping with / taking over these changes, and that the BIP is still being overhauled. |
…ate key 8794a4b QA: add test for HKDF HMAC_SHA256 L32 (Jonas Schnelli) 551d489 Add HKDF HMAC_SHA256 L=32 implementations (Jonas Schnelli) 3b64f85 QA: add test for CKey::Negate() (Jonas Schnelli) 463921b CKey: add method to negate the key (Jonas Schnelli) Pull request description: This adds a limited implementation of `HKDF` (defined by rfc5869) that supports only HMAC-SHA256 and length output of 32 bytes (will be required for v2 transport protocol). This PR also includes a method to negate a private key which is useful to enforce public keys starting with 0x02 (or 0x03) (a requirement for the v2 transport protocol). The new `CKey::Negate()` method is pretty much a wrapper around `secp256k1_ec_privkey_negate()`. Including tests. This is a subset of bitcoin#14032 and a pre-requirement for the v2 transport protocol. ACKs for commit 8794a4: Tree-SHA512: 5341929dfa29f5da766ec3612784baec6a3ad69972f08b5a985a8aafdae4dae36f104a2b888d1f5d1f33561456bd111f960d7e32c2cc4fd18e48358468f26c1a
This PR adds encryption to the p2p communication after a slightly overhauled version of BIP151 defined here (there is the plan to change BIP151 or to propose this protocol in a new BIP)
The encryption is optional and by default disabled (
-netencryption).If enabled, a peer connecting to another peer signalling
NODE_ENCRYPTED(or added via-connect=) will try to do the proposed key handshake and continue with encrypted communication.If enabled, peers can request (and perform) encrypted communications by sending a handshake request.
Peers not supporting encryption are still accepted (no option to enforce encrypted communication).
There is a plan to make the handshake quantum resistance by adding NewHope to the key handshake (https://newhopecrypto.org). But since this PR is already very large, it's unclear wether this should be an independent patch (probably another ~600 lines of code).
Out of scope:
TODO:
-connect=RPCaddnodewhere it is possible to specify the expected service flags (currently-connect=will always try for encrypted coms).