diff --git a/diagrams/key_exchange.drawio b/diagrams/key_exchange.drawio index ba55fdf..5338e31 100644 --- a/diagrams/key_exchange.drawio +++ b/diagrams/key_exchange.drawio @@ -1 +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= \ No newline at end of file +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 \ No newline at end of file diff --git a/diagrams/mpc-encryption.drawio b/diagrams/mpc-encryption.drawio new file mode 100644 index 0000000..f0855ac --- /dev/null +++ b/diagrams/mpc-encryption.drawio @@ -0,0 +1 @@ +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==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== \ No newline at end of file diff --git a/src/SUMMARY.md b/src/SUMMARY.md index d4102b5..23e55b6 100644 --- a/src/SUMMARY.md +++ b/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 diff --git a/src/css/global.css b/src/css/global.css index bfde080..7cac5b5 100644 --- a/src/css/global.css +++ b/src/css/global.css @@ -1,3 +1,7 @@ :root { --content-max-width: 1000px; } + +.aligncenter { + text-align: center; +} diff --git a/src/mpc/key_exchange.md b/src/mpc/key_exchange.md index 5712a5e..9ca8bc3 100644 --- a/src/mpc/key_exchange.md +++ b/src/mpc/key_exchange.md @@ -1,33 +1,54 @@ # 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. - +
-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 $$ @@ -35,6 +56,8 @@ Then the first party locally computes the first factor and gets $C_q$, the secon $$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)$$ \ No newline at end of file +Now each party holds their respective additive shares of the TLS pre-master secret. \ No newline at end of file diff --git a/src/png-diagrams/key_exchange.png b/src/png-diagrams/key_exchange.png index 48db956..6325565 100644 Binary files a/src/png-diagrams/key_exchange.png and b/src/png-diagrams/key_exchange.png differ diff --git a/src/png-diagrams/mpc-decryption.png b/src/png-diagrams/mpc-decryption.png new file mode 100644 index 0000000..65158a7 Binary files /dev/null and b/src/png-diagrams/mpc-decryption.png differ diff --git a/src/png-diagrams/mpc-encryption.png b/src/png-diagrams/mpc-encryption.png new file mode 100644 index 0000000..07410f1 Binary files /dev/null and b/src/png-diagrams/mpc-encryption.png differ diff --git a/src/protocol/mpc-tls/README.md b/src/protocol/mpc-tls/README.md index d0f9e89..0c37b1b 100644 --- a/src/protocol/mpc-tls/README.md +++ b/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`. diff --git a/src/protocol/mpc-tls/commitment.md b/src/protocol/mpc-tls/commitment.md deleted file mode 100644 index eeacefb..0000000 --- a/src/protocol/mpc-tls/commitment.md +++ /dev/null @@ -1,7 +0,0 @@ -# Commitment - -As part of the TLSNotary protocol, the `User` creates authenticated commitments to the plaintext and the `Notary` signs those commitments without ever seeing the plaintext. This offers a way for the `User` to selectively prove the authenticity of arbitrary portions of the plaintext to the `Verifier`. - -A naive approach of creating such authenticated commitments is to extend the `Encryption and Decryption` steps to also compute a commitment (e.g. a blake3 hash) to the plaintext using MPC and have the `Notary` sign that commitment. Unfortunately, such MPC approach is too resource-intensive, prompting us to provide a more lightweight commitment scheme. - -The high-level idea is that the `User` creates a commitment to the encodings from the MPC protocol used for `Encryption and Decryption`. 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". \ No newline at end of file diff --git a/src/protocol/mpc-tls/encryption.md b/src/protocol/mpc-tls/encryption.md index 19cf3c2..942570e 100644 --- a/src/protocol/mpc-tls/encryption.md +++ b/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). diff --git a/src/protocol/mpc-tls/handshake.md b/src/protocol/mpc-tls/handshake.md index 2c5d50b..e38a588 100644 --- a/src/protocol/mpc-tls/handshake.md +++ b/src/protocol/mpc-tls/handshake.md @@ -1,12 +1,13 @@ -# TLS Handshake +# 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`. +See our section on [Key Exchange](../../mpc/key_exchange.md) for more details of how this is done. - -> 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 provided by the underlying MPC protocols and not by TLS. + +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`. \ No newline at end of file diff --git a/src/protocol/mpc-tls/signing.md b/src/protocol/mpc-tls/signing.md deleted file mode 100644 index 75efa6e..0000000 --- a/src/protocol/mpc-tls/signing.md +++ /dev/null @@ -1,11 +0,0 @@ -# Signing the Session Header - -At the end of the TLSNotary protocol, the `Notary` signs an artifact known as a `Session Header`, thereby attesting to the authenticity of the plaintext from a TLS session. A `Session Header` contains a `User`'s commitment to the plaintext and a `User`'s commitment to TLS-specific data which uniquely identifies the server. - -The `User` can later use the signed `Session Header` to prove data provenance to a third-party `Verifier`. - -It's important to highlight that throughout the entire TLSNotary protocol, including this signing stage, the `Notary` does not gain knowledge of either the plaintext or the identity of the server with which the `User` communicated. - - - - diff --git a/src/protocol/notarization.md b/src/protocol/notarization.md new file mode 100644 index 0000000..5b5eee9 --- /dev/null +++ b/src/protocol/notarization.md @@ -0,0 +1,15 @@ +# Notarization + +As part of the TLSNotary protocol, the `Prover` can create authenticated commitments to the plaintext and have the `Notary` sign them without ever seeing the plaintext. This offers a way for the `Prover` to selectively prove the authenticity of arbitrary portions of the plaintext to a different `Verifier`. + +A naive approach of creating such authenticated commitments is to extend the `Encryption and Decryption` steps to also compute a commitment (e.g. BLAKE3 hash) to the plaintext using MPC and have the `Notary` sign that commitment. Unfortunately, such an approach 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 encodings from the MPC protocol used for `Encryption and Decryption`. Since those encodings are chosen by the `Notary` and are not known to the `Prover` at the time when she makes a commitment, they can be thought of as "authenticated plaintext". + +## Signing the Session Header + +The `Notary` signs an artifact known as a `Session Header`, thereby attesting to the authenticity of the plaintext from a TLS session. A `Session Header` contains a `Prover`'s commitment to the plaintext and a `Prover`'s commitment to TLS-specific data which uniquely identifies the server. + +The `Prover` can later use the signed `Session Header` to prove data provenance to a third-party `Verifier`. + +It's important to highlight that throughout the entire TLSNotary protocol, including this signing stage, the `Notary` does not gain knowledge of either the plaintext or the identity of the server with which the `Prover` communicated.