<h1id="run-a-notary-server"><aclass="header"href="#run-a-notary-server">Run a Notary Server</a></h1>
<p>This guide shows you how to run a <ahref="https://github.com/tlsnotary/tlsn/tree/main/notary-server">notary server</a> in an Ubuntu server instance.</p>
<h2id="configure-server-setting"><aclass="header"href="#configure-server-setting">Configure Server Setting</a></h2>
<h2id="data-provenance-without-compromising-privacy-that-is-why"><aclass="header"href="#data-provenance-without-compromising-privacy-that-is-why">Data Provenance without Compromising Privacy, That is Why!</a></h2>
<p>The Internet currently lacks effective, privacy-preserving <strong>Data Provenance</strong>. <ahref="https://en.wikipedia.org/wiki/Transport_Layer_Security">TLS</a>, also known as the "s" in "https" 🔐 to the general public, ensures that data can be securely communicated between a server and a user. But how can this user credibly share this data with another user or server without compromising security, privacy, and control?</p>
<h2id="data-provenance-without-compromising-privacy-that-is-why"><aclass="header"href="#data-provenance-without-compromising-privacy-that-is-why">Data Provenance without Compromising Privacy, That is Why!</a></h2>
<p>The Internet currently lacks effective, privacy-preserving <strong>Data Provenance</strong>. <ahref="https://en.wikipedia.org/wiki/Transport_Layer_Security">TLS</a>, also known as the "s" in "https" 🔐 to the general public, ensures that data can be securely communicated between a server and a user. But how can this user credibly share this data with another user or server without compromising security, privacy, and control?</p>
<p>The decentralized internet demands privacy-respecting data provenance!</p>
<p>Data provenance ensures internet data is authentic. It allows verification of the data's origin and ensures the data hasn't been fabricated or tampered with.</p>
<p>Here we illustrate the commitment scheme used to create authenticated commitments to the plaintext in scenarios where a general-purpose <ahref="/intro.html#tls-verification-with-a-general-purpose-notary"><code>Notary</code></a> is used. (Note that this scheme is not used when the <code>Prover</code> proves directly to the <code>Verifier</code>)</p>
<p>A naive approach of extending the <ahref="/protocol/mpc-tls/encryption.html"><code>Encryption and Decryption</code></a> 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.</p>
<h1id="dual-execution-with-asymmetric-privacy"><aclass="header"href="#dual-execution-with-asymmetric-privacy">Dual Execution with Asymmetric Privacy</a></h1>
<p>TLSNotary uses the <code>DEAP</code> protocol described below to ensure malicious security of the overall protocol.</p>
<p>When using DEAP in TLSNotary, the <code>User</code> plays the role of Alice and has full privacy and the <code>Notary</code> plays the role of Bob and reveals all of his private inputs after the TLS session with the server is over. The Notary's private input is his TLS session key share.</p>
<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 <ahref="https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman">ECDH protocol</a>. The resulting shared secret in TLS terms is <strong>called the pre-master secret <code>PMS</code></strong>.</p>
<p>With TLSNotary, at the end of the key exchange, the <code>Server</code> gets the <code>PMS</code> as usual. The <code>Prover</code> and the <code>Verifier</code>, jointly operating as the TLS client, compute additive shares of the <code>PMS</code>. This prevents either party from unilaterally sending or receiving messages with the <code>Server</code>. Subsequently, the authenticity and integrity of the messages are guaranteed to both the <code>Prover</code> and <code>Verifier</code>, while also keeping the plaintext hidden from the <code>Verifier</code>.</p>
<h2id="data-provenance-without-compromising-privacy-that-is-why"><aclass="header"href="#data-provenance-without-compromising-privacy-that-is-why">Data Provenance without Compromising Privacy, That is Why!</a></h2>
<p>The Internet currently lacks effective, privacy-preserving <strong>Data Provenance</strong>. <ahref="https://en.wikipedia.org/wiki/Transport_Layer_Security">TLS</a>, also known as the "s" in "https" 🔐 to the general public, ensures that data can be securely communicated between a server and a user. But how can this user credibly share this data with another user or server without compromising security, privacy, and control?</p>
@@ -222,7 +222,7 @@
<p>TLSNotary is not a new project; in fact, it has been around for <ahref="https://bitcointalk.org/index.php?topic=173220.0">more than a decade</a>.</p>
<p>In 2022, TLSNotary was rebuilt from the ground up in <ahref="https://www.rust-lang.org/">Rust</a> incorporating state-of-the-art cryptographic protocols. This renewed version of the TLSNotary protocol offers enhanced security, privacy, and performance.</p>
<p>Older versions of TLSNotary, including PageSigner, have been archived due to a security vulnerability.</p>
<p>The decentralized internet demands privacy-respecting data provenance!</p>
<p>Data provenance ensures internet data is authentic. It allows verification of the data's origin and ensures the data hasn't been fabricated or tampered with.</p>
@@ -247,7 +247,7 @@ With TLSNotary, Alice can selectively prove the authenticity of arbitrary portio
<h2id="make-your-data-portable-with-tlsnotary"><aclass="header"href="#make-your-data-portable-with-tlsnotary">Make your data portable with TLSNotary!</a></h2>
<p>TLSNotary is a solution designed to prove the authenticity of data while preserving user privacy. It unlocks a variety of new use cases. So, if you're looking for a way to make your data portable without compromising on privacy, TLSNotary is developed for you!</p>
<p>Dive into the protocol and integrate it into your applications. We eagerly await your feedback on <ahref="https://discord.com/invite/9XwESXtcN7">Discord</a>.</p>
<p>This quick start will help you get started with TLSNotary, both in native <ahref="quick_start/rust.html">Rust</a> and in the <ahref="quick_start/browser_extension.html">browser</a>.</p>
<ol>
@@ -296,7 +296,7 @@ There are no immediate plans to support TLS 1.3. Once the web starts to transiti
<li>Learn the basics of how to prove and verify data using TLSNotary</li>
<h1id="tlsnotary-in-reacttypescript-with-tlsn-js"><aclass="header"href="#tlsnotary-in-reacttypescript-with-tlsn-js">TLSNotary in React/Typescript with <code>tlsn-js</code><aname="browser"></a></a></h1>
<p>In this Quick Start you will learn how to use TLSNotary in React/Typescript with <ahref="https://github.com/tlsnotary/tlsn-js"><code>tlsn-js</code></a> NPM module in the browser.</p>
<p>This Quick Start uses the react/typescript <ahref="https://github.com/tlsnotary/tlsn-js/tree/main/demo/react-ts-webpack">demo app in <code>tlsn-js</code></a>. The directory contains a webpack configuration file that allows you to quickly bootstrap a webpack app using <code>tlsn-js</code>.</p>
@@ -530,7 +530,7 @@ cargo run --release
</li>
</ol>
<p>The notary server will now be running in the background waiting for connections.</p>
<p>In this Quick Start we will prove ownership of a Twitter account with TLSNotary's browser extension.
First we need to <ahref="quick_start/browser_extension.html#install">install</a> and configure a <ahref="quick_start/browser_extension.html#proxy">websocket proxy</a> and a <ahref="quick_start/browser_extension.html#notary-server">notary server</a>.</p>
@@ -633,7 +633,7 @@ cargo run --release
<li><code>Requests(0): no requests in the Browser extension</code> ➡ restart the TLSN browser extension in <ahref="chrome://extensions/">chrome://extensions/</a> and reload the Twitter page.</li>
<li>Are you using a local notary server? ➡ Check notary server's console log.</li>
<h1id="run-a-notary-server"><aclass="header"href="#run-a-notary-server">Run a Notary Server</a></h1>
<p>This guide shows you how to run a <ahref="https://github.com/tlsnotary/tlsn/tree/main/notary-server">notary server</a> in an Ubuntu server instance.</p>
<h2id="configure-server-setting"><aclass="header"href="#configure-server-setting">Configure Server Setting</a></h2>
<p>During the MPC-TLS phase the <code>Prover</code> and the <code>Verifier</code> run an MPC protocol enabling the <code>Prover</code> to connect to, and exchange data with, a TLS-enabled <code>Server</code>.</p>
<p>Listed below are some key points regarding this protocol:</p>
@@ -740,7 +740,7 @@ swapi.dev:443
A TLS handshake is the first step in establishing a TLS connection between the `Prover`/`Verifier` and the `Server`. The result of this handshake is a *Pre Master Secret (PMS)*, a symmetrical key that will be used for further encrypted communication. The server has the full key; the `Prover` and the `Verifier` only have their share of this key.
2. **Encryption, Decryption, and MAC Computation**
Next, the `Prover` and `Verifier` use MPC to encrypt, and decrypt, data sent to, and received from, the `Server`. They also compute a *Message Authentication Code (MAC)*
for the data that ensures untampered communication. --><divstyle="break-before: page; page-break-before: always;"></div><linkrel="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">
for the data that ensures untampered communication. --><divstyle="break-before: page; page-break-before: always;"></div><linkrel="stylesheet"href="https://cdn.jsdelivr.net/npm/katex@0.16.4/dist/katex.min.css">
<p>A TLS handshake is the first step in establishing a TLS connection between a <code>Prover</code> and a <code>Server</code>. In TLSNotary the <code>Prover</code> is the one who starts the TLS handshake and physically communicates with the <code>Server</code>, but all cryptographic TLS operations are performed together with the <code>Verifier</code> using MPC.</p>
@@ -751,7 +751,7 @@ for the data that ensures untampered communication. --><div style="break-before:
<p>The only exception is that since the <code>Verifier</code> is a party to the MPC TLS, the security for the <code>Prover</code> against a malicious <code>Verifier</code> is provided by the underlying MPC protocols and not by TLS.</p>
</blockquote>
<p>With the shares of the session key computed and the TLS handshake completed, the parties now proceed to the next MPC protocol where they use their session key shares to jointly generate encrypted requests and decrypt server responses while keeping the plaintext of both the requests and responses private from the <code>Verifier</code>.</p>
<h1id="encryption-decryption-and-mac-computation"><aclass="header"href="#encryption-decryption-and-mac-computation">Encryption, Decryption, and MAC Computation</a></h1>
<p>This section explains how the <code>Prover</code> and <code>Verifier</code> use MPC to encrypt data sent to the server, decrypt data received from the server, and compute the MAC for the ciphertext using MPC. It shows how the <code>Prover</code> and <code>Verifier</code> collaborate to encrypt and decrypt data. The <code>Verifier</code> performs these tasks "blindly", without acquiring knowledge of the plaintext.</p>
<p>The resulting plaintext is revealed ONLY to the <code>Prover</code>.</p>
<p>Please note, the actual low-level implementation details of decryption are more nuanced than what we have described here. For more information, please consult <ahref="protocol/mpc-tls//mpc/encryption.html">Low-level Decryption details</a>.</p>
<p>Even though the <code>Prover</code> can prove data provenance directly to the <code>Verifier</code>, in some scenarios it may be beneficial for the <code>Verifier</code> to outsource the verification of the TLS session to a trusted <code>Notary</code> as explained <ahref="protocol//intro.html#tls-verification-with-a-general-purpose-notary">here</a>.</p>
<p>As part of the TLSNotary protocol, the <code>Prover</code> creates authenticated commitments to the plaintext and has the <code>Notary</code> sign them without the <code>Notary</code> ever seeing the plaintext. This offers a way for the <code>Prover</code> to selectively prove the authenticity of arbitrary portions of the plaintext to an application-specific <code>Verifier</code> later.</p>
@@ -774,7 +774,7 @@ for the data that ensures untampered communication. --><div style="break-before:
<p>The <code>Notary</code> signs an artifact known as a <code>Session Header</code>, thereby attesting to the authenticity of the plaintext from a TLS session. A <code>Session Header</code> contains a <code>Prover</code>'s commitment to the plaintext and a <code>Prover</code>'s commitment to TLS-specific data which uniquely identifies the server.</p>
<p>The <code>Prover</code> can later use the signed <code>Session Header</code> to prove data provenance to an application-specific <code>Verifier</code>.</p>
<p>It's important to highlight that throughout the entire TLSNotary protocol, including this signing stage, the <code>Notary</code> does not gain knowledge of either the plaintext or the identity of the server with which the <code>Prover</code> communicated.</p>
<p>To prove data provenance to a third-party <code>Verifier</code>, the <code>Prover</code> provides the following information:</p>
<ul>
@@ -792,7 +792,7 @@ for the data that ensures untampered communication. --><div style="break-before:
<p>Next, the <code>Verifier</code> parses the <code>opening</code> with an application-specific parser (e.g. HTTP or JSON) to get the final output. Since the <code>Prover</code> is allowed to selectively disclose the data, that data which was not disclosed by the <code>Prover</code> will appear to the <code>Verifier</code> as redacted.</p>
<p>Below is an example of a verification output for an HTTP 1.1 request and response. Note that since the <code>Prover</code> chose not to disclose some sensitive information like their HTTP session token and address, that information will be withheld from the <code>Verifier</code> and will appear to him as redacted (in red).</p>
<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 <ahref="https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman">ECDH protocol</a>. The resulting shared secret in TLS terms is <strong>called the pre-master secret <code>PMS</code></strong>.</p>
<p>With TLSNotary, at the end of the key exchange, the <code>Server</code> gets the <code>PMS</code> as usual. The <code>Prover</code> and the <code>Verifier</code>, jointly operating as the TLS client, compute additive shares of the <code>PMS</code>. This prevents either party from unilaterally sending or receiving messages with the <code>Server</code>. Subsequently, the authenticity and integrity of the messages are guaranteed to both the <code>Prover</code> and <code>Verifier</code>, while also keeping the plaintext hidden from the <code>Verifier</code>.</p>
<p>Now we apply <code>M2A</code> to <spanclass="katex"><spanclass="katex-html"aria-hidden="true"><spanclass="base"><spanclass="strut"style="height:0.9694em;vertical-align:-0.2861em;"></span><spanclass="mord"><spanclass="mord mathnormal"style="margin-right:0.07153em;">C</span><spanclass="msupsub"><spanclass="vlist-t vlist-t2"><spanclass="vlist-r"><spanclass="vlist"style="height:0.1514em;"><spanstyle="top:-2.55em;margin-left:-0.0715em;margin-right:0.05em;"><spanclass="pstrut"style="height:2.7em;"></span><spanclass="sizing reset-size6 size3 mtight"><spanclass="mord mathnormal mtight"style="margin-right:0.03588em;">q</span></span></span></span><spanclass="vlist-s"></span></span><spanclass="vlist-r"><spanclass="vlist"style="height:0.2861em;"><span></span></span></span></span></span></span><spanclass="mspace"style="margin-right:0.2222em;"></span><spanclass="mbin">∗</span><spanclass="mspace"style="margin-right:0.2222em;"></span></span><spanclass="base"><spanclass="strut"style="height:0.9694em;vertical-align:-0.2861em;"></span><spanclass="mord"><spanclass="mord mathnormal"style="margin-right:0.07153em;">C</span><spanclass="msupsub"><spanclass="vlist-t vlist-t2"><spanclass="vlist-r"><spanclass="vlist"style="height:0.1514em;"><spanstyle="top:-2.55em;margin-left:-0.0715em;margin-right:0.05em;"><spanclass="pstrut"style="height:2.7em;"></span><spanclass="sizing reset-size6 size3 mtight"><spanclass="mord mathnormal mtight">p</span></span></span></span><spanclass="vlist-s"></span></span><spanclass="vlist-r"><spanclass="vlist"style="height:0.2861em;"><span></span></span></span></span></span></span></span></span></span> to get <spanclass="katex"><spanclass="katex-html"aria-hidden="true"><spanclass="base"><spanclass="strut"style="height:0.9694em;vertical-align:-0.2861em;"></span><spanclass="mord"><spanclass="mord mathnormal"style="margin-right:0.02778em;">D</span><spanclass="msupsub"><spanclass="vlist-t vlist-t2"><spanclass="vlist-r"><spanclass="vlist"style="height:0.1514em;"><spanstyle="top:-2.55em;margin-left:-0.0278em;margin-right:0.05em;"><spanclass="pstrut"style="height:2.7em;"></span><spanclass="sizing reset-size6 size3 mtight"><spanclass="mord mathnormal mtight"style="margin-right:0.03588em;">q</span></span></span></span><spanclass="vlist-s"></span></span><spanclass="vlist-r"><spanclass="vlist"style="height:0.2861em;"><span></span></span></span></span></span></span><spanclass="mspace"style="margin-right:0.2222em;"></span><spanclass="mbin">+</span><spanclass="mspace"style="margin-right:0.2222em;"></span></span><spanclass="base"><spanclass="strut"style="height:0.9694em;vertical-align:-0.2861em;"></span><spanclass="mord"><spanclass="mord mathnormal"style="margin-right:0.02778em;">D</span><spanclass="msupsub"><spanclass="vlist-t vlist-t2"><spanclass="vlist-r"><spanclass="vlist"style="height:0.1514em;"><spanstyle="top:-2.55em;margin-left:-0.0278em;margin-right:0.05em;"><spanclass="pstrut"style="height:2.7em;"></span><spanclass="sizing reset-size6 size3 mtight"><spanclass="mord mathnormal mtight">p</span></span></span></span><spanclass="vlist-s"></span></span><spanclass="vlist-r"><spanclass="vlist"style="height:0.2861em;"><span></span></span></span></span></span></span></span></span></span>, which leads us to two final terms each of which is the share of <spanclass="katex"><spanclass="katex-html"aria-hidden="true"><spanclass="base"><spanclass="strut"style="height:0.5806em;vertical-align:-0.15em;"></span><spanclass="mord"><spanclass="mord mathnormal">x</span><spanclass="msupsub"><spanclass="vlist-t vlist-t2"><spanclass="vlist-r"><spanclass="vlist"style="height:0.1514em;"><spanstyle="top:-2.55em;margin-left:0em;margin-right:0.05em;"><spanclass="pstrut"style="height:2.7em;"></span><spanclass="sizing reset-size6 size3 mtight"><spanclass="mord mathnormal mtight"style="margin-right:0.02778em;">r</span></span></span></span><spanclass="vlist-s"></span></span><spanclass="vlist-r"><spanclass="vlist"style="height:0.15em;"><span></span></span></span></span></span></span></span></span></span> of the respective party:</p>
during the replay, these masks are reproduced from <spanclass="katex"><spanclass="katex-html"aria-hidden="true"><spanclass="base"><spanclass="strut"style="height:0.6833em;"></span><spanclass="mord mathnormal"style="margin-right:0.00773em;">R</span></span></span></span> and indirectly checked
via <spanclass="katex"><spanclass="katex-html"aria-hidden="true"><spanclass="base"><spanclass="strut"style="height:0.6151em;"></span><spanclass="mord mathnormal">t</span><spanclass="mspace"style="margin-right:0.2778em;"></span><spanclass="mrel">==</span><spanclass="mspace"style="margin-right:0.2778em;"></span></span><spanclass="base"><spanclass="strut"style="height:0.6833em;"></span><spanclass="mord mathnormal"style="margin-right:0.13889em;">T</span></span></span></span>.</li>
<h1id="dual-execution-with-asymmetric-privacy"><aclass="header"href="#dual-execution-with-asymmetric-privacy">Dual Execution with Asymmetric Privacy</a></h1>
<p>TLSNotary uses the <code>DEAP</code> protocol described below to ensure malicious security of the overall protocol.</p>
<p>When using DEAP in TLSNotary, the <code>User</code> plays the role of Alice and has full privacy and the <code>Notary</code> plays the role of Bob and reveals all of his private inputs after the TLS session with the server is over. The Notary's private input is his TLS session key share.</p>
@@ -1043,7 +1043,7 @@ Since during the <code>Equality Check</code> all of the <code>Notary</code>'s se
<p>Bob's only options are to behave honestly, or cause Alice to abort without leaking any information.</p>
<h3id="malicious-alice--bob"><aclass="header"href="#malicious-alice--bob">Malicious Alice & Bob</a></h3>
<p>Notice that the User and Notary will already have computed <spanclass="katex"><spanclass="katex-html"aria-hidden="true"><spanclass="base"><spanclass="strut"style="height:0.6151em;"></span><spanclass="mord mathnormal">ec</span><spanclass="mord mathnormal">t</span><spanclass="mord mathnormal"style="margin-right:0.02778em;">r</span></span></span></span> when they computed <spanclass="katex"><spanclass="katex-html"aria-hidden="true"><spanclass="base"><spanclass="strut"style="height:0.7651em;vertical-align:-0.15em;"></span><spanclass="mord mathnormal">ec</span><spanclass="mord mathnormal">t</span><spanclass="mord"><spanclass="mord mathnormal"style="margin-right:0.02778em;">r</span><spanclass="msupsub"><spanclass="vlist-t vlist-t2"><spanclass="vlist-r"><spanclass="vlist"style="height:0.1514em;"><spanstyle="top:-2.55em;margin-left:-0.0278em;margin-right:0.05em;"><spanclass="pstrut"style="height:2.7em;"></span><spanclass="sizing reset-size6 size3 mtight"><spanclass="mord mathnormal mtight"style="margin-right:0.04398em;">z</span></span></span></span><spanclass="vlist-s"></span></span><spanclass="vlist-r"><spanclass="vlist"style="height:0.15em;"><span></span></span></span></span></span></span></span></span></span> earlier. Conveniently, the Notary can re-use the garbled labels <spanclass="katex"><spanclass="katex-html"aria-hidden="true"><spanclass="base"><spanclass="strut"style="height:1em;vertical-align:-0.25em;"></span><spanclass="mopen">[</span><spanclass="mord mathnormal">ec</span><spanclass="mord mathnormal">t</span><spanclass="mord mathnormal"style="margin-right:0.02778em;">r</span><spanclass="mclose"><spanclass="mclose">]</span><spanclass="msupsub"><spanclass="vlist-t vlist-t2"><spanclass="vlist-r"><spanclass="vlist"style="height:0.3283em;"><spanstyle="top:-2.55em;margin-left:0em;margin-right:0.05em;"><spanclass="pstrut"style="height:2.7em;"></span><spanclass="sizing reset-size6 size3 mtight"><spanclass="mord mathnormal mtight"style="margin-right:0.10903em;">N</span></span></span></span><spanclass="vlist-s"></span></span><spanclass="vlist-r"><spanclass="vlist"style="height:0.15em;"><span></span></span></span></span></span></span></span></span></span> as input labels for this circuit. For more details on the reuse of garbled labels see <ahref="https://eprint.iacr.org/2017/062.pdf">[AMR17]</a>.</p>
<p>Here we illustrate the commitment scheme used to create authenticated commitments to the plaintext in scenarios where a general-purpose <ahref="mpc//intro.html#tls-verification-with-a-general-purpose-notary"><code>Notary</code></a> is used. (Note that this scheme is not used when the <code>Prover</code> proves directly to the <code>Verifier</code>)</p>
<p>A naive approach of extending the <ahref="mpc//protocol/mpc-tls/encryption.html"><code>Encryption and Decryption</code></a> 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.</p>
<p>The high-level idea is that the <code>Prover</code> creates a commitment to the active plaintext encoding from the MPC protocol used for <ahref="mpc//protocol/mpc-tls/encryption.html"><code>Encryption and Decryption</code></a>.</p>
<p>We also hide the amount of commitments (to preserve <code>Prover</code> privacy) by having the <code>Prover</code> commit to the Merkle tree of commitments.</p>
<h1id="encryption-decryption-and-mac-computation"><aclass="header"href="#encryption-decryption-and-mac-computation">Encryption, Decryption, and MAC Computation</a></h1>
<p>This section explains how the <code>Prover</code> and <code>Verifier</code> use MPC to encrypt data sent to the server, decrypt data received from the server, and compute the MAC for the ciphertext using MPC. It shows how the <code>Prover</code> and <code>Verifier</code> collaborate to encrypt and decrypt data. The <code>Verifier</code> performs these tasks "blindly", without acquiring knowledge of the plaintext.</p>
<p>A TLS handshake is the first step in establishing a TLS connection between a <code>Prover</code> and a <code>Server</code>. In TLSNotary the <code>Prover</code> is the one who starts the TLS handshake and physically communicates with the <code>Server</code>, but all cryptographic TLS operations are performed together with the <code>Verifier</code> using MPC.</p>
<p>During the MPC-TLS phase the <code>Prover</code> and the <code>Verifier</code> run an MPC protocol enabling the <code>Prover</code> to connect to, and exchange data with, a TLS-enabled <code>Server</code>.</p>
<p>Listed below are some key points regarding this protocol:</p>
<p>Even though the <code>Prover</code> can prove data provenance directly to the <code>Verifier</code>, in some scenarios it may be beneficial for the <code>Verifier</code> to outsource the verification of the TLS session to a trusted <code>Notary</code> as explained <ahref="/intro.html#tls-verification-with-a-general-purpose-notary">here</a>.</p>
<p>As part of the TLSNotary protocol, the <code>Prover</code> creates authenticated commitments to the plaintext and has the <code>Notary</code> sign them without the <code>Notary</code> ever seeing the plaintext. This offers a way for the <code>Prover</code> to selectively prove the authenticity of arbitrary portions of the plaintext to an application-specific <code>Verifier</code> later.</p>
<p>In this Quick Start we will prove ownership of a Twitter account with TLSNotary's browser extension.
First we need to <ahref="#install">install</a> and configure a <ahref="#proxy">websocket proxy</a> and a <ahref="#notary-server">notary server</a>.</p>
<p>This quick start will help you get started with TLSNotary, both in native <ahref="rust.html">Rust</a> and in the <ahref="browser_extension.html">browser</a>.</p>
<h1id="tlsnotary-in-reacttypescript-with-tlsn-js"><aclass="header"href="#tlsnotary-in-reacttypescript-with-tlsn-js">TLSNotary in React/Typescript with <code>tlsn-js</code><aname="browser"></a></a></h1>
<p>In this Quick Start you will learn how to use TLSNotary in React/Typescript with <ahref="https://github.com/tlsnotary/tlsn-js"><code>tlsn-js</code></a> NPM module in the browser.</p>
<p>This Quick Start uses the react/typescript <ahref="https://github.com/tlsnotary/tlsn-js/tree/main/demo/react-ts-webpack">demo app in <code>tlsn-js</code></a>. The directory contains a webpack configuration file that allows you to quickly bootstrap a webpack app using <code>tlsn-js</code>.</p>
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
heeckhau