akwizgran created page: ForumApp

BTP.markdown

@@ -21,7 +21,7 @@ We use MAC(k, m) to define a key derivation function:
 
 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 implementation uses HMAC-SHA-256 as the message authentication code and AES-256-GCM as the authenticated cipher. In the next release we propose to use keyed BLAKE2s as the message authentication code and XSalsa20/Poly1305 as the authenticated cipher. This gives KEY_LEN = MAC_LEN = 32, NONCE_LEN = 24, and AUTH_LEN = 16.
+> Implementation note: We propose to use keyed BLAKE2s as the message authentication code and XSalsa20/Poly1305 as the authenticated cipher. This gives KEY_LEN = MAC_LEN = 32, NONCE_LEN = 24, and AUTH_LEN = 16.
 
 ### Initial state
 
@@ -36,7 +36,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 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. We propose to use D = 3600 (one hour).
 
 ### Key derivation
 
@@ -70,7 +70,7 @@ Each stream starts with a pseudo-random tag, which is TAG_LEN bytes long. The re
 
 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: We propose to use TAG_LEN = 16.
 
 ### Reordering windows
 
@@ -83,7 +83,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 W = 32. Different values of W may be suitable for different transports.
+> Implementation note: We propose to use W = 32. Different values of W may be suitable for different transports.
 
 ### Stream header
 
@@ -117,7 +117,3 @@ The nonce for the frame body is NONCE_LEN bytes long, with the following format:
 * Remaining bits: Zero
 
 The final frame flag allows the recipient to detect the end of the stream without reading to EOF, which is not possible for all transports on all platforms.
-
-### Headless mode
-
-BTP may be used in headless mode by supplying an ephemeral key. A headless stream does not have a pseudo-random tag or stream header, just one or more frames encrypted and authenticated with the ephemeral key, as described above.