No, it does not. TLS is designed to guarantee the authenticity of data only to the participants of the TLS connection. TLS does not have a mechanism to enable the server to "sign" the data.
@@ -211,6 +212,8 @@~25MB (a fixed cost per one TLSNotary session) + ~10 MB per every 1KB of outgoing data + ~40KB per every 1 KB of incoming data.
In a concrete scenario of sending a 1KB HTTP request followed by a 100KB response, the Prover's overhead will be:
25 + 10 + 4 = ~39 MB of upload data.
+A proxy is required only for the browser extension because browsers do not allow extensions to open TCP connections. Instead, our extension opens a websocket connection to a proxy (local or remote) which opens a TCP connection with the server. Our custom TLS client is then attached to this connection and the proxy only sees encrypted data.
diff --git a/print.html b/print.html index bdcdd96..df73471 100644 --- a/print.html +++ b/print.html @@ -257,6 +257,7 @@No, it does not. TLS is designed to guarantee the authenticity of data only to the participants of the TLS connection. TLS does not have a mechanism to enable the server to "sign" the data.
@@ -281,6 +282,8 @@~25MB (a fixed cost per one TLSNotary session) + ~10 MB per every 1KB of outgoing data + ~40KB per every 1 KB of incoming data.
In a concrete scenario of sending a 1KB HTTP request followed by a 100KB response, the Prover's overhead will be:
25 + 10 + 4 = ~39 MB of upload data.
+A proxy is required only for the browser extension because browsers do not allow extensions to open TCP connections. Instead, our extension opens a websocket connection to a proxy (local or remote) which opens a TCP connection with the server. Our custom TLS client is then attached to this connection and the proxy only sees encrypted data.
This quick start will help you get started with TLSNotary, both in native Rust and in the browser.
diff --git a/searchindex.js b/searchindex.js index 8cd402c..4771d57 100644 --- a/searchindex.js +++ b/searchindex.js @@ -1 +1 @@ -Object.assign(window.search, {"doc_urls":["intro.html#introduction","intro.html#data-provenance-without-compromising-privacy-that-is-why","intro.html#how-does-the-tlsnotary-protocol-work","intro.html#①-multi-party-tls-request","intro.html#②-selective-disclosure","intro.html#③-data-verification","intro.html#tls-verification-with-a-general-purpose-notary","intro.html#what-can-tlsnotary-do","intro.html#what-tls-version-does-tlsnotary-support","intro.html#who-is-behind-tlsnotary","motivation.html#motivation","motivation.html#non-repudiation-tls-is-not-enough","motivation.html#status-quo-delegate-access","motivation.html#tlsnotary-data-provenance-and-privacy-with-secure-multi-party-computation","motivation.html#make-your-data-portable-with-tlsnotary","faq.html#faq","faq.html#faq1","faq.html#faq2","faq.html#faq3","faq.html#faq4","faq.html#faq5","faq.html#faq6","faq.html#faq7","quick_start/index.html#quick-start","quick_start/rust.html#rust-quick-start","quick_start/rust.html#requirements","quick_start/rust.html#clone-the-tlsnotary-repository","quick_start/rust.html#install-rust","quick_start/rust.html#simple-example-notarizing-public-data-from-examplecom","quick_start/rust.html#1-notarize--httpsexamplecom","quick_start/rust.html#2-verify-the-proof","quick_start/rust.html#3-redact-information","quick_start/rust.html#optional-extra-experiments","quick_start/rust.html#notarizing-private-information-discord-message","quick_start/rust.html#1-start-a-local-notary-server","quick_start/rust.html#2-get-authorization-token-and-channel-id","quick_start/rust.html#3-create-the-proof","quick_start/rust.html#verify","quick_start/rust.html#optional-notarize-more-private-data","quick_start/tlsn-js.html#tlsnotary-in-reacttypescript-with-tlsn-js","quick_start/tlsn-js.html#tlsn-js-in-a-reacttypescript-app","quick_start/tlsn-js.html#run-a-local-notary-server-and-websocket-proxy--optional","quick_start/tlsn-js.html#websocket-proxy","quick_start/tlsn-js.html#run-a-local-notary-server","quick_start/browser_extension.html#tlsnotary-browser-extension","quick_start/browser_extension.html#install-browser-extension-chromebrave","quick_start/browser_extension.html#websocket-proxy","quick_start/browser_extension.html#notary-server","quick_start/browser_extension.html#run-a-local-notary-server","quick_start/browser_extension.html#notarize-twitter-account-access","quick_start/browser_extension.html#verify","quick_start/browser_extension.html#troubleshooting","developers/notary_server.html#run-a-notary-server","developers/notary_server.html#configure-server-setting","developers/notary_server.html#using-cargo","developers/notary_server.html#using-docker","developers/notary_server.html#api-endpoints","developers/notary_server.html#pse-development-notary-server","developers/notary_server.html#websocket-proxy-server","protocol/mpc-tls/index.html#mpc-tls","protocol/mpc-tls/handshake.html#handshake","protocol/mpc-tls/encryption.html#encryption-decryption-and-mac-computation","protocol/mpc-tls/encryption.html#encryption","protocol/mpc-tls/encryption.html#decryption","protocol/notarization.html#notarization","protocol/notarization.html#signing-the-session-header","protocol/verification.html#verification","mpc/key_exchange.html#key-exchange","mpc/ff-arithmetic.html#finite-field-arithmetic","mpc/ff-arithmetic.html#adding-covert-security","mpc/ff-arithmetic.html#m2a-protocol-review","mpc/ff-arithmetic.html#replay-protocol","mpc/deap.html#dual-execution-with-asymmetric-privacy","mpc/deap.html#introduction","mpc/deap.html#preliminary","mpc/deap.html#premature-leakage","mpc/deap.html#aborts","mpc/deap.html#committed-oblivious-transfer","mpc/deap.html#notation","mpc/deap.html#protocol","mpc/deap.html#setup","mpc/deap.html#execution","mpc/deap.html#equality-check","mpc/deap.html#analysis","mpc/deap.html#malicious-alice","mpc/deap.html#malicious-bob","mpc/deap.html#malicious-alice--bob","mpc/encryption.html#encryption","mpc/encryption.html#preliminary","mpc/encryption.html#ephemeral-keyshare","mpc/encryption.html#premature-leakage","mpc/encryption.html#plaintext-leakage","mpc/encryption.html#integrity","mpc/encryption.html#notation","mpc/encryption.html#encryption-protocol","mpc/encryption.html#decryption-protocol","mpc/encryption.html#proving-the-validity-of-pn","mpc/mac.html#computing-mac-in-2pc","mpc/mac.html#1-what-is-a-mac","mpc/mac.html#2-how-a-mac-is-computed-in-aes-gcm","mpc/mac.html#21-gctr-output","mpc/mac.html#22-ghash-output","mpc/mac.html#3-computing-mac-using-secure-two-party-computation-2pc","mpc/mac.html#31-example-with-a-single-ciphertext-block","mpc/mac.html#32-computing-ciphertexts-with-an-arbitrary-number-of-blocks","mpc/mac.html#33-free-squaring","mpc/mac.html#33-creating-a-robust-protocol","mpc/commitments.html#commitments","glossary.html#glossary"],"index":{"documentStore":{"docInfo":{"0":{"body":0,"breadcrumbs":2,"title":1},"1":{"body":69,"breadcrumbs":6,"title":5},"10":{"body":34,"breadcrumbs":2,"title":1},"100":{"body":20,"breadcrumbs":4,"title":3},"101":{"body":135,"breadcrumbs":4,"title":3},"102":{"body":45,"breadcrumbs":10,"title":9},"103":{"body":54,"breadcrumbs":6,"title":5},"104":{"body":284,"breadcrumbs":7,"title":6},"105":{"body":44,"breadcrumbs":4,"title":3},"106":{"body":241,"breadcrumbs":5,"title":4},"107":{"body":69,"breadcrumbs":2,"title":1},"108":{"body":84,"breadcrumbs":2,"title":1},"11":{"body":121,"breadcrumbs":5,"title":4},"12":{"body":68,"breadcrumbs":5,"title":4},"13":{"body":50,"breadcrumbs":9,"title":8},"14":{"body":33,"breadcrumbs":5,"title":4},"15":{"body":31,"breadcrumbs":2,"title":1},"16":{"body":25,"breadcrumbs":9,"title":8},"17":{"body":20,"breadcrumbs":6,"title":5},"18":{"body":33,"breadcrumbs":5,"title":4},"19":{"body":44,"breadcrumbs":3,"title":2},"2":{"body":28,"breadcrumbs":4,"title":3},"20":{"body":31,"breadcrumbs":6,"title":5},"21":{"body":26,"breadcrumbs":4,"title":3},"22":{"body":65,"breadcrumbs":5,"title":4},"23":{"body":49,"breadcrumbs":4,"title":2},"24":{"body":8,"breadcrumbs":6,"title":3},"25":{"body":11,"breadcrumbs":4,"title":1},"26":{"body":18,"breadcrumbs":6,"title":3},"27":{"body":19,"breadcrumbs":5,"title":2},"28":{"body":20,"breadcrumbs":9,"title":6},"29":{"body":42,"breadcrumbs":6,"title":3},"3":{"body":52,"breadcrumbs":5,"title":4},"30":{"body":56,"breadcrumbs":6,"title":3},"31":{"body":59,"breadcrumbs":6,"title":3},"32":{"body":21,"breadcrumbs":6,"title":3},"33":{"body":17,"breadcrumbs":8,"title":5},"34":{"body":63,"breadcrumbs":8,"title":5},"35":{"body":101,"breadcrumbs":8,"title":5},"36":{"body":118,"breadcrumbs":6,"title":3},"37":{"body":18,"breadcrumbs":4,"title":1},"38":{"body":25,"breadcrumbs":8,"title":5},"39":{"body":32,"breadcrumbs":7,"title":4},"4":{"body":35,"breadcrumbs":3,"title":2},"40":{"body":171,"breadcrumbs":7,"title":4},"41":{"body":26,"breadcrumbs":10,"title":7},"42":{"body":39,"breadcrumbs":5,"title":2},"43":{"body":53,"breadcrumbs":7,"title":4},"44":{"body":17,"breadcrumbs":7,"title":3},"45":{"body":56,"breadcrumbs":8,"title":4},"46":{"body":65,"breadcrumbs":6,"title":2},"47":{"body":88,"breadcrumbs":6,"title":2},"48":{"body":58,"breadcrumbs":8,"title":4},"49":{"body":59,"breadcrumbs":8,"title":4},"5":{"body":25,"breadcrumbs":3,"title":2},"50":{"body":32,"breadcrumbs":5,"title":1},"51":{"body":21,"breadcrumbs":5,"title":1},"52":{"body":8,"breadcrumbs":6,"title":3},"53":{"body":169,"breadcrumbs":6,"title":3},"54":{"body":79,"breadcrumbs":5,"title":2},"55":{"body":35,"breadcrumbs":5,"title":2},"56":{"body":9,"breadcrumbs":5,"title":2},"57":{"body":92,"breadcrumbs":7,"title":4},"58":{"body":62,"breadcrumbs":6,"title":3},"59":{"body":46,"breadcrumbs":4,"title":2},"6":{"body":81,"breadcrumbs":6,"title":5},"60":{"body":125,"breadcrumbs":4,"title":1},"61":{"body":34,"breadcrumbs":8,"title":4},"62":{"body":39,"breadcrumbs":5,"title":1},"63":{"body":67,"breadcrumbs":5,"title":1},"64":{"body":55,"breadcrumbs":2,"title":1},"65":{"body":56,"breadcrumbs":4,"title":3},"66":{"body":100,"breadcrumbs":2,"title":1},"67":{"body":244,"breadcrumbs":4,"title":2},"68":{"body":32,"breadcrumbs":6,"title":3},"69":{"body":159,"breadcrumbs":6,"title":3},"7":{"body":68,"breadcrumbs":2,"title":1},"70":{"body":85,"breadcrumbs":6,"title":3},"71":{"body":249,"breadcrumbs":5,"title":2},"72":{"body":70,"breadcrumbs":8,"title":4},"73":{"body":122,"breadcrumbs":5,"title":1},"74":{"body":25,"breadcrumbs":5,"title":1},"75":{"body":31,"breadcrumbs":6,"title":2},"76":{"body":13,"breadcrumbs":5,"title":1},"77":{"body":29,"breadcrumbs":7,"title":3},"78":{"body":58,"breadcrumbs":5,"title":1},"79":{"body":10,"breadcrumbs":5,"title":1},"8":{"body":10,"breadcrumbs":5,"title":4},"80":{"body":67,"breadcrumbs":5,"title":1},"81":{"body":158,"breadcrumbs":5,"title":1},"82":{"body":75,"breadcrumbs":6,"title":2},"83":{"body":0,"breadcrumbs":5,"title":1},"84":{"body":209,"breadcrumbs":6,"title":2},"85":{"body":58,"breadcrumbs":6,"title":2},"86":{"body":2,"breadcrumbs":7,"title":3},"87":{"body":19,"breadcrumbs":2,"title":1},"88":{"body":0,"breadcrumbs":2,"title":1},"89":{"body":29,"breadcrumbs":3,"title":2},"9":{"body":55,"breadcrumbs":3,"title":2},"90":{"body":61,"breadcrumbs":3,"title":2},"91":{"body":44,"breadcrumbs":3,"title":2},"92":{"body":22,"breadcrumbs":2,"title":1},"93":{"body":56,"breadcrumbs":2,"title":1},"94":{"body":72,"breadcrumbs":3,"title":2},"95":{"body":65,"breadcrumbs":3,"title":2},"96":{"body":64,"breadcrumbs":4,"title":3},"97":{"body":13,"breadcrumbs":4,"title":3},"98":{"body":56,"breadcrumbs":3,"title":2},"99":{"body":31,"breadcrumbs":6,"title":5}},"docs":{"0":{"body":"","breadcrumbs":"Introduction » Introduction","id":"0","title":"Introduction"},"1":{"body":"The Internet currently lacks effective, privacy-preserving Data Provenance . TLS , also known as the \"s\" in \"https\" 🔐 to the general public, ensures that data can be securely communicated between a server and a user. But how can this user credibly share this data with another user or server without compromising security, privacy, and control? Enter TLSNotary: a protocol enabling users to export data securely from any website. Using Zero Knowledge Proof (ZKP) technology, this data can be selectively shared with others in a cryptographically verifiable manner. TLSNotary makes data truly portable and allows a user, the Prover, to share it with another party, the Verifier, as they see fit.","breadcrumbs":"Introduction » Data Provenance without Compromising Privacy, That is Why!","id":"1","title":"Data Provenance without Compromising Privacy, That is Why!"},"10":{"body":"The decentralized internet demands privacy-respecting data provenance! Data provenance ensures internet data is authentic. It allows verification of the data's origin and ensures the data hasn't been fabricated or tampered with. Data provenance will make data truly portable, empowering users to share it with others as they see fit.","breadcrumbs":"Motivation » Motivation","id":"10","title":"Motivation"},"100":{"body":"The GCTR output is computed by simply AES-ECB encrypting a counter block with the counter set to 1 (the iv, nonce and AES key are the same as for the rest of the TLS record).","breadcrumbs":"MAC » 2.1 GCTR output","id":"100","title":"2.1 GCTR output"},"101":{"body":"The GHASH output is the output of the GHASH function described in the NIST publication in section 6.4 in this way: \"In effect, the GHASH function calculates X1•Hm⊕X2•Hm−1⊕...⊕Xm−1•H2⊕Xm•H\". H and X are elements of the extension field GF(2128). \"•\" is a special type of multiplication called multiplication in a finite field described in section 6.3 of the NIST publication. ⊕ is addition in a finite field and it is defined as XOR. In other words, GHASH splits up the ciphertext into 16-byte blocks, each block is numbered X1,X2,... etc. There's also H which is called the GHASH key, which just is the AES-encrypted zero-block. We need to raise H to as many powers as there are blocks, i.e. if we have 5 blocks then we need 5 powers: H,H2,H3,H4,H5. Each block is multiplied by the corresponding power and all products are summed together. Below is the pseudocode for multiplying two 128-bit field elements x and y in GF(2128): 1. result = 0\n2. R = 0xE1000000000000000000000000000000\n3. bit_length = 128\n4. for i=0 upto bit_length-1\n5. if y[i] == 1\n6. result ^= x\n7. x = (x >> 1) ^ ((x & 1) * R)\n8. return result Standard math properties hold in finite field math, viz. commutative: a+b=b+a and distributive: a(b+c)=ab+ac.","breadcrumbs":"MAC » 2.2 GHASH output","id":"101","title":"2.2 GHASH output"},"102":{"body":"The goal of the protocol is to compute the MAC in such a way that neither party would learn the other party's share of H i.e. the GHASH key share. At the start of the protocol each party has: ciphertext blocks X1,X2,...,Xm. XOR share of H: the User has Hu and the Notary has Hn. XOR share of the GCTR output: the User has GCTRu and the Notary has GCTRn. Note that 2. and 3. were obtained at an earlier stage of the TLSNotary protocol.","breadcrumbs":"MAC » 3. Computing MAC using secure two-party computation (2PC)","id":"102","title":"3. Computing MAC using secure two-party computation (2PC)"},"103":{"body":"To illustrate what we want to achieve, we consider the case of just having a single ciphertext block X1. The GHASH_output will be: X1•H=X1•(Hu⊕Hn)=X1•Hu⊕X1•Hn The User and the Notary will compute locally the left and the right terms respectively. Then each party will XOR their result to the GCTR output share and will get their XOR share of the MAC: User : X1•Hu⊕GCTRu=MACu Notary: X1•Hn⊕GCTRn=MACn Finally, the Notary sends MACn to the User who obtains: MAC=MACn⊕MACu For longer ciphertexts, the problem is that higher powers of the hashkey Hk cannot be computed locally, because we deal with additive sharings, i.e.(Hu)k⊕(Hn)k=Hk.","breadcrumbs":"MAC » 3.1 Example with a single ciphertext block","id":"103","title":"3.1 Example with a single ciphertext block"},"104":{"body":"We now introduce our 2PC MAC protocol for computing ciphertexts with an arbitrary number of blocks. Our protocol can be divided into the following steps. Steps First, both parties convert their additive shares Hu and Hn into multiplicative shares Hu and Hn. This allows each party to locally compute the needed higher powers of these multiplicative shares, i.e for m blocks of ciphertext: the user computes Hu2,Hu3,...Hum the notary computes Hn2,Hn3,...Hnm Then both parties convert each of these multiplicative shares back to additive shares the user ends up with Hu,Hu2,...Hum the notary ends up with Hn,Hn2,...Hnm Each party can now locally compute their additive MAC share MACn/u. The conversion steps ( 1 and 3 ) require communication between the user and the notary. They will use A2M (Addition-to-Multiplication) and M2A (Multiplication-to-Addition) protocols, which make use of oblivious transfer , to convert the shares. The user will be the sender and the notary the receiver. 2PC MAC Overview 3.2.1 (A2M) Convert additive shares of H into multiplicative share At first (step 1 ) we have to get a multiplicative share of Hn/u, so that notary and user can locally compute the needed higher powers. For this we use an adapted version of the A2M protocol in chapter 4 of Efficient Secure Two-Party Exponentiation . The user will decompose his share into i individual oblivious transfers tu,ik=R⋅(k⋅2i+Hu,i⋅2i⊕si), where R is some random value used for all oblivious transfers si is a random mask used per oblivious transfer, with ∑isi=0 k∈0,1 depending on the receiver's choice. The notary's choice in the i-th OT will depend on the bit value in the i-th position of his additive share Hn. In the end the multiplicative share of the user Hu will simply be the inverse R−1 of the random value, and the notary will sum all his OT outputs, so that all the si will vanish and hence he gets his multiplicative share Hn. H=Hu⊕Hn=R−1⋅R⋅i∑(Hu,i⊕Hn,i)⋅2i⊕si=R−1⋅i∑tu,iHn,i⊕R⋅i∑si=Hu⋅Hn 3.2.2 (M2A) Convert multiplicative shares Hk into additive shares In step 3 of our protocol, we use the oblivious transfer method described in chapter 4.1 of the Gilboa paper Two Party RSA Key Generation to convert all the multiplicative shares Hn/uk back into additive shares Hn/uk. We only show how the method works for the share Hn/u1, because it is the same for higher powers. The user will be the OT sender and decompose his shares into i individual oblivious transfers tu,ik=k⋅Hu⋅2i+si, where k∈0,1, depending on the receiver's choices. Each of these OTs is masked with a random value si. He will then obliviously send them to the notary. Depending on the binary representation of his multiplicative share, the notary will choose one of the choices and do this for all 128 oblivious transfers. After that the user will locally XOR all his si and end up with his additive share Hu, and the notary will do the same for all the results of the oblivious transfers and get Hn. H=Hu⋅Hn=Hu⋅i∑Hn,i⋅2i=i∑(Hn,i⋅Hu⋅2i⊕si)⊕i∑si=i∑tu,iHn,i⊕i∑si≡Hn⊕Hu","breadcrumbs":"MAC » 3.2 Computing ciphertexts with an arbitrary number of blocks","id":"104","title":"3.2 Computing ciphertexts with an arbitrary number of blocks"},"105":{"body":"In the actual implementation of the protocol we only compute odd multiplicative shares, i.e. H,H3,H5,…, so that we only need to share these odd shares in step 3 . This is possible because we can compute even additive shares from odd additive shares. We observe that for even k: Hk=(Hnk/2⊕Huk/2)2=(Hnk/2)2⊕Hnk/2Huk/2⊕Huk/2Hnk/2⊕(Huk/2)2=(Hnk/2)2⊕(Huk/2)2=Hnk⊕Huk So we only need to convert odd multiplicative shares into odd additive shares, which gives us a 50% reduction in cost. The remaining even additive shares can then be computed locally.","breadcrumbs":"MAC » 3.3 Free Squaring","id":"105","title":"3.3 Free Squaring"},"106":{"body":"Both the A2M and M2A protocols on their own only provide semi-honest security. They are secure against a malicious receiver, but the sender has degrees of freedom to cause leakage of the MAC keyshares. However, for our purposes this does not present a problem as long as leakage is detected. To detect a malicious sender, we require the sender to commit to the PRG seed used to generate the random values in the share conversion protocols. After the TLS session is closed the MAC keyshares are no longer secret, which allows the sender to reveal this seed to the receiver. Subsequently, the receiver can perform a consistency check to make sure the sender followed the protocol honestly. 3.3.1 Malicious notary The protocol is secure against a malicious notary, because he is the OT receiver, which means that there is actually no input from him during the protocol execution except for the final MAC output. He just receives the OT input from the user, so the only thing he can do is to provide a wrong MAC keyshare. This will cause the server to reject the MAC when the user sends the request. The protocol simply aborts. 3.3.2 Malicious user A malicious user could actually manipulate what he sends in the OT and potentially endanger the security of the protocol by leaking the notary's MAC key. To address this we force the user to reveal his MAC key after the server response so that the notary can check for the correctness of the whole MAC 2PC protocol. Then if the notary detects that the user cheated, he would simply abort the protocol. The only problem when doing this is, that we want the whole TLSNotary protocol to work under the assumption that the notary can intercept the traffic between the user and the server. This would allow the notary to trick the user into thinking that the TLS session is already terminated, if he can force the server to respond. The user would send his MAC key share too early and the notary could, now having the complete MAC key, forge the ciphertext and create a valid MAC for it. He would then send this forged request to the server and forward the response of the server to the user. To prevent this scenario we need to make sure that the TLS connection to the server is terminated before the user sends his MAC key share to the notary. Following the TLS RFC , we leverage close_notify to ensure all messages sent to the server have been processed and the connection is closed. Unfortunately, many server TLS implementations do not support close_notify. In these cases we instead send an invalid message to the server which forces it to respond with a fatal alert message and close the connection.","breadcrumbs":"MAC » 3.3 Creating a robust protocol","id":"106","title":"3.3 Creating a robust protocol"},"107":{"body":"Here we illustrate the commitment scheme used to create authenticated commitments to the plaintext in scenarios where a general-purpose Notary is used. (Note that this scheme is not used when the Prover proves directly to the Verifier) A naive approach of extending the Encryption and Decryption steps to also compute a commitment (e.g. BLAKE3 hash) using MPC is too resource-intensive, prompting us to provide a more lightweight commitment scheme. The high-level idea is that the Prover creates a commitment to the active plaintext encoding from the MPC protocol used for Encryption and Decryption . We also hide the amount of commitments (to preserve Prover privacy) by having the Prover commit to the Merkle tree of commitments. Commitment","breadcrumbs":"Commitments » Commitments","id":"107","title":"Commitments"},"108":{"body":"Term Explanation 2PC Secure Two-party computation A2M Addition-to-Multiplication AES Advanced Encryption Standard DEAP Dual Execution with Asymmetric Privacy ECB Electronic codebook (encryption mode) ECDH Elliptic-Curve Diffie-Hellman GC Garbled Circuit GCM Galois/Counter Mode GHASH GCM hash HMAC Hash-based Message Authentication Code M2a Multiplication-to-Addition MAC Message Authentication Code MPC Secure Multi-party computation OT oblivious transfer PMS Pre master secret (TLS) PRF Pseudo Random Function PRG pseudorandom generator PSE Privacy and Scaling Exploration RSA Rivest–Shamir–Adleman (public-key cryptosystem) TLS transport layer security","breadcrumbs":"Glossary » Glossary","id":"108","title":"Glossary"},"11":{"body":"Transport Layer Security (TLS) plays a crucial role in digital security. TLS protects communication against eavesdropping and tampering. It ensures that the data received by a user ( \"Alice\" ) indeed originated from the Server and was not changed. The Server's identity is verified by Alice through trusted Certificate Authorities (CAs). Data integrity is maintained by transmitting a cryptographic hash (called Message Authentication Code or MAC in TLS) alongside the data, which safeguards against deliberate alterations. However, this hash does not provide non-repudiation , meaning it cannot serve as evidence for the authenticity and integrity of the data to Bob (e.g., a service or an app). Because it is a keyed hash and TLS requires that the key is known to Alice, she could potentially modify the data and compute a corresponding hash after the TLS session is finished. Achieving non-repudiation requires digital signatures implemented with asymmetric, public-key cryptography. While the concept seems straightforward, enabling servers to sign data is not a part of the TLS protocol. Even if all data were securely signed, naively sharing all data with others could expose too much information, compromising Alice's privacy. Privacy is a vital social good that must be protected.","breadcrumbs":"Motivation » Non-repudiation: TLS is not enough","id":"11","title":"Non-repudiation: TLS is not enough"},"12":{"body":"Currently, when Alice wants to share data from a Server with another party, OAuth can be used to facilitate this if the application supports it. In this way, the other party receives the data directly from the Server, ensuring authentic and unchanged data. However, applications often do not provide fine-grained control over which data to share, leading to the other party gaining access to more information than strictly necessary. Another drawback of this solution is that the Server is aware of the access delegation, enabling it to monitor and censor the other user’s requests. It's worth noting that in many instances, OAuth is not even presented as an option. This is because a lot of servers lack the incentive to provide third-party access to the data.","breadcrumbs":"Motivation » Status Quo: delegate access","id":"12","title":"Status Quo: delegate access"},"13":{"body":"TLSNotary operates by executing the TLS communication using multi-party computation (MPC). MPC allows Alice and Bob to jointly manage the TLS connection. With TLSNotary, Alice can selectively prove the authenticity of arbitrary portions of the data to Bob. Since Bob participated in the MPC-TLS communication, he is guaranteed that the data is authentic. The TLSNotary protocol is transparent to the Server. From the Server's perspective, the TLS connection appears just like any other connection, meaning no modifications to the TLS protocol are necessary .","breadcrumbs":"Motivation » TLSNotary: data provenance and privacy with secure multi-party computation","id":"13","title":"TLSNotary: data provenance and privacy with secure multi-party computation"},"14":{"body":"TLSNotary is a solution designed to prove the authenticity of data while preserving user privacy. It unlocks a variety of new use cases. So, if you're looking for a way to make your data portable without compromising on privacy, TLSNotary is developed for you! Dive into the protocol and integrate it into your applications. We eagerly await your feedback on Discord .","breadcrumbs":"Motivation » Make your data portable with TLSNotary!","id":"14","title":"Make your data portable with TLSNotary!"},"15":{"body":"Doesn't TLS allow a third party to verify data authenticity? How exactly does a Verifier participate in the TLS connection? What are the trust assumptions of the TLSNotary protocol? What is the role of a Notary? Is the Notary an essential part of the TLSNotary protocol? Which TLS versions are supported? What is the overhead of using the TLSNotary protocol?","breadcrumbs":"FAQ » FAQ","id":"15","title":"FAQ"},"16":{"body":"No, it does not. TLS is designed to guarantee the authenticity of data only to the participants of the TLS connection. TLS does not have a mechanism to enable the server to \"sign\" the data. The TLSNotary protocol overcomes this limitation by making the third-party Verifier a participant in the TLS connection.","breadcrumbs":"FAQ » Doesn't TLS allow a third party to verify data authenticity?","id":"16","title":"Doesn't TLS allow a third party to verify data authenticity?"},"17":{"body":"The Verifier collaborates with the Prover using secure multi-party computation (MPC). There is no requirement for the Verifier to monitor or to access the Prover's TLS connection. The Prover is the one who communicates with the server.","breadcrumbs":"FAQ » How exactly does a Verifier participate in the TLS connection?","id":"17","title":"How exactly does a Verifier participate in the TLS connection?"},"18":{"body":"The protocol does not have trust assumptions. In particular, it does not rely on secure hardware or on the untamperability of the communication channel. The protocol does not rely on participants to act honestly. Specifically, it guarantees that, on the one hand, a malicious Prover will not be able to convince the Verifier of the authenticity of false data, and, on the other hand, that a malicious Verifier will not be able to learn the private data of the Prover.","breadcrumbs":"FAQ » What are the trust assumptions of the TLSNotary protocol?","id":"18","title":"What are the trust assumptions of the TLSNotary protocol?"},"19":{"body":"In some scenarios where the Verifier is unable to participate in a TLS connection, they may choose to delegate the verification of the online phase of the protocol to an entity called the Notary. Just like the Verifier would ( see FAQ above ), the Notary collaborates with the Prover using MPC to enable the Prover to communicate with the server. At the end of the online phase, the Notary produces an attestation trusted by the Verifier. Then, in the offline phase, the Verifier is able to ascertain data authenticity based on the attestation.","breadcrumbs":"FAQ » What is the role of a Notary?","id":"19","title":"What is the role of a Notary?"},"2":{"body":"The TLSNotary protocol consists of 3 steps: The Prover requests data from a Server over TLS while cooperating with the Verifier in secure and privacy-preserving multi-party computation (MPC) . The Prover selectively discloses the data to the Verifier. The Verifier verifies the data.","breadcrumbs":"Introduction » How Does the TLSNotary Protocol Work?","id":"2","title":"How Does the TLSNotary Protocol Work?"},"20":{"body":"No, it is not essential. The Notary is an optional role which we introduced in the tlsn library as a convenience mode for Verifiers who choose not to participate in the TLS connection themselves. For historical reasons, we continue to refer to the protocol between the Prover and the Verifier as the \"TLSNotary\" protocol, even though the Verifier may choose not to use a Notary.","breadcrumbs":"FAQ » Is the Notary an essential part of the TLSNotary protocol?","id":"20","title":"Is the Notary an essential part of the TLSNotary protocol?"},"21":{"body":"We support TLS 1.2, which is an almost-universally deployed version of TLS on the Internet. There are no immediate plans to support TLS 1.3. Once the web starts to transition away from TLS 1.2, we will consider adding support for TLS 1.3 or newer.","breadcrumbs":"FAQ » Which TLS versions are supported?","id":"21","title":"Which TLS versions are supported?"},"22":{"body":"Due to the nature of the underlying MPC, the protocol is bandwidth-bound. We are in the process of implementing more efficient MPC protocols designed to decrease the total data transfer. With the upcoming protocol upgrade planned for 2025, we expect the Prover's upload data overhead to be: ~25MB (a fixed cost per one TLSNotary session) + ~10 MB per every 1KB of outgoing data + ~40KB per every 1 KB of incoming data. In a concrete scenario of sending a 1KB HTTP request followed by a 100KB response, the Prover's overhead will be: 25 + 10 + 4 = ~39 MB of upload data.","breadcrumbs":"FAQ » What is the overhead of using the TLSNotary protocol?","id":"22","title":"What is the overhead of using the TLSNotary protocol?"},"23":{"body":"This quick start will help you get started with TLSNotary, both in native Rust and in the browser . Most Basic Example: Proving and Verifying Public Data (Rust) Proving and Verifying a Private Discord DM (Rust) Proving and Verifying data in a React/Typescript app Proving and Verifying ownership of a Twitter account (Browser) Objectives of this quick start: Gain a better understanding of what you can do with TLSNotary Learn the basics of how to prove and verify data using TLSNotary Let's start !","breadcrumbs":"Quick Start » Quick Start","id":"23","title":"Quick Start"},"24":{"body":"This Quick Start will show you how to use TLSNotary in a native Rust application.","breadcrumbs":"Quick Start » Rust » Rust Quick Start","id":"24","title":"Rust Quick Start"},"25":{"body":"Before we start, make sure you have cloned the tlsn repository and have a recent version of Rust installed.","breadcrumbs":"Quick Start » Rust » Requirements","id":"25","title":"Requirements"},"26":{"body":"Clone the tlsn repository (defaults to the main branch, which points to the latest release): git clone https://github.com/tlsnotary/tlsn.git\" Next open the tlsn folder in your favorite IDE.","breadcrumbs":"Quick Start » Rust » Clone the TLSNotary Repository","id":"26","title":"Clone the TLSNotary Repository"},"27":{"body":"If you don't have Rust installed yet, you can install it using rustup : curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh To configure your current shell, run: source \"$HOME/.cargo/env\"","breadcrumbs":"Quick Start » Rust » Install Rust","id":"27","title":"Install Rust"},"28":{"body":"We will start with the simplest possible use case for TLSNotary: Notarize: Fetch https://example.com/ and create a proof of its content. Verify the proof. Redact the USER_AGENT and titles. Verify the redacted proof.","breadcrumbs":"Quick Start » Rust » Simple Example: Notarizing Public Data from example.com","id":"28","title":"Simple Example: Notarizing Public Data from example.com"},"29":{"body":"Run a simple prover: cd tlsn/examples/simple\ncargo run --release --example simple_prover If the notarization was successful, you should see this output in the console: Starting an MPC TLS connection with the server\nGot a response from the server\nNotarization completed successfully!\nThe proof has been written to `simple_proof.json` If you want to see more details, you can run the prover with extra logging: RUST_LOG=DEBUG,uid_mux=INFO,yamux=INFO cargo run --release --example simple_prover","breadcrumbs":"Quick Start » Rust » 1. Notarize https://example.com/","id":"29","title":"1. Notarize https://example.com/"},"3":{"body":"TLSNotary works by adding a third party, a Verifier, to the usual TLS connection between the Prover and a Server. This Verifier is not \" a man in the middle \" . Instead, the Verifier participates in a secure multi-party computation (MPC) to jointly operate the TLS connection without seeing the data in plain text. By participating in the MPC, the Verifier can validate the authenticity of the data the Prover received from the Server. The TLSNotary protocol is transparent to the Server. From the Server's perspective, the Prover's connection is a standard TLS connection.","breadcrumbs":"Introduction » ① Multi-party TLS Request","id":"3","title":"① Multi-party TLS Request"},"30":{"body":"When you open simple_proof.json in an editor, you will see a JSON file with lots of non-human-readable byte arrays. (Note: The plaintext is included, in byte array form. ) You can verify this file and create a human-friendly output by running: cargo run --release --example simple_verifier This will output the TLS-transaction in clear text: Successfully verified that the bytes below came from a session with Dns(\"example.com\") at 2023-11-03 08:48:20 UTC.\nNote that the bytes which the Prover chose not to disclose are shown as X. Bytes sent:\n...","breadcrumbs":"Quick Start » Rust » 2. Verify the Proof","id":"30","title":"2. Verify the Proof"},"31":{"body":"Open tlsn/examples/simple/simple_prover.rs and locate the line with: let redact = false; and change it to: let redact = true; Next, if you run the simple_prover and simple_verifier again, you'll notice redacted X's in the output: cargo run --release --example simple_prover\ncargo run --release --example simple_verifier \n\n