Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Zktls #94

Open
wants to merge 8 commits into
base: main
Choose a base branch
from
Open

Zktls #94

Show file tree
Hide file tree
Changes from 4 commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
f500515
First draft for a MPC-TLS vs zkTLS blog post
heeckhau Aug 23, 2024
e352e17
rewrite blog
heeckhau Aug 27, 2024
ea11743
take 3
heeckhau Aug 28, 2024
37e5bfd
TODOs
heeckhau Aug 28, 2024
f437317
Update blogs/202408/zktls.md
heeckhau Sep 19, 2024
a4ce80b
Update blogs/202408/zktls.md
heeckhau Sep 19, 2024
1b1de7c
Applied feedback
heeckhau Sep 20, 2024
edc27a1
more edits
heeckhau Sep 23, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
39 changes: 39 additions & 0 deletions blogs/202408/overview1.drawio
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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>
3 changes: 3 additions & 0 deletions blogs/202408/overview1.svg
View file
Open in desktop
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
56 changes: 56 additions & 0 deletions blogs/202408/overview2.drawio
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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>
3 changes: 3 additions & 0 deletions blogs/202408/overview2.svg
View file
Open in desktop
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
38 changes: 38 additions & 0 deletions blogs/202408/zktls.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,38 @@
# Does TLSNotary produce "proofs" or "attestations"?

Recently, we've seen an increasing use of the term ["zkTLS"](https://x.com/search?q=zktls). The "zk" prefix suggests a combination of TLS with zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument 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, we want to explain how TLSNotary achieves verifiable TLS sessions. Spoiler: TLSNotary's output is not a publicly verifiable proof; it is an attestation.


Before we dive 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—cooperate 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. On the server’s side, 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 what if a fourth or fifth party wants to verify the TLS session? They could repeat the process above to obtain their own cryptographic guarantees. However, in many cases, it’s more practical to delegate the TLS verification to a trusted party and rely on their attestations.
heeckhau marked this conversation as resolved.
Show resolved Hide resolved

## Proofs vs. Attestations

When we talk about **proofs** in cryptography, we 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 and allow anyone to verify the proof without needing to trust any specific party. These systems are highly desirable but unfortunately not always feasible.
heeckhau marked this conversation as resolved.
Show resolved Hide resolved

**Designated verifier** systems delegate verification to one verifier (or a coordinated group of verifiers). After successful verification, a verifier can **attest** to the data for other parties 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 knows the TLS session was authentic, so it can attest to it. However, the result is not something that everyone can independently verify without trust in the Verifier.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bit redundant with above


**Remark:** In the TLSNotary source code, the lines between a proof and an attestation can seem confusing. While TLSNotary generates something that is a proof to the Verifier, to anyone else, it is an attestation.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to unpack this sentence. But also my changes are only accurate from a high level pov. In the actual code, the Prover sends commitments to the Notary and the Notary attests to those commitments + adds some additional info to the attestation.
So, I sacrificed a bit of accuracy for the sake of giving a better mental image. It's a trade-off, feel free to not include this if you think this adds more confusion than clarity.

Suggested change
**Remark:** In the TLSNotary source code, the lines between a proof and an attestation can seem confusing. While TLSNotary generates something that is a proof to the Verifier, to anyone else, it is an attestation.
**Remark:** In the TLSNotary source code, the lines between a proof and an attestation can seem confusing. It is useful to have the following mental model. First, a Prover generates a proof to prove statements about the TLS connection data to a Verifier. Then, based on that proof, the Verifier issues an attestation.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would exclude this remark and instead we just fix this ambiguity


## Onchain Attestations

The Verifier cannot operate onchain, as it must be online simultaneously with both the Prover and the Server. However, the TLSNotary result can still be utilized onchain if the Verifier signs the output as an attestation. This attestation, however, is not a publicly verifiable proof. Since a Verifier could potentially sign anything, consumers of this information must trust the Verifier. While TLSNotary can be used to build oracles, it does not solve the **oracle problem**.
heeckhau marked this conversation as resolved.
Show resolved Hide resolved

## Conclusion

The term zkTLS is catchy and may sound appealing, but it’s important not to jump to conclusions. The "zk" prefix in zkTLS suggests public verifiability, which is not applicable to TLS. Therefore, it’s crucial to use the term "proof" cautiously in this context; in most cases, "attestation" is the more accurate term, especially when discussing the use of TLSNotary outputs onchain.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The term zkTLS is catchy and may sound appealing, but it’s important not to jump to conclusions.

This has a negative vibe. I was a bit snarky in my tweet about it, but we should maintain a matter-of-fact tone in TLSNotary publications.

The "zk" prefix in zkTLS suggests public verifiability

It doesn't. This reads as a normative statement

which is not applicable to TLS

It could be if TLS was modified

In general I think we should avoid taking shots at zkTLS and instead focus on providing clarifying information.