From 35b2257f6cb531960076d0bf53d90c9972d2cb52 Mon Sep 17 00:00:00 2001 From: sinu <65924192+sinui0@users.noreply.github.com> Date: Wed, 6 Sep 2023 11:23:36 -0700 Subject: [PATCH] update handshake --- src/protocol/mpc-tls/handshake.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/protocol/mpc-tls/handshake.md b/src/protocol/mpc-tls/handshake.md index 2c5d50b..80cfffb 100644 --- a/src/protocol/mpc-tls/handshake.md +++ b/src/protocol/mpc-tls/handshake.md @@ -1,12 +1,12 @@ # TLS Handshake -A TLS handshake is the first step in establishing a TLS connection between a `User` and a `Server`. In TLSNotary the `User` is the one who starts the TLS handshake and physically communicates with the `Server`, but all cryptographic TLS operations are performed together with the `Notary` using MPC. +A TLS handshake is the first step in establishing a TLS connection between a `Prover` and a `Server`. In TLSNotary the `Prover` is the one who starts the TLS handshake and physically communicates with the `Server`, but all cryptographic TLS operations are performed together with the `Verifier` using MPC. -The `User` and `Notary` use a series of MPC protocols to compute the TLS session key in such a way that both only have their share of the key and never learn the full key. Both parties then proceed to complete the TLS handshake using their shares of the key. +The `Prover` and `Verifier` use a series of MPC protocols to compute the TLS session key in such a way that both only have their share of the key and never learn the full key. Both parties then proceed to complete the TLS handshake using their shares of the key. -With the shares of the session key computed and the TLS handshake completed, the parties now proceed to the next MPC protocol where they use their session key shares to jointly generate encrypted requests and decrypt server responses while keeping the plaintext of both the requests and responses private from the `Notary`. +With the shares of the session key computed and the TLS handshake completed, the parties now proceed to the next MPC protocol where they use their session key shares to jointly generate encrypted requests and decrypt server responses while keeping the plaintext of both the requests and responses private from the `Verifier`. -> Note: to a third party observer, the `User`'s connection to the server appears like a regular TLS connection and the security guaranteed by TLS remains intact for the `User`. +> Note: to a third party observer, the `Prover`'s connection to the server appears like a regular TLS connection and the security guaranteed by TLS remains intact for the `Prover`. > -> The only exception is that since the `Notary` is a party to the MPC TLS, the security for the `User` against a malicious `Notary` is guaranteed by the underlying MPC protocols and not by the TLS. \ No newline at end of file +> The only exception is that since the `Verifier` is a party to the MPC TLS, the security for the `Prover` against a malicious `Verifier` is guaranteed by the underlying MPC protocols and not by TLS. \ No newline at end of file