akwizgran created page: BTP

BTP.markdown

@@ -17,7 +17,7 @@ BTP uses the following cryptographic primitives:
 
 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:** Previous versions of BTP used HMAC-SHA-256 as the pseudo-random function and AES-256-GCM as the authenticated cipher. Future versions will use BLAKE2s as the pseudo-random function and XSalsa20-Poly1305 as the authenticated cipher. In both cases, key_len == 32, nonce_len == 24, mac_len == 32, and auth_len == 16.
+> Implementation note: The current version of BTP uses HMAC-SHA-256 as the pseudo-random function and AES-256-GCM as the authenticated cipher. The next version will use BLAKE2s as the pseudo-random function and XSalsa20-Poly1305 as the authenticated cipher. In both cases, key_len == 32, mac_len == 32, nonce_len == 24, and auth_len == 16.
 
 ### Initial state
 
@@ -32,7 +32,7 @@ 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 notes:** 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.
+> 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.
 
 ### Key derivation
 
@@ -79,7 +79,7 @@ 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 tag_length == 16 and W == 32. Different values of W may be suitable for different transports.
+> Implementation note: The current implementation uses tag_len == 16 and W == 32. Different values of W may be suitable for different transports.
 
 ### Stream header