AtHeartEngineer/docs-mdbook
1
0
Fork 0
mirror of https://github.com/AtHeartEngineer/docs-mdbook.git synced 2026-01-08 00:43:49 -05:00
Code Issues Packages Projects Releases Wiki Activity

Readability improvements

Browse Source 
+ added a glossary

# Conflicts:
#	src/SUMMARY.md
#	src/protocol/notarization/commitment2.md
#	src/protocol/notarization/encryption2.md
#	src/protocol/notarization/handshake.md
This commit is contained in:
Hendrik Eeckhaut
2023-08-03 14:43:31 +02:00
parent 2992bfa483
commit fe51d5315f
5 changed files with 44 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
src/SUMMARY.md
View File

@@ -23,3 +23,4 @@
- [Encryption](./mpc/encryption.md)
- [TLS handhsake](./mpc/tls_handshake.md)
+[Glossary](./glossary.md)

21
src/glossary.md Normal file
View File

@@ -0,0 +1,21 @@
# Glossary
| Term | Explanation |
| ----- | ----------------------------------------------- |
| AES | Advanced Encryption Standard |
| A2M | Addition-to-Multiplication |
| DEAP | Dual Execution with Asymmetric Privacy |
| ECDH | Elliptic-Curve Diffie-Hellman |
| ECB | Electronic codebook (encryption mode) |
| GC | Garbled Circuit |
| GCM | Galois/Counter Mode |
| GHASH | GCM hash |
| HMAC | Hash-based Message Authentication Code |
| MAC | Message Authentication Code |
| M2a | Multiplication-to-Addition |
| OT | oblivious transfer |
| RSA | Rivest–Shamir–Adleman (public-key cryptosystem) |
| PMS | Pre master secret (TLS) |
| PRF | Pseudo Random Function |
| PSE | Privacy and Scaling Exploration |
| TLS | transport layer security |

9
src/protocol/notarization/commitment.md
View File

@@ -1,8 +1,9 @@
# Commitment
The TLSNotary protocol completely hides the plaintext transcript from the `Notary`. At the same time we want to have a way for the `User` to selectively prove the authenticity of arbitrary portions of the plaintext to the `Verifier`.
The TLSNotary protocol entirely conceals the plaintext transcript from the `Notary`. Simultaneously, the TLSNotary protocol offers a way to the `User` to selectively prove the authenticity of arbitrary portions of the plaintext to the `Verifier`.
Naively, we could extend the above `Encryption and Decryption` steps to also compute a commitment (e.g. a blake3 hash) to the plaintext in MPC and have the `Notary` sign that commitment. Then the `User` could open the commitment to the `Verifier`. Unfortunately such approach would be resource-heavy, and so we provide a more lightweight commitment scheme.
A naive approach could extend the `Encryption and Decryption` steps to also compute a commitment (e.g. a blake3 hash) to the plaintext in MPC, with the `Notary` signing that commitment. The `User` could then open the commitment to the `Verifier`. Unfortunately, this approach would be resource-intensive, prompting us to provide a more lightweight commitment scheme.
The high-level idea is that the `User` will reuse the encodings from the MPC protocol used for `Encryption and Decryption` to create commitments (see here for low-level details). Since those encodings are chosen by the `Notary` and are not known to the `User` at the time when she makes a commitment, they can be thought of as "authenticated plaintext".
For technical details on the commitment scheme, see [Commitment scheme](/mpc/commitment_scheme.md)
The high-level idea is that the `User` will reuse the encodings from the MPC protocol used for `Encryption and Decryption` to create commitments[^commitment_scheme]. Since those encodings are chosen by the `Notary` and are not known to the `User` at the time when she makes a commitment, they can be thought of as "authenticated plaintext".
[^commitment_scheme] For technical details on the commitment scheme, see [Commitment scheme](/mpc/commitment_scheme.md)

30
src/protocol/notarization/encryption.md
View File

