Zktls

blogs/202408/overview1.drawio

@@ -0,0 +1,39 @@
+<mxfile host="Electron" agent="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/24.7.5 Chrome/126.0.6478.183 Electron/31.3.0 Safari/537.36" version="24.7.5">
+  <diagram id="kcIGn_kX_1L25iIxUXLg" name="Page-1">
+    <mxGraphModel dx="2508" dy="1452" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="850" pageHeight="1100" math="0" shadow="0">
+      <root>
+        <mxCell id="0" />
+        <mxCell id="1" parent="0" />
+        <mxCell id="EZAqd18MQriHtEKbU3QA-1" value="TLS&lt;br&gt;Prover" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;shadow=1;fontStyle=1;connectable=1;" parent="1" vertex="1">
+          <mxGeometry x="200" y="260" width="80" height="80" as="geometry" />
+        </mxCell>
+        <mxCell id="EZAqd18MQriHtEKbU3QA-2" value="TLS&lt;br&gt;Server" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;shadow=1;fontStyle=1" parent="1" vertex="1">
+          <mxGeometry x="38" y="260" width="80" height="80" as="geometry" />
+        </mxCell>
+        <mxCell id="GdnXkJGOJiVmK7E47u4y-43" value="TLS&lt;br&gt;Verifier" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;shadow=1;fontStyle=1" parent="1" vertex="1">
+          <mxGeometry x="360" y="260" width="80" height="80" as="geometry" />
+        </mxCell>
+        <mxCell id="GdnXkJGOJiVmK7E47u4y-45" value="" style="endArrow=classic;startArrow=classic;html=1;rounded=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" parent="1" source="EZAqd18MQriHtEKbU3QA-2" target="EZAqd18MQriHtEKbU3QA-1" edge="1">
+          <mxGeometry width="50" height="50" relative="1" as="geometry">
+            <mxPoint x="350" y="490" as="sourcePoint" />
+            <mxPoint x="400" y="440" as="targetPoint" />
+          </mxGeometry>
+        </mxCell>
+        <mxCell id="GdnXkJGOJiVmK7E47u4y-46" value="TLS" style="whiteSpace=wrap;html=1;fillColor=none;strokeColor=none;fontSize=10;" parent="1" vertex="1">
+          <mxGeometry x="126.5" y="286" width="67.5" height="10" as="geometry" />
+        </mxCell>
+        <mxCell id="GdnXkJGOJiVmK7E47u4y-49" value="" style="endArrow=classic;html=1;rounded=0;startArrow=classic;startFill=1;exitX=1;exitY=0.5;exitDx=0;exitDy=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" parent="1" source="EZAqd18MQriHtEKbU3QA-1" target="GdnXkJGOJiVmK7E47u4y-43" edge="1">
+          <mxGeometry width="50" height="50" relative="1" as="geometry">
+            <mxPoint x="280" y="289" as="sourcePoint" />
+            <mxPoint x="360" y="289" as="targetPoint" />
+          </mxGeometry>
+        </mxCell>
+        <mxCell id="10" value="MPC-TLS" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];fontSize=10;labelBackgroundColor=none;" parent="GdnXkJGOJiVmK7E47u4y-49" vertex="1" connectable="0">
+          <mxGeometry x="-0.5071" relative="1" as="geometry">
+            <mxPoint x="20" y="-9" as="offset" />
+          </mxGeometry>
+        </mxCell>
+      </root>
+    </mxGraphModel>
+  </diagram>
+</mxfile>

blogs/202408/overview2.drawio

