diff --git a/protocols/BQP.md b/protocols/BQP.md index 4b5317d198f64a77b555e5e82139bd8ac2f78b18..c0a00989bc2cacd822e65d42df485de2d1d1757b 100644 --- a/protocols/BQP.md +++ b/protocols/BQP.md @@ -98,6 +98,8 @@ The peers exchange a series of **records** over the connection chosen by Alice. - record = record\_header || payload +The maximum length of the payload is 48 KiB. + The current version of the protocol is 4, which has three record types: **0: KEY** - The payload consists of the sender's ephemeral public key. diff --git a/protocols/BRP.md b/protocols/BRP.md index 2283de720aba40787458ac7a623321a4d7384cfe..334ed83d405a14849cbe85f5a03d19ac6f5c9392 100644 --- a/protocols/BRP.md +++ b/protocols/BRP.md @@ -4,23 +4,23 @@ Bramble Rendezvous Protocol (BRP) is a discovery protocol for peer-to-peer networks. It enables two peers that have previously exchanged public keys to connect to each other. No other information, such as network addresses, needs to be exchanged in advance. -BRP is designed to operate over a wide range of connection-oriented transport protocols. The current version of BRP uses the Tor hidden service protocol as the transport. Future versions of BRP may support other transports. +BRP is designed to operate over connection-oriented, bidirectional transport protocols. Unidirectional transports are not suitable for BRP. + +The current version of BRP uses the Tor hidden service protocol as its transport. Future versions of BRP may support other transports. ### 1.1 Motivation BRP enables two peers in a peer-to-peer network to connect to each other. In general terms this requires each peer to have some kind of network address at which the other peer can contact it. -Regardless of what kind of network address is used, there are risks associated with exchanging network addresses over an insecure channel where they may be seen by an adversary. - -If an adversary knows a peer's network address, the adversary can connect to the address in order to track when the peer is online or carry out attacks such as flooding the peer with connection attempts. +If the peers were to exchange network addresses over an insecure channel, an adversary who saw the addresses could connect to them in order to track when the peers were online or carry out attacks such as flooding the peers with connection attempts. -To avoid exposing their network addresses, peers in BRP exchange public keys instead of network addresses. Two peers that have exchanged public keys can derive a shared secret that is not known to any other party, including an adversary who may have seen both public keys. The peers then derive network addresses from the shared secret and use these addresses for connecting to each other. +To avoid exposing their network addresses, peers in BRP exchange public keys instead of network addresses. Two peers that have exchanged public keys can derive a shared secret that is not known to any other party, including an adversary who has seen both public keys. The peers then derive network addresses from the shared secret and use these addresses for connecting to each other. ### 1.2 Adversary Model -We assume the adversary can read, modify, delete and insert traffic on all transports at will. We assume the adversary knows both peers' public keys but does not know the corresponding private keys. +We assume the adversary can read, modify, delete and insert traffic on all transports at will. -If the adversary can modify the public keys exchanged by the peers then BRP does not prevent man-in-the-middle attacks. If the adversary can see but not modify the public keys then BRP prevents man-in-the-middle attacks. +We do not assume the peers exchanged their public keys over a secure channel. If the adversary intercepted the prior exchange of public keys and replaced them with its own public keys then BRP does not detect or prevent man-in-the-middle attacks. If the adversary knows both peers' public keys but did not replace them during the prior exchange then BRP prevents man-in-the-middle attacks. ### 1.3 Notation @@ -34,7 +34,7 @@ If the adversary can modify the public keys exchanged by the peers then BRP does ### 1.4 Cryptographic Primitives -BRP uses three cryptographic primitives: +BRP uses four cryptographic primitives: 1. **A cryptographic hash function**, H(m) @@ -58,14 +58,14 @@ All hashes are HASH\_LEN bytes, all symmetric keys are KEY\_LEN bytes, and the o ### 1.5 Prerequisites -Before two peers can communicate using BRP they must exchange public keys. BRP does not specify how this should be done. Any synchronous or asynchronous communication channel can be used, subject to the caveat that if an adversary can modify the keys being exchanged then the adversary can carry out a man-in-the-middle attack. +Before two peers can communicate using BRP they must exchange public keys. BRP does not specify how this should be done. Any synchronous or asynchronous communication channel can be used, subject to the caveat that if an adversary can modify the keys being exchanged then the adversary can carry out a man-in-the-middle attack against BRP. + +After exchanging public keys, each peer decides whether it will take the role of **Alice** or **Bob** in BRP. The peers take roles according to the lexicographic order of their public keys, compared as byte strings. The peer with the earlier key plays the role of Alice, while the peer with the later key plays the role of Bob. The roles are symmetrical. ## 2 The Rendezvous Protocol ### 2.1 Deriving the Rendezvous Key -After exchanging public keys, each peer decides whether it will take the role of **Alice** or **Bob**. The peers take roles according to the lexicographic order of their public keys, compared as byte strings. The peer with the earlier key plays the role of Alice, while the peer with the later key plays the role of Bob. The roles are identical apart from some key derivation constants. - Both peers calculate the "raw" shared secret as follows: - Alice calculates raw\_secret = DH(pri\_a, pub\_b) diff --git a/protocols/BSP.md b/protocols/BSP.md index e0cfee8dea076f8578c05d02989f8992a3812c7c..e5eed4d8a73ffeba0bc2e5533d95a835a86a7320 100644 --- a/protocols/BSP.md +++ b/protocols/BSP.md @@ -82,13 +82,11 @@ The message format version is 1 for the current version of BSP. ### 3.1 Record Format -Peers synchronise data by exchanging **records** via the transport layer security protocol. Each record starts with a four-byte header with the following format: +Peers synchronise data by exchanging **records** via the transport layer security protocol. Each record has the following format: -- Bits 0-7: Protocol version +- record\_header = int\_8(protocol\_version) || int\_8(record\_type) || int\_16(len(payload)) -- Bits 8-15: Record type - -- Bits 16-31: Length of the payload in bytes as a 16-bit integer +- record = record\_header || payload The maximum length of the payload is 48 KiB.