Dark mode diagrams

# Conflicts:
#	diagrams/convert_all.sh
#	diagrams/overview3.drawio
#	diagrams/overview4.drawio
#	src/intro.md
#	src/png-diagrams/overview3.png

diagrams/convert_all.sh

@@ -1,8 +1,10 @@
 #!/bin/bash
 
+FORMAT="svg"
+
 # Convert all diagrams in the diagrams folder to pngs in the mdbook src/png-diagrams folder
 SOURCE_DIR=$(dirname "$0")
-TARGET_DIR=$(realpath "$(dirname "$0")/../src/png-diagrams/")
+TARGET_DIR=$(realpath "$(dirname "$0")/../src/diagrams/")
 
 OS=$(uname)
 case "$OS" in
@@ -21,6 +23,13 @@ fi
 
 pushd "$SOURCE_DIR" >/dev/null
 for file in *.drawio; do
-    "$DRAW_IO" -x -f png --scale 2.5 -o "${TARGET_DIR}/${file%.drawio}.png" "$file"
+    SOURCE="$file"
+    TARGET="${TARGET_DIR}/${file%.drawio}.${FORMAT}"
+    # Only convert if the source is more recent than the target
+    if [[ "$SOURCE" -nt "${TARGET}" ]]; then
+        "$DRAW_IO" --export --format ${FORMAT} --scale 2.5 -o "${TARGET}" "$SOURCE"
+        # add styling for dark mode (https://github.com/jgraph/drawio-github/blob/master/DARK-MODE.md)
+        sed -i -e "s$<defs/>$<defs><style type=\"text/css\"> @media (prefers-color-scheme: dark) { svg { filter: invert(93%) hue-rotate(180deg); background-color: transparent !important; } image { filter: invert(100%) hue-rotate(180deg) saturate(1.25); } } </style></defs>$" "${TARGET}"
+    fi
 done
 popd >/dev/null

src/diagrams/README.md

@@ -0,0 +1 @@
+The files in this folders are generated. See `../../diagrams/convert_all.sh`

src/intro.md

@@ -16,7 +16,7 @@ The TLSNotary protocol consists of 4 steps:
 3. The `User` **selectively discloses** the data to the `Verifier`.
 4. The `Verifier` **verifies** the data.
 
-![](./png-diagrams/overview3.png)
+![](./diagrams/overview3.svg)
 
 ### ① Multi-party TLS Request
 

src/motivation.md

@@ -8,7 +8,7 @@ Data provenance will make data truly portable, empowering users to share it with
 
 ## Non-repudiation: TLS is not enough
 
-![](png-diagrams/data_provenance_none.png)
+![](diagrams/data_provenance_none.svg)
 
 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 the `User` indeed originated from the `Server` and was not changed. The `Server`'s identity is verified by the `User` 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.
 
@@ -20,7 +20,7 @@ While the concept seems straightforward, enabling servers to sign data is not a
 
 ## Status Quo: delegate access
 
-![](png-diagrams/data_provenance_oauth.png)
+![](diagrams/data_provenance_oauth.svg)
 
 Currently, when a `User` 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.
 
@@ -30,7 +30,7 @@ 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
 
-![](png-diagrams/data_provenance_tlsn.png)
+![](diagrams/data_provenance_tlsn.svg)
 
 TLSNotary operates by introducing a third party, the `Notary`, into the usual TLS connection between the `User` and a `Server`. This `Notary` is **not an intermediary**. Instead, the `Notary` participates in a **secure multi-party computation** (MPC) to jointly manage the TLS connection without ever viewing the data in plain text; the `Notary` only has access to encrypted data. Furthermore, as the `Notary` only possesses the ephemeral keys of the `Server`, it remains unaware of which `Server` the `User` is communicating with.
 

src/mpc/key_exchange.md

@@ -2,7 +2,7 @@
 
 In TLS, the first step towards obtaining TLS session keys is to compute a shared secret between the client and the server by running the [ECDH protocol](https://en.wikipedia.org/wiki/Elliptic-curve_Diffie–Hellman). The resulting shared secret in TLS terms is called the pre-master secret `PMS`.
 
-<img src="../../png-diagrams/key_exchange.png" width="800">
+<img src="../../diagrams/key_exchange.svg" width="800">
 
 Using the notation from Wikipedia, below is the 3-party ECDH protocol between the `Server` the `Requester` and the `Notary`, enabling the `Requester` and the `Notary` to arrive at shares of `PMS`.
 

src/overview.md

@@ -3,4 +3,4 @@
 The following diagram is a high-level protocol overview introducing the main components of
 TLSNotary.
 
-![TLSNotary Overview](./png-diagrams/intro-diagram.png)
+![TLSNotary Overview](./diagrams/intro-diagram.svg)