inernal links

src/mpc/commitment_scheme.md

@@ -2,8 +2,8 @@
 
 <!-- TODO will polish -->
 
-BEFORE the `Notary` "opens his gabled circuit" in Step 17 of [DEAP](/mpc/deap.md), the `User` commits (e.g. computes a blake3 hash) to the encodings of the plaintext generated by the `Notary` (i.e. the encoded output [v]_B from Step 8 in DEAP).
+BEFORE the `Notary` "opens his gabled circuit" in Step 17 of [DEAP](deap.md), the `User` commits (e.g. computes a blake3 hash) to the encodings of the plaintext generated by the `Notary` (i.e. the encoded output [v]_B from Step 8 in DEAP).
 
-"Opening the garbled circuit" simply means that the `Notary` reveals and signs the seed of randomness which (among other things) was used to generate the [encoding](/mpc/encodings.md) of the plaintext. 
+"Opening the garbled circuit" simply means that the `Notary` reveals and signs the seed of randomness which (among other things) was used to generate the [encoding](encodings.md) of the plaintext. 
 
 Having both the signed seed from the `Notary` and also the commitment to the plaintext encoding, the `User` can prove to any third-party Verifier the authenticity of the plaintext. 

src/mpc/commitments.md

@@ -2,9 +2,9 @@
 
 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.md) 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.md).
 
 We also hide the amount of commitments (to preserve `Prover` privacy) by having the `Prover` commit to the Merkle tree of commitments.
 

src/mpc/key_exchange.md

@@ -4,7 +4,7 @@ In TLS, the first step towards obtaining TLS session keys is to compute a shared
 
 With TLSNotary, at the end of the key exchange, the `Server` gets the `PMS` as usual. The `Prover` and the `Verifier`, jointly operating as the TLS client, compute additive shares of the `PMS`. This prevents either party from unilaterally sending or receiving messages with the `Server`. Subsequently, the authenticity and integrity of the messages are guaranteed to both the `Prover` and `Verifier`, while also keeping the plaintext hidden from the `Verifier`.
 
-<img src="../../diagrams/key_exchange.svg" width="800">
+<img src="../diagrams/key_exchange.svg" width="800">
 
 The 3-party ECDH protocol between the `Server` the `Prover` and the `Verifier` works as follows:
 

src/mpc/tls_handshake.md

@@ -5,11 +5,11 @@ During the TLS handshake the TLS Client and the TLS Server compute the session k
 In TLSNotary protocol `User` and `Notary` jointly play the role of the TLS Client. They use MPC to compute the session keys in such a way that neither party ever learns the full keys but each has their share of the keys.
 
 
-First they compute their shares of the TLS Client's ECDH secret using [this protocol](./key_exchange.md). Since an ECDH secret is an EC point, the parties have their shares of that point.
+First they compute their shares of the TLS Client's ECDH secret using [this protocol](key_exchange.md). Since an ECDH secret is an EC point, the parties have their shares of that point.
 
 Then they compute their shares of the pre-master secret (PMS) using an MPC protocol described [here](./ectf.md).
 
-Then the parties input their PMS shares as private inputs to the [DEAP](/mpc/deap.md) protocol (along with some other public data). They perform the following in MPC: 
+Then the parties input their PMS shares as private inputs to the [DEAP](deap.md) protocol (along with some other public data). They perform the following in MPC: 
 
 - they derive their shares of the TLS session keys
 - they encrypt the Client Finished message (and the `User` sends the CF to the server)

src/spec/notarized_session.md

@@ -16,9 +16,9 @@ Since the `Notary` remains unaware of the signature or the certificate, the serv
 
 ### Plaintext Encodings
 
-These are the [encodings](/mpc/encodings.md) employed by the Notary to encode the plaintext.
+These are the [encodings](../mpc/encodings.md) employed by the Notary to encode the plaintext.
 
-Again, note that the `Notary` does not gain knowledge of the actual plaintext. The `Notary` transmits these encodings to the `User` using [Oblivious Transfer](/mpc/oblivious_transfer.md).
+Again, note that the `Notary` does not gain knowledge of the actual plaintext. The `Notary` transmits these encodings to the `User` using [Oblivious Transfer](../mpc/oblivious_transfer.md).
 
 For efficiency, the `Notary` employs a small PRG seed to generate random plaintext encodings.
 

src/spec/verification_steps.md

@@ -30,4 +30,4 @@ To summarize: the `Verifier` will only learn those portions of the TLS session t
 
 <!-- // paste here a picture of an HTTP request with redacted fields -->
 
-![Verification example](/diagrams/verification_example.svg)
+![Verification example](../diagrams/verification_example.svg)