deploy: 919bf52a58

index.html

@@ -188,7 +188,7 @@
 <li>The <code>User</code> <strong>selectively discloses</strong> the data to the <code>Verifier</code>.</li>
 <li>The <code>Verifier</code> <strong>verifies</strong> the data.</li>
 </ol>
-<p><img src="./png-diagrams/overview3.png" alt="" /></p>
+<p><img src="./diagrams/overview3.svg" alt="" /></p>
 <h3 id="①-multi-party-tls-request"><a class="header" href="#①-multi-party-tls-request">① Multi-party TLS Request</a></h3>
 <p>TLSNotary works by adding a third party, the <code>Notary</code>, to the usual TLS connection between the <code>User</code> and a <code>Server</code>. This <code>Notary</code> is <strong>not &quot;<a href="https://en.wikipedia.org/wiki/Man-in-the-middle_attack">a man in the middle</a>&quot;</strong>. Instead, the <code>Notary</code> participates in a <strong>secure multi-party computation</strong> (MPC) to jointly operate the TLS connection without ever seeing the data in plain text; the <code>Notary</code> only sees encrypted data. Given that the <code>Notary</code> only sees the temporary key of the <code>Server</code>, the <code>Notary</code> does not know which <code>Server</code> the <code>User</code> is communicating with. The TLSNotary protocol is transparent to the <code>Server</code>. From the <code>Server</code>'s perspective, the <code>User</code>'s connection is a standard TLS connection.</p>
 <!-- - Transport Layer Security (TLS)

intro.html

@@ -188,7 +188,7 @@
 <li>The <code>User</code> <strong>selectively discloses</strong> the data to the <code>Verifier</code>.</li>
 <li>The <code>Verifier</code> <strong>verifies</strong> the data.</li>
 </ol>
-<p><img src="./png-diagrams/overview3.png" alt="" /></p>
+<p><img src="./diagrams/overview3.svg" alt="" /></p>
 <h3 id="①-multi-party-tls-request"><a class="header" href="#①-multi-party-tls-request">① Multi-party TLS Request</a></h3>
 <p>TLSNotary works by adding a third party, the <code>Notary</code>, to the usual TLS connection between the <code>User</code> and a <code>Server</code>. This <code>Notary</code> is <strong>not &quot;<a href="https://en.wikipedia.org/wiki/Man-in-the-middle_attack">a man in the middle</a>&quot;</strong>. Instead, the <code>Notary</code> participates in a <strong>secure multi-party computation</strong> (MPC) to jointly operate the TLS connection without ever seeing the data in plain text; the <code>Notary</code> only sees encrypted data. Given that the <code>Notary</code> only sees the temporary key of the <code>Server</code>, the <code>Notary</code> does not know which <code>Server</code> the <code>User</code> is communicating with. The TLSNotary protocol is transparent to the <code>Server</code>. From the <code>Server</code>'s perspective, the <code>User</code>'s connection is a standard TLS connection.</p>
 <!-- - Transport Layer Security (TLS)

motivation.html

@@ -180,18 +180,18 @@
 <p>Data provenance ensures internet data is authentic. It allows verification of the data's origin, ensuring it hasn't been fabricated or tampered with.</p>
 <p>Data provenance will make data truly portable, empowering users to share it with others as they see fit.</p>
 <h2 id="non-repudiation-tls-is-not-enough"><a class="header" href="#non-repudiation-tls-is-not-enough">Non-repudiation: TLS is not enough</a></h2>
