From 1b8ecf1ce9e397c5c4bd173dcdfea5431cc97229 Mon Sep 17 00:00:00 2001 From: Hendrik Eeckhaut Date: Tue, 8 Oct 2024 09:58:06 +0200 Subject: [PATCH] Use relative links (for easier markdown navigation) --- src/mpc/commitments.md | 8 ++++---- src/mpc/encryption.md | 8 ++++---- src/protocol/mpc-tls/encryption.md | 8 ++++---- src/protocol/notarization.md | 4 ++-- src/protocol/verification.md | 4 ++-- 5 files changed, 16 insertions(+), 16 deletions(-) diff --git a/src/mpc/commitments.md b/src/mpc/commitments.md index b00da99..f2d78b1 100644 --- a/src/mpc/commitments.md +++ b/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) \ No newline at end of file +![Commitment](../diagrams/encoding_commitment.svg) \ No newline at end of file diff --git a/src/mpc/encryption.md b/src/mpc/encryption.md index bdae867..163ae1a 100644 --- a/src/mpc/encryption.md +++ b/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$$ diff --git a/src/protocol/mpc-tls/encryption.md b/src/protocol/mpc-tls/encryption.md index 9017941..5d2ae33 100644 --- a/src/protocol/mpc-tls/encryption.md +++ b/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). diff --git a/src/protocol/notarization.md b/src/protocol/notarization.md index c08f9d0..3be4f7b 100644 --- a/src/protocol/notarization.md +++ b/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 diff --git a/src/protocol/verification.md b/src/protocol/verification.md index 26b4361..4efe461 100644 --- a/src/protocol/verification.md +++ b/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)