fix(noise): fix formatting (#63)

_posts/2022-05-17-noise.md

@@ -71,9 +71,9 @@ Informally, a DH exchange between Alice and Bob proceeds as follows:
 - By commutativity of scalar multiplication, both Alice and Bob can now compute the point $P_{AB} = s_As_B\cdot P$, using the elliptic curve point received from the other party and their secret scalar.
 
 
-The assumed hardness of computing discrete logarithms in $E(\mathbb{F}_p)$, ensures that it is not possible to compute $s_A$ or $s_B$ from $P_A$ and $P_B$, respectively. Another security assumption (named [Computational Diffie-Hellman assumption](https://en.wikipedia.org/wiki/Computational_Diffie%E2%80%93Hellman_assumption)) ensures that it is not possible to compute $P_{AB}$ from $P$, $P_A$ and $P_B$. Hence the point $P_{AB}$ shared by Alice and Bob at the end of the above protocol cannot be efficiently computed by an attacker intercepting $P_A$ and $P_B$, and can then be used to generate a secret to be later employed, for example, as a symmetric encryption key.
+The assumed hardness of computing discrete logarithms in the elliptic curve, ensures that it is not possible to compute $s_A$ or $s_B$ from $P_A$ and $P_B$, respectively. Another security assumption (named [Computational Diffie-Hellman assumption](https://en.wikipedia.org/wiki/Computational_Diffie%E2%80%93Hellman_assumption)) ensures that it is not possible to compute $P_{AB}$ from $P$, $P_A$ and $P_B$. Hence the point $P_{AB}$ shared by Alice and Bob at the end of the above protocol cannot be efficiently computed by an attacker intercepting $P_A$ and $P_B$, and can then be used to generate a secret to be later employed, for example, as a symmetric encryption key.
 
-On a side note, this protocol shows the interplay between two components typical to public-key based schemes: the scalars $s_A$ and $s_B$ can be seen as _private keys_ associated to the _public keys_ $P_A$ and $P_B$, respectively, which allow Alice and Bob only to compute the shared secret point $P_AB$.
+On a side note, this protocol shows the interplay between two components typical to public-key based schemes: the scalars $s_A$ and $s_B$ can be seen as _private keys_ associated to the _public keys_ $P_A$ and $P_B$, respectively, which allow Alice and Bob only to compute the shared secret point $P_{AB}$.
 
 ## Ephemeral and Static Public Keys
 
@@ -104,7 +104,7 @@ Depending on the _handshake pattern_ adopted, different security guarantees can
 The Noise handshakes we support in Waku all provide the following security properties:
 
 - **Confidentiality**: the adversary should not be able to learn what data is being sent between Alice and Bob.
-    - **Strong forward secrecy**: an active adversary cannot decrypt messages nor infer any information on the employed encryption key, even in the case he has access to Alice's and Bob's long-term private keys (during or after their communication).
+- **Strong forward secrecy**: an active adversary cannot decrypt messages nor infer any information on the employed encryption key, even in the case he has access to Alice's and Bob's long-term private keys (during or after their communication).
 - **Authenticity**: the adversary should not be able to cause either Alice or Bob to accept messages coming from a party different than their original senders.
 - **Integrity**: the adversary should not be able to cause Alice or Bob to accept data that has been tampered with.
 - **Identity-hiding**: once a secure communication channel is established, a passive adversary should not be able to link exchanged encrypted messages to their corresponding sender and recipient by knowing their long-term static keys.
@@ -137,7 +137,6 @@ indicates that the initiator knew the responder's ephemeral key before he sends
 At this point it should be clear how such notation is able to compactly represent a large variety of DH based key-agreements. Nevertheless, we can easily define additional tokens and processing rules in order to address specific applications and security requirements, such as the [`psk`](http://www.noiseprotocol.org/noise.html#handshake-tokens) token used to process arbitrary pre-shared key material. 
 
 As an example of Noise flexibility, the custom protocol we detailed [above](#Ephemeral-and-Static-Public-Keys) can be shortly represented as _(Alice is on the left)_:
-
 ```
 -> e
 <- e, ee, s
@@ -190,10 +189,9 @@ For more details on supported handshakes and on how these are implemented in Wak
 
 
 
-### The `K1K1` Handshake
+### The K1K1 Handshake
 
 If Alice and Bob know each others' static key (e.g., these are public or were already exchanged in a previous handshake) , they MAY execute a `K1K1` handshake.  In Noise notation *(Alice is on the left)* this can be sketched as:
-
 ```
  K1K1:
     ->  s
@@ -203,17 +201,15 @@ If Alice and Bob know each others' static key (e.g., these are public or were al
     <-  e, ee, es
     ->  se
 ```
-
 We note that here only ephemeral keys are exchanged. This handshake is useful in case Alice needs to instantiate a new separate encrypted communication channel with Bob, e.g. opening multiple parallel connections, file transfers, etc.
 
 **Security considerations on identity-hiding (active attacker)**: no static key is transmitted, but an active attacker impersonating Alice can check candidates for Bob's static key.
 
-### The `XK1` Handshake
+### The XK1 Handshake
 
 Here, Alice knows how to initiate a communication with Bob and she knows his public static key: such discovery can be achieved, for example, through a publicly accessible register of users' static keys, smart contracts, or through a previous public/private advertisement of Bob's static key.
 
 A Noise handshake pattern that suits this scenario is `XK1`:
-
 ```
  XK1:
     <-  s
@@ -222,25 +218,22 @@ A Noise handshake pattern that suits this scenario is `XK1`:
     <-  e, ee, es
     ->  s, se
 ```
-
 Within this handshake, Alice and Bob reciprocally authenticate their static keys `s` using ephemeral keys `e`. We note that while Bob's static key is assumed to be known to Alice (and hence is not transmitted), Alice's static key is sent to Bob encrypted with a key derived from both parties ephemeral keys and Bob's static key.
 
 **Security considerations on identity-hiding (active attacker)**: Alice's static key is encrypted with forward secrecy to an authenticated party. An active attacker initiating the handshake can check candidates for Bob's static key against recorded/accepted exchanged handshake messages.
 
 
-### The `XX` and `XXpsk0` Handshakes
+### The XX and XXpsk0 Handshakes
 
 If Alice is not aware of any static key belonging to Bob (and neither Bob knows anything about Alice), she can execute an `XX` handshake, where each party tran**X**mits to the other its own static key. 
 
 The handshake goes as follows:
-
 ```
  XX:
     ->  e
     <-  e, ee, s, es
     ->  s, se
 ```
-
 We note that the main difference with `XK1` is that in second step Bob sends to Alice his own static key encrypted with a key obtained from an ephemeral-ephemeral Diffie-Hellman exchange.