From 13f79076d0207045e89033f0deb4b775b96a49c2 Mon Sep 17 00:00:00 2001 From: akwizgran Date: Wed, 1 Apr 2015 10:20:39 +0000 Subject: [PATCH] akwizgran created page: BSP --- BTP.markdown | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/BTP.markdown b/BTP.markdown index 3c6d8b4..e7e9f72 100644 --- a/BTP.markdown +++ b/BTP.markdown @@ -6,7 +6,7 @@ The underlying transport is not required to provide any security properties. We ### Notation -We use || to denote concatenation, double quotes to denote an ASCII string, int(x) to denote x represented as a 64-bit integer, len(x) to denote the length of x in bytes, and pack(x) as shorthand for int(len(x)) || x. All integers in BTP are big-endian. +We use || to denote concatenation, double quotes to denote an ASCII string, int(x) to denote x represented as a 64-bit integer, and len(x) to denote the length of x in bytes, represented as a 32-bit integer. All integers in BTP are big-endian. ### Crypto primitives @@ -15,9 +15,9 @@ BTP uses the following cryptographic primitives: * A message authentication code, MAC(k, m) * An authenticated cipher, ENC(k, n, m) and DEC(k, n, m), where n is a nonce -All keys are key_len bytes and all nonces are nonce_len bytes. The output of MAC(k, m) is mac_len bytes, and the output of ENC(k, n, m) is auth_len bytes longer than m. For simplicity we require that mac_len == key_len. +All keys are KEY_LEN bytes and all nonces are NONCE_LEN bytes. The output of MAC(k, m) is MAC_LEN bytes, and the output of ENC(k, n, m) is AUTH_LEN bytes longer than m. For simplicity we require that MAC_LEN == KEY_LEN. -> Implementation note: The current version of BTP uses HMAC-SHA-256 as the message authentication code and AES-256-GCM as the authenticated cipher. The next version will use BLAKE2s as the message authentication code and XSalsa20-Poly1305 as the authenticated cipher. In both cases, key_len == 32, mac_len == 32, nonce_len == 24, and auth_len == 16. +> Implementation note: The current version of BTP uses BLAKE2s as the message authentication code and XSalsa20-Poly1305 as the authenticated cipher. This gives KEY_LEN = 32, MAC_LEN = 32, NONCE_LEN = 24, and AUTH_LEN = 16. ### Initial state @@ -32,13 +32,13 @@ How this state is established is outside the scope of BTP. The devices must esta The devices must also agree which of them will play the role of Alice and which will play the role of Bob. The roles are identical except for some key derivation constants. -> Implementation note: Shared secrets for multiple transports may be derived from an initial shared secret established by a separate key agreement protocol. T may be hard-coded or negotiated by the key agreement protocol. D and L may be hard-coded. The current implementation uses D == 3600 (one hour). +> Implementation note: Shared secrets for multiple transports may be derived from an initial shared secret established by a separate key agreement protocol. T may be hard-coded or negotiated by the key agreement protocol. D and L may be hard-coded. The current implementation uses D = 3600 (one hour). ### Key derivation BTP's key derivation function is based on a message authentication code: -KDF(k, x_1, ..., x_n) == MAC(k, pack(x_1) || ... || pack(x_n)) +KDF(k, x_1, ..., x_n) == MAC(k, len(x_1) || x_1 || ... || len(x_n) || x_n) Each device derives four initial keys from S: @@ -66,11 +66,11 @@ If the sender starts sending a stream at time t according to the sender's clock, ### Tags -Each stream starts with a pseudo-random tag, which is tag_len bytes long. The recipient calculates the tag in advance and uses it to recognise which sender the stream comes from and which incoming header key should be used. +Each stream starts with a pseudo-random tag, which is TAG_LEN bytes long. The recipient calculates the tag in advance and uses it to recognise which sender the stream comes from and which incoming header key should be used. -The tag for the i^th stream from the sender to the recipient in a given rotation period is the first tag_len bytes of MAC(k, int(i)), where k is the sender's outgoing tag key. We require that mac_len >= tag_len. Streams are counted starting from zero in each rotation period. +The tag for the i^th stream from the sender to the recipient in a given rotation period is the first TAG_LEN bytes of MAC(k, int(i)), where k is the sender's outgoing tag key. For simplicity we require that TAG_LEN <= MAC_LEN. Streams are counted starting from zero in each rotation period. -> Implementation note: The current implementation uses tag_len == 16. +> Implementation note: The current implementation uses TAG_LEN = 16. ### Reordering windows @@ -83,17 +83,17 @@ If the window slides past a tag that has not been seen, the recipient can no lon To avoid reusing tags, which would allow the adversary to distinguish BTP traffic from random, the sender must persistently store the number of streams sent to the recipient in the current rotation period. To avoid accepting replayed streams, the recipient must persistently store the reordering windows for the previous, current and next rotation periods. -> Implementation note: The current implementation uses W == 32. Different values of W may be suitable for different transports. +> Implementation note: The current implementation uses W = 32. Different values of W may be suitable for different transports. ### Stream header -The pseudo-random tag is followed by the stream header, which consists of a random nonce and an ephemeral key encrypted and authenticated with the sender's outgoing header key and the nonce. The stream header is nonce_len + key_len + auth_len bytes long. The ephemeral key is used for encrypting and authenticating the rest of the stream. +The pseudo-random tag is followed by the stream header, which consists of a random nonce and an ephemeral key encrypted and authenticated with the sender's outgoing header key and the nonce. The stream header is NONCE_LEN + KEY_LEN + AUTH_LEN bytes long. The ephemeral key is used for encrypting and authenticating the rest of the stream. ### Frames The remainder of the stream consists of one or more frames. Each frame has a fixed-length header and a variable-length body that may contain data, padding, neither or both. The frames are numbered starting from zero. A stream may not contain more than 2^63 frames. -The plaintext frame header is 4 bytes long with the following format: +The plaintext frame header is 4 bytes long, with the following format: * Bit 0: Final frame flag, set to one if this is the last frame in the stream * Bits 1-15: Length of the data in bytes as a 15-bit integer @@ -104,13 +104,13 @@ The plaintext frame body contains the data and padding. The total length of the The header and body are encrypted and authenticated separately using the ephemeral key and deterministic nonces, which are not sent. -The nonce for the frame header is nonce_len bytes long with the following format: +The nonce for the frame header is NONCE_LEN bytes long, with the following format: * Bit 0: Header flag, set to one * Bits 1-63: Frame number as a 63-bit integer * Remaining bits: Zero -The nonce for the frame body is nonce_len bytes long with the following format: +The nonce for the frame body is NONCE_LEN bytes long, with the following format: * Bit 0: Header flag, set to zero * Bits 1-63: Frame number as a 63-bit integer