-
Notifications
You must be signed in to change notification settings - Fork 12
Zktls #94
base: main
Are you sure you want to change the base?
Zktls #94
Changes from 4 commits
f500515
e352e17
ea11743
37e5bfd
f437317
a4ce80b
1b1de7c
edc27a1
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
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<br>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<br>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<br>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> |
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<br>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<br>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<br>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<br>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> |
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>— 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. | ||||||
|
||||||
 | ||||||
|
||||||
**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. | ||||||
|
||||||
## 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. | ||||||
|
||||||
 | ||||||
|
||||||
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. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
Suggested change
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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.
It doesn't. This reads as a normative statement
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. |
Uh oh!
There was an error while loading. Please reload this page.