Key exchange update

diagrams/key_exchange.drawio

@@ -1 +1 @@
-<mxfile host="app.diagrams.net" modified="2022-07-12T05:02:59.309Z" agent="5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.0.0 Safari/537.36" etag="9Thzvw0-MVdKURfvbQUH" version="20.0.4" type="device"><diagram id="kcIGn_kX_1L25iIxUXLg" name="Page-1">7Ztbk6I4FIB/jY9NAQHER7V1pmpmtpyxtnZnX7bSEDHbSJwQu3V//SaQyCXeuhsvvY0vwiHkcs6Xk5MDdMBwsf5E4XL+jYQo7thmuO6A+45tW65n8j8h2eQS37dzQURxKAsVgin+F0mhvC9a4RCllYKMkJjhZVUYkCRBAavIIKXkuVpsRuJqq0sYIU0wDWCsS//AIZvLUbhmIf+McDRXLVumvLKAqrAUpHMYkueSCIw6YEgJYfnRYj1EsVCe0kt+33jP1W3HKErYKTeM/ur/Ci3/23eKP7PRl4ffwff+nevk1TzBeCVHLHvLNkoF6SNigRiL2QGDJcEJQ3T0xFsVqrW4bDsycRLCdI5CWXrOFrEqxCh5REMSE8olIZrBVcz7PYjhA4onJMUMk4RfCZCon194QpRhboivtQIPhDGyKBXoxzgSFxhZcilZsRgnvCHFg+gHlEW2lfMuL8XwFutIcGuQ2QwHyEhRsKKYbYxHtPl7iegCpylvlQ90MMNxrHrfsUF3POg73IYDDh6DvEEqx0mWMOA18DNXtDzjl6dSlztMJkViKGhdEkkTfkJkgRjd8CLyqqfIk/PJtaUFnws6bTcXzUtgukDOCTkfom3N28Z+cH3BJOJd3bYGzGprAJhaaz1Tb00xr1qDMVd7Ahni5knCtMwpPyiNsxBl9L6EZI1bFPKZLE8JZXMSkQTGo0I6oKI3W1iLMl+JQCkz5z+IsY10S3DFSBXqvQZNyYoG6EB3ZTnRx4NmpyiGDD9VvdEBI07E/CwM6DhVA3a9mmUYpBFi8q7mraL4LtzLD/RrhVIxCzV7xTH36sIuz3PM0JRPJHHlmU/QqtZhusyn9gyvhfWqDqiBSebUsLdNHXt/B/a+ud8+Fc2+VI3ONeBOORusL9ZQLkhIgt4EvOtdhnjbvC7xtkb8FNGnm8bd8m4Md+99+XJwGbI9/7pkA43s3whvcnPDZHvOjZFt9zQl6upLQuV1gxjyADSoaq1K+l4tHcWxpAN3hw6U7O3+2FAB6aYWlKha8hmmgbsrmjG6R+o69yQwP5oB6yHkq61X91+XNp21f2n2sq3ogziKxNFk9RBzq9nmF6S7t3Y//JL9cANeHFi6C7F0R/4ht72ghfp9Qu06zRP9ptAEeB9tZfO6PcP3qzPd7hm298roBJxU3bn3n7oZVZjeOoS3OgTxG4+bcgCOhsuO7cllfUD3o/kAsaXwQGM+QOx2rOPVnXuT4rc+4F34ANvVl4yr+wA9RVHK2ZtbYHSWWoRORGg8FhA1tDm6QYQcfVOigyGViBfZE/iytXfb5qhJMxgGMHiMsiWopO9Z9uNFssb6Kuto7kpByv7czxkTrxj0hSbscRAmjoH5NmCG+eJGjYC3aI9DyCD/E/JU/JNEHboi2ZBduFvGq/TOsn1jmURl3kXrldlRhbwjzCh+NXyOPYh5ATkm0MhRa1eJHAB0csDZyPH1eOP8qX+0xuxPcbtIM+SnP0uX7tey6uxkcyyyOfq8wHFODIEaztxt3x04Eobw8A5uSsUyt53ub8dVYWOtnQKEvMZGYxynd11Suv8nUuqp2bOR4l+DlBPecaqCceSxVSVkeYUL5/JebzhsbCOpEtvqlaAdmaTta2nz6stq53LjrqbyqYiORI7Vngw19fORskMRn1z0dqyDWnBWDx4WOAzjfc8iq2bfvzQ3YqUq+q59Wk4ZnM1Gjef7uHLoRnhHyzAtdf4z85aO6ytB4SOzs035bIIo5qPL8qwH9Z77oyY854VSjTUH69af3Z+cZKy//3eip27MmTaeIdpSc2captltuTkUwr2aG+DU3I9vGqDbK34XpUhpp0TR5NtUZaHM6RyKpaJNJZySShiPzYaWKKfrVaMz78p5BFd/fbTF5OqYeJZ7Y5job6aVMpZaxpviJ8hQp015vzxfWfu4oQmf49lGFSfX7inJ1YDS85d7n5+0NL36AUrzNHnAuTmW9K1wi0mTX1idIfBpP6qqfbSxOwBrKb5s4GX5XePWQq9T0gEXSMsXGYc3f6gkB3A0U3DrHzQdrUj7ymFPLuG4M+GnxXfMefHia3Aw+g8=</diagram></mxfile>
+<mxfile host="Electron" modified="2023-09-06T20:20:30.037Z" agent="5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/20.2.3 Chrome/102.0.5005.167 Electron/19.0.11 Safari/537.36" etag="5nnnjiDcUuiNZAazsxjc" version="20.2.3" type="device"><diagram id="kcIGn_kX_1L25iIxUXLg" name="Page-1">7Ztbk6I4FIB/jY9NAQHER7V1pmqmq5y19jL7spWGiNlG4obYrfvrN8FELlGxu/HS2/giHEIu53w5OTlABwwX6y8ULucPJERxxzbDdQfcd2zbMnuA/wnJZivxXCmIKA5loVwwxf8idaeUrnCI0lJBRkjM8LIsDEiSoICVZJBS8lIuNiNxudUljJAmmAYw1qW/45DNt1LfNXP5V4SjuWrZMuWVBVSFpSCdw5C8FERg1AFDSgjbHi3WQxQL5Sm9bO8bH7i66xhFCTvlhtGf/X9Cy3/4QfFXNvr2+Cv40b9znW01zzBeyRHL3rKNUkH6hFggxmJ2wGBJcMIQHT3zVoVqLS7bjUychDCdo1CWnrNFrAoxSp7QkMSEckmIZnAV834PYviI4glJMcMk4VcCJOrnF54RZZgb4nulwCNhjCwKBfoxjsQFRpZcSlYsxglvSPEg+gFlkV3lvMtLMbzFOhLcGmQ2wwEyUhSsKGYb4wlt/loiusBpylvlAx3McByr3nds0B0P+g634YCDxyBvkMpxkiUMeA38zBUtz/jlqdTlHpNJkRgKWhdE0oRfEFkgRje8yFrNH4mTnE+uLS34ktNpu1vRvACmmnZQzodoV/OusV+4vmAS8a7uWgNmuTUATK21nqm3pphXrcGYqz2BDHHzJGFa5JQfFMaZizJ6X0Oyxi0K+UyWp4SyOYlIAuNRLh1Q0ZsdrHmZ70SglJnzb8TYRroluGKkDPVBg6ZkRQN0pLuynOjjUbNTFEOGn8ve6IgRJ2J+5gZ0nLIBu17FMgzSCDF5V/NWUXzn7mVCCaddN1Ycc5cujPIyxwxN+SwSV1747CyrHKbL7bye4bUwXdn7NDDDnArztqkz7+9h3jcPG6ek1tfq0LkG2SkHg/XFAsoFCUnQu2h3vcvgbpvXxd3WcJ8ietu4W96N4e59LEcOLkO251+XbKCR/RuieIZvmm3PuTG27Z6mRl19Saj8bhBDHn8GZa2VWT+opVogCzpw9+hAyd7vkQ0Vj24qMYmqZTvHNHT3BTNGt6auc08D87MZsBpBvtl6VQ92adNZhxdnL9uJPoqjSBxNVo8xt5ptfkMbzbztdvg12+EGvDiwdBdi6Y78U+56QQv1x4TadZon+l2hCfA+28rmdXuG75dnut0zbO+N0Qk4qbpz70B1M+aBeusS3usSxG88bsoFOBowezYol/UC3c/mBcSmwgONeQGx37Hqqzv3NsVvvcAH8QK2qy8bV/cCeppCpe3NHS06SC0/J/IzHguCGtod3SA/jr4r0cGQSsSL7Al80dr7bVNr0gyGAQyeomwFKuh7lv14kayxvko7mvtykLI/93PGxCsGfaEJexyEiWNgvg+YYb62USPgLdrjEDLI/4Q8Ff8kUYeuyDZkF+6W8Sq9s2zfWCZRkXfReml2lCHvCDOKXwWfumcxryDHBBo5aukqkAOATg44Gzm+Hm6cP/uP1pj9IW4XeYbt6c/Cpfu1rDo72dQFNrWPDBznxAio4dTd7t2BmiiER3dwUyiWue30cDuuihor7eQgbGtsNMRxetclpft/IqWamz0bKf41SDnhHacyGDXPrUohyxtcOJf3esNhY/tIldlWrwTtSSXtXkubl19WO5cbdzWVT0V0JJKs9mSoqZ+PlB2L+OSit2cd1IKzavCwwGEYH3oYWTb74aW5ESuV0Xft05LK4Gw2ajzhx5VDN8I7WoZpqfOfmbd0XF8Jch+ZnW2KZxO+SeWjyxKtR/W+9UdNeM4L5RorDtatPr4/OctYff/vRE/dmDNtPEG0o+bONEyz23JzLIR7MzfAqbgf3zRAt5f/LkqR0k4xwfAwVSkoczqHYqloUwmnpBLGY7OhJcrpeuXozLtyHsHd8/poi8m1MfEs98Yw0V9OU+lKLddN8TNkqNMmu1+frKx82dCEw/Fso8ySa/eU5Go06cnLI89OWp7e/PCkeZ484NwcTfpOuMWkyQ+szhD3tN9UVT7b2B9/tRRfNu6y/K5xa5HXKdmAC2Tl84TDuz9VkgOoTRTc+idNtRVpXzkcSCXUOxN+mn/GvC2efwwORv8B</diagram></mxfile>

