diff --git a/PR/AEAD/decryption.png b/PR/AEAD/decryption.png index efbb593..21e5077 100644 Binary files a/PR/AEAD/decryption.png and b/PR/AEAD/decryption.png differ diff --git a/PR/AEAD/encryption.png b/PR/AEAD/encryption.png index 3628f47..0df88eb 100644 Binary files a/PR/AEAD/encryption.png and b/PR/AEAD/encryption.png differ diff --git a/PR/README.md b/PR/README.md deleted file mode 100644 index 3a1595d..0000000 --- a/PR/README.md +++ /dev/null @@ -1,7 +0,0 @@ -## Contents - -| Item | Description | PR links | -| --- | ----------- | -------- | -| [bitcoin's AEAD](AEAD) | `crypto`| [20962](https://github.com/bitcoin/bitcoin/pull/20962) | -| [elligator square](elligator-square) | `crypto` | [23432](https://github.com/bitcoin/bitcoin/pull/23432) | -| [ECDH](handshake-prereq) | `crypto` | [23561](https://github.com/bitcoin/bitcoin/pull/23561) | diff --git a/PR/elligator-square/decoding.png b/PR/elligator-square/decoding.png index 76f6abc..f5138db 100644 Binary files a/PR/elligator-square/decoding.png and b/PR/elligator-square/decoding.png differ diff --git a/PR/elligator-square/encoding.png b/PR/elligator-square/encoding.png index c858bda..18228cb 100644 Binary files a/PR/elligator-square/encoding.png and b/PR/elligator-square/encoding.png differ diff --git a/README.md b/README.md deleted file mode 100644 index f94f8f8..0000000 --- a/README.md +++ /dev/null @@ -1,18 +0,0 @@ -# ₿logosphere -![header](./images/header.png) - -## Contents - -| index | topic | tag | -|-------|-------------------------------------------------------------------------------------|---------------------------------| -| 1. | [BIP 324](./bip324.md) | `bip324` `crypto` `TODO:update` | -| 2. | [Elligator, Elligator Squared and Elligator Swift](./elligator.md) | `bip324` `crypto` | -| 3. | [Shallue–van de Woestijne encoding](./shallue-van-de-woestijne.md) | `math` `crypto` | -| 4. | [Swift EC encoding](./swiftEC.md) | `math` `crypto` | -| 5. | [Bitcoin4India 2022 slides on BIP 324](./slides_BIP324.pdf) | `bip324` `slides` | -| 6. | [Netgroups and why we need them](./netgroups.md) | `notes` `p2p` | -| 7. | [Bitcoin Inquisition](./bitcoin-inquisition.md) | `pics` `consensus` | -| 8. | [Addrman bucketing algorithm in python](./addrman.py) | `p2p` | -| 9. | [Writeup about implementing BIP 324 integration test](./integration_test_bip324.md) | `notes` `p2p` | -| 10. | [Signed-digit multi-comb ecmult_gen algorithm ](./sdmc.md) | `notes` `crypto` | -| 11. | [bitcoin++ Austin 2024 slides](./btcpp_atx24.pdf) | `bip324` `slides` | diff --git a/bip324.md b/bip324.md deleted file mode 100644 index 7a6d30f..0000000 --- a/bip324.md +++ /dev/null @@ -1,167 +0,0 @@ -# How to encrypt the P2P protocol? -- Description: An ELI5 article explaining how BIP 324 works -- Date: 12/Feb/2022 -- Author: [@stratospher](https://github.com/stratospher) -- **Index:** - - [How can we encrypt the P2P protocol?](#how-can-we-encrypt-the-p2p-protocol) - - [Step 1: The Initial v2 Handshake](#step-1-the-initial-v2-handshake) - - [Step 2: ChaCha20Poly1305 AE specification](#step-2-chacha20poly1305-ae-specification) - - [ChaCha20(key, iv, ctr)](#chacha20key-iv-ctr) - - [ChaCha20DRBG(key, iv)](#chacha20drbgkey-iv) - - [ChaCha20Forward4064DRBG(key)](#chacha20forward4064drbgkey) - - [ChaCha20Poly1305 AE specification](#chacha20poly1305-ae-specification) - - [Encryption](#encryption) - - [Decryption](#decryption) - - [Step 3: Build/Receive v2 P2P messages](#step-3-buildreceive-v2-p2p-messages) - -In the bitcoin peer-to-peer network, nodes establish TCP connections to known peers and lots of different messages -like version, verack, getaddr etc. can be exchanged. Packet analyzers like [Wireshark](https://www.wireshark.org/docs/dfref/b/bitcoin.html) -can capture the TCP traffic and will be able to identify when the bitcoin protocol is being used in the packets. -Whoever controls the routing infrastructure of a network essentially controls the data flowing through the network. -If such individuals/organisations want to make it hard for normal users to run a bitcoin node, they'd ask the routers to -drop the bitcoin packets. To make bitcoin more censorship-resistant and easier to use for a normal user, -it's super important to encrypt the P2P communication. - -## How can we encrypt the P2P protocol? -![how to do v2 P2P protocol](./images/bip324/1.jpg) - -This can be visualised in 3 steps: -1. Initial v2 handshake -2. ChaCha20Poly1305 AE specification -3. Build/Receive v2 P2P messages - -The answer boils down to the nodes (sender and receiver) having the same keystream. The sender node could encrypt -and send `ciphertext = plaintext message xor keystream` and the receiver could receive and decrypt the message using -`plaintext message = ciphertext xor keystream`. No one other than the sender and receiver would have any clue about -what's in the packets. The receiver should also be able to know if the packet really comes from the sender. -This is what Step 2 and 3 deals with. - -The sender and receiver nodes should have the keystream with them before any message is exchanged(even before the -version handshake). The big question becomes how do we obtain the keystream? Steps 1 and 2 will get us the keystream we -need. The initial v2 handshake in Step 1 will let only the sender and receiver nodes derive the same set of keys. -Step 2 makes use of a new cryptographic primitive which will let us derive as much keystream as we'd want -from those keys for encrypting/decrypting. - -## Step 1: The Initial v2 Handshake -![initial v2 handshake](./images/bip324/2.jpg) -Suppose Node 1 and Node 2 want to communicate via v2 protocol. Before the handshake, each node would have its own -private key and public key. -1. Node 1 could send it's public key `X` over the TCP connection. But this would be easily identifiable - as a secp256k1 curve point and would be suspected of running the bitcoin protocol. - > the probability that 30 random observed transmission would always be valid X coordinates is less - than one in a billion. - > - > -- [Elligator Squared for BN-like curves][1] - - [1]: https://github.com/sipa/writeups/tree/main/elligator-square-for-bn -2. So instead we send an Elligator squared encoding of `X` to Node 2 which makes the curve point indistinguishable from - random to an observer. -3. Node 2 decodes and obtains `X`, uses `ECDH(y, X)` to establish a shared secret where `y` is its private key and then - performs key extraction using HKDF to derive 2 keys for sending, 2 keys for receiving and a session id. -4. Node 2 sends an Elligator squared encoding of its public key `Y` along with its encrypted transport version to Node 1. - (Encryption can be done now that we have the keys. Step 3's ChaCha20Poly1305 AE is used to derive the keystream.) - Transport versioning is needed to add more upgrades like authentication and post-quantum cryptography in the future. -5. Node 1 decodes and obtains `Y`, computes `ECDH(x, Y)` and derives the 4 keys and the session id. The keys and the - session id would be the same since the shared secret(`ECDH(y, X) = ECDH(x, Y)`) is the same. -6. Node 1 sends the encrypted transport version it supports to Node 2. The nodes communicate with the minimum - transport version they both support. - ![state after initial v2 handshake](./images/bip324/3.jpg) - -## Step 2: ChaCha20Poly1305 AE specification - -Before we get into what this powerful cryptographic primitive is, let's review and define other cryptographic -primitives which we'll use to build the ChaCha20Poly1305 AE specification. - -*Note: In the diagrams below, overflow conditions for counter and iv are mentioned for academic interest. These -conditions are too huge and those many bytes won't be exchanged in practice.* - -### ChaCha20(key, iv, ctr) -The ChaCha20 stream cipher takes as input: -1. 4 words constant -2. 8 words key -3. 2 words counter -4. 2 words iv - -You can read more about ChaCha20 [here](https://voluntarymind.com/bitcoin/chacha20/). -After performing 20 ChaCha rounds, we can use the 512 pseudorandom bits as keystream. - -![ChaCha20 and ChaCha20DRBG](./images/bip324/4.jpg) - -### ChaCha20DRBG(key, iv) -`ChaCha20DRBG(key, iv)` is the cryptographic primitive we'd get if we concatenate the keystreams using all possible -values of counter [0, 2**64) in `ChaCha20(key, iv, ctr)`. - -### ChaCha20Forward4064DRBG(key) -![ChaCha20Forward4064DRBG](./images/bip324/5.jpg) -Suppose attackers learn the key in `ChaCha20DRBG(key, iv)`, it's possible for them to decrypt previous ciphertext. -`ChaCha20Forward4064DRBG(key)` prevents such a situation from happening. -1. We can get as much keystream as we want from `ChaCha20Forward4064DRBG(key)`. -2. We know the initial key and iv is 0 in the beginning. -3. The keystream is made by concatenating `ChaCha20DRBG(key, iv)` instances where key and iv gets updated. - After every 4064 bytes of generated keystream, the next 32 bytes is used as the new key, `key'`. So the next 4064 - bytes from the keystream is obtained using `ChaCha20DRBG(key', iv+1)`. And this process continues. - -### ChaCha20Poly1305 AE specification -![ChaCha20Poly1305 AE](./images/bip324/6.jpg) - -Remember how we obtained 4 keys in Step 1. A node uses 2 AEs - one for sending messages and another for receiving -messages. Each AE uses 2 keys: -1. F - for fixed length purposes. F requires 35 bytes - 3 bytes is used for encrypting/decrypting the length. Remaining - 32 bytes is used for instantiating a poly1305 key for authentication. -2. V - for variable length purposes. V is used for encrypting/decrypting the message. - -`ChaCha20Forward4064DRBG(F)` and `ChaCha20Forward4064DRBG(V)` are constructed, and we can get `keystream_F` and -`keystream_V` to perform encryption/decryption. - -#### Encryption -![AE Encryption](./images/bip324/7.jpg) -The inputs are: -1. `keystream_F` -2. `keystream_V` -3. message to be encrypted - -The output ciphertext obtained after encryption consists of 3 parts: -1. 3 bytes encrypted length - encrypted by performing xor operation on the length of message in little endian with the - first 3 bytes from `keystream_F`. -2. variable bytes encrypted message - encrypted by performing xor operation on the message with `keystream_V`. -3. 16 bytes MAC tag - computed using the [Poly1305 algorithm](http://cr.yp.to/mac/poly1305-20050329.pdf). - - Inputs to the Poly1305 Algorithm - - 32-byte **one-time key** which is obtained from the next 32 bytes of `keystream_F`. - - 3 bytes encrypted length and variable bytes encrypted message are passed as the message. - - Output of the Poly1305 Algorithm - - 16 bytes MAC tag. - -#### Decryption -![AE Decryption](./images/bip324/8.jpg) -The inputs are: -1. ciphertext -2. `keystream_F` -3. `keystream_V` - -The decryption process is just the reverse of the encryption process. An additional step performed is checking if the -MAC tag obtained directly from the ciphertext and the MAC tag calculated using the Poly1305 algorithm in the decryption -process are the same. The MAC tags will match if the message really came from the sender and has not been tampered with. - -## Step 3: Build/Receive v2 P2P messages - -v2 P2P protocol follows a different message structure. Messages here do not start with magic bytes. -P2P messages can be built in 2 stages: -1. Building/Deconstructing the payload -2. Encrypting/Decrypting it using ChaCha20Poly1305 AE. Messages are now ready to be sent/read! - -### Building/Deconstructing the payload -![Building the payload](./images/bip324/9.jpg) -The payload consists of the message type and the data to be sent. The message type can be a 1 byte message type ID. -For example, version message has a message type ID of 37. *(See the BIP for full list.)* -Message type IDs can be values in the range 13 to 255. - -Or the message type can consist of: -1. 1 byte denoting length of message type - this can have a value from 1 to 12 -2. 1-12 bytes describing the ASCII message type -In total, the message type can have 2-13 bytes. - -### Encrypting/Decrypting it using ChaCha20Poly1305 AE -![Building/Receiving v2 P2P messages](./images/bip324/10.jpg) -The v2 P2P messages are encrypted using the ChaCha20Poly1305 AE. Messages can now be sent over the -TCP connection. Reverse process is applied after receiving a message. Decryption is done using ChaCha20Poly1305 AE. -The message type and data is obtained. diff --git a/images/bip324/1.jpg b/images/bip324/1.jpg index e1d8aef..8494c3e 100644 Binary files a/images/bip324/1.jpg and b/images/bip324/1.jpg differ diff --git a/images/bip324/10.jpg b/images/bip324/10.jpg index 0695494..9d4f998 100644 Binary files a/images/bip324/10.jpg and b/images/bip324/10.jpg differ diff --git a/images/bip324/2.jpg b/images/bip324/2.jpg index a3aa8aa..3e20b72 100644 Binary files a/images/bip324/2.jpg and b/images/bip324/2.jpg differ diff --git a/images/bip324/3.jpg b/images/bip324/3.jpg index 503b37f..74d1e0e 100644 Binary files a/images/bip324/3.jpg and b/images/bip324/3.jpg differ diff --git a/images/bip324/4.jpg b/images/bip324/4.jpg index 3bc1638..2af11aa 100644 Binary files a/images/bip324/4.jpg and b/images/bip324/4.jpg differ diff --git a/images/bip324/5.jpg b/images/bip324/5.jpg index f8f6bf5..66de788 100644 Binary files a/images/bip324/5.jpg and b/images/bip324/5.jpg differ diff --git a/images/bip324/6.jpg b/images/bip324/6.jpg index a06f891..e8afd51 100644 Binary files a/images/bip324/6.jpg and b/images/bip324/6.jpg differ diff --git a/images/bip324/7.jpg b/images/bip324/7.jpg index be9d1a3..9116081 100644 Binary files a/images/bip324/7.jpg and b/images/bip324/7.jpg differ diff --git a/images/bip324/8.jpg b/images/bip324/8.jpg index 436270a..4034d40 100644 Binary files a/images/bip324/8.jpg and b/images/bip324/8.jpg differ diff --git a/images/bip324/9.jpg b/images/bip324/9.jpg index e41f652..aa6f918 100644 Binary files a/images/bip324/9.jpg and b/images/bip324/9.jpg differ diff --git a/images/elligator/4.jpg b/images/elligator/4.jpg index b1a2ebd..5ac7478 100644 Binary files a/images/elligator/4.jpg and b/images/elligator/4.jpg differ diff --git a/images/elligator/5.jpg b/images/elligator/5.jpg index 8367336..a584978 100644 Binary files a/images/elligator/5.jpg and b/images/elligator/5.jpg differ diff --git a/images/elligator/6.jpg b/images/elligator/6.jpg index 84218bf..f6939a6 100644 Binary files a/images/elligator/6.jpg and b/images/elligator/6.jpg differ diff --git a/images/elligator/7.jpg b/images/elligator/7.jpg index b34007f..5c19cd2 100644 Binary files a/images/elligator/7.jpg and b/images/elligator/7.jpg differ diff --git a/images/header.png b/images/header.png index 05f63cd..07e6ca9 100644 Binary files a/images/header.png and b/images/header.png differ diff --git a/images/inquisition/need.jpg b/images/inquisition/need.jpg index 4a73cf4..5f0d599 100644 Binary files a/images/inquisition/need.jpg and b/images/inquisition/need.jpg differ diff --git a/images/inquisition/working-1.jpg b/images/inquisition/working-1.jpg index 313da9e..f31f615 100644 Binary files a/images/inquisition/working-1.jpg and b/images/inquisition/working-1.jpg differ diff --git a/images/inquisition/working-2.jpg b/images/inquisition/working-2.jpg index 276bfa4..de69b0a 100644 Binary files a/images/inquisition/working-2.jpg and b/images/inquisition/working-2.jpg differ diff --git a/images/sdmc/sdmc_bts.jpg b/images/sdmc/sdmc_bts.jpg index f149a41..4b3789e 100644 Binary files a/images/sdmc/sdmc_bts.jpg and b/images/sdmc/sdmc_bts.jpg differ diff --git a/images/sdmc/sdmc_table.jpg b/images/sdmc/sdmc_table.jpg index 59cea28..164cd7c 100644 Binary files a/images/sdmc/sdmc_table.jpg and b/images/sdmc/sdmc_table.jpg differ diff --git a/images/self-advertisement/self-adv-1.jpg b/images/self-advertisement/self-adv-1.jpg index ffb1a9a..c74443e 100644 Binary files a/images/self-advertisement/self-adv-1.jpg and b/images/self-advertisement/self-adv-1.jpg differ diff --git a/images/self-advertisement/self-adv-2.jpg b/images/self-advertisement/self-adv-2.jpg index 32dd8f5..4b76a8c 100644 Binary files a/images/self-advertisement/self-adv-2.jpg and b/images/self-advertisement/self-adv-2.jpg differ diff --git a/images/svw/map.jpg b/images/svw/map.jpg index 51a16df..5767a5d 100644 Binary files a/images/svw/map.jpg and b/images/svw/map.jpg differ diff --git a/images/svw/proof.jpg b/images/svw/proof.jpg index 6554a2d..52d7680 100644 Binary files a/images/svw/proof.jpg and b/images/svw/proof.jpg differ diff --git a/images/swiftEC/map.jpg b/images/swiftEC/map.jpg index 255f02f..4b37899 100644 Binary files a/images/swiftEC/map.jpg and b/images/swiftEC/map.jpg differ diff --git a/images/swiftEC/proof.jpg b/images/swiftEC/proof.jpg index bef063a..7f903ab 100644 Binary files a/images/swiftEC/proof.jpg and b/images/swiftEC/proof.jpg differ diff --git a/images/transaction-analysis/100-blocks-tx-size.png b/images/transaction-analysis/100-blocks-tx-size.png index c1a5fbe..ccb76b5 100644 Binary files a/images/transaction-analysis/100-blocks-tx-size.png and b/images/transaction-analysis/100-blocks-tx-size.png differ diff --git a/images/transaction-analysis/length.png b/images/transaction-analysis/length.png index 8ac71ce..f4c758d 100644 Binary files a/images/transaction-analysis/length.png and b/images/transaction-analysis/length.png differ diff --git a/images/transaction-analysis/mempool-tx-size.png b/images/transaction-analysis/mempool-tx-size.png index 08803d8..6fa74fa 100644 Binary files a/images/transaction-analysis/mempool-tx-size.png and b/images/transaction-analysis/mempool-tx-size.png differ diff --git a/traffic-analysis.md b/traffic-analysis.md deleted file mode 100644 index 0b2e248..0000000 --- a/traffic-analysis.md +++ /dev/null @@ -1,53 +0,0 @@ -# I still see you! - -## Problem - -Sending transactions across the P2P network is sensitive data. - -![show transaction tracking based on size](./images/transaction-analysis/length.png) - -Global passive observers can differentiate whether it's this tx or that tx from the size of the packet! - -## Statistics - -### Common transaction size (in bytes) in the last 100 blocks -![show common transaction size in last 100 blocks](./images/transaction-analysis/100-blocks-tx-size.png) -- 96.7 % of transactions below 1000 bytes -- 99% of transactions below 3000 bytes - -### Common transaction size (in bytes) in the mempool -![show common transaction size in mempool](./images/transaction-analysis/mempool-tx-size.png) -- 89.6 % of transactions below 1000 bytes -- 92% of transactions below 3000 bytes - -## Solution - -1. Pad transaction messages - -- last 100 blocks - - | | pad to a fixed size=1000 | pad to a fixed size=3000 | pad to a dynamic size | - |--------------------------|--------------------------|--------------------------|-----------------------| - | how much padding? | 1000 | 3000 | Padmé algo | - | what is extra bandwidth? | 43 MB | 162 MB | 10.9 GB | - -- mempool - - | | pad to a fixed size=1000 | pad to a fixed size=3000 | pad to a dynamic size | - |--------------------------|--------------------------|--------------------------|-----------------------| - | how much padding? | 1000 | 3000 | Padmé algo | - | what is extra bandwidth? | 37 MB | 139.8 MB | 123 MB | - -2. Broadcast decoy messages with size (transaction message) - -## Code - -- branch - https://github.com/stratospher/bitcoin/tree/2024-05-tx-traffic -- jupyter notebook - https://colab.research.google.com/drive/1q2fLkxuAiqr2hlAEQ4r6x2Lx9bTh4bN0?usp=sharing - -## Conclusion - -| | advantage | disadvantage | -|-----------------|--------------------------|------------------------------------------------------------------------| -| fixed padding | bandwidth efficient | can't hide the outliers + optimal padding might vary based on data set | -| dynamic padding | covers even the outliers | too much bandwidth |