fix(noise): minor fixes/spacing

noise-research/secure-transfer.md

@@ -1,6 +1,5 @@
 # Secure Transfers with Noise
 
-
 In this document we describe a compound protocol to enable two devices to mutually authenticate and securely exchange (arbitrary) information. 
 It consists of two main subprotocols or *phases*:
 
@@ -21,7 +20,9 @@ If device `A` doesn't have a camera while device `B` does, [it is possible](#Rat
 - `Curve25519`: the underlying elliptic curve for Diffie-Hellman (DH) operations.
 
 ### The `WakuPairing` Noise Handshake
+
 The devices execute a custom handshake derived from `X1X1`, where they mutually exchange and authenticate their device static keys by exchanging messages over the content topic
+
 ```
 contentTopic = /{application-name}/{application-version}/wakunoise/1/sessions-{shard-id}/proto
 ```
@@ -39,18 +40,17 @@ WakuPairing:
 {}: payload,    []: user interaction
 ```
 
-
-Beside the ephemeral key, all the information embedded in the QR code should be passed to the prologue of the Noise handshake (e.g. `H(sB||r)`, `contentTopic`, `message_nametag`, etc.).
-
-
 ### Protocol Flow
+
 1. The device `B` exposes through a QR code a Base64 serialization of:
+
     - An ephemeral public key `eB`;
     - The content topic parameters `contentTopicParams = {application-name}, {application-version}, {shard-id}`.
     -  A randomly generated 8-bytes long `messageNametag`. 
     - A commitment `H(sB||r)` for its static key `sB` where `r` is a random fixed-lenght value.
 
 2. The device `A`:
+
     - scans the QR code;
     - obtains `eB`, `contentTopicParams`, `messageNametag`, `Hash(sB|r)`;
     - checks if `{application-name}` and `{application-version}` from `contentTopicParams` match the local application name and version: if not, aborts the pairing. 
@@ -63,6 +63,7 @@ Beside the ephemeral key, all the information embedded in the QR code should be
     - an 8-digits authorization code `authcode` obtained as `HKDF(h) mod 10^8` is displayed on the device, where `h`is the handshake value obtained once the first handshake message is processed.
 
 3. The device `B`:
+
     - listens to messages sent to `/{application-name}/{application-version}/wakunoise/1/sessions-{shard-id}/proto` and locally filters only those with [Waku payload](https://rfc.vac.dev/spec/35/#abnf) starting with `messageNametag`. If any, continues.
     - initializes the Noise handshake by passing `contentTopicParams`, `messageNametag` and `Hash(sB||r)` to the handshake prologue;
     - executes the pre-handshake message, i.e. processes its static key `eB`;
@@ -75,12 +76,14 @@ Beside the ephemeral key, all the information embedded in the QR code should be
 4. Device `A` and `B` wait the user to confirm with an interaction (button press) that the authorization code displayed on both devices are the same. If not, the protocol is aborted.
     
 5. The device `B`:
+
     - executes the second handshake message, i.e.
         - processes and sends his (encrypted) device static key `sB` over `contentTopic`;
         - performs `DH(eA,sB)` (which updates the symmetric encryption key);
         - attaches as payload the (encrypted) commitment randomness `r` used to compute `H(sB||r)`.
 
 6. The device `A`:
+
     - listens to messages sent to `/{application-name}/{application-version}/wakunoise/1/sessions-{shard-id}/proto` and locally filters only those with Waku payload starting with `messageNametag`. If any, continues.
     - obtains from decrypting the received message a public key `sB`. If `sB` is not a valid public key, the protocol is aborted.
     - performs `DH(eA,sB)` (which updates a symmetric encryption key);
@@ -105,6 +108,7 @@ Beside the ephemeral key, all the information embedded in the QR code should be
     - Calls Split() and obtains two cipher states to encrypt inbound and outbound messages.
 
 ### The `WakuPairing` for Devices without a Camera
+
 In the above pairing handshake, the QR is by default exposed by device `B` and not by `A` because device `B` locally stores no relevant cryptographic material, so an active local attacker that scans the QR code first would only be able to transfer *his own* session information and get nothing from `A`. 
 
 However, since the user confirms at the end of message `1` that the authorization code is the same on both devices, the role of handhsake initiator and responder can be safely swapped in message `0` and `1`. 
@@ -126,6 +130,7 @@ WakuPairing2:
 ## Security Analysis
 
 ### Assumptions
+
 - The attacker is active, i.e. can interact with both devices `A` and `B` by sending messages over `contentTopic`.
 
 - The attacker has access to the QR code, that is knows the ephemeral key `eB`, the commitment `H(sB||r)` and the `contentTopic` exposed by the device `B`.
@@ -160,7 +165,6 @@ WakuPairing2:
 - Device `A` opens a commitment to its static key at message `3.` because:
     - if device `B` doesn't abort the pairing, device `A` acknowledges that device `B` correctly received his static key `sA`, since `s` was encrypted under an encryption key derived from the static keys `sA` and `sB` and the genuine (due to the previous `authcode` verification) ephemeral keys `eA` and `eB`.
 
-
 # Secure Transfer
 
 Once the handshake is concluded, sensitive information can be exchanged using the encryption keys agreed during the pairing phase. If stronger security guarantees are required, some [additional tweaks](#Additional-Possible-Tweaks) are possible.
@@ -170,9 +174,11 @@ In the following subsections we report the details of applications which are cur
 However, the pairing and transfer phases descriptions are designed to be application-agnostic, and should be flexible enough to mutually authenticate and allow secure communication of two devices over a distributed network of Waku2 nodes.
 
 ## N11M session management mechanism
+
 In this scenario, one of Alice's devices is already communicating with one of Bob's devices within an active Noise session, e.g. after a successful execution of a Noise handshake.
 
 Alice and Bob would then share some cryptographic key material, used to encrypt their communications. According to [37/WAKU2-NOISE-SESSIONS](https://rfc.vac.dev/spec/37/) this information consists of:
+
 - A `session-id` (32 bytes)
 - Two cipher state `CSOutbound`, `CSInbound`, where each of them contains:
     - an encryption key `k` (2x32bytes)
@@ -185,11 +191,11 @@ In a [`N11M`](https://rfc.vac.dev/spec/37/#the-n11m-session-management-mechanism
 Hence, if Alice wishes to add a new device, she must securely transfer a copy of such data from one of her device `A` to a new device `B` in her possession.
 
 In order to do so she can:
+
 - pair device `A` with `B` in order to have a Noise session between them; 
 - securely transfer within such session the 176 bytes serializing the active session with Bob;
 - manually instantiate in `B` a Noise session with Bob from the received session serialization.
 
-
 # Additional Possible Tweaks
 
 ## Randomized Rekey
@@ -197,6 +203,7 @@ In order to do so she can:
 The Noise framework supports [`Rekey()`](http://www.noiseprotocol.org/noise.html#rekey) in order to update encryption keys *"so that a compromise of cipherstate keys will not decrypt older* \[exchanged\] *messages"*. However, if a certain cipherstate key is compromised, it will become possible for the attacker not only to decrypt messages encrypted under that key, but also all those messages encrypted under any successive new key obtained through a call to `Rekey()`.
 
 This can be mitigated by:
+
 - keeping the full Handhshake State even after the handshake is complete (*by Noise specification a call to `Split()` should delete the Handshake State*)
 - continuing updating the Handshake State by processing every after-handshake exchanged message (i.e. the `payload`) according to the Noise [processing rules](http://www.noiseprotocol.org/noise.html#processing-rules) (i.e. by calling `EncryptAndHash(payload)` and `DecryptAndHash(payload)`);
 - adding to each (or every few) message exchanged in the transfer phase a random ephemeral key `e` and perform Diffie-Hellman operations with the other party's ephemeral/static keys in order to update the underlying CipherState and recover new random inbound/outbound encryption keys by calling `Split()`.
@@ -228,6 +235,7 @@ We note that since the `ChaChaPoly` cipher used to encrypt messages supports *ad
 
 
 # Future Work: `n-to-1` Device Pairing
+
 The above protocol pairs a single device `A` with `B`, creating the conditions for a secure transfer. However, we would like to efficiently address scenarios (e.g. the [NM](https://rfc.vac.dev/spec/37/#the-nm-session-management-mechanism) session management mechanism) where a device `B` is paired with multiple devices `A1, A2, ..., An`, which were, in turn, already paired two-by-two. A naive approach requires `B` to be paired with each of such devices, but exposing/scanning `n` QRs would quickly become impractical as the number of devices increases. 
 
 As a future work, we wish to design a `n-to-1` pairing protocol, where only one out of `n` devices scans the QR exposed by the pairing requester device and the latter can efficiently (in term of exchanged messages) be securely paired to all of them.