-<p><img src="png-diagrams/data_provenance_none.png" alt="" /></p>
+<p><img src="diagrams/data_provenance_none.svg" alt="" /></p>
 <p>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 <code>User</code> indeed originated from the <code>Server</code> and was not changed. The <code>Server</code>'s identity is verified by the <code>User</code> 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.</p>
 <p>However, this hash does not provide <strong>non-repudiation</strong>, meaning it cannot serve as evidence for the <strong>authenticity and integrity</strong> of the data to third parties (e.g., a service or an app). Because it is a keyed hash and TLS requires that the key is known to the <code>User</code>, the <code>User</code> could potentially modify the data and compute a corresponding hash after the TLS session is finished.</p>
 <p>Achieving non-repudiation requires digital signatures implemented with asymmetric, public-key cryptography.</p>
 <p>While the concept seems straightforward, enabling servers to sign data is not a part of the TLS protocol. Even if all data were securely signed, naively sharing all data with others could expose too much information, compromising the <code>User</code>'s privacy. <strong>Privacy</strong> is a vital social good that must be protected.</p>
 <h2 id="status-quo-delegate-access"><a class="header" href="#status-quo-delegate-access">Status Quo: delegate access</a></h2>
-<p><img src="png-diagrams/data_provenance_oauth.png" alt="" /></p>
+<p><img src="diagrams/data_provenance_oauth.svg" alt="" /></p>
 <p>Currently, when a <code>User</code> wants to share data from a <code>Server</code> 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 <code>Server</code>, 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.</p>
 <p>Another drawback of this solution is that the <code>Server</code> is aware of the access delegation, enabling it to monitor and censor the other user’s requests.</p>
 <p>It's worth noting that in many instances, OAuth is not even presented as an option. This is because a lot of servers lack the incentive to provide third-party access to the data.</p>
 <h2 id="tlsnotary-data-provenance-and-privacy-with-secure-multi-party-computation"><a class="header" href="#tlsnotary-data-provenance-and-privacy-with-secure-multi-party-computation">TLSNotary: data provenance and privacy with secure multi-party computation</a></h2>
-<p><img src="png-diagrams/data_provenance_tlsn.png" alt="" /></p>
+<p><img src="diagrams/data_provenance_tlsn.svg" alt="" /></p>
 <p>TLSNotary operates by introducing a third party, the <code>Notary</code>, into the usual TLS connection between the <code>User</code> and a <code>Server</code>. This <code>Notary</code> is <strong>not an intermediary</strong>. Instead, the <code>Notary</code> participates in a <strong>secure multi-party computation</strong> (MPC) to jointly manage the TLS connection without ever viewing the data in plain text; the <code>Notary</code> only has access to encrypted data. Furthermore, as the <code>Notary</code> only possesses the ephemeral keys of the <code>Server</code>, it remains unaware of which <code>Server</code> the <code>User</code> is communicating with.</p>
 <p>The TLSNotary protocol is <strong>transparent</strong> to the <code>Server</code>. From the <code>Server</code>'s perspective, the TLS connection is indistinguishable from all other connections. As such, <strong>no modifications to the TLS protocol are necessary</strong>.</p>
 <p>The TLSNotary protocol enables the <code>User</code> to selectively prove the authenticity of arbitrary portions of the data to a <code>Verifier</code> as long as the <code>Verifier</code> trusts the <code>Notary</code> who signed the data.</p>

mpc/key_exchange.html

@@ -177,7 +177,7 @@
                         <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/katex@0.12.0/dist/katex.min.css" integrity="sha384-AfEj0r4/OFrOo5t7NnNe46zW/tFgW6x/bCJG8FqQCEo3+Aro6EYUG4+cU+KJWu/X" crossorigin="anonymous">
 <h1 id="key-exchange"><a class="header" href="#key-exchange">Key Exchange</a></h1>
 <p>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 <a href="https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman">ECDH protocol</a>. The resulting shared secret in TLS terms is called the pre-master secret <code>PMS</code>.</p>