@@ -0,0 +1,56 @@
+<mxfile host="Electron" agent="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/24.7.5 Chrome/126.0.6478.183 Electron/31.3.0 Safari/537.36" version="24.7.5">
+  <diagram id="kcIGn_kX_1L25iIxUXLg" name="Page-1">
+    <mxGraphModel dx="1003" dy="581" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="850" pageHeight="1100" math="0" shadow="0">
+      <root>
+        <mxCell id="0" />
+        <mxCell id="1" parent="0" />
+        <mxCell id="EZAqd18MQriHtEKbU3QA-1" value="TLS&lt;br&gt;Prover" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;shadow=1;fontStyle=1;connectable=1;" parent="1" vertex="1">
+          <mxGeometry x="200" y="260" width="80" height="80" as="geometry" />
+        </mxCell>
+        <mxCell id="EZAqd18MQriHtEKbU3QA-2" value="TLS&lt;br&gt;Server" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;shadow=1;fontStyle=1" parent="1" vertex="1">
+          <mxGeometry x="38" y="260" width="80" height="80" as="geometry" />
+        </mxCell>
+        <mxCell id="58" value="" style="edgeStyle=none;html=1;" parent="1" source="GdnXkJGOJiVmK7E47u4y-43" target="32" edge="1">
+          <mxGeometry relative="1" as="geometry" />
+        </mxCell>
+        <mxCell id="GdnXkJGOJiVmK7E47u4y-43" value="TLS&lt;br&gt;Verifier" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;shadow=1;fontStyle=1" parent="1" vertex="1">
+          <mxGeometry x="360" y="260" width="80" height="80" as="geometry" />
+        </mxCell>
+        <mxCell id="GdnXkJGOJiVmK7E47u4y-45" value="" style="endArrow=classic;startArrow=classic;html=1;rounded=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" parent="1" source="EZAqd18MQriHtEKbU3QA-2" target="EZAqd18MQriHtEKbU3QA-1" edge="1">
+          <mxGeometry width="50" height="50" relative="1" as="geometry">
+            <mxPoint x="350" y="490" as="sourcePoint" />
+            <mxPoint x="400" y="440" as="targetPoint" />
+          </mxGeometry>
+        </mxCell>
+        <mxCell id="GdnXkJGOJiVmK7E47u4y-46" value="TLS" style="whiteSpace=wrap;html=1;fillColor=none;strokeColor=none;fontSize=10;" parent="1" vertex="1">
+          <mxGeometry x="126.5" y="286" width="67.5" height="10" as="geometry" />
+        </mxCell>
+        <mxCell id="GdnXkJGOJiVmK7E47u4y-49" value="" style="endArrow=classic;html=1;rounded=0;startArrow=classic;startFill=1;exitX=1;exitY=0.5;exitDx=0;exitDy=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" parent="1" source="EZAqd18MQriHtEKbU3QA-1" target="GdnXkJGOJiVmK7E47u4y-43" edge="1">
+          <mxGeometry width="50" height="50" relative="1" as="geometry">
+            <mxPoint x="280" y="289" as="sourcePoint" />
+            <mxPoint x="360" y="289" as="targetPoint" />
+          </mxGeometry>
+        </mxCell>
+        <mxCell id="10" value="MPC-TLS" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];fontSize=10;labelBackgroundColor=none;" parent="GdnXkJGOJiVmK7E47u4y-49" vertex="1" connectable="0">
+          <mxGeometry x="-0.5071" relative="1" as="geometry">
+            <mxPoint x="20" y="-9" as="offset" />
+          </mxGeometry>
+        </mxCell>
+        <mxCell id="32" value="Attestation&lt;br&gt;Verifier" style="ellipse;whiteSpace=wrap;html=1;aspect=fixed;shadow=1;fontStyle=1" parent="1" vertex="1">
+          <mxGeometry x="520" y="260" width="80" height="80" as="geometry" />
+        </mxCell>
+        <mxCell id="33" value="" style="endArrow=classic;html=1;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" parent="1" target="32" edge="1">
+          <mxGeometry width="50" height="50" relative="1" as="geometry">
+            <mxPoint x="440" y="299.71" as="sourcePoint" />
+            <mxPoint x="510" y="300" as="targetPoint" />
+          </mxGeometry>
+        </mxCell>
+        <mxCell id="57" value="Attest" style="edgeLabel;html=1;align=center;verticalAlign=middle;resizable=0;points=[];fillColor=none;labelBackgroundColor=none;" parent="33" vertex="1" connectable="0">
+          <mxGeometry x="-0.3267" y="1" relative="1" as="geometry">
+            <mxPoint x="15" y="-8" as="offset" />
+          </mxGeometry>
+        </mxCell>
+      </root>
+    </mxGraphModel>
+  </diagram>
+</mxfile>

blogs/202408/zktls.md

