Use relative links (for easier markdown navigation)

src/mpc/commitments.md

@@ -1,12 +1,12 @@
 # Commitments
 
-Here we illustrate the commitment scheme used to create authenticated commitments to the plaintext in scenarios where a general-purpose [`Notary`](/intro.html#tls-verification-with-a-general-purpose-notary) is used. (Note that this scheme is not used when the `Prover` proves directly to the `Verifier`)
+Here we illustrate the commitment scheme used to create authenticated commitments to the plaintext in scenarios where a general-purpose [`Notary`](../intro.md#tls-verification-with-a-general-purpose-notary) is used. (Note that this scheme is not used when the `Prover` proves directly to the `Verifier`)
 
-A naive approach of extending the [`Encryption and Decryption`](/protocol/mpc-tls/encryption.html) steps to also compute a commitment (e.g. BLAKE3 hash) using MPC is too resource-intensive, prompting us to provide a more lightweight commitment scheme.
+A naive approach of extending the [`Encryption and Decryption`](../protocol/mpc-tls/encryption.html) steps to also compute a commitment (e.g. BLAKE3 hash) using MPC is too resource-intensive, prompting us to provide a more lightweight commitment scheme.
 
-The high-level idea is that the `Prover` creates a commitment to the active plaintext encoding from the MPC protocol used for [`Encryption and Decryption`](/protocol/mpc-tls/encryption.html). 
+The high-level idea is that the `Prover` creates a commitment to the active plaintext encoding from the MPC protocol used for [`Encryption and Decryption`](../protocol/mpc-tls/encryption.html).
 
 We also hide the amount of commitments (to preserve `Prover` privacy) by having the `Prover` commit to the Merkle tree of commitments.
 
 
-![Commitment](/diagrams/encoding_commitment.svg)
+![Commitment](../diagrams/encoding_commitment.svg)

src/mpc/encryption.md

@@ -2,7 +2,7 @@
 
 Here we will explain our protocol for 2PC encryption using a block cipher in counter-mode.
 
-Our documentation on [Dual Execution with Asymmetric Privacy](/mpc/deap.md) is recommended prior reading for this section.
+Our documentation on [Dual Execution with Asymmetric Privacy](deap.md) is recommended prior reading for this section.
 
 ## Preliminary
 
@@ -10,7 +10,7 @@ Our documentation on [Dual Execution with Asymmetric Privacy](/mpc/deap.md) is r
 
 It is important to recognise that the Notary's keyshare is an _ephemeral secret_. It is only private for the duration of the User's TLS session, after which the User is free to learn it without affecting the security of the protocol.
 
-It is this fact which allows us to achieve malicious security for relatively low cost. More details on this [here](/mpc/deap.md).
+It is this fact which allows us to achieve malicious security for relatively low cost. More details on this [here](../mpc/deap.md).
 
 ### Premature Leakage
 
@@ -41,7 +41,7 @@ During the entirety of the TLS session the User performs the role of the garbled
 
 ## Encryption Protocol
 
-The encryption protocol uses [DEAP](/mpc/deap.md) without any special variations. The User and Notary directly compute the ciphertext for each block of a message the User wishes to send to the Server:
+The encryption protocol uses [DEAP](../mpc/deap.md) without any special variations. The User and Notary directly compute the ciphertext for each block of a message the User wishes to send to the Server:
 
 $$f(k_U, k_N, ctr, p) = \mathsf{Enc}(k_U \oplus k_N, ctr) \oplus p = c$$
 
@@ -51,7 +51,7 @@ The User creates a commitment to the plaintext active labels for the Notary's ci
 
 The protocol for decryption is very similar but has some key differences to encryption.
 
-For decryption, [DEAP](/mpc/deap.md) is used for every block of the ciphertext to compute the _masked encrypted counter-block_:
+For decryption, [DEAP](../mpc/deap.md) is used for every block of the ciphertext to compute the _masked encrypted counter-block_:
 
 $$f(k_U, k_N, ctr, z) = \mathsf{Enc}(k_U \oplus k_N, ctr) \oplus z = ectr_z$$
 

src/protocol/mpc-tls/encryption.md

@@ -4,7 +4,7 @@ This section explains how the `Prover` and `Verifier` use MPC to encrypt data se
 
 ## Encryption
 
-To encrypt the plaintext, both parties input their TLS key shares as private inputs to the [MPC](/mpc/deap.md) protocol, along with some other public data. Additionally, the `Prover` inputs her plaintext as a private input.
+To encrypt the plaintext, both parties input their TLS key shares as private inputs to the [MPC](../../mpc/deap.md) protocol, along with some other public data. Additionally, the `Prover` inputs her plaintext as a private input.
 
 ![Encryption](../../diagrams/mpc-encryption.svg)
 
@@ -14,12 +14,12 @@ The `Prover` then dispatches the ciphertext and the MAC to the server.
 
 ## Decryption
 
-Once the `Prover` receives the ciphertext and its associated MAC from the server, the parties first authenticate the ciphertext by validating the MAC. They do this by running the [MPC](/mpc/mac.md) protocol to compute the authentic MAC for the ciphertext. They then verify if the authentic MAC matches the MAC received from the server.
+Once the `Prover` receives the ciphertext and its associated MAC from the server, the parties first authenticate the ciphertext by validating the MAC. They do this by running the [MPC](../../mpc/mac.md) protocol to compute the authentic MAC for the ciphertext. They then verify if the authentic MAC matches the MAC received from the server.
 
-Next, the parties decrypt the ciphertext by providing their key shares as private inputs to the [MPC](/mpc/deap.md) protocol, along with the ciphertext and some other public data.
+Next, the parties decrypt the ciphertext by providing their key shares as private inputs to the [MPC](../../mpc/deap.md) protocol, along with the ciphertext and some other public data.
 
 ![Decryption](../../diagrams/mpc-decryption.svg)
 
 The resulting plaintext is revealed ONLY to the `Prover`.
 
-Please note, the actual low-level implementation details of decryption are more nuanced than what we have described here. For more information, please consult [Low-level Decryption details](/mpc/encryption.md).
+Please note, the actual low-level implementation details of decryption are more nuanced than what we have described here. For more information, please consult [Low-level Decryption details](../../mpc/encryption.md).

src/protocol/notarization.md

@@ -1,10 +1,10 @@
 # Notarization
 
-Even though the `Prover` can prove data provenance directly to the `Verifier`, in some scenarios it may be beneficial for the `Verifier` to outsource the verification of the TLS session to a trusted `Notary` as explained [here](/intro.html#tls-verification-with-a-general-purpose-notary).
+Even though the `Prover` can prove data provenance directly to the `Verifier`, in some scenarios it may be beneficial for the `Verifier` to outsource the verification of the TLS session to a trusted `Notary` as explained [here](../intro.md#tls-verification-with-a-general-purpose-notary).
 
 As part of the TLSNotary protocol, the `Prover` creates authenticated commitments to the plaintext and has the `Notary` sign them without the `Notary` ever seeing the plaintext. This offers a way for the `Prover` to selectively prove the authenticity of arbitrary portions of the plaintext to an application-specific `Verifier` later.
 
-Please refer to the [Commitments](/mpc/commitments.md) section for low-level details on the commitment scheme.  
+Please refer to the [Commitments](../mpc/commitments.md) section for low-level details on the commitment scheme.
 
 ## Signing the Session Header
 

src/protocol/verification.md

@@ -1,7 +1,7 @@
 # Verification
 
 To prove data provenance to a third-party `Verifier`, the `Prover` provides the following information:
-- [`Session Header`](/protocol/notarization.md#signing-the-session-header) signed by the `Notary`
+- [`Session Header`](notarization.md#signing-the-session-header) signed by the `Notary`
 - `opening` to the plaintext commitment
 - `TLS-specific data` which uniquely identifies the server
 - `identity` of the server
@@ -15,4 +15,4 @@ Next, the `Verifier` parses the `opening` with an application-specific parser (e
 
 Below is an example of a verification output for an HTTP 1.1 request and response. Note that since the `Prover` chose not to disclose some sensitive information like their HTTP session token and address, that information will be withheld from the `Verifier` and will appear to him as redacted (in red).
 
-![Verification example](/diagrams/verification_example.svg)
+![Verification example](../diagrams/verification_example.svg)