-<img src="../../png-diagrams/key_exchange.png" width="800">
+<img src="../../diagrams/key_exchange.svg" width="800">
 <p>Using the notation from Wikipedia, below is the 3-party ECDH protocol between the <code>Server</code> the <code>Requester</code> and the <code>Notary</code>, enabling the <code>Requester</code> and the <code>Notary</code> to arrive at shares of <code>PMS</code>.</p>
 <ol>
 <li><code>Server</code> sends its public key <span class="katex"><span class="katex-html" aria-hidden="true"><span class="base"><span class="strut" style="height:0.8778em;vertical-align:-0.1944em;"></span><span class="mord"><span class="mord mathnormal">Q</span><span class="msupsub"><span class="vlist-t vlist-t2"><span class="vlist-r"><span class="vlist" style="height:0.3361em;"><span style="top:-2.55em;margin-left:0em;margin-right:0.05em;"><span class="pstrut" style="height:2.7em;"></span><span class="sizing reset-size6 size3 mtight"><span class="mord mathnormal mtight">b</span></span></span></span><span class="vlist-s">​</span></span><span class="vlist-r"><span class="vlist" style="height:0.15em;"><span></span></span></span></span></span></span></span></span></span> to <code>Requester</code>, and <code>Requester</code> forwards it to <code>Notary</code></li>

print.html

@@ -186,7 +186,7 @@
 <li>The <code>User</code> <strong>selectively discloses</strong> the data to the <code>Verifier</code>.</li>
 <li>The <code>Verifier</code> <strong>verifies</strong> the data.</li>
 </ol>
-<p><img src="./png-diagrams/overview3.png" alt="" /></p>
+<p><img src="./diagrams/overview3.svg" alt="" /></p>
 <h3 id="①-multi-party-tls-request"><a class="header" href="#①-multi-party-tls-request">① Multi-party TLS Request</a></h3>
 <p>TLSNotary works by adding a third party, the <code>Notary</code>, to the usual TLS connection between the <code>User</code> and a <code>Server</code>. This <code>Notary</code> is <strong>not &quot;<a href="https://en.wikipedia.org/wiki/Man-in-the-middle_attack">a man in the middle</a>&quot;</strong>. Instead, the <code>Notary</code> participates in a <strong>secure multi-party computation</strong> (MPC) to jointly operate the TLS connection without ever seeing the data in plain text; the <code>Notary</code> only sees encrypted data. Given that the <code>Notary</code> only sees the temporary key of the <code>Server</code>, the <code>Notary</code> does not know which <code>Server</code> the <code>User</code> is communicating with. The TLSNotary protocol is transparent to the <code>Server</code>. From the <code>Server</code>'s perspective, the <code>User</code>'s connection is a standard TLS connection.</p>
 <!-- - Transport Layer Security (TLS)
@@ -227,18 +227,18 @@ The data origin can be verified by inspecting the <code>Server</code> certificat
 <p>Data provenance ensures internet data is authentic. It allows verification of the data's origin, ensuring it hasn't been fabricated or tampered with.</p>
 <p>Data provenance will make data truly portable, empowering users to share it with others as they see fit.</p>
 <h2 id="non-repudiation-tls-is-not-enough"><a class="header" href="#non-repudiation-tls-is-not-enough">Non-repudiation: TLS is not enough</a></h2>
-<p><img src="png-diagrams/data_provenance_none.png" alt="" /></p>
+<p><img src="diagrams/data_provenance_none.svg" alt="" /></p>
 <p>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 <code>User</code> indeed originated from the <code>Server</code> and was not changed. The <code>Server</code>'s identity is verified by the <code>User</code> 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.</p>
 <p>However, this hash does not provide <strong>non-repudiation</strong>, meaning it cannot serve as evidence for the <strong>authenticity and integrity</strong> of the data to third parties (e.g., a service or an app). Because it is a keyed hash and TLS requires that the key is known to the <code>User</code>, the <code>User</code> could potentially modify the data and compute a corresponding hash after the TLS session is finished.</p>
 <p>Achieving non-repudiation requires digital signatures implemented with asymmetric, public-key cryptography.</p>
 <p>While the concept seems straightforward, enabling servers to sign data is not a part of the TLS protocol. Even if all data were securely signed, naively sharing all data with others could expose too much information, compromising the <code>User</code>'s privacy. <strong>Privacy</strong> is a vital social good that must be protected.</p>
 <h2 id="status-quo-delegate-access"><a class="header" href="#status-quo-delegate-access">Status Quo: delegate access</a></h2>