@@ -0,0 +1,46 @@
+# Does TLSNotary Produce "Proofs" or "Attestations"?
+Recently, the term ["zkTLS"](https://x.com/search?q=zktls) has become very popular on Crypto Twitter. But what does zkTLS mean? Does it simply refer to the use of Zero Knowledge cryptography, or is it an abbreviation of zk-SNARKs TLS (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge), implying that the protocol would be publicly verifiable?
+
+<blockquote class="twitter-tweet"><p lang="en" dir="ltr">Incalculable levels of public confusion caused by a catchy prefix <a href="https://t.co/2OSyWwHQqN">pic.twitter.com/2OSyWwHQqN</a></p>&mdash; sinu (@sinu_eth) <a href="https://twitter.com/sinu_eth/status/1827135565185401239?ref_src=twsrc%5Etfw">August 24, 2024</a></blockquote>
+<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
+
+To avoid confusion, this post explains how TLSNotary achieves verifiable TLS sessions. Spoiler: **TLSNotary does not produce publicly verifiable proofs. It provides a cryptographic proof only to the Verifier; to everyone else, it offers attestations**.
+
+Before diving deeper into TLSNotary, let’s first recap TLS itself.
+
+**TLS (Transport Layer Security)** is the protocol that underpins much of the secure communication on the Internet. It is the “s” in HTTPS. TLS ensures that data sent between a client and server is encrypted and remains private. However, unless the data is cryptographically signed at the source, traditional TLS doesn’t offer a straightforward way to prove to a third party what data was exchanged.
+
+![Overview](./overview1.svg)
+
+**TLSNotary** is a tool designed to solve this problem by implementing an **MPC-TLS (Multi-Party Computation TLS)** protocol. In TLSNotary, two parties—a Prover and a Verifier—collaborate to establish a TLS connection and retrieve authenticated data from a server. Through this collaboration, both parties receive cryptographic guarantees about the data’s authenticity and integrity. From the server’s perspective, this looks like a normal TLS session. TLSNotary also protects the privacy of the Prover (aka the "user"), but that is beyond the scope of this blog post.
+
+But can an external party **trustlessly** verify the data from a TLS connection? No, they cannot. Their only option is to act as a Verifier in the TLSNotary protocol to obtain their own cryptographic guarantees. However, in many cases, it’s more practical to delegate verification to a trusted party and rely on their attestations.
+
+## Proofs vs. Attestations
+
+In cryptography, **proofs** usually refer to something that is **publicly verifiable**—anyone with the proof can independently verify its validity without needing additional information. Publicly verifiable proofs are often associated with zk-SNARKs, which allow anyone to verify the proof without trusting a specific party. While these systems are highly desirable, they are not always feasible.
+
+**Designated-verifier** systems, on the other hand, delegate verification to one verifier (or a coordinated group of verifiers). After successful verification, a verifier can **attest** to the data for others by issuing a signed **attestation**. This approach requires trust in the designated verifier’s integrity.
+
+![Overview](./overview2.svg)
+
+In the case of MPC-TLS, the Verifier has cryptographic guarantees that the TLS session was authentic, allowing the Verifier to attest to it as the designated verifier. This is an attestation, not a publicly verifiable proof.
+
+All TLS-verifying protocols known to the TLSNotary team (and which do not modify the TLS protocol) are designated-verifier protocols.
+
+**Remark:** In the TLSNotary source code, the lines between a proof and an attestation can seem confusing. It is helpful to have the following mental model: first, the Prover generates a proof to demonstrate statements about the TLS connection data to the Verifier. Then, based on that proof, the Verifier issues an attestation.
+
+## On-Chain Attestations
+
+The Verifier cannot operate on-chain because it must be online simultaneously with both the Prover and the Server. However, an attestation can still be used on-chain. Since a Notary could potentially sign anything, consumers of this information must trust the Notary. While TLSNotary can be used to build blockchain oracles, it does not solve the **oracle problem**.
+
+For most off-chain applications, a designated verifier is a perfectly suitable solution. In traditional settings, delegating verification to a trusted party is common and practical. Off-chain, trust can be established through legal agreements, reputation, or regulatory frameworks, making attestations sufficient for many use cases.
+
+## The Ideal Solution
+
+In a perfect world, all data served by TLS servers would be cryptographically signed, making it **natively verifiable** without any extra complexity. This would eliminate the need for solutions like TLSNotary altogether. However, today, there is **little incentive** for most servers to cryptographically sign their data. Many servers prefer to avoid the added responsibility and potential liability that signing entails. As a result, we don’t yet live in a world where data is universally signed. Until that changes, **TLSNotary fills a crucial gap**, offering a practical, privacy-preserving, secure solution to verify data in the absence of widespread cryptographic signing.
+
+## Conclusion
+In summary, TLSNotary provides a reliable method for verifying TLS sessions, giving the Verifier cryptographic guarantees that the disclosed data is authentic. In most cases, especially in on-chain applications, verification is delegated to a designated verifier. This means that verification does not result in publicly verifiable proofs, such as zk-SNARKs, but instead produces signed attestations that vouch for the authenticity of the data exchanged over a TLS connection.
+
+While this model involves some trust assumptions, it remains a practical solution for many off-chain and on-chain use cases. TLSNotary bridges the gap in a world where native cryptographic signing of data is still uncommon, offering a valuable tool for ensuring data authenticity without compromising user privacy.