Improved diagrams (dark/light mode support)

docs/MPC/commitments.md

@@ -11,5 +11,5 @@ The high-level idea is that the `Prover` creates a commitment to the active plai
 
 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/light/encoding_commitment.svg#gh-light-mode-only)
+![Commitment](../../diagrams/dark/encoding_commitment.svg#gh-dark-mode-only)

docs/Protocol/mpc-tls/encryption.md

@@ -11,7 +11,8 @@ This section explains how the `Prover` and `Verifier` use MPC to encrypt data se
 
 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)
+![Encryption](../../../diagrams/light/mpc-encryption.svg#gh-light-mode-only)
+![Encryption](../../../diagrams/dark/mpc-encryption.svg#gh-dark-mode-only)
 
 Both parties see the resulting ciphertext and execute the [2PC MAC](../../mpc/mac.md) protocol to compute the MAC for the ciphertext.
 
@@ -23,7 +24,8 @@ Once the `Prover` receives the ciphertext and its associated MAC 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.
 
-![Decryption](../../diagrams/mpc-decryption.svg)
+![Decryption](../../../diagrams/light/mpc-decryption.svg#gh-light-mode-only)
+![Decryption](../../../diagrams/dark/mpc-decryption.svg#gh-dark-mode-only)
 
 The resulting plaintext is revealed ONLY to the `Prover`.
 

docs/Protocol/mpc-tls/handshake.md

@@ -4,7 +4,8 @@ sidebar_position: 1
 
 # Handshake
 
-![](../../diagrams/key_exchange.svg)
+![Encryption](../../../diagrams/light/key_exchange.svg#gh-light-mode-only)
+![Encryption](../../../diagrams/dark/key_exchange.svg#gh-dark-mode-only)
 
 A TLS handshake is the first step in establishing a TLS connection between a `Prover` and a `Server`. In TLSNotary the `Prover` is the one who starts the TLS handshake and physically communicates with the `Server`, but all cryptographic TLS operations are performed together with the `Verifier` using MPC.
 

docs/Protocol/verification.md

@@ -18,4 +18,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/light/verification_example.svg)

docs/_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)
+![](../../diagrams/light/verification_example.svg)

docs/intro.md

@@ -19,7 +19,8 @@ The TLSNotary protocol consists of 3 steps:
 2. The `Prover` **selectively discloses** the data to the `Verifier`.
 3. The `Verifier` **verifies** the data.
 
-![](./diagrams/overview_prover_verifier.svg)
+![](../diagrams/light/overview_prover_verifier.svg#gh-light-mode-only)
+![](../diagrams/dark/overview_prover_verifier.svg#gh-dark-mode-only)
 
 ### ① Multi-party TLS Request
 
@@ -41,7 +42,8 @@ The `Verifier` now validates the proof received from the `Prover`. The data orig
 
 Since the validation of the TLS traffic neither reveals anything about the plaintext of the TLS session nor about the `Server`, it is possible to outsource the MPC-TLS verification ① to a general-purpose TLS verifier, which we term a `Notary`. This `Notary` can sign (aka *notarize*) ② the data, making it portable. The `Prover` can then take this signed data and selectively disclose ③ sections to an application-specific `Verifier`, who then verifies the data ④.
 
-![](./diagrams/overview_notary.svg)
+![](../diagrams/light/overview_notary.svg#gh-light-mode-only)
+![](../diagrams/dark/overview_notary.svg#gh-dark-mode-only)
 
 In this setup, the `Notary` cryptographically signs commitments to the data and the server's identity. The `Prover` can store this signed data, redact it, and share it with any `Verifier` as they see fit, making the signed data both reusable and portable.
 

docs/motivation.md

@@ -12,7 +12,8 @@ Data provenance will make data truly portable, empowering users to share it with
 
 ## Non-repudiation: TLS is not enough
 
-![](diagrams/data_provenance_none.svg)
+![](../diagrams/light/data_provenance_none.svg#gh-light-mode-only)
+![](../diagrams/dark/data_provenance_none.svg#gh-dark-mode-only)
 
 Transport Layer Security (TLS) plays a crucial role in digital security. TLS protects communication against eavesdropping and tampering. It ensures that the data received by a user (_"Alice"_) indeed originated from the `Server` and was not changed. The `Server`'s identity is verified by Alice through trusted Certificate Authorities (CAs). Data integrity is maintained by transmitting a cryptographic hash (called Message Authentication Code or MAC in TLS) alongside the data, which safeguards against deliberate alterations.
 
@@ -24,7 +25,8 @@ While the concept seems straightforward, enabling servers to sign data is not a
 
 ## Status Quo: delegate access
 
-![](diagrams/data_provenance_oauth.svg)
+![](../diagrams/light/data_provenance_oauth.svg#gh-light-mode-only)
+![](../diagrams/dark/data_provenance_oauth.svg#gh-dark-mode-only)
 
 Currently, when Alice wants to share data from a `Server` with another party, OAuth can be used to facilitate this if the application supports it. In this way, the other party receives the data directly from the `Server`, ensuring authentic and unchanged data. However, applications often do not provide fine-grained control over which data to share, leading to the other party gaining access to more information than strictly necessary.
 
@@ -34,7 +36,8 @@ It's worth noting that in many instances, OAuth is not even presented as an opti
 
 ## TLSNotary: data provenance and privacy with secure multi-party computation
 
-![](diagrams/data_provenance_tlsn.svg)
+![](../diagrams/light/data_provenance_tlsn.svg#gh-light-mode-only)
+![](../diagrams/dark/data_provenance_tlsn.svg#gh-dark-mode-only)
 
 TLSNotary operates by executing the TLS communication using **multi-party computation** (MPC). MPC allows Alice and Bob to jointly manage the TLS connection.
 With TLSNotary, Alice can selectively prove the authenticity of arbitrary portions of the data to Bob. Since Bob participated in the MPC-TLS communication, he is guaranteed that the data is authentic.

docs/mpc/key_exchange.md

@@ -7,7 +7,8 @@ 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`.
 
-![](../diagrams/key_exchange.svg)
+![](../../diagrams/light/key_exchange.svg#gh-light-mode-only)
+![](../../diagrams/dark/key_exchange.svg#gh-dark-mode-only)
 
 The 3-party ECDH protocol between the `Server` the `Prover` and the `Verifier` works as follows:
 

docs/quick_start/rust.md

@@ -18,7 +18,8 @@ Before we start, make sure you have cloned the `tlsn` repository and have a rece
 
 ## Simple Interactive Verifier: Verifying Data from an API in Rust<a name="interactive"></a>
 
-![](../diagrams/overview_prover_verifier.svg)
+![](../../diagrams/light/overview_prover_verifier.svg#gh-light-mode-only)
+![](../../diagrams/dark/overview_prover_verifier.svg#gh-dark-mode-only)
 
 This example demonstrates how to use TLSNotary in a simple interactive session between a Prover and a Verifier. It involves the Verifier first verifying the MPC-TLS session and then confirming the correctness of the data.
 
@@ -27,7 +28,8 @@ https://github.com/tlsnotary/tlsn/tree/main/crates/examples/interactive#readme
 
 ## Simple Attestation Example: Verifying Data from an API in Rust with a Notary<a name="attestation"></a>
 
-![](../diagrams/overview_notary.svg)
+![](../../diagrams/light/overview_notary.svg#gh-light-mode-only)
+![](../../diagrams/dark/overview_notary.svg#gh-dark-mode-only)
 
 TLSNotary can also be used in a setup where MPC-TLS verification is delegated to a notary server. In this example, the notary attests to the data served to the prover. Next, the prover can share this attestation with a Verifier who can verify the data.
 

docs/quick_start/tlsn-js.md

@@ -60,7 +60,8 @@ In this demo, we will request JSON data from the Star Wars API at https://swapi.
 
 ## Interactive verification with `tlsn-js` <a name="interactive-demo"></a>
 
-![](../diagrams/overview_prover_verifier.svg)
+![](../../diagrams/light/overview_prover_verifier.svg#gh-light-mode-only)
+![](../../diagrams/dark/overview_prover_verifier.svg#gh-dark-mode-only)
 
 Follow the instructions from:
 https://github.com/tlsnotary/tlsn-js/blob/main/demo/interactive-demo/README.md