diagrams/mpc-encryption.drawio

@@ -0,0 +1 @@
+<mxfile host="Electron" modified="2023-09-06T19:14:04.183Z" agent="5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/20.2.3 Chrome/102.0.5005.167 Electron/19.0.11 Safari/537.36" etag="4mVY3mnT_2M1H0Z3yH2e" version="20.2.3" type="device" pages="2"><diagram id="cXJQAhfcsM0mhUN3nRq7" name="encryption">7VhNc5swEP01PjoDCLBzjJ04mUk7zUw67VkBGTQViArZxv31XUB8CHBiJ6ZtOjkZrcRKfu/tatkJWkbZrcBJ+Jn7hE0sw88m6HpiWSYyLfjJLfvSMpuj0hAI6qtFjeGR/iLKaCjrhvok1RZKzpmkiW70eBwTT2o2LATf6cvWnOm7JjggPcOjh1nf+p36MiyttjtvTdwRGoRqa4QMdfIIV6uVIQ2xz3ctE7qZoKXgXJZPUbYkLEevAqZ8b3Vgtj6AILE85oWfm9VX90uQXQZLL7uPYuM6nk6Vly1mG/WPJ5bLwN9izcEtnFruFRbuzw2vJqZpwdQVLLDsBNheNPPwFOS/D4JviajcwblKj+WkgqR2bsFZgVMYLHYhleQxwV4+swNZgS2UEYORCY84TUqi1zQjvjrPo3JkqvEKR5TlkrsjbEsk9TBM1ASY9QHa6FVQECFJ1jIpNG8Jj4gUe1hSzRoV10rczlyNd41UTFfZwpZKaiNW8gxq5w2B8KA4PIFPazw+vxFB1/T/ZtRBXUadv80o6jF6E3tin8ge4IJvYj8HsIDjBdAPYlqAX+Zhyx4DY2umY+waA1HjDGGMxsLYHoiarppj/yq/T2DkMZym1NPxbMA3TkH3IKDE1y6mPpwttIbAqmyCMCzpVr/OhgBUOzxwWuSJii2zy5bdISHlG+ER9Vr7+ul6stwXPEksAiJ7ngpG6z/+epKdN6dG81BqvCf78oIX5OjsCPx+wk9QLum5kNEgzjUGeoBUixZ5YIF02JWaiKjv5z4WgsDB8FPhL5dckuNWIOksJs61rjXTfk6UfRE+GyXdUK+rL3Uarb4ZSgFT48KY2aamhqoSea1eazedV/h6nZJR9OR+JI2jk8bl2ZJG19PISWPWI/mBYdiLZP379x2GdKXhN4e0cWHZtn0W9UxNt5MZOpSPF9Lzk0I65jE5SzynIGLZTxSFeUVZ5R22ViPjPSQBu1NLu659UX39n5wHHOtlZyOngsuP+uFtyaaKrn+yflCu5x2n1p9KPeZQJ2b0csJ8F+UEsptgr/qI3W/BozPJkLP5cUUFgI/3rWUqZE47uKt16eCh9HpeMfXbQEuahEXg9euWwqgJKZWC/yBLzrho7rk13D0d0/HZZqgbcW65ntCDQKYzrICWoofaPK/oQMCw6fGWBDetcnTzGw==</diagram><diagram id="ibZt9Yd9wpwoR1g8O56q" name="decryption">7Vhbc6IwGP01PupAElAfvfSybXems06728cUoqQTCA3xwv76DRBALrbV6m67U18kX5Iv8ZzznUQ6cOJvLgQOve/cJawDDHfTgdMOACY0gfpKInEW6Q9gFlgI6upBZWBGfxMdNHR0SV0SVQZKzpmkYTXo8CAgjqzEsBB8XR0256y6aogXpBGYOZg1oz+pK70siuzBVscloQtPLw2hoXfu43y0DkQedvl6KwTPOnAiOJfZk7+ZEJaglwOTzTvf0VtsQJBAvmWCM4jDu/uHu2f+Q3Zl6N/cI9DVWVaYLfUv7gCbqXzjOVdp1a5lrLGwn5c87+hGKVMjNQCgULE9LvvV0yL5vhV8RUSeTu0ry5h1akiK5EDtVXGqGuO1RyWZhdhJetZKVirmSZ+plqkecRRmRM/phrh6PzOdyNTtc+xTlkjukrAVkdTBqqMgwCw2sI1eDgURkmy2QhrNC8J9IkWshuS9Rs61Frc10O11KRXT1jFvSyVFEGt5LorkJYHqQXO4B5/gdHzeE0Hn9P9m1IJ1Rq1/zShsMDoljohD2QBc8GXgJgCmcLwC+k5MU/AzHwboFBiDfhVj22ipGqsNY3gqjFFL1dTVHLij5DxRLYfhKKJOFc8SfGMfdHcCStzKwdSEcwutNrDymCAMS7qqHmdtAOoVbjlNfSJny6yzhWokRHwpHKKnbR8/9UzAfiWTxGJBZCNTymjxww8n2Xq3NZq7rPGaxNkBL8ib3VHxe4Mf1XWp6oWMLoJEY0oPymrhOCksJR020h0+dd0kx1gQtTH8mOZLJBcmuKVIWuOONa1qzUQvibIpwherpF7qxe1L76Zyv2mzgK7RM/rIrKghv4kcqtciTW0Kn88jchI92XuZRsADchTHiFSZyKYVpeFzyvLsamndMj6DzUCEeoP2Y2Fvo4HIqh7i/b9rNP2GMCY09NKqaR7an9AHcuG/2weMHkAIHafu61NOV/eDr7o/Xt2j2oXbtlGvPyw/gwM9wAJ75T2xIwy/rh7vs5y85j7k1UOnHtaSghMY0vXDt6fwl/CvR9Qx42l8dnX11PoO58uQjvV/Z3i0/zv1TMcznVZZNF8F3TKs1vp8t5AXVf8hbiG5u9g1D6gxfogHqGb5jjgbXr5qh2d/AA==</diagram></mxfile>

