From f500515a0ea3c0966feca3f2a18cdaa7bf50c1be Mon Sep 17 00:00:00 2001 From: Hendrik Eeckhaut Date: Fri, 23 Aug 2024 15:12:58 +0200 Subject: [PATCH 1/8] First draft for a MPC-TLS vs zkTLS blog post --- blogs/202408/zktls.md | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) create mode 100644 blogs/202408/zktls.md diff --git a/blogs/202408/zktls.md b/blogs/202408/zktls.md new file mode 100644 index 0000000..c75f0cc --- /dev/null +++ b/blogs/202408/zktls.md @@ -0,0 +1,39 @@ +# Terminology Matters: Why We Use MPC-TLS Attestations and Not zkTLS "Proofs" + +**TL;DR:** +Terminology matters, especially in the world of cryptography. In this post, we explain why **MPC-TLS attestations** are the preferred choice over *zkTLS "proofs"* within the context of TLSNotary. zkTLS is a misnomer. + + +## TLS and TLSNotary: A Brief Overview + +**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, both the Prover and the Verifier cooperate to establish a TLS connection, ensuring that the data exchanged is authentic. 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 is gaining popularity among developers for its ability to provide verifiable evidence of interactions with a server, ensuring that the data remains trustworthy for both parties involved. TLSNotary also protects the privacy of the user, but that is beyond the scope of this blog post. + +## MPC or ZK? What’s the Difference? + +**MPC (Multi-Party Computation)** and **ZK (Zero-Knowledge)** are two cryptographic techniques often mentioned together, but they serve different purposes. + +**MPC** allows multiple parties to jointly compute a function over their inputs while keeping those inputs private. In the context of TLSNotary, MPC is used to perform a TLS handshake so both the Prover and the Verifier each have a key share. They need to cooperate to encrypt requests and decrypt responses with TLS's symmetric encryption. Through this collaboration, both parties receive cryptographic guarantees about the data’s authenticity and integrity. Additionally, during the MPC-TLS process, the Verifier only sees encrypted information, thus protecting the user’s privacy. + +**ZK proofs** enable one party to prove to another that a statement is true without revealing any other information. Prefixing "zk" to a term is fashionable nowadays; however, **zkTLS** as a term is a misnomer. **True zero-knowledge proofs of TLS sessions are not feasible today**—TLS relies on interactive, stateful communication, which is too complex to fit into zk circuits. + +TLSNotary uses ZK technology, but the main driver is MPC. + +## Attestations vs. Proofs + +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. This is the strength of zero-knowledge proofs in general: they are self-contained and can be verified by anyone, anywhere. + +On the other hand, an **attestation** is a statement made by one party to another about something that has occurred, and it often requires some level of trust in the party making the statement. In the case of MPC-TLS, the Verifier knows the TLS session was authentic, so it can attest to it. But the result is not something that everyone can independently verify without trust in the Verifier. + +**Remark:** In the TLSNotary source code, the lines between a proof and an attestation blur. While the process generates something that is a proof to the Verifier, to anyone else, it is an attestation; they have to trust the Verifier’s claim about what happened. + +## Onchain Attestations + +When dealing with blockchain and onchain attestations, the Verifier cannot run onchain. This means that the attestation put onchain by the Prover (or the Verifier) is not a standalone proof but an attestation. Consumers of this information need to trust that there wasn't any collusion between the Prover and Verifier. TLSNotary can be used to build oracles, but it does not solve the **oracle problem**. + +## Conclusion + +In the end, terminology matters because it shapes our understanding and expectations of the technology we use. The term zkTLS might sound appealing, but it is inaccurate. TLS sessions are not proven using zero-knowledge proofs. Instead, TLSNotary favors the term **MPC-TLS attestations**. + +By choosing the right terminology and understanding the implications of these choices, we can build more robust, efficient, and trustworthy cryptographic systems. From e352e17cb21a0a60b97aeab94697e4255df70e30 Mon Sep 17 00:00:00 2001 From: Hendrik Eeckhaut Date: Tue, 27 Aug 2024 14:47:34 +0200 Subject: [PATCH 2/8] rewrite blog --- blogs/202408/zktls.md | 32 +++++++++++++++----------------- 1 file changed, 15 insertions(+), 17 deletions(-) diff --git a/blogs/202408/zktls.md b/blogs/202408/zktls.md index c75f0cc..e27c116 100644 --- a/blogs/202408/zktls.md +++ b/blogs/202408/zktls.md @@ -1,39 +1,37 @@ # Terminology Matters: Why We Use MPC-TLS Attestations and Not zkTLS "Proofs" -**TL;DR:** -Terminology matters, especially in the world of cryptography. In this post, we explain why **MPC-TLS attestations** are the preferred choice over *zkTLS "proofs"* within the context of TLSNotary. zkTLS is a misnomer. - +We are seeing more and more occurrences of the term "zkTLS" [TODO: add links to Twitter]. The TLSNotary team believes this term is poorly chosen because it seems to imply that TLS sessions have all the typical properties of zero-knowledge proofs. In this blog post, we explain why we prefer the term **MPC-TLS Attestations** and choose not to use **zkTLS "Proofs."** ## TLS and TLSNotary: A Brief Overview -**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. +Before we dive into zkTLS vs. MPC-TLS, let’s first recap TLS and TLSNotary. -**TLSNotary** is a tool designed to solve this problem by implementing an **MPC-TLS (Multi-Party Computation TLS)** protocol. In TLSNotary, both the Prover and the Verifier cooperate to establish a TLS connection, ensuring that the data exchanged is authentic. 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 is gaining popularity among developers for its ability to provide verifiable evidence of interactions with a server, ensuring that the data remains trustworthy for both parties involved. TLSNotary also protects the privacy of the user, but that is beyond the scope of this blog post. +**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. -## MPC or ZK? What’s the Difference? +[TODO: add TLSNotary diagram here later] -**MPC (Multi-Party Computation)** and **ZK (Zero-Knowledge)** are two cryptographic techniques often mentioned together, but they serve different purposes. +**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. -**MPC** allows multiple parties to jointly compute a function over their inputs while keeping those inputs private. In the context of TLSNotary, MPC is used to perform a TLS handshake so both the Prover and the Verifier each have a key share. They need to cooperate to encrypt requests and decrypt responses with TLS's symmetric encryption. Through this collaboration, both parties receive cryptographic guarantees about the data’s authenticity and integrity. Additionally, during the MPC-TLS process, the Verifier only sees encrypted information, thus protecting the user’s privacy. +TLSNotary is gaining popularity among developers for its ability to provide verifiable evidence of interactions with a server, ensuring that the data remains trustworthy for both parties involved. TLSNotary also protects the privacy of the user, but that is beyond the scope of this blog post. -**ZK proofs** enable one party to prove to another that a statement is true without revealing any other information. Prefixing "zk" to a term is fashionable nowadays; however, **zkTLS** as a term is a misnomer. **True zero-knowledge proofs of TLS sessions are not feasible today**—TLS relies on interactive, stateful communication, which is too complex to fit into zk circuits. +## Proofs vs. Attestations -TLSNotary uses ZK technology, but the main driver is MPC. +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 zero-knowledge proofs (ZKPs) and allow anyone to verify the proof without needing to trust any specific party. These systems are highly desirable but unfortunately not always feasible. -## Attestations vs. Proofs +**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. -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. This is the strength of zero-knowledge proofs in general: they are self-contained and can be verified by anyone, anywhere. +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. -On the other hand, an **attestation** is a statement made by one party to another about something that has occurred, and it often requires some level of trust in the party making the statement. In the case of MPC-TLS, the Verifier knows the TLS session was authentic, so it can attest to it. But the result is not something that everyone can independently verify without trust in the Verifier. +**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 blur. While the process generates something that is a proof to the Verifier, to anyone else, it is an attestation; they have to trust the Verifier’s claim about what happened. +[TODO embed https://x.com/sinu_eth/status/1827135565185401239 here] ## Onchain Attestations -When dealing with blockchain and onchain attestations, the Verifier cannot run onchain. This means that the attestation put onchain by the Prover (or the Verifier) is not a standalone proof but an attestation. Consumers of this information need to trust that there wasn't any collusion between the Prover and Verifier. TLSNotary can be used to build oracles, but it does not solve the **oracle problem**. +The Verifier cannot run onchain. The Verifier must be online simultaneously with both the Prover and the Server. This means that the attestation put onchain by the Prover (or the Verifier) is not a standalone proof but an attestation. And because an attester could attest to (or sign) whatever it wants, consumers of this information need to trust the attester. TLSNotary can be used to build oracles, but it does not solve the **oracle problem**. ## Conclusion -In the end, terminology matters because it shapes our understanding and expectations of the technology we use. The term zkTLS might sound appealing, but it is inaccurate. TLS sessions are not proven using zero-knowledge proofs. Instead, TLSNotary favors the term **MPC-TLS attestations**. +In the end, terminology matters because it shapes our understanding and expectations of the technology we use. -By choosing the right terminology and understanding the implications of these choices, we can build more robust, efficient, and trustworthy cryptographic systems. +The term zkTLS might sound appealing, but it is confusing. The "zk" prefix in zkTLS seems to imply public verifiability, which is not the case. This is the reason we prefer **MPC-TLS Attestations** instead. \ No newline at end of file From ea117431731266f9acfdacbf046d086233d73485 Mon Sep 17 00:00:00 2001 From: Hendrik Eeckhaut Date: Wed, 28 Aug 2024 11:57:09 +0200 Subject: [PATCH 3/8] take 3 --- blogs/202408/overview1.drawio | 39 ++++++++++++++++++++++++ blogs/202408/overview1.svg | 3 ++ blogs/202408/overview2.drawio | 56 +++++++++++++++++++++++++++++++++++ blogs/202408/overview2.svg | 3 ++ blogs/202408/zktls.md | 28 +++++++++--------- 5 files changed, 115 insertions(+), 14 deletions(-) create mode 100644 blogs/202408/overview1.drawio create mode 100644 blogs/202408/overview1.svg create mode 100644 blogs/202408/overview2.drawio create mode 100644 blogs/202408/overview2.svg diff --git a/blogs/202408/overview1.drawio b/blogs/202408/overview1.drawio new file mode 100644 index 0000000..f0586b4 --- /dev/null +++ b/blogs/202408/overview1.drawio @@ -0,0 +1,39 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/blogs/202408/overview1.svg b/blogs/202408/overview1.svg new file mode 100644 index 0000000..7f644da --- /dev/null +++ b/blogs/202408/overview1.svg @@ -0,0 +1,3 @@ + + +
TLS
Prover
TLS
Server
TLS
Verifier
TLS
MPC-TLS
 \ No newline at end of file diff --git a/blogs/202408/overview2.drawio b/blogs/202408/overview2.drawio new file mode 100644 index 0000000..d9fa998 --- /dev/null +++ b/blogs/202408/overview2.drawio @@ -0,0 +1,56 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/blogs/202408/overview2.svg b/blogs/202408/overview2.svg new file mode 100644 index 0000000..52f680f --- /dev/null +++ b/blogs/202408/overview2.svg @@ -0,0 +1,3 @@ + + +
