More conversions + added TODO notes

README.md

@@ -49,3 +49,8 @@ Front matter:
 https://docusaurus.io/docs/markdown-features#front-matter
 
 https://docusaurus.io/docs/api/plugins/@docusaurus/plugin-content-docs#markdown-front-matter
+
+
+Other Docusaurus websites at PSE:
+* MACI: https://github.com/privacy-scaling-explorations/maci/tree/dev/apps/website
+* MPC: https://github.com/privacy-scaling-explorations/mpc-framework-website

TODO.md

@@ -0,0 +1,17 @@
+TODO:
+* Design/Styling
+* drawio/svg cleanup
+* use cases
+* math in SVGs
+* social card
+* review
+* deployment flow
+* old links? https://docusaurus.io/docs/api/plugins/@docusaurus/plugin-client-redirects
+  * e.g. https://docs.tlsnotary.org/faq.html -> /docs/faq
+* README
+* Matomo tracking: https://github.com/karser/docusaurus-plugin-matomo/tree/main ?
+* check links
+* dark/light theme diagrams
+* rename repo landing-page -> website
+* archive old documentation website
+* What to do with drafts etc?

docs/Protocol/commit_strategy.md

@@ -25,4 +25,4 @@ The commitment strategies differ mainly in the number of committed ranges (`K`).
 | `Attestation` | Artifact signed by the `Notary` attesting to the authenticity of the plaintext from a TLS session | Constant     | `Attestation` only contains data that remains constant-sized regardless of `K`, e.g., the Merkle root of the commitments |
 | `Secret`      | Artifact containing secret data that correspond to commitments in `Attestation`                   | Linear       | `Secret` contains some data whose sizes scale linearly with `K`, e.g., a Merkle tree whose number of leaves equals `K`   |
 