src/SUMMARY.md

@@ -6,13 +6,12 @@
 
 # Protocol
 
-1. [MPC-TLS](./protocol/mpc-tls/README.md)
-    - [TLS Handshake](./protocol/mpc-tls/handshake.md)
+- [MPC-TLS](./protocol/mpc-tls/README.md)
+    - [Handshake](./protocol/mpc-tls/handshake.md)
     - [Encryption and Decryption](./protocol/mpc-tls/encryption.md)
-    - [Commitment](./protocol/mpc-tls/commitment.md)
-    - [Signing](./protocol/mpc-tls/signing.md)
-2. [Verification](./protocol/verification.md)
-3. [Selective Disclosure]()
+- [Notarization](./protocol/notarization.md)
+- [Verification]()
+- [Selective Disclosure]()
 
 # MPC
 

src/css/global.css

@@ -1,3 +1,7 @@
 :root {
   --content-max-width: 1000px;
 }
+
+.aligncenter {
+  text-align: center;
+}

src/mpc/key_exchange.md

@@ -1,40 +1,63 @@
 # Key Exchange
 
-In TLS, the first step towards obtaining TLS session keys is to compute a shared secret between the client and the server by running the [ECDH protocol](https://en.wikipedia.org/wiki/Elliptic-curve_Diffie–Hellman). The resulting shared secret in TLS terms is called the pre-master secret `PMS`.
+In TLS, the first step towards obtaining TLS session keys is to compute a shared secret between the client and the server by running the [ECDH protocol](https://en.wikipedia.org/wiki/Elliptic-curve_Diffie–Hellman). The resulting shared secret in TLS terms is called the pre-master secret.
 
-<img src="../../png-diagrams/key_exchange.png" width="800">
+<div class="aligncenter"><img src="../../png-diagrams/key_exchange.png" width="800"></div>
 
-Using the notation from Wikipedia, below is the 3-party ECDH protocol between the `Server` the `Requester` and the `Notary`, enabling the `Requester` and the `Notary` to arrive at shares of `PMS`.
+## ECDH
 
+We will denote:
 
-1. `Server` sends its public key $Q_b$ to `Requester`, and `Requester` forwards it to `Notary`
-2. `Requester` picks a random private key share $d_c$ and computes a public key share $Q_c = d_c * G$
-3. `Notary` picks a random private key share $d_n$ and computes a public key share $Q_n = d_n * G$
-4. `Notary` sends $Q_n$ to `Requester` who computes $Q_a = Q_c + Q_n $ and sends $Q_a$ to `Server`
-5. `Requester` computes an EC point $(x_p, y_p) = d_c * Q_b$
-6. `Notary` computes an EC point $(x_q, y_q) = d_n * Q_b$
-7. Addition of points $(x_p, y_p)$ and $(x_q, y_q)$ results in the coordinate $x_r$, which is `PMS`. (The coordinate $y_r$ is not used in TLS)
+- $P$ as the `Prover`
+- $V$ as the `Verifier`
+- $S$ as the `Server`
+- $\mathbb{pms}$ as the TLS pre-master secret.
 
+Below is the 3-party ECDH protocol between $S$, $P$ and $V$, enabling $P$ and $V$ to arrive at shares of $\mathbb{pms}$.
+
+
+1. $S$ sends its public key $Q_b$ to $P$, and $P$ forwards it to $V$
+2. $P$ picks a random private key share $d_c$ and computes a public key share $Q_c = d_c * G$
+3. $V$ picks a random private key share $d_n$ and computes a public key share $Q_n = d_n * G$
+4. $V$ sends $Q_n$ to $P$ who computes $Q_a = Q_c + Q_n $ and sends $Q_a$ to $S$
+5. $P$ computes an EC point $(x_p, y_p) = d_c * Q_b$
+6. $V$ computes an EC point $(x_q, y_q) = d_n * Q_b$
+
+Now our goal is to compute additive shares of $\mathbb{pms}$, which we'll redenote as $x_r$, using elliptic curve point addition
 
-Using the notation from [here](https://en.wikipedia.org/wiki/Elliptic_curve_point_multiplication#Point_addition), our goal is to compute
 $$ x_r = (\frac{y_q-y_p}{x_q-x_p})^2 - x_p - x_q $$
+
 in such a way that
-1. Neither party learns the other party's $x$ value
-2. Neither party learns $x_r$, only their respective shares of $x_r$.
 
-We will use two maliciously secure protocols described on p.25 in the paper [Efficient Secure Two-Party Exponentiation](https://www.cs.umd.edu/~fenghao/paper/modexp.pdf):
+- Neither party learns the other party's share.
+- Neither party learns $x_r$, only their respective shares of $x_r$.
+
+To do this we will need two functionalities defined below:
+
+### A2M
 
-- `A2M` protocol, which converts additive shares into multiplicative shares, i.e. given shares `a` and `b` such that `a + b = c`, it converts them into shares `d` and `e` such that `d * e = c`    
-- `M2A` protocol, which converts multiplicative shares into additive shares
+$\mathsf{A2M}$ converts additive shares into multiplicative shares.
 
-We apply `A2M` to $y_q + (-y_p)$ to get $A_q * A_p$ and also we apply `A2M` to $x_q + (-x_p)$ to get $B_q * B_p$. Then the above can be rewritten as:
+For example, given additive shares $a$ and $b$ such that $a + b = c$, invoking $\mathsf{A2M}$ gives $(d, e) \larr (a, b)_{\mathsf{A2M}}$ such that $d * e = c$
+
+### M2A
+
+$\mathsf{M2A}$, which converts multiplicative shares into additive shares.
+
+For example, given multiplicative shares $d$ and $e$ such that $d * e = c$, invoking $\mathsf{M2A}$ gives $(a, b) \larr (d, e)_{\mathsf{M2A}}$ such that $a + b = c$
+
+### Deriving additive shares of the pre-master secret
+
+We apply $\mathsf{A2M}$ to $y_q + (-y_p)$ to get $A_q * A_p$ and also we apply $\mathsf{A2M}$ to $x_q + (-x_p)$ to get $B_q * B_p$. Then the above can be rewritten as:
 
 $$x_r = (\frac{A_q}{B_q})^2 * (\frac{A_p}{B_p})^2 - x_p - x_q $$
 
 Then the first party locally computes the first factor and gets $C_q$, the second party locally computes the second factor and gets $C_p$. Then we can again rewrite as:
 
 $$x_r = C_q * C_p - x_p - x_q $$
 
-Now we apply `M2A` to $C_q * C_p$ to get $D_q + D_p$, which leads us to two final terms each of which is the share of $x_r$ of the respective party: 
+Now we apply $\mathsf{M2A}$ to $C_q * C_p$ to get $D_q + D_p$, which leads us to two final terms each of which is the share of $x_r$ of the respective party: 
+
+$$x_r = (D_q - x_q) + (D_p - x_p)$$
 
-$$x_r = (D_q - x_q) + (D_p - x_p)$$
+Now each party holds their respective additive shares of the TLS pre-master secret.

src/protocol/mpc-tls/README.md

@@ -1,9 +1,9 @@
 # MPC-TLS
 
-During the MPC-TLS Phase the `Prover` and the `Notary` work together to generate an authenticated `Transcript` of a TLS session with a `Server`.
+During the MPC-TLS Phase the `Prover` and the `Verifier` work together to generate an authenticated `Transcript` of a TLS session with a `Server`.
 
 Listed below are some key points regarding this process:
 
- - The identity of the `Server` is not revealed to the `Notary`, but the `Prover` is capable of proving the `Server` identity to a `Verifier` later.
- - The `Notary` only ever sees the *encrypted* application data of the TLS session.
+ - The identity of the `Server` can be hidden from the `Verifier`, while the `Prover` is still capable of proving the `Server` identity later.
+ - The `Verifier` only ever sees the *encrypted* application data of the TLS session.
  - The protocol guarantees that the `Prover` is not solely capable of constructing requests, nor can they forge responses from the `Server`.

src/protocol/mpc-tls/encryption.md

@@ -1,29 +1,25 @@
 # Encryption, Decryption, and MAC Computation
 
-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 using MPC.
+This section explains how the `Prover` and `Verifier` use MPC to encrypt data sent to the server, decrypt data received from the server, and compute the MAC for the ciphertext using MPC. It shows how the `Prover` and `Verifier` collaborate to encrypt and decrypt data. The `Verifier` performs these tasks "blindly", without acquiring knowledge of the plaintext.
 
 ## Encryption
 
-To encrypt the plaintext, both parties input their TLS 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 TLS key shares as private inputs to the [MPC](/mpc/deap.md) protocol, along with some other public data. Additionally, the `Prover` inputs her plaintext as a private input.
 
-Both parties see the resulting ciphertext and execute the [2PC MAC](../../mpc/mac.md) protocol to compute the MAC for the ciphertext.
+![Encryption](../../png-diagrams/mpc-encryption.png)
 
-The `User` then dispatches the ciphertext and the MAC to the server.
+Both parties see the resulting ciphertext and execute the [2PC MAC](../../mpc/mac.md) protocol to compute the MAC for the ciphertext.
 
-As explained in the [Commitment section](commitment.md), the `User` creates a commitment to the plaintext (her private input to MPC).
+The `Prover` then dispatches the ciphertext and the MAC to the server.
 
 ## Decryption
 
-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.
+Once the `Prover` 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.
 
 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`.
-
-As discussed in the [Commitment section](/protocol/mpc-tls/commitment.md), the `User` creates a commitment to the plaintext.
-
-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).
+![Decryption](../../png-diagrams/mpc-decryption.png)
 
-## Summary
+The resulting plaintext is revealed ONLY to the `Prover`.
 
-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 which `Server` the `User` is communicating with. Additionally, the `User` creates commitments to the plaintext and can use them later to prove the authenticity of the plaintext to a third party `Verifier`.
+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).