@@ -1,33 +1,29 @@
# Encryption and Decryption (and MAC computation)
# Encryption, Decryption, and MAC Computation
Here we explain how the `User` and the `Notary` use MPC to encrypt the data for the server and also how they decrypt the data received from the server. They also compute the MAC for the ciphertext in MPC.
This section explains how the `User` and `Notary` use MPC to encrypt data for the server, decrypt data received from the server, and compute the MAC for the ciphertext in MPC.
## Encryption
In order to encrypt the plaintext, the parties input their key shares as private inputs to the [MPC](/mpc/deap.md) protocol (along with some other public data). Additionally, the `User` inputs her plaintext as a private input.
To encrypt the plaintext, both parties input their key shares as private inputs to the [MPC](/mpc/deap.md) protocol, along with some other public data. Additionally, the `User` inputs her plaintext as a private input.
Both parties learn the resulting ciphertext and they proceed to run an [MPC](/mpc/mac.md) protocol to compute the MAC for the ciphertext.
Both parties see the resulting ciphertext and execute the [2PC MAC](/protocol/2pc/mac.md) protocol to compute the MAC for the ciphertext.
The User sends the ciphertext with the MAC to the server.
As we explain in the [Commitment section](/protocol/notarization/commitment.md), the `User` creates a commitment to the plaintext (her private input to MPC).
The `User` then dispatches the ciphertext and the MAC to the server.
As explained in the [Commitment section](/protocol/notarization/commitment2.md), the `User` creates a commitment to the plaintext (her private input to DEAP).
## Decryption
After the `User` receives the ciphertext with the associated MAC from the server, the parties first authenticate the ciphertext by checking if MAC is valid. They do it by running an [MPC] (/mpc/mac.md) protocol to compute the authentic MAC for the ciphertext. Then they check if the authentic MAC matches the MAC received from the server.
Once the `User` receives the ciphertext and its associated MAC from the server, the parties first authenticate the ciphertext by validating the MAC. They do this by running the [MPC] (/mpc/mac.md) protocol to compute the authentic MAC for the ciphertext. They then verify if the authentic MAC matches the MAC received from the server.
The parties then decrypt the ciphertext by inputting their key shares as private inputs to the [MPC](/mpc/deap.md) protocol (along with the ciphertext and some other public data).
Next, the parties decrypt the ciphertext by providing their key shares as private inputs to the [MPC](/mpc/deap.md) protocol, along with the ciphertext and some other public data.
The resulting plaintext is revealed ONLY to the User.
The resulting plaintext is revealed ONLY to the `User`.
As we explain in the [Commitment section](/protocol/notarization/commitment.md), the `User` creates a commitment to the plaintext.
As discussed in the [Commitment section](/protocol/notarization/commitment.md), the `User` establishes a commitment to the plaintext.
Note that the actual low-level details of implementation of `Decryption` are more nuanced than what we described here. Please consult the [Low-level Decryption details](/mpc/encryption.md) for more information.
Please note, the actual low-level implementation details of `Decryption` are more nuanced than what we have described here. For more information, please consult [Low-level Decryption details](/mpc/encryption.md).
## Summary
To summarize:
We showed above how the Notary and User work together to encrypt and decrypt data. The Notary does it "blindly", without learning the plaintext. In fact, the Notary does not even know which server the User is communicating with.
Additionally, the User created commitments to the plaintext and will be able to later prove the plaintext authenticity to a third party.
This chapter illustrated how the `Notary` and `User` collaborate to encrypt and decrypt data. The `Notary` performs these tasks "blindly," without acquiring knowledge of the plaintext. In fact, the `Notary` even remains unaware of the `Server` with which the `User` is communicating. Additionally, the `User` creates commitments to the plaintext and can use these later to prove the authenticity of the plaintext to a third party `Verifier`.

8
src/protocol/notarization/handshake.md
View File

@@ -1,13 +1,13 @@
# TLS handshake
# TLS Handshake
During the TLS handshake the TLS Client and the TLS Server compute the session keys needed to perform the encryption and decryption of data.
During the TLS handshake, the TLS Client and the TLS Server compute the session keys needed for the encryption and decryption of data.
In TLSNotary protocol `User` and `Notary` jointly play the role of the TLS Client. The User is the one who physically communicates with the server but all cryptographic TLS operations are performed in MPC.
The parties use MPC to compute the session keys in such a way that neither party ever learns the full keys but each has their share of the keys.
They then use their shares of the keys to finish the TLS handshake.
To a third party who observes the `User`'s connection to the server, the connection looks like a regular TLS connection. The `User` maintains all the security guarantees of a regular TLS connection against a third-party bad actor.
To a third party observing the `User`'s connection to the server, the connection appears like a regular TLS connection. The `User` maintains all the security guarantees of a standard TLS connection against a third-party bad actor.
However, the `User`'s TLS connection does not maintain the normal TLS security against the `Notary`. Instead, the `User` relies on the security which the underlying MPC protocols provide.
With the shares of the session keys computed, the parties now proceed to the next MPC protocol where they use their session key shares to jointly encrypt requests to and decrypt responses from the server while keeping the plaintext of the request/response private from the Notary.
With the shares of the session keys computed, the parties now proceed to the next MPC protocol where they use their session key shares to jointly encrypt requests to and decrypt responses from the server while keeping the plaintext of the request/response private from the Notary.