-Using the default hash algorithm (i.e., BLAKE3), every additional range committed costs around 250 bytes of increment in the size of `Secret`. For more details, please visit this [Jupyter notebook](https://github.com/tlsnotary/docs-mdbook/blob/main/src/protocol/commit_strategy.ipynb).
+Using the default hash algorithm (i.e., BLAKE3), every additional range committed costs around 250 bytes of increment in the size of `Secret`. For more details, please visit this [Jupyter notebook](https://github.com/tlsnotary/landing-page/blob/docusaurus/docs/Protocol/commit_strategy.ipynb).

docs/faq.md

@@ -8,6 +8,59 @@ import TOCInline from '@theme/TOCInline';
 
 <TOCInline toc={toc} />
 
+## Generic Questions
+
+### Why is TLS not sufficient for data portability?
+
+TLS indeed signs a checksum (a Message Authentication Code, MAC) to check data integrity. However, in TLS, both the Server and the User use symmetric keys for data exchange, meaning the same key is employed for both encryption and decryption. This symmetric key usage allows a User to modify the data and retroactively compute a new checksum. As a result, this checksum alone is insufficient to guarantee data authenticity to a third party.
+
+### How can I verify the data origin in a TLSNotary proof?
+
+The proof contains the domain name and ephemeral public key of the server. A standard certificate verifier can verify whether the key is valid for the provided server name and that it chains to at least one trusted root certificate.
+
+### What does “privacy-centric” exactly mean for TLSNotary?
+
+TLSNotary does not compromise on privacy for performance reasons. It prioritizes user privacy in all its operations. The verifier only sees the data the prover decides to share.  
+
+If a generic notary is used to verify the TLS session, this notary only sees encrypted data and does not know what Server the Prover communicates with. The only information the Notary can see is: the time of the TLS-session, the length of the requests and responses, the number or round trips, and which cipher suite is used.
+
+### What is the overhead of using TLSNotary?
+
+The Multi-Party Computation (MPC) between the Prover and the Verifier requires significant bandwidth, orders of magnitude more than the Server's data size.
+
+### Can the server detect that a TLS session is being notarized?
+
+To the server, the TLS connection appears the same as any other connection. Only the User communicates with the Server, not the Notary or the Verifier. However, the timing patterns of TLS communication might have a different fingerprint, so through statistical analysis, specific identifying patterns might be uncovered.
+
+### Can TLSNotary be used for public data?
+
+Yes, but for public data, a less-resource-intensive man-in-the-middle approach is more economical since the privacy features of TLSNotary are superfluous in this scenario.
+
+### How can I inspect and verify a TLSNotary proof?
+
+The easiest way is to use the proof-of-concept [TLSNotary Explorer](https://explorer.tlsnotary.org).
+
+### Which TLS versions are supported?
+
+TLSNotary currently supports TLS 1.2. Support for TLS 1.3 is on the roadmap.
+
+### How can I use TLSNotary to verify data on-chain?
+
+At the moment the most practical way to verify data on-chain is to prove the data directly to an off-chain application-specific verifier. There are planned upgrades to make TLSNotary proofs directly verifiable on-chain.
+
+### Why can a verifier trust a TLSNotary proof?
+
+A TLSNotary proof is trustworthy because of its cryptographic integrity and its inclusion of an ephemeral key, allowing verifiers to confirm the data's origin from the claimed domain. This trust also hinges on the verifier's confidence in the data source (the server) and the validity of any redactions. Additionally, if the verifier did not conduct the TLS-MPC process themselves, they must trust in the notary's neutrality, ensuring it has not been influenced or compromised by the Prover.
+
+### How does TLSNotary differ from other TLS portability approaches?
+
+TLSNotary distinguishes itself with its dedication to open-source development and a strong emphasis on trustlessness. Developed as a public good without a business model, it fosters transparency and allows for community-driven improvements.  
+
+Unlike other solutions, TLSNotary is designed to prioritize trustlessness, thereby guaranteeing superior levels of privacy and security. It achieves this without depending on particular network assumptions or compromising on privacy or security to enhance performance. This strategy positions TLSNotary as the go-to choice for projects that place a high value on security and privacy in their TLS portability needs.
+
+
+## Protocol Questions
+
 ### Doesn't TLS allow a third party to verify data authenticity?
 
 No, it does not. TLS is designed to guarantee the authenticity of data **only to the participants** of the TLS connection. TLS does not have a mechanism to enable the server to "sign" the data.

docusaurus.config.ts

@@ -57,8 +57,8 @@ const config: Config = {
           rehypePlugins: [rehypeKatex],
           // Please change this to your repo.
           // Remove this to remove the "edit this page" links.
-          editUrl:
-            'https://github.com/facebook/docusaurus/tree/main/packages/create-docusaurus/templates/shared/',
+          // editUrl:
+          //   'https://github.com/facebook/docusaurus/tree/main/packages/create-docusaurus/templates/shared/',
           // Useful options to enforce blogging best practices
           onInlineTags: 'warn',
           onInlineAuthors: 'warn',
@@ -91,15 +91,17 @@ const config: Config = {
         src: 'img/logo/tlsn-logo-white-on-blue.png',
       },
       items: [
+        { to: '/about', label: 'About', position: 'left' },
+
+        { to: '/use_cases', label: 'Use Cases', position: 'left' },
         {
           type: 'docSidebar',
           sidebarId: 'tutorialSidebar',
           position: 'left',
-          label: 'Tutorial',
+          label: 'Documentation',
         },
-        { to: '/use_cases', label: 'Use Cases', position: 'left' },
+        { to: '/docs/faq', label: 'FAQ', position: 'left' },
 
-        { to: '/docs/intro', label: 'Documentation', position: 'left' },
         { href: 'https://tlsnotary.github.io/tlsn/tlsn_prover/', label: 'API', position: 'left' },
         { to: '/blog', label: 'Blog', position: 'left' },
         {
@@ -159,7 +161,7 @@ const config: Config = {
           ],
         },
       ],
-      copyright: `Copyright © ${new Date().getFullYear()} My Project, Inc. Built with Docusaurus.`,
+      copyright: `TLSNotary is a project of Privacy and Scaling Explorations, an Ethereum Foundation supported team.`,
     },
     prism: {
       theme: prismThemes.github,

research/README.md

@@ -0,0 +1,18 @@
+# TLSNotary Research
+
+This folder contains write-ups from research.
+
+## Typst
+
+The research write-ups are written in the [typst](https://github.com/typst/typst) markup language.
+
+You can install `typst` with:
+```sh
+cargo install --git https://github.com/typst/typst typst-cli
+```
+or `brew install typst` on MacOs.
+
+To compile the `typ`-files into `pdf`-files, run:
+```sh
+typst compile file.typ
+```

research/a2m_and_m2a.typ

@@ -0,0 +1,91 @@
+#set page(paper: "a4")
+#set par(justify: true)
+
+= M2A
+OT sender and receiver want to get an *additive* sharing $(y, overline(b))$ from a
+*multiplicative* sharing $(x, a)$. So the sender starts with $x$ and ends up with
+$y$ and the receiver starts with $a$ and ends up with $overline(b)$.
+
+They compute $y=a x + b arrow.l.r.double y - b = a x arrow.l.r.double y +
+overline(b) = a x$ in $n$ OTs, where $n$ is given by the bitsize of the field
+elements $y, x, a, b$. The receiver's inputs for every $i$-th OT are $x_i$ and
+his output is $y_i$. The sender's inputs are a linear combination of $a$ and
+$b_i$ and he outputs $b_i$.
+
+== Compute $y = a x + b$
+
+#align(center)[
+  #box[$P_R$ #v(4em)]
+  #box[$x_i$ #line(length: 2cm) #v(3em) $y_i$ #line(length: 2cm) #v(1em)]
+  #box[#square(size: 8em)[#v(3em) $"OT"_i$]]
+  #box[$k_i = (b_i, a+b_i)$ #line(length: 2.5cm) #v(3em) $b_i$ #line(length: 2.5cm) #v(1em)]
+  #box[$P_S$ #v(4em)]
+]
+
+=== *The OT sender $P_S$:*
++ Sample $n$ random field elements $b_i arrow.l \$$ so that $b = sum_(i = 0)^n 2^i b_i$
++ In each $i$-th OT: Send $k_i = (b_i, a + b_i)$ to $P_R$
++ Compute and output $overline(b) = - b = - sum_(i = 0)^n 2^i b_i$
+
+=== *The OT receiver $P_R$:*
++ Bit-decomposes $x = sum_(i = 0)^n 2^i x_i$
++ In each $i$-th OT: Depending on the bit of $x_i$ he receives $y_i =
+k_i^x_i$, which is
+  - $k_i^0 = b_i$ if $x_i = 0$
+  - $k_i^1 = a + b_i$ if $x_i = 1$
++ Compute and output $y = sum_(i = 0)^n 2^i k_i = a x + b$
+
+== Correctness Check
++ Repeat the whole M2A protocol for the same $x$ but with random $a_2, b_2$. We
+  now label $a_1 := a$ and $b_1 := b$, which are the original values from the
+  previously executed M2A protocol
++ $P_R$ sends $2$ random field elements $chi_1, chi_2$ to $P_S$
++ $P_S$ computes $a^* = chi_1 a_1 + chi_2 a_2$ and $b^* = chi_1 b_1 + chi_2 b_2$
+  and sends them to $P_R$.
++ $P_R$ checks that $ chi_1 y_1 + chi_2 y_2 = a^* x + b^*$ 
+
+= A2M
+OT sender and receiver want to get a *multiplicative* sharing $(y, overline(b))$
+from an *additive* sharing $(x, a)$. So the sender starts with $x$ and ends up
+with $y$ and the receiver starts with $a$ and ends up with $overline(b)$.
+
+They compute $y=(a + x) b arrow.l.r.double y  b^(-1) = a + x arrow.l.r.double y 
+overline(b) = a + x$ in $n$ OTs, where $n$ is given by the bitsize of the field
+elements $y, x, a, b$. The receiver's inputs for every $i$-th OT are $x_i$ and
+his output is $y_i$. The sender's inputs are a linear combination of $a_i$ and
+$b$ including a mask $m_i$ and he outputs $b$.
+
+== Compute $y = (a + x) b$
+
+#align(center)[
+  #box[$P_R$ #v(4em)]
+  #box[$x_i$ #line(length: 2cm) #v(3em) $y_i$ #line(length: 2cm) #v(1em)]
+  #box[#square(size: 8em)[#v(3em) *OT*]]
+  #box[$k_i = (a_i b + m_i, (a_i + 1) b + m_i)$ #line(length: 5cm) #v(3em) $b$ #line(length: 5cm) #v(1em)]
+  #box[$P_S$ #v(4em)]
+]
+
+
+=== *The OT sender $P_S$:*
++ Sample a random field element $b arrow.l \$$
++ Sample $n$ random field elements $m_i arrow.l \$$, with $sum_(i = 0)^n 2^i m_i = 0$
++ Bit-decomposes $a = sum_(i = 0)^n 2^i a_i$
++ In each $i$-th OT: Send $k_i = (a_i b + m_i, (a_i + 1) b + m_i)$ to $P_R$
++ Compute and output $overline(b) = b^(-1)$
+
+=== *The OT receiver $P_R$:*
++ Bit-decomposes $x = sum_(i = 0)^n 2^i x_i$
++ In each $i$-th OT: Depending on the bit of $x_i$ he receives $y_i =
+k_i^x_i$, which is
+  - $k_i^0 = a_i b + m_i$ if $x_i = 0$
+  - $k_i^1 = (a_i + 1) b + m_i$ if $x_i = 1$
++ Compute and output $y = sum_(i = 0)^n 2^i k_i = (a + x) b$
+
+== Correctness Check
++ Repeat the whole A2M protocol for the same $x$ but with random $a_2, b_2$. We
+  now label $a_1 := a$ and $b_1 := b$, which are the original values from the
+  previously executed A2M protocol
++ $P_R$ sends $2$ random field elements $chi_1, chi_2$ to $P_S$
++ $P_S$ computes $z^* = chi_1 a_1 b_1 + chi_2 a_2 b_2$ and $b^* = chi_1 b_1 + chi_2 b_2$
+  and sends them to $P_R$.
++ $P_R$ checks that $ chi_1 y_1 + chi_2 y_2 = b^* x + z^*$ 

research/ghash.typ

@@ -0,0 +1,203 @@
+#set page(paper: "a4")
+#set par(justify: true)
+#set text(size: 12pt)
+#show link: underline 
+
+
+= GHASH
+We want to compute GHASH MAC in 2PC which is of the form $sum_(k=1)^l H^k dot
+b_k$, where $H^k, b_k in "GF"(2^128)$. $H$ is split into additive shares for
+parties $P_A$ and $P_B$, such that $P_A$ knows $H_1$ and $P_B$ knows $H_2$ and
+$H = H_1 + H_2$. We now need to compute additive shares of powers of $H$.
+
+
+== Functionality $cal(F)_(H^l)$
+On input $(H_1)$ from $P_A$ and $H_2$ from $P_B$, the functionality returns
+all the  $H_(1,k)$ to $P_A$ and $H_(2,k)$ to $P_B$ for $k = 2...l$, such that 
+$H_(1,k) + H_(2,k) = (H_1 + H_2)^k$.
+
+
+== Protocols
+The following protocols all implement the functionality $cal(F)_(H^l)$. All
+protocols guarantee privacy for $H_1$ and $H_2$, i.e. there is no leakage to the
+other party. All protocols are implementations with unpredictable errors, that
+means correctness is *not* guaranteed in the presence of a malicious adversary
+deviating from the protocol. This is tolerable in the context of TLSNotary.
+
+We will assume that $l$, which determines the highest power $H^l$ both parties want
+to compute is a compile-time constant, so that it does not complicate protocol
+and performance analysis.
+
+When computing bandwidths of protocols, we assume that both parties have access
+to a sufficient number of pre-distributed random OTs. In order to simplify the
+computation of rounds, we assume that there is a sufficient number of
+pre-distributed ROLEs available. This means we ignore rounds for setting up
+ROLEs, because this can be batched and is needed for every protocol discussed
+here.
+
+The following table gives an overview about the different protocols:
+#align(center)[
+  #table(
+    columns: (auto, auto, auto, auto),
+    inset: 10pt,
+    align: horizon + center,
+    [*Protocol*], [*0 Issue*], [*Rounds*], [*Bandwidth*],
+
+    $Pi_"A2M"$,
+    "yes",
+    [
+      Off:  0\
+      On: 1.5\
+    ],
+    [
+      Off:  0\
+      On: 2.1 MB\
+    ],
+
+    $Pi_"ROLE + OLE"$,
+    "yes",
+    [
+      Off:  0.5\
+      On: 0.5\
+    ],
+    [
+      Off:  2.1 MB\
+      On: 128 bit\
+    ],
+
+    $Pi_"ROLE + OLE + Zero"$,
+    "no",
+    [
+      Off:  0.5\
+      On: 0.5\
+    ],
+    [
+      Off:  6.3 MB\
+      On: 256 bit\
+    ],
+
+    $Pi_"Beaver"$,
+    "no",
+    [
+      Off: 2\
+      On: 0.5\
+    ],
+    [
+      Off:  4.2 MB\
+      On: 128 bit\
+    ],
+)
+]
+
+=== A2M Protocol
+This protocol converts the additive shares $H_"1/2"$ into multiplicative shares
+$H_"1/2"^*$. Then both parties can locally computer higher powers
+$H_(1"/"2)^k^*$. Afterwards they convert these higher powers back into additive
+shares $H_("1/2", k)$.
+
+
+==== Protocol $Pi_"A2M"^l$
++ $P_A$ samples a random field element $r arrow.l "GF"(2^128)$.
++ Both parties call $cal(F)_"OLE" (r, H_2) -> (x, y)$. So $P_A$ knows $(r,
+  x)$ and $P_B$ knows $(H_2, y)$ and it holds that $r dot H_2 = x + y$.
++ $P_A$ defines $m = r dot H_1 + x$  and sends $m$ to $P_B$.
++ $P_A$ defines $H_1^* = r^(-1)$ and $P_B$ defines $H_2^* = m + y$.
++ Both parties locally compute $H_"1/2"^k^*$ for $k = 2...l$.
++ Both parties call $cal(F)_"OLE" (H_1^k^*, H_2^k^*) arrow.r (H_"1,k",
+H_"2,k")$ for $k = 2...l$.
++ $P_A$ outputs $H_"1,k"$ and $P_B$ outputs $H_"2,k"$.
+
+
+==== Performance Analysis
+The protocol has no offline communication, all the communication takes place
+online with 1.5 rounds (steps 2, 3, 6). The bandwidth of the protocol is $1026
+dot (128 + 128^2) + 1026 dot 128 + 128 approx 2.1 "MB"$.
+
+
+=== ROLE + OLE Protocol
+This protocol is nearly identical to the original GHASH construction from
+#link("https://eprint.iacr.org/2023/964")[XYWY23]. It only addresses the leakage
+of $H_(1"/"2)$ in the presence of a malicious adversary using $0$ as an input
+for $cal(F)_"OLE"$. Instead of using $cal(F)_"OLE"$ for all powers $k = 1...l$,
+we replace the first invocation of $cal(F)_"OLE"$ with $cal(F)_"ROLE"$ and then
+only use $cal(F)_"OLE"$ for $k = 2...l$. The 0 issue is still present for higher
+powers of $H$, but it can be fixed with the zero check.
+
+
+==== Protocol $Pi_"ROLE + OLE"^l$
++ Both parties call $cal(F)_"ROLE"$, so that $P_A$ gets $(a_1, x_1)$ and $P_B$
+  gets $(b_1, y_1)$.
++ $P_A$ defines $(r_A, r_1) := (a_1, x_1)$ and $P_B$ defines
+  $(r_B, r_2) := (b_1, y_1)$.
++ $P_A$ locally computes $r_A^k$ and $P_B$ locally computes $r_B^k$, for
+  $k=2...l$.
++ Both parties call $cal(F)_"OLE" (r_A^k, r_B^k) arrow.r (r_(1,k), r_(2,k))$, so
+  that $P_A$ gets $r_(1,k)$ and $P_B$ gets $r_(2,k)$ for $k = 2...l$.
++ $P_A$ opens $d_1 = H_1 - r_1$ and $P_B$ opens $d_2 = H_2 - r_2$, so that both
+  parties know $d = d_1 + d_2 = (H_1 + H_2) - (r_1 +r_2)$.
++ Define the polynomials $f_k$ over $"GF"(2^128)$, with
+  $f_k (x) := (d + x)^k = sum_(j=0)^k f_(j,k) dot x^j$. $P_A$ locally evaluates
+  and outputs $H_(1,k) = f_k (r_(1,k))$ and $P_B$ locally evaluates and outputs 
+  $H_(2,k) = f_k (r_(2,k))$ for $k = 1...l$.
+
+==== Analysis of 0 issue
+The OLEs of step 4 are still vulnerable to the 0 issue. This allows a malicious
+$P_A$ to learn all the $r_(2,k), k = 2...l$ and by that also all the $H_(2,k)$.
+$P_A$ can then output some arbitrary $s_k in bb(F)$ in step 6, which allows him to
+completely set all the $H^k$ for $k = 2...l$.
+
+However, he will not be able to set $r_(2,1)$, which means he cannot set $H^1$. He
+is also not able to remove it from $"MAC" = sum_(k=1)^l H^k dot b_k$, if for example
+some $b_k = b_(k')$, because he would need to know $r_(2,1)$ for that. So in
+other words if $"MAC" = "MAC"_1 + "MAC"_2$, then $"MAC"_2$ always contains some private,
+uncontrollable mask $H_2^1 dot b_1$, which prevents $P_A$ from completely
+controlling the $"MAC"$. Thus, fixing the 0 issue is optional.
+
+==== Performance Analysis
+
+- The protocol only needs 0.5 offline round (step 4) and 0.5 online round
+  (step 5). This holds even if the zero-check is applied.
+- The protocol has an upload/download size of 
+  - *Offline*: 
+    - *Without zero-check*: $1026 dot (128 + 128^2) + 1025 dot 128 approx 2.1 "MB"$
+    - *With zero-check*: Approximately 2-times overhead, so $approx 6.3 "MB"$
+  - *Online*: 
+    - *Without zero-check*: $128 "bit"$
+    - *With zero-check*: $256 "bit"$
+
+
+=== Beaver Protocol
+This protocol is nearly identical to the original GHASH construction from
+#link("https://eprint.iacr.org/2023/964")[XYWY23]. It only addresses the leakage
+of $H_(1"/"2)$ in the presence of a malicious adversary using $0$ as an input
+for $cal(F)_"OLE"$. Instead of using $cal(F)_"OLE"$ , we sample $r = r_1 + r_2$
+randomly and compute the higher powers of additive shares with
+$cal(F)_"Beaver"$. This protocol does not suffer from the 0 issue.
+
+
+==== Protocol $Pi_"Beaver"^l$
+
++ Both parties sample a random field element. $P_A$ samples $r_1 arrow.l
+  "GF"(2^128)$ and $P_B$ samples $r_1 arrow.l "GF"(2^128)$.
++ Both parties repeatedly call $cal(F)_"Beaver" (r_(1,k - 1), r_1, r_(2,k - 1),
+  r_2) -> (r_(1, k), r_(2, k))$ for $k = 2...l$.
++ $P_A$ opens $d_1 = H_1 - r_1$ and $P_B$ opens $d_2 = H_2 - r_2$, so that both
+  parties know $d = d_1 + d_2 = (H_1 + H_2) - (r_1 +r_2)$.
++ Define the polynomials $f_k$ over $"GF"(2^128)$, with
+  $f_k (x) := (d + x)^k = sum_(j=0)^k f_(j,k) dot x^j$. $P_A$ locally evaluates
+  and outputs $H_(1,k) = f_k (r_(1,k))$ and $P_B$ locally evaluates and outputs 
+  $H_(2,k) = f_k (r_(2,k))$ for $k = 1...l$.
+
+
+==== Performance Analysis
+
+- By using free-squaring in $"GF"(2^128)$ and batching calls to $cal(F)_"Beaver"$
+  the protocol needs 2 offline rounds (repeatedly step 2) and 0.5 online round
+  (step 3).
+- The protocol has an upload/download size of 
+  - *Offline*: $1025 dot (128 + 128^2) + 1025 dot 128 approx 2.1 "MB"$
+  - *Online*: $128 "bit"$
+
+
+
+

research/ole-flavors.typ

@@ -0,0 +1,132 @@
+#set page(paper: "a4")
+#set par(justify: true)
+#set text(size: 12pt)
+
+= Oblivious Linear Evaluation (OLE) flavors from random OT 
+Here we sum up different OLE flavors, where some of them are needed for
+subprotocols of TLSNotary. All mentioned OLE protocol flavors are
+implementations with errors, i.e. in the presence of a malicious adversary, he
+can introduce additive errors to the result. This means correctness is not
+guaranteed, but privacy is.
+
+== Functionality $cal(F)_"ROT"$
+*Note*: In the literature there are different flavors of random OT, depending on
+if the receiver can choose his input or not. Here we that assume the receiver
+has a choice.
+
+Define the functionality $cal(F)_"ROT"$:
+- The sender $P_A$ receives the random tuple $(t_0, t_1)$, where $t_0, t_1$ are
+  $kappa$-bit messages.
+- The receiver $P_B$ inputs a bit $x$ and receives the corresponding $t_x$.
+
+== Random OLE
+=== Functionality $cal(F)_"ROLE"$
+Define the functionality $cal(F)_"ROLE"$ where
+- $P_A$ receives $(a, x)$
+- $P_B$ receives $(b, y)$
+such that $ y = a dot b + x$
+
+=== Protocol $Pi_"ROLE"$
++ $P_B$ randomly samples $d arrow.l bb(F)$ and $f arrow.l bb(F)$.
++ $P_A$ randomly samples $c arrow.l bb(F)$ and $e arrow.l bb(F)$.
++ For each $i = 1, ... , l$  where $l = |f|$: Both parties call
+  $cal(F)_"ROT" (f)$, so $P_A$ knows $t_0^i, t_1^i$ and $P_B$ knows $t_(f_i)$.
++ $P_A$ sends $e$ and $u_i = t_(i,0) - t_(i,1) + c$ to $P_B$.
++ $P_B$ defines $b = e + f$ and sends $d$ to $P_A$.
++ $P_A$ defines $a = c + d$ and outputs
+  $x = sum 2^i t_(i,0) - a dot e$
++ $P_B$ computes $ y_i 
+  &= f_i (u_i + d) + t_(i,f_i) \
+  &= f_i (t_(i,0) - t_(i,1) + c + d) + t_(i,f_i) \
+  &= f_i dot a + t_(i,0) $
+  and outputs $y = 2^i y_i$
++ Now it holds that $y = a dot b + x$.
+
+== Vector OLE
+=== Functionality $cal(F)_"VOLE"$
+Define the functionality $cal(F)_"VOLE"$ which maintains a counter $k$ and
+which allows to call an $"Extend"_k$ command multiple times.
+- When calling $"Initialize"$, $P_B$ inputs a field element $b$. This sets up the
+  functionality for subsequent calls to $"Extend"_k$.
+- When calling $"Extend"_k$: $P_A$ receives $(a_k, x_k)$ and $P_B$ receives
+  $y_k$.
+
+such that $ y_k = a_k dot b + x_k$
+
+=== Protocol $Pi_"VOLE"$
+*Note*: This is the $Pi_"COPEe"$ construction from KOS16.
++ Initialization:
+  - $P_B$ chooses some field element $b$.
+  - Both parties call $cal(F)_"ROT" (b)$, so $P_A$ knows
+    $t_0^i, t_1^i$ and $P_B$ knows $t_(b_i)$.
+  - With some PRF define: $s_(i,0)^k := "PRF"(t^i_0, k)$, $s_(i,1)^k :=
+    "PRF"(t^i_1, k)$
+  
++ $"Extend"_k$: This can be batched or/and repeated several times.
+  - $P_A$ chooses some field element $a_k$ and sends
+    $u_i^k = s_(i,0)^k - s_(i,1)^k + a_k$ to $P_B$.
+  - $P_A$ outputs $x_k = sum 2^i s_(i,0)^k$
+  - $P_B$ computes $ y^k_i 
+    &= b_i dot u^k_i + s_(i,f_i)^k \
+    &= b_i (s_(i,0)^k - s_(i,1)^k + a_k) + s_(i,f_i)^k \
+    &= b_i dot a_k + s_(i,0)^k $
+    and outputs $y_k = 2^i y^k_i$
+
++ Now it holds that $y_k = a_k dot b + x_k$.
+
+
+== Random Vector OLE
+=== Functionality $cal(F)_"RVOLE"$
+Define the functionality $cal(F)_"RVOLE"$ which maintains a counter $k$ and
+which allows to call an $"Extend"_k$ command multiple times.
+- When calling $"Initialize"$, $P_B$ receives a field element $b$. This sets up
+  the functionality for subsequent calls to $"Extend"_k$.
+- When calling $"Extend"_k$: $P_A$ receives $(a_k, x_k)$ and $P_B$ receives
+  $y_k$.
+
+such that $ y_k = a_k dot b + x_k$
+
+=== Protocol $Pi_"RVOLE"$
++ Initialization:
+  - $P_B$ chooses some field element $f$.
+  - Both parties call $cal(F)_"ROT" (f)$, so $P_A$ knows
+    $t_0^i, t_1^i$ and $P_B$ knows $t_(f_i)$.
+  - $P_A$ sends $e$ to $P_B$ and $P_B$ defines $b = e + f$.
+  - With some PRF define: $s_(i,0)^k := "PRF"(t^i_0, k)$, $s_(i,1)^k :=
+    "PRF"(t^i_1, k)$
+  
++ $"Extend"_k$: This can be batched or/and repeated several times.
+  - $P_A$ samples randomly $c_k arrow.l bb(F)$ and
+    $P_B$ samples randomly $d_k arrow.l bb(F)$.
+  - $P_A$ sends $u_i^k = s_(i,0)^k - s_(i,1)^k + c_k$ to $P_B$. 
+  - $P_B$ sends $d_k$ to $P_A$.
+  - $P_A$ defines $a_k = c_k + d_k$ and outputs
+    $x_k = sum 2^i s_(i,0)^k - a_k dot e$
+  - $P_B$ computes $ y^k_i 
+    &= f_i (u^k_i + d_k) + s_(i,f_i)^k \
+    &= f_i (s_(i,0)^k - s_(i,1)^k + c_k + d_k) + s_(i,f_i)^k \
+    &= f_i dot a_k + s_(i,0)^k $
+    and outputs $y_k = 2^i y^k_i$
+
++ Now it holds that $y_k = a_k dot b + x_k$.
+
+
+== OLE from random OLE
+=== Functionality $cal(F)_"OLE"$
+Define the functionality $cal(F)_"OLE"$. After getting input $a$ from $P_A$ and $b$
+from $P_B$ return $x$ to $P_A$ and $y$ to $P_B$ such that $y = a dot b + x$.
+
+=== Protocol $Pi_"OLE"$
+Both parties have access to a functionality $cal(F)_"ROLE"$, and call
+$"Extend"_k$, so $P_A$ receives $(a'_k, x'_k)$ and $P_B$ receives $(b'_k, y'_k)$.
+Then they perform the following derandomization:
+- $P_A$ sends $u_k = a_k + a'_k$ to $P_B$.
+- $P_B$ sends $v_k = b_k + b'_k$ to $P_A$.
+- $P_A$ outputs $x_k = x'_k + a'_k dot v_k$.
+- $P_B$ outputs $y_k = y'_k + b_k dot u_k$.
+
+Now it holds that $ y_k - x_k
+&= (y'_k + b_k dot u_k) - (x'_k + a'_k dot v_k) \
+&= (y'_k + b_k dot (a_k + a'_k)) - (x'_k + a'_k dot (b_k + b'_k)) \
+&= a_k dot b_k
+$

research/ole-zero-check.typ

@@ -0,0 +1,99 @@
+#set page(paper: "a4")
+#set par(justify: true)
+#set text(size: 12pt)
+
+= Zero Check for Oblivious Linear Evaluation 
+
+In many subprotocols of TLSNotary we use OLEs to convert shares of a product into
+shares of a sum. We recall the definition of the functionality:
+
+=== Functionality $cal(F)_"OLE"$
+Define the functionality $cal(F)_"OLE"$. After getting input $a$ from $P_A$ and $b$
+from $P_B$ return $x$ to $P_A$ and $y$ to $P_B$ such that $y = a dot b + x$.
+
+Problems arise in the presence of a malicious adversary, who inputs $0$ into the
+protocol, because now $y = x$, which means that privacy for the honest party's
+output is no longer guaranteed.
+
+To address this shortcoming both parties can run the following protocol, which
+allows an honest party to detect an input of $0$. Without loss of generality
+let's assume $P_B$ is honest and wants to check if $P_A$ used a 0 input. The
+protocol can be repeated with roles swapped, to also check that $P_B$ was honest. 
+Note that these executions can be batched.
+
+=== Protocol $Pi_"OLE-Zero"$
++ $P_A$ chooses some OLE input $a_k$ and $P_B$ chooses $b_k$ for $k = 1...l$.
+  These are the base OLEs we want to check for 0 input of $P_A$.
++ Both parties call $cal(F)_"ROLE" -> (a_0, b_0), (x_0, y_0)$. This is needed as
+  a mask later.
++ $P_A$ sets $a_(k + 1) := a_(k - l)^(-1)$ , and $P_B$ sets $b_(k + 1) := y_(k - l)$ for
+  $k = l...2l$.
++ Both parties call $cal(F)_"OLE" (a_k, b_k) -> (x_k, y_k)$ for
+  $k = 1...(2l + 1)$. 
++ $P_A$ computes $ s = sum_(k = 0)^l - x_k dot a_k^(-1) + sum_(k = l + 1)^(2l +
+  1) - x_k$ and sends $s$ to $P_B$.
++ $P_B$ checks that $sum_(k = 0)^l b_k  = s + sum_(k = l + 1)^(2l + 1) y_k $. If
+  this does not hold $P_B$ aborts.
+
+=== Intuition
++ We notice that a linear function has an inverse: $ y(x) &= m x + n \
+  y^(-1)(x) &= 1/m x - 1/m n $ such that $y^(-1)(y(x)) = x$. So if we have some
+  value $x_0$ and plug it in into $y(x)$ we get $y(x_0) = y_0$. Then the inverse
+  function gives us back $y^(-1)(y_0) = x_0$.
++ Having a function $y(x) = n$, is a constant function. This function does not
+  have an inverse, because we cannot solve for $x$. So there is no way to get
+  back from $y_0 arrow.r x_0$. But this is the exact thing what happens when
+  some of the parties $P_(A"/"B)$ inputs 0 into the OLE. Maybe we can exploit
+  this to construct some check.
++ To have an easy example, we now look at a single OLE, but it also works for an
+  arbitrary number. So we want to come up with a check for a single
+  $cal(F)_"OLE" (a_0, b_0) -> (x_0, y_0)$. We assume now $P_B$ wants to check if $P_A$
+  did input $a_0 = 0$ into this OLE. So $P_A$ inputs $a_0$ and gets $x_0$, and $P_B$
+  inputs $b_0$ and gets $y_0$, such that $y_0 = a_0 b_0 + x_0$. Notice, how we have the
+  analogy to the linear function. We now have $y(b)$, $P_A$ being the function
+  provider, defining the function with slope $a_0$ and offset $x_0$. $P_B$ is the
+  evaluator, plugging in $b_0$ into $y(b)$ and getting $y_0$.
++ $P_A$ now has to pass a check. He is required to invert the function, which
+  gives him $ y^(-1) (b) = 1/a b - 1/a x $
+  Now the problem is that when trying to do an OLE with this inverse function 
+  $P_A$ can only invert the slope $a_1$ but not the offset $x_1$ since this is
+  the output of the OLE for him. But what he can do is calculate the difference
+  and send this as a correction to $P_B$. $P_B$ will input his output from the
+  OLE before and expect to get his original input (including a correction term),
+  since they call the inverse function.
+
+  So both parties will now call the inverse OLE. $P_A$ will input
+  $a_1 = a_0^(-1)$ and $P_B$ will input $b_1 = y_0$, such that
+  $ cal(F)_"OLE" (a_1, b_1) arrow.r (x_1, y_1) =
+  cal(F)_"OLE" (a_0^(-1), y_0) arrow.r (x_1, y_1)$. So the equation will be
+  $ y_1 = 1/a_0 y_0 + x_1 $ Using that $y_0 = a_0 b_0 + x_0$, we get
+  $ y_1 = b_0 + x_0 / a_0 + x_1 $
+  In other words $P_B$ will get $y_1$ as an output. $P_A$ will send him the
+  correction term $s = -x_0/a_0 - x_1$ and $P_B$ will check that $y_1 + s =
+  b_0$.
++ The last thing we have to make sure is that $P_B$ cannot abuse this check
+  to get some information about the inputs and outputs of $P_A$. For example,
+  when $P_B$ plugs in a $b_1 eq.not y_0$ he would learn another point on the
+  inverse function, not belonging to the original point. He can easily do the
+  math and arrive at
+  $
+    x_0 &= (b_0 b_1 -y_0 (y_1 + s)) / (b_0 - y_1 - s) \ 
+    a_0 &= (y_0 - x_0) / b_0 \
+    a_1 &= 1 / a_0 \
+    x_1 &= - x_0 / a_0 - s
+  $
+
+  Since $P_B$ knows $y_0, y_1, b_0, b_1, s$ this would totally leak the inputs
+  and outputs of $P_A$.
++ We address this by introducing a ROLE which works as a mask for the correction
+  term. $P_A$ and $P_B$ call $cal(F)_"ROLE" arrow.r (a_2, x_2), (b_2, y_2)$ and
+  then the inverse OLE for this ROLE (note this has to be an OLE because it is
+  chosen input) $ cal(F)_"OLE" (a_3, b_3) arrow.r (x_3, y_3) = cal(F)_"OLE"
+  (a_2^(-1), y_2) arrow.r (x_3, y_3)$. Then instead of sending $s = -x_0 / a_0 -
+  x_1$, $P_A$ will send $s = -x_0 / a_0 - x_1 -x_2 / a_2 - x_3$ and $P_B$ will
+  check that $y_1 + y_3 + s = b_0 + b_2$. Note that a single ROLE is enough to
+  mask the correction term for an arbitrary amount of OLEs, not just 1 like in
+  this example.
+
+
+

src/pages/about.md

@@ -0,0 +1,33 @@
+---
+title: About
+---
+## Who we are
+    
+TLSNotary is an open-source protocol developed by the **Privacy and Scaling Exploration (PSE)** research lab of the Ethereum Foundation.
+
+TLSNotary is not a new project; in fact, it has been around for **more than a decade**. In 2022, TLSNotary was rebuilt from the ground up in **Rust** incorporating state-of-the-art cryptographic protocols. This renewed version of the TLSNotary protocol offers enhanced security, privacy, and performance.
+
+## How it works
+
+TLSNotary is a protocol which allows people to export data from any web application and prove facts about it to a third-party in a privacy-preserving way by leveraging secure multi-party computation (MPC) to authenticate data communicated between a Prover and a TLS-enabled web server.
+
+![](/img/tlsnotary-diagram.svg)
+
+
+### Step 1: Multiparty TLS Request"
+
+The Prover requests data from a Server over TLS. The verifier cooperates in secure and privacy-preserving multi-party computation (MPC). This cooperation guaranties that the Prover can not cheat and allows the Verifier to check the authenticity of the data in step 3.",
+
+### Step 2: Selective Disclosure",
+
+The Prover selectively discloses the data to the Verifier by redacting sensitive information prior to sharing it. Selective disclosure may involve simple redactions, or more advanced techniques such as a zero-knowledge proofs that can prove properties of redacted data without revealing the data itself.
+
+### "Step 3: Data Verification"
+
+The Verifier verifies that the prover did not tamper with the data and also verifiers the data origin, by inspecting the Server certificate through trusted certificate authorities (CAs). The Verifier can now make assertions about the non-redacted content of the transcript.
+
+## Get involved
+
+An alpha version of the TLSNotary protocol is available for testing. We welcome folks to start playing around with it, including trying to break it!
+
+Both codebases are 100% Rust and compile to WASM targets with an eye on deployment into browser environments. All our code is and always will be open source! Dual-licensed under Apache 2 and MIT, at your choice.\n\nWe've invested effort into making sure our code is modular and capable of evolving. We hope that others may find some of the components independently interesting and useful. Contributions are welcome!

src/pages/index.tsx

@@ -17,6 +17,9 @@ function HomepageHeader() {
           {siteConfig.title}
         </Heading>
         <p className="hero__subtitle">{siteConfig.tagline}</p>
+        <div className="">
+          <p>TLSNotary is an open-source protocol that can verify the authenticity of TLS data while protecting privacy. If you're looking for a way to make data portable without compromising on security, check out the protocol and integrate it into your applications!</p>
+        </div>
         <div className={styles.buttons}>
           <Link
             className="button button--secondary button--lg"
@@ -45,7 +48,17 @@ export default function Home(): ReactNode {
       description="Description will go into a meta tag in <head />">
       <HomepageHeader />
       <main>
-        <HomepageFeatures />
+        <section className={styles.introduction}>
+          <div className="container">
+            <h2 className={styles.borderBlue}>Why use TLSNotary?</h2>
+            <p>TLS (Transport Layer Security), also known as the "s" in "https" 🔐, can secure communication between a server and a user. But what if you want to credibly share data with others without compromising security, privacy, or control?
+            </p>
+            <p>TLSNotary solves this by adding a Verifier to the TLS connection using secure Multi-Party Computation (MPC). MPC provides cryptographic guarantees, allowing the Verifier to authenticate the TLS transcript without requiring external trust or revealing the complete data to anyone. TLSNotary can sign (aka notarize) data and make it portable in a privacy preserving way.
+            </p>
+            <p>With TLSNotary, users are in full control over the data they choose to share.
+            </p>
+          </div>
+        </section>
       </main>
     </Layout>
   );

src/pages/use_cases.md

@@ -3,7 +3,39 @@ title: my hello page title
 description: my hello page description
 hide_table_of_contents: true
 ---
+import styles from './index.module.css';
+import Link from '@docusaurus/Link';
 
 # Use cases
 
-TODO
+You can use TLSNotary for:
+
+- **Identity Verification**: Verify your name, age, or citizenship from online government services.
+
+- **Reputation Verification**: Verify user experience or trustworthiness on platforms like Airbnb, Uber, Strava.
+
+- **Real World Asset Ownership Verification**: Confirm ownership of tangible assets (e.g., vehicles, real estate).
+
+- **Health Information Verification**: Verify personal health records from platforms like MyHealth, HealthVault, etc.
+
+- **Account Ownership Verification**: Confirm control over online accounts (e.g., Google, Microsoft, Apple, Twitter).
+
+- **Financial Verification**: Verify your financial standing or prove financial dealings from your bank or other services.
+
+- **User Restriction Verification**: Confirm if a user is barred from accessing specific applications or services.
+
+...and more!
+
+<!-- TODO: Projects using TLSNotary -->
+
+## Share what you're building with TLSNotary
+
+Are you using TLSNotary in your project? Reach out on Discord and tell us about your work!
+
+<div className={styles.buttons}>
+    <Link
+    className="button button--secondary button--lg"
+    to="https://discord.gg/9XwESXtcN7">
+        Join our Discord
+    </Link>
+</div>