small fixes

README.md

@@ -5,7 +5,7 @@
 Install mdbook and mdbook-katex
 
 ```bash
-cargo install mdbook --version 0.4.21
+cargo install mdbook --version 0.4.29
 cargo install mdbook-katex --version 0.2.17
 ```
 

src/protocol/2pc/ff-arithmetic.md

@@ -13,7 +13,7 @@ For this reason we require that the adversary cannot do anything which would
 give him a better chance than guessing the private input at random, which is  
 guessing $k$ bits with a probability of $2^{-k}$ for not being detected.
 
-In the following we want to have closer look at how the sender and receiver can
+In the following we want to have a closer look at how the sender and receiver can
 deviate from the protocol.
 
 #### Malicious receiver

src/protocol/notarization/commitment.md

@@ -1,3 +1,5 @@
+# Commitment
+
 At the end of the TLSNotary protocol, the User has the authenticated AES ciphertext which can be thought of as a commitment to the plaintext. This form of commitment is not amenable to use cases when the User wants to make part of the plaintext public while keeping another part private. Naively, the User's option is to prove the decryption of the ciphertext in zero-knowledge which is computationally expensive.
 
 We describe two less computationally heavy approaches for converting the AES ciphertext commitments. 

src/protocol/notarization/prf.md

@@ -38,15 +38,15 @@ Notice that in each step the key, in this case `PMS`, is constant. Thus both the
 Below is the description of the all the steps to compute the `PRF` both inside and outside the 2PC circuit.
 
 
-## ---- Computing the master secret
+## Computing the master secret
 
-### -- Inside the circuit
+### Inside the circuit
 
 1. To evaluate the circuit, the parties input their `PMS` shares. The circuit outputs:
  - H(PMS ⊕ opad) called `PMS` `outer hash state` to `N` and
  - H(PMS ⊕ ipad) called `PMS` `inner hash state` to `U`
 
-### -- Outside the circuit
+### Outside the circuit
 
 2. `U` computes H((PMS ⊕ ipad) || a0) called `inner hash` of `a1` and passes it to `N`.
 
@@ -63,12 +63,12 @@ Below is the description of the all the steps to compute the `PRF` both inside a
 
 8. `U` computes the `inner hash` of `p1`.
 
-### -- Inside the circuit
+### Inside the circuit
 
 9. To evaluate the circuit, `N` inputs the `PMS outer hash state` and `U` inputs `p2` and the `inner hash` of `p1`. The circuit computes the master secret (`MS`).
 
 
-## ---- Computing the expanded keys
+## Computing the expanded keys
 
 The parties proceed to compute the `expanded keys`. The corresponding python code is:
 
@@ -86,13 +86,13 @@ client_write_IV = ek[32:36]
 server_write_IV = ek[36:40]
 ```
 
-### -- Inside the circuit
+### Inside the circuit
 
 10. Having computed `MS`, the circuit outputs:
  - H(MS ⊕ opad) called the `MS outer hash state` to `N` and
  - H(MS ⊕ ipad) called the `MS inner hash state` to `U`
 
-### -- Outside the circuit
+### Outside the circuit
 
 11. `U` computes the `inner hash` of `a1` and sends it to `N`.
 
@@ -104,18 +104,18 @@ server_write_IV = ek[36:40]
 
 15. `U` computes the `inner hash state` of `p1` and the `inner hash state` of `p2`.
 
-### -- Inside the circuit
+### Inside the circuit
 
 16. To evaluate the circuit, `N` inputs `MS outer hash state` (from Step 10) and `U` inputs `inner hash state` of `p1` and `inner hash state` of `p2`. The circuit computes `p1` and `p2`. The circuit outputs xor shares of the `expanded keys` to each party.
 
 
-## ---- Computing the encrypted Client_Finished
+## Computing the encrypted Client_Finished
 
-### -- Inside the circuit
+### Inside the circuit
 
 17. To evaluate the circuit, the parties input their shares of the `expanded keys`. The circuit outputs data needed to encrypt and authenticate the `Client_Finished` (`CF`) message.
 
-### -- Outside the circuit
+### Outside the circuit
 
 The parties proceed to compute `verify_data` for the `CF` message. The corresponding python code is:
 
@@ -140,7 +140,7 @@ verify_data = p1[:12]
 
 Using the data from Step 17, `U` proceeds to encrypt and authenticate `CF` and sends it to the webserver.
 
-## ---- Verifying the Server_Finished
+## Verifying the Server_Finished
 
 Upon `U`'s receiving the encrypted `Server_Finished` (`SF`) from the webserver, the parties proceed to compute `verify_data` for `SF`, to enable `U` to check that the received `SF` is correct. The corresponding python code is:
 
@@ -153,7 +153,7 @@ p1 = hmac.new(ms, a1+seed, hashlib.sha256).digest()
 verify_data = p1[:12]
 ```
 
-### -- Outside the circuit
+### Outside the circuit
 
 22. `U` computes `inner hash` of `a1` and sends it to `N`.
 
@@ -161,7 +161,7 @@ verify_data = p1[:12]
 
 24. `U` computes `inner hash` of `p1`.
 
-### -- Inside the circuit
+### Inside the circuit
 
 25. To evaluate the circuit, `N` inputs `MS` `outer hash state` (from Step 10) and `U` inputs `inner hash` of `p1`. The circuit outputs `verify_data` for `SF` to `U`.
 

src/protocol/notarization/public_data_commitment.md

@@ -1,6 +1,8 @@
+# Commitment to public data
+
 We describe an interactive protocol between the User `U` and the Notary `N`, whereby `U` can convert the authenticated AES ciphertext into a hash commitment to Garbled Circuits wire labels.
 
-### ---- Creating the new commitment
+## Creating the new commitment
 
 0. At the end of the TLSNotary session, both `U` and `N` know the authenticated AES `ciphertext`. 
 
@@ -20,7 +22,7 @@ We describe an interactive protocol between the User `U` and the Notary `N`, whe
 
 > Now, (`seed` + `commitment to IWLs`) become `U`'s new commitment to `p`.
 
-### ---- Verifying the commitment
+## Verifying the commitment
 
 Verifier performs the following steps:
 
@@ -35,7 +37,7 @@ Verifier performs the following steps:
 5. Accepts `p` as authentic.
 
 
-### ---- Dynamic commitment using a Merkle tree
+## Dynamic commitment using a Merkle tree
 
 In situations where `U` does not know in advance which subset of the public data she will be revealing later to the Verifier, `U` can commit to the Merkle tree of all her input wire labels (from Step 4 above). 
 Later, `U` can reveal only those Merkle leaves which she wants to make public to the Verifier.