-<p><img src="png-diagrams/data_provenance_oauth.png" alt="" /></p>
+<p><img src="diagrams/data_provenance_oauth.svg" alt="" /></p>
 <p>Currently, when a <code>User</code> wants to share data from a <code>Server</code> 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 <code>Server</code>, 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.</p>
 <p>Another drawback of this solution is that the <code>Server</code> is aware of the access delegation, enabling it to monitor and censor the other user’s requests.</p>
 <p>It's worth noting that in many instances, OAuth is not even presented as an option. This is because a lot of servers lack the incentive to provide third-party access to the data.</p>
 <h2 id="tlsnotary-data-provenance-and-privacy-with-secure-multi-party-computation"><a class="header" href="#tlsnotary-data-provenance-and-privacy-with-secure-multi-party-computation">TLSNotary: data provenance and privacy with secure multi-party computation</a></h2>
-<p><img src="png-diagrams/data_provenance_tlsn.png" alt="" /></p>
+<p><img src="diagrams/data_provenance_tlsn.svg" alt="" /></p>
 <p>TLSNotary operates by introducing a third party, the <code>Notary</code>, into the usual TLS connection between the <code>User</code> and a <code>Server</code>. This <code>Notary</code> is <strong>not an intermediary</strong>. Instead, the <code>Notary</code> participates in a <strong>secure multi-party computation</strong> (MPC) to jointly manage the TLS connection without ever viewing the data in plain text; the <code>Notary</code> only has access to encrypted data. Furthermore, as the <code>Notary</code> only possesses the ephemeral keys of the <code>Server</code>, it remains unaware of which <code>Server</code> the <code>User</code> is communicating with.</p>
 <p>The TLSNotary protocol is <strong>transparent</strong> to the <code>Server</code>. From the <code>Server</code>'s perspective, the TLS connection is indistinguishable from all other connections. As such, <strong>no modifications to the TLS protocol are necessary</strong>.</p>
 <p>The TLSNotary protocol enables the <code>User</code> to selectively prove the authenticity of arbitrary portions of the data to a <code>Verifier</code> as long as the <code>Verifier</code> trusts the <code>Notary</code> who signed the data.</p>
@@ -376,7 +376,7 @@ user-agent: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 <!-- // paste here a picture of an HTTP request with redacted fields --><div style="break-before: page; page-break-before: always;"></div><link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/katex@0.12.0/dist/katex.min.css" integrity="sha384-AfEj0r4/OFrOo5t7NnNe46zW/tFgW6x/bCJG8FqQCEo3+Aro6EYUG4+cU+KJWu/X" crossorigin="anonymous">
 <h1 id="key-exchange"><a class="header" href="#key-exchange">Key Exchange</a></h1>
 <p>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 <a href="https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman">ECDH protocol</a>. The resulting shared secret in TLS terms is called the pre-master secret <code>PMS</code>.</p>
-<img src="mpc/../../png-diagrams/key_exchange.png" width="800">
+<img src="mpc/../../diagrams/key_exchange.svg" width="800">
 <p>Using the notation from Wikipedia, below is the 3-party ECDH protocol between the <code>Server</code> the <code>Requester</code> and the <code>Notary</code>, enabling the <code>Requester</code> and the <code>Notary</code> to arrive at shares of <code>PMS</code>.</p>
 <ol>
 <li><code>Server</code> sends its public key <span class="katex"><span class="katex-html" aria-hidden="true"><span class="base"><span class="strut" style="height:0.8778em;vertical-align:-0.1944em;"></span><span class="mord"><span class="mord mathnormal">Q</span><span class="msupsub"><span class="vlist-t vlist-t2"><span class="vlist-r"><span class="vlist" style="height:0.3361em;"><span style="top:-2.55em;margin-left:0em;margin-right:0.05em;"><span class="pstrut" style="height:2.7em;"></span><span class="sizing reset-size6 size3 mtight"><span class="mord mathnormal mtight">b</span></span></span></span><span class="vlist-s">​</span></span><span class="vlist-r"><span class="vlist" style="height:0.15em;"><span></span></span></span></span></span></span></span></span></span> to <code>Requester</code>, and <code>Requester</code> forwards it to <code>Notary</code></li>