From 246ba5092c117be4eb1ac426df23aaa49a0589b5 Mon Sep 17 00:00:00 2001 From: "sinu.eth" <65924192+sinui0@users.noreply.github.com> Date: Mon, 2 Dec 2024 07:41:34 -0800 Subject: [PATCH] Update src/faq.md Co-authored-by: dan --- src/faq.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/faq.md b/src/faq.md index 250a8d3..bf731c9 100644 --- a/src/faq.md +++ b/src/faq.md @@ -26,7 +26,7 @@ The TLSNotary protocol overcomes this limitation by making the third-party `Veri One may wonder why the `Prover` can not simply generate a proof of the TLS connection locally without the help of another party. This is not possible because of the way TLS is designed. Specifically, TLS utilizes symmetric-key cryptography with message authentication codes (MACs). As a consequence the TLS client, i.e. the `Prover`, -knows the secret key the `Server` uses to authenticate data and can trivially generate fake transcripts locally. Introducing another party into the connection mitigates this problem. +knows the secret key the `Server` uses to authenticate data and can trivially generate fake transcripts locally. Introducing another party into the connection mitigates this problem by removing unilateral access to the secret key from the `Prover`. ### How exactly does a Verifier participate in the TLS connection? { #faq3 }