TLS
Prover
TLS
Server
TLS
Verifier
TLS
MPC-TLS
Attestation
Verifier
Attest
 \ No newline at end of file diff --git a/blogs/202408/zktls.md b/blogs/202408/zktls.md index e27c116..93df1c2 100644 --- a/blogs/202408/zktls.md +++ b/blogs/202408/zktls.md @@ -1,37 +1,37 @@ -# Terminology Matters: Why We Use MPC-TLS Attestations and Not zkTLS "Proofs" +# Does TLSNotary produce "proofs" or "attestations"? -We are seeing more and more occurrences of the term "zkTLS" [TODO: add links to Twitter]. The TLSNotary team believes this term is poorly chosen because it seems to imply that TLS sessions have all the typical properties of zero-knowledge proofs. In this blog post, we explain why we prefer the term **MPC-TLS Attestations** and choose not to use **zkTLS "Proofs."** +Recently, we've seen an increasing use of the term "zkTLS" [TODO: add links to Twitter]. 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. -## TLS and TLSNotary: A Brief Overview +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 into zkTLS vs. MPC-TLS, let’s first recap TLS and TLSNotary. +[TODO embed https://x.com/sinu_eth/status/1827135565185401239 here] + +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. -[TODO: add TLSNotary diagram here later] +![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** 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. -TLSNotary is gaining popularity among developers for its ability to provide verifiable evidence of interactions with a server, ensuring that the data remains trustworthy for both parties involved. TLSNotary also protects the privacy of 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 zero-knowledge proofs (ZKPs) and allow anyone to verify the proof without needing to trust any specific party. These systems are highly desirable but unfortunately not always feasible. +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. **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. **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. -[TODO embed https://x.com/sinu_eth/status/1827135565185401239 here] - ## Onchain Attestations -The Verifier cannot run onchain. The Verifier must be online simultaneously with both the Prover and the Server. This means that the attestation put onchain by the Prover (or the Verifier) is not a standalone proof but an attestation. And because an attester could attest to (or sign) whatever it wants, consumers of this information need to trust the attester. TLSNotary can be used to build oracles, but it does not solve the **oracle problem**. +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**. ## Conclusion -In the end, terminology matters because it shapes our understanding and expectations of the technology we use. - -The term zkTLS might sound appealing, but it is confusing. The "zk" prefix in zkTLS seems to imply public verifiability, which is not the case. This is the reason we prefer **MPC-TLS Attestations** instead. \ No newline at end of file +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. \ No newline at end of file From 37e5bfdd4f9e7b04aee0d236c44cd039e8c07f03 Mon Sep 17 00:00:00 2001 From: Hendrik Eeckhaut Date: Wed, 28 Aug 2024 12:05:15 +0200 Subject: [PATCH 4/8] TODOs --- blogs/202408/zktls.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/blogs/202408/zktls.md b/blogs/202408/zktls.md index 93df1c2..d8689a3 100644 --- a/blogs/202408/zktls.md +++ b/blogs/202408/zktls.md @@ -1,10 +1,11 @@ # Does TLSNotary produce "proofs" or "attestations"? -Recently, we've seen an increasing use of the term "zkTLS" [TODO: add links to Twitter]. 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. +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. + + 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. -[TODO embed https://x.com/sinu_eth/status/1827135565185401239 here] Before we dive deeper into TLSNotary, let’s first recap TLS itself. From f437317af6a050ab5de706e52e60e41df7424281 Mon Sep 17 00:00:00 2001 From: Hendrik Eeckhaut Date: Thu, 19 Sep 2024 15:00:21 +0200 Subject: [PATCH 5/8] Update blogs/202408/zktls.md Co-authored-by: dan --- blogs/202408/zktls.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/blogs/202408/zktls.md b/blogs/202408/zktls.md index d8689a3..c115d88 100644 --- a/blogs/202408/zktls.md +++ b/blogs/202408/zktls.md @@ -15,7 +15,7 @@ Before we dive deeper into TLSNotary, let’s first recap TLS itself. **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. +But can an external party **trustlessly** verify the `data` from a TLS connection mentioned above? No, they can't. 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 the (Note to reviewers: removing `TLS` to avoid an unnecessary detail in favor of simplicity of the exposition) verification to a trusted party and rely on their attestations. ## Proofs vs. Attestations From a4ce80bcbf072f8abeb4135fd382a421c48b0cf0 Mon Sep 17 00:00:00 2001 From: Hendrik Eeckhaut Date: Thu, 19 Sep 2024 15:00:43 +0200 Subject: [PATCH 6/8] Update blogs/202408/zktls.md Co-authored-by: sinu.eth <65924192+sinui0@users.noreply.github.com> --- blogs/202408/zktls.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/blogs/202408/zktls.md b/blogs/202408/zktls.md index c115d88..b97ad2a 100644 --- a/blogs/202408/zktls.md +++ b/blogs/202408/zktls.md @@ -31,7 +31,7 @@ In the case of MPC-TLS, the Verifier knows the TLS session was authentic, so it ## 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**. +The Verifier cannot operate onchain, as it must be online simultaneously with both the Prover and the Server. However, an attestation can still be utilized onchain. 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**. ## Conclusion From 1b1de7c9b508870ee69498b3cfc68aeb4b4ddc3e Mon Sep 17 00:00:00 2001 From: Hendrik Eeckhaut Date: Fri, 20 Sep 2024 15:11:04 +0200 Subject: [PATCH 7/8] Applied feedback --- blogs/202408/zktls.md | 40 ++++++++++++++++++++++++---------------- 1 file changed, 24 insertions(+), 16 deletions(-) diff --git a/blogs/202408/zktls.md b/blogs/202408/zktls.md index b97ad2a..6ff0381 100644 --- a/blogs/202408/zktls.md +++ b/blogs/202408/zktls.md @@ -1,38 +1,46 @@ -# Does TLSNotary produce "proofs" or "attestations"? +# 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. +Recently, the term ["zkTLS"](https://x.com/search?q=zktls) has become very popular on Crypto Twitter. The "zk" prefix suggests a combination of TLS with zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge), implying that the protocol would be publicly verifiable. - + + -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. +To avoid confusion, this post explains how TLSNotary achieves verifiable TLS sessions. Spoiler: **TLSNotary's output is not a publicly verifiable proof; it is an attestation**. +Before diving deeper into TLSNotary, let’s first recap TLS itself. -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. +**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. +**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. 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 mentioned above? No, they can't. 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 the (Note to reviewers: removing `TLS` to avoid an unnecessary detail in favor of simplicity of the exposition) verification to a trusted party and rely on their attestations. +But can an external party **trustlessly** verify the data from a TLS connection? No, they can't. 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 the 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. +When one talks about **proofs** in cryptography, one usually refers 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. -**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. +**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. +In the case of MPC-TLS, the Verifier has cryptographic guarantees that the TLS session was authentic, so it can attest to it as the designated verifier. This is an attestation, not a publicly verifiable proof. + +All TLS-verifying protocols that the TLSNotary team is aware of (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 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. + +## On-Chain Attestations + +The Verifier cannot operate on-chain, as it must be online simultaneously with both the Prover and the Server. However, an attestation can still be utilized 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**. -**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. +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. -## Onchain Attestations +## The Ideal Solution -The Verifier cannot operate onchain, as it must be online simultaneously with both the Prover and the Server. However, an attestation can still be utilized onchain. 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**. +In a perfect world, all data served by TLS servers would be cryptographically signed, making it **natively verifiable** without any extra complexity. This would remove 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 -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. \ No newline at end of file +While the term "zkTLS" is catchy and suggests a fully trustless, publicly verifiable protocol, it's important to understand the nuances. **TLSNotary does not produce publicly verifiable proofs, but attestations from designated verifiers.** In many practical applications—especially offchain—the use of attestations is both sufficient and appropriate within existing trust models. \ No newline at end of file From edc27a16e4e277f47b095196b34a37993d8dd348 Mon Sep 17 00:00:00 2001 From: Hendrik Eeckhaut Date: Mon, 23 Sep 2024 16:26:30 +0200 Subject: [PATCH 8/8] more edits --- blogs/202408/zktls.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/blogs/202408/zktls.md b/blogs/202408/zktls.md index 6ff0381..3584a3d 100644 --- a/blogs/202408/zktls.md +++ b/blogs/202408/zktls.md @@ -1,11 +1,10 @@ # Does TLSNotary Produce "Proofs" or "Attestations"? - -Recently, the term ["zkTLS"](https://x.com/search?q=zktls) has become very popular on Crypto Twitter. The "zk" prefix suggests a combination of TLS with zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge), implying that the protocol would be publicly verifiable. +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? -To avoid confusion, this post explains how TLSNotary achieves verifiable TLS sessions. Spoiler: **TLSNotary's output is not a publicly verifiable proof; it is an attestation**. +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. @@ -13,34 +12,35 @@ Before diving deeper into TLSNotary, let’s first recap TLS itself. ![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. 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. +**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 can't. 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 the verification to a trusted party and rely on their attestations. +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 -When one talks about **proofs** in cryptography, one usually refers 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. +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 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. +**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, so it can attest to it as the designated verifier. This is an attestation, not a publicly verifiable proof. +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 that the TLSNotary team is aware of (and which do not modify the TLS protocol) are designated-verifier protocols. +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 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. +**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, as it must be online simultaneously with both the Prover and the Server. However, an attestation can still be utilized 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**. +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 remove 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. +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 the term "zkTLS" is catchy and suggests a fully trustless, publicly verifiable protocol, it's important to understand the nuances. **TLSNotary does not produce publicly verifiable proofs, but attestations from designated verifiers.** In many practical applications—especially offchain—the use of attestations is both sufficient and appropriate within existing trust models. \ No newline at end of file +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. \ No newline at end of file