From 4dbfae67a6425cbd881b363d94d2d8acf3dbbba5 Mon Sep 17 00:00:00 2001 From: akwizgran <michael@briarproject.org> Date: Thu, 14 Mar 2019 15:40:09 +0000 Subject: [PATCH] Update BTP.md --- protocols/BTP.md | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/protocols/BTP.md b/protocols/BTP.md index d6c17d6..10ae822 100644 --- a/protocols/BTP.md +++ b/protocols/BTP.md @@ -76,7 +76,7 @@ Transport connections themselves may be reordered. There is no requirement that If one endpoint of a connection starts writing to the transport at time T0 and the other endpoint starts reading from the transport at time T1, we call T1 - T0 the **latency** of the connection. For a bidirectional connection we define the latency of the connection to be the maximum latency in either direction. -If a transport imposes a maximum connection length, such as the storage capacity of a disk, BTP passes this restriction on to higher protocol layers by limiting the stream length; it does not fragment a stream across multiple connections. BTP cannot use transport connections with less capacity than the minimum length of a stream. (*Note:* In the current version of the protocol, the minimum length of a stream is 118 bytes.) +If a transport imposes a maximum connection length, such as the storage capacity of a disk, BTP passes this restriction on to higher protocol layers by limiting the stream length; it does not fragment a stream across multiple connections. BTP cannot use transport connections with less capacity than the minimum length of a stream. (*Note:* In the current version of the protocol, the minimum length of a stream is 134 bytes.) Using BTP over a datagram-oriented transport such as UDP (which does not have a concept of connections) would require the use of an intermediate connection-oriented protocol such as UDT to provide an ordered sequence of bytes in each direction. @@ -142,9 +142,7 @@ If two endpoints wish to communicate across more than one transport, they must e ### 2.2 Key Derivation Function -BTP uses a **key derivation function** to derive temporary keys from the root key. - -The key derivation function is based on PRF(k, m): +BTP uses a **key derivation function** to derive temporary keys from the root key. The key derivation function is based on PRF(k, m): - KDF(k, x\_1, ..., x\_n) = PRF(k, int\_32(len(x\_1)) || x\_1 || ... || int\_32(len(x\_n)) || x\_n) @@ -152,13 +150,13 @@ The key derivation function is based on PRF(k, m): For each transport, BTP divides time into numbered periods, where period zero starts at the Unix epoch. A different set of temporary keys is used for each period. -The length of each period is R = D + L seconds, where D is the maximum expected difference between the endpoints' clocks and L is the maximum expected latency of the transport. Recall that the endpoints must agree on the values of D and L, which may be hard-coded. +The length of each period is D + L seconds, where D is the maximum expected difference between the endpoints' clocks and L is the maximum expected latency of the transport. This ensures that if the sender starts sending a stream in period P0 according to the sender's clock, and if D and L are not exceeded, then the recipient will start receiving the stream in period P1 according to the recipient's clock, where abs(P1 - P0) <= 1. In other words, the recipient only needs to retain the temporary keys for the previous, current and next periods. ### 2.4 Key Derivation for Dynamic Mode -In dynamic mode, BTP achieves forward secrecy by periodically rotating and deleting the temporary keys. The key derivation function is deterministic, so endpoints that start from the same root key and timestamp T will derive the same temporary keys for each time period. Forward secrecy relies on the one-way nature of the key derivation function: the keys of an earlier period cannot be re-derived from those of a later period. +In dynamic mode, BTP achieves forward secrecy by periodically rotating and deleting the temporary keys. The key derivation function is deterministic, so endpoints that start from the same root key and timestamp will derive the same temporary keys for each time period. Forward secrecy relies on the one-way nature of the key derivation function: the keys of an earlier period cannot be re-derived from those of a later period. ##### Initial Keys @@ -188,7 +186,7 @@ After deriving the initial keys, both endpoints must delete the root key. The initial keys are used as the temporary keys for the period preceding the period containing the timestamp T. -The purpose of the timestamp is to save the cost of rotating keys from period zero to the current period. If it is not possible or convenient to agree a timestamp T along with the root key then T can be hard-coded to some value that is certain to be in the past according to both endpoints' clocks, at the cost of some extra key rotations. +The purpose of the timestamp is to save the cost of rotating keys from period zero up to the current period. If it is not possible or convenient to agree a timestamp T along with the root key then T can be hard-coded to some value that is certain to be in the past according to both endpoints' clocks, at the cost of some extra key rotations. ##### Key Rotation @@ -244,7 +242,7 @@ The tag for the i<sup>th</sup> stream from a given sender to a given recipient i ### 3.2 Stream Headers -The pseudo-random tag is followed by the stream header, which is composed as follows: +The pseudo-random tag is followed by the stream header, which has the following format: - nonce = R(NONCE\_LEN) -- GitLab