Document not found (404)
+This URL is invalid, sorry. Please use the navigation bar or search to continue.
+ +":e:f.tabReplace?e.replace(/\t/g,f.tabReplace):e):e}function E(e){let n=null;const t=function(e){var n=e.className+" ";n+=e.parentNode?e.parentNode.className:"";const t=f.languageDetectRe.exec(n);if(t){var r=T(t[1]);return r||(console.warn(g.replace("{}",t[1])),console.warn("Falling back to no-highlight mode for this block.",e)),r?t[1]:"no-highlight"}return n.split(/\s+/).find(e=>p(e)||T(e))}(e);if(p(t))return;S("before:highlightBlock",{block:e,language:t}),f.useBR?(n=document.createElement("div")).innerHTML=e.innerHTML.replace(/\n/g,"").replace(/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/intro.html b/intro.html
new file mode 100644
index 0000000..edfeb5a
--- /dev/null
+++ b/intro.html
@@ -0,0 +1,249 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Introduction
+TLSNotary is a protocol which allows users to export data from any website in a +credible way. This way they can verify the authenticity of parts of a +TLS-encrypted web session without compromising on privacy.
+It works by adding a third party, the Notary, to the usual TLS connection +between the User and a web server. The User forwards the encrypted TLS traffic +to the Notary which checks that it has not been tampered with and notarizes the +whole TLS session by signing a transcript of it.
+The User can now use this transcript and disclose parts of it to another +party, which we call the Verifier. The Verifier only needs to trust the Notary +in order to accept proofs from many different users. This way, TLSNotary +can be used for a variety of purposes. For example you can use TLSNotary to +prove that
+-
+
- you have received a money transfer using your online banking account, without +revealing your login credentials or sensitive financial information. +
- you have access to an account on a web platform. +
- a website showed some specific content on a certain date. +
Overall, the TLSNotary protocol can be used in any scenario where you need to +prove to a third party facts about the content of a TLS connection.
+Some interesting aspects of TLSNotary are:
+-
+
- The protocol is transparent to the web server, because it is not aware of the +notarization process. For the server it just looks like normal browsing. +
- Data is kept private from the Notary. The Notary only sees the ciphertext and +never has access to the plaintext. +
- No modifications to the TLS protocol are needed. You can use it without any +changes to web servers. +
- The Notary and the Verifier can be the same entity. That means if you as a +Verifier do not want to trust some Notary server, you can run one yourself. +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/mark.min.js b/mark.min.js
new file mode 100644
index 0000000..1636231
--- /dev/null
+++ b/mark.min.js
@@ -0,0 +1,7 @@
+/*!***************************************************
+* mark.js v8.11.1
+* https://markjs.io/
+* Copyright (c) 2014–2018, Julian Kühnel
+* Released under the MIT license https://git.io/vwTVl
+*****************************************************/
+!function(e,t){"object"==typeof exports&&"undefined"!=typeof module?module.exports=t():"function"==typeof define&&define.amd?define(t):e.Mark=t()}(this,function(){"use strict";var e="function"==typeof Symbol&&"symbol"==typeof Symbol.iterator?function(e){return typeof e}:function(e){return e&&"function"==typeof Symbol&&e.constructor===Symbol&&e!==Symbol.prototype?"symbol":typeof e},t=function(e,t){if(!(e instanceof t))throw new TypeError("Cannot call a class as a function")},n=function(){function e(e,t){for(var n=0;n
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Introduction
+TLSNotary is a protocol which allows users to export data from any website in a +credible way. This way they can verify the authenticity of parts of a +TLS-encrypted web session without compromising on privacy.
+It works by adding a third party, the Notary, to the usual TLS connection +between the User and a web server. The User forwards the encrypted TLS traffic +to the Notary which checks that it has not been tampered with and notarizes the +whole TLS session by signing a transcript of it.
+The User can now use this transcript and disclose parts of it to another +party, which we call the Verifier. The Verifier only needs to trust the Notary +in order to accept proofs from many different users. This way, TLSNotary +can be used for a variety of purposes. For example you can use TLSNotary to +prove that
+-
+
- you have received a money transfer using your online banking account, without +revealing your login credentials or sensitive financial information. +
- you have access to an account on a web platform. +
- a website showed some specific content on a certain date. +
Overall, the TLSNotary protocol can be used in any scenario where you need to +prove to a third party facts about the content of a TLS connection.
+Some interesting aspects of TLSNotary are:
+-
+
- The protocol is transparent to the web server, because it is not aware of the +notarization process. For the server it just looks like normal browsing. +
- Data is kept private from the Notary. The Notary only sees the ciphertext and +never has access to the plaintext. +
- No modifications to the TLS protocol are needed. You can use it without any +changes to web servers. +
- The Notary and the Verifier can be the same entity. That means if you as a +Verifier do not want to trust some Notary server, you can run one yourself. +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/print.html b/print.html
new file mode 100644
index 0000000..c185e95
--- /dev/null
+++ b/print.html
@@ -0,0 +1,1002 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Overview
+The following diagram is a high-level protocol overview introducing the main components of +TLSNotary.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/protocol/2pc/2pc-mac-overview.png b/protocol/2pc/2pc-mac-overview.png
new file mode 100644
index 0000000..01a69e7
Binary files /dev/null and b/protocol/2pc/2pc-mac-overview.png differ
diff --git a/protocol/2pc/deap.html b/protocol/2pc/deap.html
new file mode 100644
index 0000000..4908d05
--- /dev/null
+++ b/protocol/2pc/deap.html
@@ -0,0 +1,317 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Introduction
+TLSNotary is a protocol which allows users to export data from any website in a +credible way. This way they can verify the authenticity of parts of a +TLS-encrypted web session without compromising on privacy.
+It works by adding a third party, the Notary, to the usual TLS connection +between the User and a web server. The User forwards the encrypted TLS traffic +to the Notary which checks that it has not been tampered with and notarizes the +whole TLS session by signing a transcript of it.
+The User can now use this transcript and disclose parts of it to another +party, which we call the Verifier. The Verifier only needs to trust the Notary +in order to accept proofs from many different users. This way, TLSNotary +can be used for a variety of purposes. For example you can use TLSNotary to +prove that
+-
+
- you have received a money transfer using your online banking account, without +revealing your login credentials or sensitive financial information. +
- you have access to an account on a web platform. +
- a website showed some specific content on a certain date. +
Overall, the TLSNotary protocol can be used in any scenario where you need to +prove to a third party facts about the content of a TLS connection.
+Some interesting aspects of TLSNotary are:
+-
+
- The protocol is transparent to the web server, because it is not aware of the +notarization process. For the server it just looks like normal browsing. +
- Data is kept private from the Notary. The Notary only sees the ciphertext and +never has access to the plaintext. +
- No modifications to the TLS protocol are needed. You can use it without any +changes to web servers. +
- The Notary and the Verifier can be the same entity. That means if you as a +Verifier do not want to trust some Notary server, you can run one yourself. +
Protocol
+ +Overview
+The following diagram is a high-level protocol overview introducing the main components of +TLSNotary.
+
Notarization Phase
+During the Notarization Phase the Requester, otherwise referred to as the User, and the Notary 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
Serveris not revealed to theNotary, but theRequesteris capable of proving theServeridentity to aVerifierlater.
+ - The
Notaryonly ever sees the encrypted application data of the TLS session.
+ - The protocol guarantees that the
Requesteris not solely capable of constructing requests, nor can they forge responses from theServer.
+
Requester
+The Requester is the party which runs the TLS connection with the Server. The Requester constructs application payloads, eg. HTTP requests, and coordinates with the Notary to encrypt them with the TLS session keys prior to sending them. Subsequently, the Requester works with the Notary to decrypt responses from the Server. The plaintext of the application data is only ever revealed to the Requester.
Notary
+The Notary is the party of which the authenticity of the Transcript relies on. During the session the Notary withholds its' shares of the TLS keys and participates in a series of secure 2-party computation protocols with the Requester to operate the TLS connection.
Server
+The Server can be any server which supports TLS. The TLSNotary protocol is entirely transparent to the Server, thus it can not be censored nor does it have to support any additional functionality.
+Transcript
+The primary artifact generated from this phase is called the Transcript. It contains session meta-data, handshake data, and commitments to all the requests and responses. Typically the Transcript is signed by the Notary, however that is not necessary in the case where the Notary will also act as the Verifier in the selective disclosure phase.
++Note that the server ephemeral key does not reveal the identity of the server to the
+Notary.
+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. The resulting shared secret in TLS terms is called the pre-master secret PMS.
+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.
-
+
Serversends its public key toRequester, andRequesterforwards it toNotary
+Requesterpicks a random private key share and computes a public key share
+Notarypicks a random private key share and computes a public key share
+Notarysends toRequesterwho computes and sends toServer
+Requestercomputes an EC point
+Notarycomputes an EC point
+- Addition of points and results in the coordinate , which is
PMS. (The coordinate is not used in TLS)
+
Using the notation from here, our goal is to compute + +in such a way that
+-
+
- Neither party learns the other party's value +
- Neither party learns , only their respective shares of . +
We will use two maliciously secure protocols described on p.25 in the paper Efficient Secure Two-Party Exponentiation:
+-
+
A2Mprotocol, which converts additive shares into multiplicative shares, i.e. given sharesaandbsuch thata + b = c, it converts them into sharesdandesuch thatd * e = c
+M2Aprotocol, which converts multiplicative shares into additive shares
+
We apply A2M to to get and also we apply A2M to to get . Then the above can be rewritten as:
+
Then the first party locally computes the first factor and gets , the second party locally computes the second factor and gets . Then we can again rewrite as:
++
Now we apply M2A to to get , which leads us to two final terms each of which is the share of of the respective party:
+ +
Overview
+The pre-master secret (PMS) must be put through a PRF (pseudo-random function) defined by the TLS spec in order to compute the symmetric TLS keys and also to compute the verify_data for the Client_Finished and the Server_Finished messages.
Below we describe how the parties (N stands for Notary and U stands for User) who have their shares of PMS can use 2PC to compute the PRF.
++Since the TLSNotary protocol already uses Garbled Circuits and Oblivious Transfer which give 128-bit computational security for the parties against each other, we argue that it is acceptable to perform some PRF computations outside of 2PC as long as it is done with at least 128-bit security. +Performing some PRF computations outside of 2PC allows to save on computation and bandwidth.
+
++Note that the User's TLS connection retains the standard TLS security guarantees against any third-party adversary.
+
To elaborate, recall how HMAC is computed (assuming |k| <= block size):
+HMAC(k, m) = H((k ⊕ opad) | H((k ⊕ ipad) | m))
+Notice that both H(k ⊕ opad) and H(k ⊕ ipad) can be computed separately prior to finalization. In this +document we name these units as such:
+-
+
outer hash state: H(k ⊕ opad)
+inner hash state: H(k ⊕ ipad)
+inner hash: H((k ⊕ ipad) | m)
+
In TLS, the master secret is computed like so:
+seed = "master secret" | client_random | server_random
+a0 = seed
+a1 = HMAC(pms, a0)
+a2 = HMAC(pms, a1)
+p1 = HMAC(pms, a1 | seed)
+p2 = HMAC(pms, a2 | seed)
+ms = (p1 | p2)[:48]
+Notice that in each step the key, in this case PMS, is constant. Thus both the outer and inner hash state can be reused for each step.
Below is the description of the all the steps to compute the PRF both inside and outside the 2PC circuit.
Computing the master secret
+Inside the circuit
+-
+
- To evaluate the circuit, the parties input their
PMSshares. The circuit outputs:
+
-
+
- H(PMS ⊕ opad) called
PMSouter hash statetoNand
+ - H(PMS ⊕ ipad) called
PMSinner hash statetoU
+
Outside the circuit
+-
+
-
+
+Ucomputes H((PMS ⊕ ipad) || a0) calledinner hashofa1and passes it toN.
+ -
+
+Ncomputesa1and passes it toU.
+ -
+
+Ucomputes theinner hashofa2and passes it toN.
+ -
+
+Ncomputesa2and passes it toU.
+ -
+
+Ucomputes theinner hashof p2 and passes it toN.
+ -
+
+Ncomputesp2and passes it toU. +>Note that now both parties knowp2which is the last 16 bytes of the master secret. They still don't know the other 32 bytes of the master secret, which ensures adequate security.
+ -
+
+Ucomputes theinner hashofp1.
+
Inside the circuit
+-
+
- To evaluate the circuit,
Ninputs thePMS outer hash stateandUinputsp2and theinner hashofp1. The circuit computes the master secret (MS).
+
Computing the expanded keys
+The parties proceed to compute the expanded keys. The corresponding python code is:
seed = str.encode("key expansion") + server_random + client_random
+a0 = seed
+a1 = hmac.new(ms , a0, hashlib.sha256).digest()
+a2 = hmac.new(ms , a1, hashlib.sha256).digest()
+p1 = hmac.new(ms, a1+seed, hashlib.sha256).digest()
+p2 = hmac.new(ms, a2+seed, hashlib.sha256).digest()
+ek = (p1 + p2)[:40]
+client_write_key = ek[:16]
+server_write_key = ek[16:32]
+client_write_IV = ek[32:36]
+server_write_IV = ek[36:40]
+Inside the circuit
+-
+
- Having computed
MS, the circuit outputs:
+
-
+
- H(MS ⊕ opad) called the
MS outer hash statetoNand
+ - H(MS ⊕ ipad) called the
MS inner hash statetoU
+
Outside the circuit
+-
+
-
+
+Ucomputes theinner hashofa1and sends it toN.
+ -
+
+Ncomputesa1and sends it toU.
+ -
+
+Ucomputes theinner hashofa2and sends it toN.
+ -
+
+Ncomputesa2and sends it toU.
+ -
+
+Ucomputes theinner hash stateofp1and theinner hash stateofp2.
+
Inside the circuit
+-
+
- To evaluate the circuit,
NinputsMS outer hash state(from Step 10) andUinputsinner hash stateofp1andinner hash stateofp2. The circuit computesp1andp2. The circuit outputs xor shares of theexpanded keysto each party.
+
Computing the encrypted Client_Finished
+Inside the circuit
+-
+
- To evaluate the circuit, the parties input their shares of the
expanded keys. The circuit outputs data needed to encrypt and authenticate theClient_Finished(CF) message.
+
Outside the circuit
+The parties proceed to compute verify_data for the CF message. The corresponding python code is:
# (handshake_hash) is a sha256 hash of all TLS handshake message up to this point
+seed = str.encode('client finished') + handshake_hash
+a0 = seed
+a1 = hmac.new(ms, a0, hashlib.sha256).digest()
+p1 = hmac.new(ms, a1+seed, hashlib.sha256).digest()
+verify_data = p1[:12]
+-
+
-
+
+Ucomputesinner hashofa1and sends it toN.
+ -
+
+N(who hasMSouter hash statefrom Step 10) computesa1and sends it toU.
+ -
+
+Ucomputesinner hashofp1and sends it toN.
+ -
+
+Ncomputesp1and getsverify_dataand sends it toU.
+
++Note that it is safe for
+Nto knowverify_dataforCF.
Using the data from Step 17, U proceeds to encrypt and authenticate CF and sends it to the webserver.
Verifying the Server_Finished
+Upon U's receiving the encrypted Server_Finished (SF) from the webserver, the parties proceed to compute verify_data for SF, to enable U to check that the received SF is correct. The corresponding python code is:
# (handshake_hash) is a sha256 hash of all TLS handshake message up to this point
+seed = str.encode('server finished') + handshake_hash
+a0 = seed
+a1 = hmac.new(ms, a0, hashlib.sha256).digest()
+p1 = hmac.new(ms, a1+seed, hashlib.sha256).digest()
+verify_data = p1[:12]
+Outside the circuit
+-
+
-
+
+Ucomputesinner hashofa1and sends it toN.
+ -
+
+N(who hasMSouter hash statefrom Step 10) computesa1and sends it toU.
+ -
+
+Ucomputesinner hashofp1.
+
Inside the circuit
+-
+
- To evaluate the circuit,
NinputsMSouter hash state(from Step 10) andUinputsinner hashofp1. The circuit outputsverify_dataforSFtoU.
+
The parties proceed to decrypt and authenticate the SF in 2PC. U checks that verify_data from SF matches verify_data from Step 25.
Encryption
+Here we will explain our protocol for 2PC encryption using a block cipher in counter-mode.
+Our documentation on Dual Execution with Asymmetric Privacy is recommended prior reading for this section.
+Preliminary
+Ephemeral Keyshare
+It is important to recognise that the Notary's keyshare is an ephemeral secret. It is only private for the duration of the User's TLS session, after which the User is free to learn it without affecting the security of the protocol.
+It is this fact which allows us to achieve malicious security for relatively low cost. More details on this here.
+Premature Leakage
+A small amount of undetected premature keyshare leakage is quite tolerable. For example, if the Notary leaks 3 bits of their keyshare, it gives the User no meaningful advantage in any attack, as she could have simply guessed the bits correctly with probability and mounted the same attack. Assuming a sufficiently long cipher key is used, eg. 128 bits, this is not a concern.
+The equality check at the end of our protocol ensures that premature leakage is detected with a probability of where k is the number of leaked bits. The Notary is virtually guaranteed to detect significant leakage and can abort prior to notarization.
+Plaintext Leakage
+Our protocol assures no leakage of the plaintext to the Notary during both encryption and decryption. The Notary reveals their keyshare at the end of the protocol, which allows the Notary to open their garbled circuits and oblivious transfers completely to the User. The User can then perform a series of consistency checks to ensure that the Notary behaved honestly. Because these consistency checks do not depend on any inputs of the User, aborting does not reveal any sensitive information (in contrast to standard DualEx which does).
+Integrity
+During the entirety of the TLS session the User performs the role of the garbled circuit generator, thus ensuring that a malicious Notary can not corrupt or otherwise compromise the integrity of messages sent to/from the Server.
+Notation
+-
+
- is one block of plaintext +
- is the corresponding block of ciphertext, ie +
- is the cipher key +
- is the counter block +
- and denote the User and Notary cipher keyshares, respectively, where +
- is a mask randomly selected by the User +
- is the encrypted counter-block, ie +
- denotes the block cipher used by the TLS session +
- denotes a binding commitment to the value +
- denotes a garbled encoding of chosen by party +
Encryption Protocol
+The encryption protocol uses DEAP without any special variations. The User and Notary directly compute the ciphertext for each block of a message the User wishes to send to the Server:
++
The User creates a commitment to the plaintext active labels for the Notary's circuit where is a random key known only to the User. The User sends this commitment to the Notary to be used in the authdecode protocol later. It's critical that the User commits to prior to the Notary revealing in the final phase of DEAP. This ensures that if is a commitment to valid labels, then it must be a valid commitment to the plaintext . This is because learning the complementary wire label for any bit of prior to learning is virtually impossible.
+Decryption Protocol
+The protocol for decryption is very similar but has some key differences to encryption.
+For decryption, DEAP is used for every block of the ciphertext to compute the masked encrypted counter-block:
++
This mask , chosen by the User, hides from the Notary and thus the plaintext too. Conversely, the User can simply remove this mask in order to compute the plaintext .
+Following this, the User can retrieve the wire labels from the Notary using OT.
+Similarly to the procedure for encryption, the User creates a commitment where is a random key known only to the User. The User sends this commitment to the Notary to be used in the authdecode protocol later.
+Proving the validity of
+In addition to computing the masked encrypted counter-block, the User must also prove that the labels they chose afterwards actually correspond to the ciphertext sent by the Server.
+This is can be done efficiently in one execution using the zero-knowledge protocol described in [JKO13] the same as we do in the final phase of DEAP.
+The Notary garbles a circuit which computes:
++
Notice that the User and Notary will already have computed when they computed earlier. Conveniently, the Notary can re-use the garbled labels as input labels for this circuit. For more details on the reuse of garbled labels see [AMR17].
+ +Commitment
+At the end of the TLSNotary protocol, the User has the authenticated AES ciphertext which can be thought of as a commitment to the plaintext. This form of commitment is not amenable to use cases when the User wants to make part of the plaintext public while keeping another part private. Naively, the User's option is to prove the decryption of the ciphertext in zero-knowledge which is computationally expensive.
+We describe two less computationally heavy approaches for converting the AES ciphertext commitments.
+The first approach is useful for commitments to the data which the User intends to make public. It is based on decrypting the ciphertext with Garbled Circuits and producing a hash commitment to the wire labels.
+The second approach is useful for commitments to the private data which the User later intends to prove statements about in zero-knowledge. This approach produces a Poseidon hash over the private data.
+ +Commitment to public data
+We describe an interactive protocol between the User U and the Notary N, whereby U can convert the authenticated AES ciphertext into a hash commitment to Garbled Circuits wire labels.
Creating the new commitment
+-
+
-
+
At the end of the TLSNotary session, both
+UandNknow the authenticated AESciphertext.
+ -
+
+Nreveals his TLS session key shares toU.
+ -
+
+Udecrypts theciphertextin the clear and learns the plaintextp.
+ -
+
+Npicks aseedand uses it as the source of randomness to generate (in the semi-honest model) a privacy-free garbled circuit whose functionality is to accept the plaintext input, encrypt it, and output the ciphertext.
+ -
+
With
+pas her circuit input,Ureceives input wire labelsIWLsvia Oblivious Transfer and then evaluates the circuit on thoseIWLs. The result of the evaluation are output wire labelsOWLswhichUdoes not know the decoding for.
+ -
+
+Usends two commitments:commitment to IWLsandcommitment to OWLstoN.
+ -
+
+Nreveals theseedandUchecks that the circuit (including itsIWLsandOWLs) was generated correctly and, if successful, reveals herOWLs.
+ -
+
+Nverifiescommitment to OWLsand then checks that decodedOWLsmatch theciphertext(from Step 0) and, if successful, signs (seed+commitment to IWLs).
+
++Now, (
+seed+commitment to IWLs) becomeU's new commitment top.
Verifying the commitment
+Verifier performs the following steps:
+-
+
-
+
Receives the following from
+U: plaintextp,signaturefor (seed+commitment to IWLs),seed,commitment to IWLs.
+ -
+
(using a trusted
+Ns pubkey) Verifies thesignature.
+ -
+
Re-generates the
+IWLsfrom theseed.
+ -
+
Picks only those
+IWLswhich correspond topand checks that the commitment to thoseIWLsmatchescommitment to IWLs.
+ -
+
Accepts
+pas authentic.
+
Dynamic commitment using a Merkle tree
+In situations where U does not know in advance which subset of the public data she will be revealing later to the Verifier, U can commit to the Merkle tree of all her input wire labels (from Step 4 above).
+Later, U can reveal only those Merkle leaves which she wants to make public to the Verifier.
Secure 2-Party Computation
+ +Dual Execution with Asymmetric Privacy
+Introduction
+Malicious secure 2-party computation with garbled circuits typically comes at the expense of dramatically lower efficiency compared to execution in the semi-honest model. One technique, called Dual Execution [MF06] [HKE12], achieves malicious security with a minimal 2x overhead. However, it comes with the concession that a malicious adversary may learn bits of the other's input with probability .
+We present a variant of Dual Execution which provides different trade-offs. Our variant ensures complete privacy for one party, by sacrificing privacy entirely for the other. Hence the name, Dual Execution with Asymmetric Privacy (DEAP). During the execution phase of the protocol both parties have private inputs. The party with complete privacy learns the authentic output prior to the final stage of the protocol. In the final stage, prior to the equality check, one party reveals their private input. This allows a series of consistency checks to be performed which guarantees that the equality check can not cause leakage.
+Similarly to standard DualEx, our variant ensures output correctness and detects leakage (of the revealing parties input) with probability where is the number of bits leaked.
+Preliminary
+The protocol takes place between Alice and Bob who want to compute where and are Alice and Bob's inputs respectively. The privacy of Alice's input is ensured, while Bob's input will be revealed in the final steps of the protocol.
+Premature Leakage
+Firstly, our protocol assumes a small amount of premature leakage of Bob's input is tolerable. By premature, we mean prior to the phase where Bob is expected to reveal his input.
+If Alice is malicious, she has the opportunity to prematurely leak bits of Bob's input with probability of it going undetected.
+Aborts
+We assume that it is acceptable for either party to cause the protocol to abort at any time, with the condition that no information of Alice's inputs are leaked from doing so.
+Committed Oblivious Transfer
+In the last phase of our protocol Bob must open all oblivious transfers he sent to Alice. To achieve this, we require a very relaxed flavor of committed oblivious transfer. For more detail on these relaxations see section 2 of Zero-Knowledge Using Garbled Circuits [JKO13].
+Notation
+-
+
- and are Alice and Bob's inputs, respectively. +
- denotes an encoding of chosen by Alice. +
- and are Alice and Bob's encoded active inputs, respectively, ie . +
- denotes a binding commitment to +
- denotes a garbled circuit for computing , where:
+
-
+
- +
- . +
+ - denotes output decoding information where +
- denotes the global offset of a garbled circuit where +
- denotes a secure pseudo-random generator +
- denotes a secure hash function +
Protocol
+The protocol can be thought of as three distinct phases: The setup phase, execution, and equality-check.
+Setup
+-
+
- Alice creates a garbled circuit with corresponding input labels , and output label commitment . +
- Bob creates a garbled circuit with corresponding input labels . +
- For committed OT, Bob picks a seed and uses it to generate all random-tape for his OTs with . Bob sends to Alice. +
- Alice retrieves her active input labels from Bob using OT. +
- Bob retrieves his active input labels from Alice using OT. +
- Alice sends , , and to Bob. +
- Bob sends , , and to Alice. +
Execution
+Both Alice and Bob can execute this phase of the protocol in parallel as described below:
+Alice
+-
+
- Evaluates using and to acquire . +
- Decodes to using which she received earlier. She computes which we will call . +
- Computes a commitment where is a key only known to Alice. She sends this commitment to Bob. +
- Waits to receive from Bob1. +
- Checks that is authentic, aborting if not, then decodes to using . +
At this stage, if Bob is malicious, Alice could detect that . However, Alice must not react in this case. She proceeds with the protocol regardless, having the authentic output .
+Bob
+-
+
- Evaluates using and to acquire . He checks against the commitment which Alice sent earlier, aborting if it is invalid. +
- Decodes to using which he received earlier. He computes which we'll call , and stores it for the equality check later. +
- Sends to Alice1. +
- Receives from Alice and stores it for the equality check later. +
Bob, even if malicious, has learned nothing except the purported output and is not convinced it is correct. In the next phase Alice will attempt to convince Bob that it is.
+Alice, if honest, has learned the correct output thanks to the authenticity property of garbled circuits. Alice, if malicious, has potentially learned Bob's entire input .
+1
+
+This is a significant deviation from standard DualEx protocols such as [HKE12]. Typically the output labels are not returned to the Generator, instead, output authenticity is established during a secure equality check at the end. See the section below for more detail.
+Equality Check
+-
+
- Bob opens his garbled circuit and OT by sending , and to Alice. +
- Alice, can now derive the purported input labels to Bob's garbled circuit . +
- Alice uses to open all of Bob's OTs for and verifies that they were performed honestly. Otherwise she aborts. +
- Alice verifies that was garbled honestly by checking . Otherwise she aborts. +
- Alice now opens by sending and to Bob. +
- Bob verifies then asserts , aborting otherwise. +
Bob is now convinced that is correct, ie . Bob is also assured that Alice only learned up to k bits of his input prior to revealing, with a probability of of it being undetected.
+Analysis
+Malicious Alice
+On the Leakage of Corrupted Garbled Circuits [DPB18] is recommended reading on this topic.
+During the first execution, Alice has some degrees of freedom in how she garbles . According to [DPB18], when using a modern garbling scheme such as [ZRE15], these corruptions can be analyzed as two distinct classes: detectable and undetectable.
+Recall that our scheme assumes Bob's input is an ephemeral secret which can be revealed at the end. For this reason, we are entirely unconcerned about the detectable variety. Simply providing Bob with the output labels commitment is sufficient to detect these types of corruptions. In this context, our primary concern is regarding the correctness of the output of .
+[DPB18] shows that any undetectable corruption made to is constrained to the arbitrary insertion or removal of NOT gates in the circuit, such that computes instead of . Note that any corruption of has an equivalent effect. [DPB18] also shows that Alice's ability to exploit this is constrained by the topology of the circuit.
+Recall that in the final stage of our protocol Bob checks that the output of matches the output of , or more specifically:
++
For the moment we'll assume Bob garbles honestly and provides the same inputs for both evaluations.
++
In the scenario where Bob reveals the output of prior to Alice committing to there is a trivial adaptive attack available to Alice. As an extreme example, assume Alice could choose such that . For most practical functions this is not possible to garble without detection, but for the sake of illustration we humor the possibility. In this case she could simply compute where in order to pass the equality check.
+To address this, Alice is forced to choose , and prior to Bob revealing the output. In this case it is obvious that any valid combination of must satisfy all constraints on . Thus, for any non-trivial , choosing a valid combination would be equivalent to guessing correctly. In which case, any attack would be detected by the equality check with probability where k is the number of guessed bits of . This result is acceptable within our model as explained earlier.
+Malicious Bob
+Zero-Knowledge Using Garbled Circuits [JKO13] is recommended reading on this topic.
+The last stage of our variant is functionally equivalent to the protocol described in [JKO13]. After Alice evaluates and commits to , Bob opens his garbled circuit and all OTs entirely. Following this, Alice performs a series of consistency checks to detect any malicious behavior. These consistency checks do not depend on any of Alice's inputs, so any attempted selective failure attack by Bob would be futile.
+Bob's only options are to behave honestly, or cause Alice to abort without leaking any information.
+Malicious Alice & Bob
+They deserve whatever they get.
+ +Computing MAC in 2PC
+-
+
- What is a MAC +
- How a MAC is computed in AES-GCM +
- Computing MAC using secure two-party computation (2PC) +
1. What is a MAC
+When sending an encrypted ciphertext to the Webserver, the User attaches a +checksum to it. The Webserver uses this checksum to check whether the ciphertext +has been tampered with while in transit. This checksum is known as the +"authentication tag" and also as the "Message Authentication Code" (MAC).
+In order to create a MAC for some ciphertext not only the ciphertext but also +some secret key is used as an input. This makes it impossible to forge some +ciphertext without knowing the secret key.
+The first few paragraphs of this article +explain what would happen if there was no MAC: it would be possible for a +malicious actor to modify the plaintext by flipping certain bits of the +ciphertext.
+2. How a MAC is computed in AES-GCM
+In TLS the plaintext is split up into chunks called "TLS records". Each TLS
+record is encrypted and a MAC is computed for the ciphertext. The MAC (in
+AES-GCM) is obtained by XORing together the GHASH output and the GCTR output. Let's see how each of those outputs is computed:
2.1 GCTR output
+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).
2.2 GHASH output
+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 ".
+and are elements of the extension field .
-
+
- "•" is a special type of multiplication called
multiplication in a finite fielddescribed in section 6.3 of the NIST publication.
+ - ⊕ is
addition in a finite fieldand it is defined as XOR.
+
In other words, GHASH splits up the ciphertext into 16-byte blocks, each block
+is numbered etc. There's also
+which is called the GHASH key, which just is the AES-encrypted zero-block. We
+need to raise to as many powers as there are blocks, i.e. if
+we have 5 blocks then we need 5 powers: .
+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 :
1. result = 0
+2. R = 0xE1000000000000000000000000000000
+3. bit_length = 128
+4. for i=0 upto bit_length-1
+5. if y[i] == 1
+6. result ^= x
+7. x = (x >> 1) ^ ((x & 1) * R)
+8. return result
+Standard math properties hold in finite field math, viz. commutative: +and distributive: .
+3. Computing MAC using secure two-party computation (2PC)
+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 i.e. the GHASH key
+share. At the start of the protocol each party has:
-
+
- ciphertext blocks . +
- XOR share of : the
Userhas +and theNotaryhas .
+ - XOR share of the
GCTR output: theUserhas +and theNotaryhas .
+
Note that 2. and 3. were obtained at an earlier stage of the TLSNotary protocol.
+3.1 Example with a single ciphertext block
+To illustrate what we want to achieve, we consider the case of just having
+a single ciphertext block . The GHASH_output will be:
+
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 :
Notary:
Finally, the Notary sends to the User who obtains:
+
For longer ciphertexts, the problem is that higher powers of the hashkey + cannot be computed locally, because we deal with additive sharings, +i.e..
+3.2 Computing ciphertexts with an arbitrary number of blocks
+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 and into +multiplicative shares and . +
- This allows each party to locally compute the needed higher powers of these multiplicative
+shares, i.e for blocks of ciphertext:
+
-
+
- the user computes +
- the notary computes +
+ - Then both parties convert each of these multiplicative shares back to additive shares
+
-
+
- the user ends up with +
- the notary ends up with +
+ - Each party can now locally compute their additive MAC share . +
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.
+
3.2.1 (A2M) Convert additive shares of H into multiplicative share
+At first (step 1) we have to get a multiplicative share of , +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 individual oblivious transfers +, where
+-
+
- is some random value used for all oblivious transfers +
- is a random mask used per oblivious transfer, with +
- 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 . In the end the multiplicative share of +the user will simply be the inverse of the +random value, and the notary will sum all his OT outputs, so that all the + will vanish and hence he gets his multiplicative share +.
++
3.2.2 (M2A) Convert multiplicative shares 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 back into +additive shares . We only show how the method works for the share +, because it is the same for higher powers.
+The user will be the OT sender and decompose his shares into individual +oblivious transfers , +where , depending on the receiver's choices. Each of these +OTs is masked with a random value . 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 and end up with his additive +share , and the notary will do the same for all the results of the +oblivious transfers and get .
++
3.3 Free Squaring
+In the actual implementation of the protocol we only compute odd multiplicative +shares, i.e. , 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 :
++
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.
+3.3 Creating a robust protocol
+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.
Finite-Field Arithmetic
+Some protocols used in TLSNotary need to convert two-party sharings of products +or sums of some field elements into each other. For this purpose we use share +conversion protocols which use oblivious transfer (OT) as a sub-protocol. Here +we want to have a closer look at the security guarantees these protocols offer.
+Adding covert security
+Our goal is to add covert security to our share conversion protocols. This
+means that we want an honest party to be able to detect a malicious adversary,
+who is then able to abort the protocol. Our main concern is that the adversary
+might be able to leak private inputs of the honest party without being noticed.
+For this reason we require that the adversary cannot do anything which would
+give him a better chance than guessing the private input at random, which is
+guessing bits with a probability of for not being detected.
In the following we want to have a closer look at how the sender and receiver can +deviate from the protocol.
+Malicious receiver
+Note that in our protocol a malicious receiver cannot forge the protocol output, +since he does not send anything to the sender during protocol execution. Even +when this protocol is embedded into an outer protocol, where at some point the +receiver has to open his output or a computation involving it, then all he can +do is to open an output with , which is just equivalent to +changing his input from .
+Malicious sender
+In the case of a malicious sender the following things can happen:
+-
+
- The sender can impose an arbitrary field element as input onto the +receiver without him noticing. To do this he simply sends in +every OT, where is i-th bit of . +
- The sender can execute a selective-failure attack, which allows him to learn +any predicate about the receiver's input. For each OT round , the sender +alters one of the OT values to be , where . This will cause that in the end the equation + no longer holds but only if the forged OT value has +actually been picked by the receiver. +
- The sender does not use a random number generator with a seed to sample +the masks , instead he simply chooses them at will. +
M2A Protocol Review
+Without loss of generality let us recall the Multiplication-To-Addition (M2A) +protocol, but our observations also apply to the Addition-To-Multiplication +(A2M) protocol, which is very similar. We start with a short review of the M2A +protocol.
+Let there be a sender with some field element and some receiver with another +field element . After protocol execution the sender ends up with and the +receiver ends up with , so that .
+-
+
- +
- - rng seed +
- - bit-length of elements in +
- - bit-length of rng seed +
OT Sender
+with input
+-
+
- Sample some random masks: +
- For every compute:
+
-
+
- +
- +
+ - Compute new share: +
- Send OTs to receiver: +
OT Receiver
+with input
+-
+
- Set (from OT) +
- Compute new share: +
Replay protocol
+In order to mitigate the mentioned protocol deviations in the case of a malicious +sender we will introduce a replay protocol.
+In this section we will use capital letters for values sent in the replay +protocol, which in the case of an honest sender are equal to their lowercase +counterparts.
+The idea for the replay protocol is that at some point after the conversion +protocol, the sender has to reveal the rng seed and his input to the +receiver. In order to do this, he will send and to the receiver after +the conversion protocol has been executed. If the sender is honest then of +course and . The receiver can then check if the value he picked +during protocol execution does match what he can now reconstruct from and +, i.e. that .
+Using this replay protocol the sender at some point reveals all his secrets +because he sends his rng seed and protocol input to the receiver. This means +that we can only use covertly secure share conversion with replay as a +sub-protocol if it is acceptable for the outer protocol, that the input to +share-conversion becomes public at some later point.
+Now in practice we often want to execute several rounds of share-conversion, as we +need to convert several field elements. Because of this we let the sender use +the same rng seed to seed his rng once and then he uses this rng instance +for all protocol rounds. This means we have protocol executions , and all masks produced from this rng seed . +So the sender will write his seed and all the to some tape, which in +the end is sent to the receiver. As a security precaution we also let the sender +commit to his rng seed before the first protocol execution. In detail:
+Sender
+-
+
- Sender has some inputs and picks some rng seed . +
- Sender commits to his rng seed and sends the commitment to the receiver. +
- Sender sends all his OTs for protocol executions. +
- Sender sends tape which contains the rng seed and all the . +
Receiver
+-
+
- Receiver checks that is indeed the committed rng seed. +
- For every protocol execution the receiver checks that . +
Having a look at the ways a malicious sender could cheat from earlier, we +notice:
+-
+
- The sender can no longer impose an arbitrary field element onto the +receiver, because the receiver would notice that during the replay. +
- The sender can still carry out a selective-failure attack, but this is +equivalent to guessing bits of at random with a probability of + for being undetected. +
- The sender is now forced to use an rng seed to produce the masks, because +during the replay, these masks are reproduced from and indirectly checked +via . +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/protocol/2pc/ff-arithmetic.html b/protocol/2pc/ff-arithmetic.html
new file mode 100644
index 0000000..9015f07
--- /dev/null
+++ b/protocol/2pc/ff-arithmetic.html
@@ -0,0 +1,335 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Dual Execution with Asymmetric Privacy
+Introduction
+Malicious secure 2-party computation with garbled circuits typically comes at the expense of dramatically lower efficiency compared to execution in the semi-honest model. One technique, called Dual Execution [MF06] [HKE12], achieves malicious security with a minimal 2x overhead. However, it comes with the concession that a malicious adversary may learn bits of the other's input with probability .
+We present a variant of Dual Execution which provides different trade-offs. Our variant ensures complete privacy for one party, by sacrificing privacy entirely for the other. Hence the name, Dual Execution with Asymmetric Privacy (DEAP). During the execution phase of the protocol both parties have private inputs. The party with complete privacy learns the authentic output prior to the final stage of the protocol. In the final stage, prior to the equality check, one party reveals their private input. This allows a series of consistency checks to be performed which guarantees that the equality check can not cause leakage.
+Similarly to standard DualEx, our variant ensures output correctness and detects leakage (of the revealing parties input) with probability where is the number of bits leaked.
+Preliminary
+The protocol takes place between Alice and Bob who want to compute where and are Alice and Bob's inputs respectively. The privacy of Alice's input is ensured, while Bob's input will be revealed in the final steps of the protocol.
+Premature Leakage
+Firstly, our protocol assumes a small amount of premature leakage of Bob's input is tolerable. By premature, we mean prior to the phase where Bob is expected to reveal his input.
+If Alice is malicious, she has the opportunity to prematurely leak bits of Bob's input with probability of it going undetected.
+Aborts
+We assume that it is acceptable for either party to cause the protocol to abort at any time, with the condition that no information of Alice's inputs are leaked from doing so.
+Committed Oblivious Transfer
+In the last phase of our protocol Bob must open all oblivious transfers he sent to Alice. To achieve this, we require a very relaxed flavor of committed oblivious transfer. For more detail on these relaxations see section 2 of Zero-Knowledge Using Garbled Circuits [JKO13].
+Notation
+-
+
- and are Alice and Bob's inputs, respectively. +
- denotes an encoding of chosen by Alice. +
- and are Alice and Bob's encoded active inputs, respectively, ie . +
- denotes a binding commitment to +
- denotes a garbled circuit for computing , where:
+
-
+
- +
- . +
+ - denotes output decoding information where +
- denotes the global offset of a garbled circuit where +
- denotes a secure pseudo-random generator +
- denotes a secure hash function +
Protocol
+The protocol can be thought of as three distinct phases: The setup phase, execution, and equality-check.
+Setup
+-
+
- Alice creates a garbled circuit with corresponding input labels , and output label commitment . +
- Bob creates a garbled circuit with corresponding input labels . +
- For committed OT, Bob picks a seed and uses it to generate all random-tape for his OTs with . Bob sends to Alice. +
- Alice retrieves her active input labels from Bob using OT. +
- Bob retrieves his active input labels from Alice using OT. +
- Alice sends , , and to Bob. +
- Bob sends , , and to Alice. +
Execution
+Both Alice and Bob can execute this phase of the protocol in parallel as described below:
+Alice
+-
+
- Evaluates using and to acquire . +
- Decodes to using which she received earlier. She computes which we will call . +
- Computes a commitment where is a key only known to Alice. She sends this commitment to Bob. +
- Waits to receive from Bob1. +
- Checks that is authentic, aborting if not, then decodes to using . +
At this stage, if Bob is malicious, Alice could detect that . However, Alice must not react in this case. She proceeds with the protocol regardless, having the authentic output .
+Bob
+-
+
- Evaluates using and to acquire . He checks against the commitment which Alice sent earlier, aborting if it is invalid. +
- Decodes to using which he received earlier. He computes which we'll call , and stores it for the equality check later. +
- Sends to Alice1. +
- Receives from Alice and stores it for the equality check later. +
Bob, even if malicious, has learned nothing except the purported output and is not convinced it is correct. In the next phase Alice will attempt to convince Bob that it is.
+Alice, if honest, has learned the correct output thanks to the authenticity property of garbled circuits. Alice, if malicious, has potentially learned Bob's entire input .
+1
+
+This is a significant deviation from standard DualEx protocols such as [HKE12]. Typically the output labels are not returned to the Generator, instead, output authenticity is established during a secure equality check at the end. See the section below for more detail.
+Equality Check
+-
+
- Bob opens his garbled circuit and OT by sending , and to Alice. +
- Alice, can now derive the purported input labels to Bob's garbled circuit . +
- Alice uses to open all of Bob's OTs for and verifies that they were performed honestly. Otherwise she aborts. +
- Alice verifies that was garbled honestly by checking . Otherwise she aborts. +
- Alice now opens by sending and to Bob. +
- Bob verifies then asserts , aborting otherwise. +
Bob is now convinced that is correct, ie . Bob is also assured that Alice only learned up to k bits of his input prior to revealing, with a probability of of it being undetected.
+Analysis
+Malicious Alice
+On the Leakage of Corrupted Garbled Circuits [DPB18] is recommended reading on this topic.
+During the first execution, Alice has some degrees of freedom in how she garbles . According to [DPB18], when using a modern garbling scheme such as [ZRE15], these corruptions can be analyzed as two distinct classes: detectable and undetectable.
+Recall that our scheme assumes Bob's input is an ephemeral secret which can be revealed at the end. For this reason, we are entirely unconcerned about the detectable variety. Simply providing Bob with the output labels commitment is sufficient to detect these types of corruptions. In this context, our primary concern is regarding the correctness of the output of .
+[DPB18] shows that any undetectable corruption made to is constrained to the arbitrary insertion or removal of NOT gates in the circuit, such that computes instead of . Note that any corruption of has an equivalent effect. [DPB18] also shows that Alice's ability to exploit this is constrained by the topology of the circuit.
+Recall that in the final stage of our protocol Bob checks that the output of matches the output of , or more specifically:
++
For the moment we'll assume Bob garbles honestly and provides the same inputs for both evaluations.
++
In the scenario where Bob reveals the output of prior to Alice committing to there is a trivial adaptive attack available to Alice. As an extreme example, assume Alice could choose such that . For most practical functions this is not possible to garble without detection, but for the sake of illustration we humor the possibility. In this case she could simply compute where in order to pass the equality check.
+To address this, Alice is forced to choose , and prior to Bob revealing the output. In this case it is obvious that any valid combination of must satisfy all constraints on . Thus, for any non-trivial , choosing a valid combination would be equivalent to guessing correctly. In which case, any attack would be detected by the equality check with probability where k is the number of guessed bits of . This result is acceptable within our model as explained earlier.
+Malicious Bob
+Zero-Knowledge Using Garbled Circuits [JKO13] is recommended reading on this topic.
+The last stage of our variant is functionally equivalent to the protocol described in [JKO13]. After Alice evaluates and commits to , Bob opens his garbled circuit and all OTs entirely. Following this, Alice performs a series of consistency checks to detect any malicious behavior. These consistency checks do not depend on any of Alice's inputs, so any attempted selective failure attack by Bob would be futile.
+Bob's only options are to behave honestly, or cause Alice to abort without leaking any information.
+Malicious Alice & Bob
+They deserve whatever they get.
+ +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/protocol/2pc/garbled_circuits.html b/protocol/2pc/garbled_circuits.html
new file mode 100644
index 0000000..cf55d88
--- /dev/null
+++ b/protocol/2pc/garbled_circuits.html
@@ -0,0 +1,224 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Finite-Field Arithmetic
+Some protocols used in TLSNotary need to convert two-party sharings of products +or sums of some field elements into each other. For this purpose we use share +conversion protocols which use oblivious transfer (OT) as a sub-protocol. Here +we want to have a closer look at the security guarantees these protocols offer.
+Adding covert security
+Our goal is to add covert security to our share conversion protocols. This
+means that we want an honest party to be able to detect a malicious adversary,
+who is then able to abort the protocol. Our main concern is that the adversary
+might be able to leak private inputs of the honest party without being noticed.
+For this reason we require that the adversary cannot do anything which would
+give him a better chance than guessing the private input at random, which is
+guessing bits with a probability of for not being detected.
In the following we want to have a closer look at how the sender and receiver can +deviate from the protocol.
+Malicious receiver
+Note that in our protocol a malicious receiver cannot forge the protocol output, +since he does not send anything to the sender during protocol execution. Even +when this protocol is embedded into an outer protocol, where at some point the +receiver has to open his output or a computation involving it, then all he can +do is to open an output with , which is just equivalent to +changing his input from .
+Malicious sender
+In the case of a malicious sender the following things can happen:
+-
+
- The sender can impose an arbitrary field element as input onto the +receiver without him noticing. To do this he simply sends in +every OT, where is i-th bit of . +
- The sender can execute a selective-failure attack, which allows him to learn +any predicate about the receiver's input. For each OT round , the sender +alters one of the OT values to be , where . This will cause that in the end the equation + no longer holds but only if the forged OT value has +actually been picked by the receiver. +
- The sender does not use a random number generator with a seed to sample +the masks , instead he simply chooses them at will. +
M2A Protocol Review
+Without loss of generality let us recall the Multiplication-To-Addition (M2A) +protocol, but our observations also apply to the Addition-To-Multiplication +(A2M) protocol, which is very similar. We start with a short review of the M2A +protocol.
+Let there be a sender with some field element and some receiver with another +field element . After protocol execution the sender ends up with and the +receiver ends up with , so that .
+-
+
- +
- - rng seed +
- - bit-length of elements in +
- - bit-length of rng seed +
OT Sender
+with input
+-
+
- Sample some random masks: +
- For every compute:
+
-
+
- +
- +
+ - Compute new share: +
- Send OTs to receiver: +
OT Receiver
+with input
+-
+
- Set (from OT) +
- Compute new share: +
Replay protocol
+In order to mitigate the mentioned protocol deviations in the case of a malicious +sender we will introduce a replay protocol.
+In this section we will use capital letters for values sent in the replay +protocol, which in the case of an honest sender are equal to their lowercase +counterparts.
+The idea for the replay protocol is that at some point after the conversion +protocol, the sender has to reveal the rng seed and his input to the +receiver. In order to do this, he will send and to the receiver after +the conversion protocol has been executed. If the sender is honest then of +course and . The receiver can then check if the value he picked +during protocol execution does match what he can now reconstruct from and +, i.e. that .
+Using this replay protocol the sender at some point reveals all his secrets +because he sends his rng seed and protocol input to the receiver. This means +that we can only use covertly secure share conversion with replay as a +sub-protocol if it is acceptable for the outer protocol, that the input to +share-conversion becomes public at some later point.
+Now in practice we often want to execute several rounds of share-conversion, as we +need to convert several field elements. Because of this we let the sender use +the same rng seed to seed his rng once and then he uses this rng instance +for all protocol rounds. This means we have protocol executions , and all masks produced from this rng seed . +So the sender will write his seed and all the to some tape, which in +the end is sent to the receiver. As a security precaution we also let the sender +commit to his rng seed before the first protocol execution. In detail:
+Sender
+-
+
- Sender has some inputs and picks some rng seed . +
- Sender commits to his rng seed and sends the commitment to the receiver. +
- Sender sends all his OTs for protocol executions. +
- Sender sends tape which contains the rng seed and all the . +
Receiver
+-
+
- Receiver checks that is indeed the committed rng seed. +
- For every protocol execution the receiver checks that . +
Having a look at the ways a malicious sender could cheat from earlier, we +notice:
+-
+
- The sender can no longer impose an arbitrary field element onto the +receiver, because the receiver would notice that during the replay. +
- The sender can still carry out a selective-failure attack, but this is +equivalent to guessing bits of at random with a probability of + for being undetected. +
- The sender is now forced to use an rng seed to produce the masks, because +during the replay, these masks are reproduced from and indirectly checked +via . +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/protocol/2pc/mac.html b/protocol/2pc/mac.html
new file mode 100644
index 0000000..6824077
--- /dev/null
+++ b/protocol/2pc/mac.html
@@ -0,0 +1,421 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Secure 2-Party Computation
+ +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/protocol/index.html b/protocol/index.html
new file mode 100644
index 0000000..be8e1c0
--- /dev/null
+++ b/protocol/index.html
@@ -0,0 +1,224 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Computing MAC in 2PC
+-
+
- What is a MAC +
- How a MAC is computed in AES-GCM +
- Computing MAC using secure two-party computation (2PC) +
1. What is a MAC
+When sending an encrypted ciphertext to the Webserver, the User attaches a +checksum to it. The Webserver uses this checksum to check whether the ciphertext +has been tampered with while in transit. This checksum is known as the +"authentication tag" and also as the "Message Authentication Code" (MAC).
+In order to create a MAC for some ciphertext not only the ciphertext but also +some secret key is used as an input. This makes it impossible to forge some +ciphertext without knowing the secret key.
+The first few paragraphs of this article +explain what would happen if there was no MAC: it would be possible for a +malicious actor to modify the plaintext by flipping certain bits of the +ciphertext.
+2. How a MAC is computed in AES-GCM
+In TLS the plaintext is split up into chunks called "TLS records". Each TLS
+record is encrypted and a MAC is computed for the ciphertext. The MAC (in
+AES-GCM) is obtained by XORing together the GHASH output and the GCTR output. Let's see how each of those outputs is computed:
2.1 GCTR output
+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).
2.2 GHASH output
+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 ".
+and are elements of the extension field .
-
+
- "•" is a special type of multiplication called
multiplication in a finite fielddescribed in section 6.3 of the NIST publication.
+ - ⊕ is
addition in a finite fieldand it is defined as XOR.
+
In other words, GHASH splits up the ciphertext into 16-byte blocks, each block
+is numbered etc. There's also
+which is called the GHASH key, which just is the AES-encrypted zero-block. We
+need to raise to as many powers as there are blocks, i.e. if
+we have 5 blocks then we need 5 powers: .
+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 :
1. result = 0
+2. R = 0xE1000000000000000000000000000000
+3. bit_length = 128
+4. for i=0 upto bit_length-1
+5. if y[i] == 1
+6. result ^= x
+7. x = (x >> 1) ^ ((x & 1) * R)
+8. return result
+Standard math properties hold in finite field math, viz. commutative: +and distributive: .
+3. Computing MAC using secure two-party computation (2PC)
+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 i.e. the GHASH key
+share. At the start of the protocol each party has:
-
+
- ciphertext blocks . +
- XOR share of : the
Userhas +and theNotaryhas .
+ - XOR share of the
GCTR output: theUserhas +and theNotaryhas .
+
Note that 2. and 3. were obtained at an earlier stage of the TLSNotary protocol.
+3.1 Example with a single ciphertext block
+To illustrate what we want to achieve, we consider the case of just having
+a single ciphertext block . The GHASH_output will be:
+
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 :
Notary:
Finally, the Notary sends to the User who obtains:
+
For longer ciphertexts, the problem is that higher powers of the hashkey + cannot be computed locally, because we deal with additive sharings, +i.e..
+3.2 Computing ciphertexts with an arbitrary number of blocks
+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 and into +multiplicative shares and . +
- This allows each party to locally compute the needed higher powers of these multiplicative
+shares, i.e for blocks of ciphertext:
+
-
+
- the user computes +
- the notary computes +
+ - Then both parties convert each of these multiplicative shares back to additive shares
+
-
+
- the user ends up with +
- the notary ends up with +
+ - Each party can now locally compute their additive MAC share . +
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.
+
3.2.1 (A2M) Convert additive shares of H into multiplicative share
+At first (step 1) we have to get a multiplicative share of , +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 individual oblivious transfers +, where
+-
+
- is some random value used for all oblivious transfers +
- is a random mask used per oblivious transfer, with +
- 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 . In the end the multiplicative share of +the user will simply be the inverse of the +random value, and the notary will sum all his OT outputs, so that all the + will vanish and hence he gets his multiplicative share +.
++
3.2.2 (M2A) Convert multiplicative shares 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 back into +additive shares . We only show how the method works for the share +, because it is the same for higher powers.
+The user will be the OT sender and decompose his shares into individual +oblivious transfers , +where , depending on the receiver's choices. Each of these +OTs is masked with a random value . 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 and end up with his additive +share , and the notary will do the same for all the results of the +oblivious transfers and get .
++
3.3 Free Squaring
+In the actual implementation of the protocol we only compute odd multiplicative +shares, i.e. , 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 :
++
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.
+3.3 Creating a robust protocol
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/protocol/notarization/commitment.html b/protocol/notarization/commitment.html
new file mode 100644
index 0000000..5290fe0
--- /dev/null
+++ b/protocol/notarization/commitment.html
@@ -0,0 +1,228 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Protocol
+ +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/protocol/notarization/encryption.html b/protocol/notarization/encryption.html
new file mode 100644
index 0000000..68c0052
--- /dev/null
+++ b/protocol/notarization/encryption.html
@@ -0,0 +1,267 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Commitment
+At the end of the TLSNotary protocol, the User has the authenticated AES ciphertext which can be thought of as a commitment to the plaintext. This form of commitment is not amenable to use cases when the User wants to make part of the plaintext public while keeping another part private. Naively, the User's option is to prove the decryption of the ciphertext in zero-knowledge which is computationally expensive.
+We describe two less computationally heavy approaches for converting the AES ciphertext commitments.
+The first approach is useful for commitments to the data which the User intends to make public. It is based on decrypting the ciphertext with Garbled Circuits and producing a hash commitment to the wire labels.
+The second approach is useful for commitments to the private data which the User later intends to prove statements about in zero-knowledge. This approach produces a Poseidon hash over the private data.
+ +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/protocol/notarization/index.html b/protocol/notarization/index.html
new file mode 100644
index 0000000..5720dc9
--- /dev/null
+++ b/protocol/notarization/index.html
@@ -0,0 +1,243 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Encryption
+Here we will explain our protocol for 2PC encryption using a block cipher in counter-mode.
+Our documentation on Dual Execution with Asymmetric Privacy is recommended prior reading for this section.
+Preliminary
+Ephemeral Keyshare
+It is important to recognise that the Notary's keyshare is an ephemeral secret. It is only private for the duration of the User's TLS session, after which the User is free to learn it without affecting the security of the protocol.
+It is this fact which allows us to achieve malicious security for relatively low cost. More details on this here.
+Premature Leakage
+A small amount of undetected premature keyshare leakage is quite tolerable. For example, if the Notary leaks 3 bits of their keyshare, it gives the User no meaningful advantage in any attack, as she could have simply guessed the bits correctly with probability and mounted the same attack. Assuming a sufficiently long cipher key is used, eg. 128 bits, this is not a concern.
+The equality check at the end of our protocol ensures that premature leakage is detected with a probability of where k is the number of leaked bits. The Notary is virtually guaranteed to detect significant leakage and can abort prior to notarization.
+Plaintext Leakage
+Our protocol assures no leakage of the plaintext to the Notary during both encryption and decryption. The Notary reveals their keyshare at the end of the protocol, which allows the Notary to open their garbled circuits and oblivious transfers completely to the User. The User can then perform a series of consistency checks to ensure that the Notary behaved honestly. Because these consistency checks do not depend on any inputs of the User, aborting does not reveal any sensitive information (in contrast to standard DualEx which does).
+Integrity
+During the entirety of the TLS session the User performs the role of the garbled circuit generator, thus ensuring that a malicious Notary can not corrupt or otherwise compromise the integrity of messages sent to/from the Server.
+Notation
+-
+
- is one block of plaintext +
- is the corresponding block of ciphertext, ie +
- is the cipher key +
- is the counter block +
- and denote the User and Notary cipher keyshares, respectively, where +
- is a mask randomly selected by the User +
- is the encrypted counter-block, ie +
- denotes the block cipher used by the TLS session +
- denotes a binding commitment to the value +
- denotes a garbled encoding of chosen by party +
Encryption Protocol
+The encryption protocol uses DEAP without any special variations. The User and Notary directly compute the ciphertext for each block of a message the User wishes to send to the Server:
++
The User creates a commitment to the plaintext active labels for the Notary's circuit where is a random key known only to the User. The User sends this commitment to the Notary to be used in the authdecode protocol later. It's critical that the User commits to prior to the Notary revealing in the final phase of DEAP. This ensures that if is a commitment to valid labels, then it must be a valid commitment to the plaintext . This is because learning the complementary wire label for any bit of prior to learning is virtually impossible.
+Decryption Protocol
+The protocol for decryption is very similar but has some key differences to encryption.
+For decryption, DEAP is used for every block of the ciphertext to compute the masked encrypted counter-block:
++
This mask , chosen by the User, hides from the Notary and thus the plaintext too. Conversely, the User can simply remove this mask in order to compute the plaintext .
+Following this, the User can retrieve the wire labels from the Notary using OT.
+Similarly to the procedure for encryption, the User creates a commitment where is a random key known only to the User. The User sends this commitment to the Notary to be used in the authdecode protocol later.
+Proving the validity of
+In addition to computing the masked encrypted counter-block, the User must also prove that the labels they chose afterwards actually correspond to the ciphertext sent by the Server.
+This is can be done efficiently in one execution using the zero-knowledge protocol described in [JKO13] the same as we do in the final phase of DEAP.
+The Notary garbles a circuit which computes:
++
Notice that the User and Notary will already have computed when they computed earlier. Conveniently, the Notary can re-use the garbled labels as input labels for this circuit. For more details on the reuse of garbled labels see [AMR17].
+ +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/protocol/notarization/key_exchange.html b/protocol/notarization/key_exchange.html
new file mode 100644
index 0000000..32538c8
--- /dev/null
+++ b/protocol/notarization/key_exchange.html
@@ -0,0 +1,254 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Notarization Phase
+During the Notarization Phase the Requester, otherwise referred to as the User, and the Notary 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
Serveris not revealed to theNotary, but theRequesteris capable of proving theServeridentity to aVerifierlater.
+ - The
Notaryonly ever sees the encrypted application data of the TLS session.
+ - The protocol guarantees that the
Requesteris not solely capable of constructing requests, nor can they forge responses from theServer.
+
Requester
+The Requester is the party which runs the TLS connection with the Server. The Requester constructs application payloads, eg. HTTP requests, and coordinates with the Notary to encrypt them with the TLS session keys prior to sending them. Subsequently, the Requester works with the Notary to decrypt responses from the Server. The plaintext of the application data is only ever revealed to the Requester.
Notary
+The Notary is the party of which the authenticity of the Transcript relies on. During the session the Notary withholds its' shares of the TLS keys and participates in a series of secure 2-party computation protocols with the Requester to operate the TLS connection.
Server
+The Server can be any server which supports TLS. The TLSNotary protocol is entirely transparent to the Server, thus it can not be censored nor does it have to support any additional functionality.
+Transcript
+The primary artifact generated from this phase is called the Transcript. It contains session meta-data, handshake data, and commitments to all the requests and responses. Typically the Transcript is signed by the Notary, however that is not necessary in the case where the Notary will also act as the Verifier in the selective disclosure phase.
++Note that the server ephemeral key does not reveal the identity of the server to the
+Notary.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/protocol/notarization/prf.html b/protocol/notarization/prf.html
new file mode 100644
index 0000000..7d8a5e4
--- /dev/null
+++ b/protocol/notarization/prf.html
@@ -0,0 +1,394 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 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. The resulting shared secret in TLS terms is called the pre-master secret PMS.
+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.
-
+
Serversends its public key toRequester, andRequesterforwards it toNotary
+Requesterpicks a random private key share and computes a public key share
+Notarypicks a random private key share and computes a public key share
+Notarysends toRequesterwho computes and sends toServer
+Requestercomputes an EC point
+Notarycomputes an EC point
+- Addition of points and results in the coordinate , which is
PMS. (The coordinate is not used in TLS)
+
Using the notation from here, our goal is to compute + +in such a way that
+-
+
- Neither party learns the other party's value +
- Neither party learns , only their respective shares of . +
We will use two maliciously secure protocols described on p.25 in the paper Efficient Secure Two-Party Exponentiation:
+-
+
A2Mprotocol, which converts additive shares into multiplicative shares, i.e. given sharesaandbsuch thata + b = c, it converts them into sharesdandesuch thatd * e = c
+M2Aprotocol, which converts multiplicative shares into additive shares
+
We apply A2M to to get and also we apply A2M to to get . Then the above can be rewritten as:
+
Then the first party locally computes the first factor and gets , the second party locally computes the second factor and gets . Then we can again rewrite as:
++
Now we apply M2A to to get , which leads us to two final terms each of which is the share of of the respective party:
+ +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/protocol/notarization/public_data_commitment.html b/protocol/notarization/public_data_commitment.html
new file mode 100644
index 0000000..50dce3d
--- /dev/null
+++ b/protocol/notarization/public_data_commitment.html
@@ -0,0 +1,277 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Overview
+The pre-master secret (PMS) must be put through a PRF (pseudo-random function) defined by the TLS spec in order to compute the symmetric TLS keys and also to compute the verify_data for the Client_Finished and the Server_Finished messages.
Below we describe how the parties (N stands for Notary and U stands for User) who have their shares of PMS can use 2PC to compute the PRF.
++Since the TLSNotary protocol already uses Garbled Circuits and Oblivious Transfer which give 128-bit computational security for the parties against each other, we argue that it is acceptable to perform some PRF computations outside of 2PC as long as it is done with at least 128-bit security. +Performing some PRF computations outside of 2PC allows to save on computation and bandwidth.
+
++Note that the User's TLS connection retains the standard TLS security guarantees against any third-party adversary.
+
To elaborate, recall how HMAC is computed (assuming |k| <= block size):
+HMAC(k, m) = H((k ⊕ opad) | H((k ⊕ ipad) | m))
+Notice that both H(k ⊕ opad) and H(k ⊕ ipad) can be computed separately prior to finalization. In this +document we name these units as such:
+-
+
outer hash state: H(k ⊕ opad)
+inner hash state: H(k ⊕ ipad)
+inner hash: H((k ⊕ ipad) | m)
+
In TLS, the master secret is computed like so:
+seed = "master secret" | client_random | server_random
+a0 = seed
+a1 = HMAC(pms, a0)
+a2 = HMAC(pms, a1)
+p1 = HMAC(pms, a1 | seed)
+p2 = HMAC(pms, a2 | seed)
+ms = (p1 | p2)[:48]
+Notice that in each step the key, in this case PMS, is constant. Thus both the outer and inner hash state can be reused for each step.
Below is the description of the all the steps to compute the PRF both inside and outside the 2PC circuit.
Computing the master secret
+Inside the circuit
+-
+
- To evaluate the circuit, the parties input their
PMSshares. The circuit outputs:
+
-
+
- H(PMS ⊕ opad) called
PMSouter hash statetoNand
+ - H(PMS ⊕ ipad) called
PMSinner hash statetoU
+
Outside the circuit
+-
+
-
+
+Ucomputes H((PMS ⊕ ipad) || a0) calledinner hashofa1and passes it toN.
+ -
+
+Ncomputesa1and passes it toU.
+ -
+
+Ucomputes theinner hashofa2and passes it toN.
+ -
+
+Ncomputesa2and passes it toU.
+ -
+
+Ucomputes theinner hashof p2 and passes it toN.
+ -
+
+Ncomputesp2and passes it toU. +>Note that now both parties knowp2which is the last 16 bytes of the master secret. They still don't know the other 32 bytes of the master secret, which ensures adequate security.
+ -
+
+Ucomputes theinner hashofp1.
+
Inside the circuit
+-
+
- To evaluate the circuit,
Ninputs thePMS outer hash stateandUinputsp2and theinner hashofp1. The circuit computes the master secret (MS).
+
Computing the expanded keys
+The parties proceed to compute the expanded keys. The corresponding python code is:
seed = str.encode("key expansion") + server_random + client_random
+a0 = seed
+a1 = hmac.new(ms , a0, hashlib.sha256).digest()
+a2 = hmac.new(ms , a1, hashlib.sha256).digest()
+p1 = hmac.new(ms, a1+seed, hashlib.sha256).digest()
+p2 = hmac.new(ms, a2+seed, hashlib.sha256).digest()
+ek = (p1 + p2)[:40]
+client_write_key = ek[:16]
+server_write_key = ek[16:32]
+client_write_IV = ek[32:36]
+server_write_IV = ek[36:40]
+Inside the circuit
+-
+
- Having computed
MS, the circuit outputs:
+
-
+
- H(MS ⊕ opad) called the
MS outer hash statetoNand
+ - H(MS ⊕ ipad) called the
MS inner hash statetoU
+
Outside the circuit
+-
+
-
+
+Ucomputes theinner hashofa1and sends it toN.
+ -
+
+Ncomputesa1and sends it toU.
+ -
+
+Ucomputes theinner hashofa2and sends it toN.
+ -
+
+Ncomputesa2and sends it toU.
+ -
+
+Ucomputes theinner hash stateofp1and theinner hash stateofp2.
+
Inside the circuit
+-
+
- To evaluate the circuit,
NinputsMS outer hash state(from Step 10) andUinputsinner hash stateofp1andinner hash stateofp2. The circuit computesp1andp2. The circuit outputs xor shares of theexpanded keysto each party.
+
Computing the encrypted Client_Finished
+Inside the circuit
+-
+
- To evaluate the circuit, the parties input their shares of the
expanded keys. The circuit outputs data needed to encrypt and authenticate theClient_Finished(CF) message.
+
Outside the circuit
+The parties proceed to compute verify_data for the CF message. The corresponding python code is:
# (handshake_hash) is a sha256 hash of all TLS handshake message up to this point
+seed = str.encode('client finished') + handshake_hash
+a0 = seed
+a1 = hmac.new(ms, a0, hashlib.sha256).digest()
+p1 = hmac.new(ms, a1+seed, hashlib.sha256).digest()
+verify_data = p1[:12]
+-
+
-
+
+Ucomputesinner hashofa1and sends it toN.
+ -
+
+N(who hasMSouter hash statefrom Step 10) computesa1and sends it toU.
+ -
+
+Ucomputesinner hashofp1and sends it toN.
+ -
+
+Ncomputesp1and getsverify_dataand sends it toU.
+
++Note that it is safe for
+Nto knowverify_dataforCF.
Using the data from Step 17, U proceeds to encrypt and authenticate CF and sends it to the webserver.
Verifying the Server_Finished
+Upon U's receiving the encrypted Server_Finished (SF) from the webserver, the parties proceed to compute verify_data for SF, to enable U to check that the received SF is correct. The corresponding python code is:
# (handshake_hash) is a sha256 hash of all TLS handshake message up to this point
+seed = str.encode('server finished') + handshake_hash
+a0 = seed
+a1 = hmac.new(ms, a0, hashlib.sha256).digest()
+p1 = hmac.new(ms, a1+seed, hashlib.sha256).digest()
+verify_data = p1[:12]
+Outside the circuit
+-
+
-
+
+Ucomputesinner hashofa1and sends it toN.
+ -
+
+N(who hasMSouter hash statefrom Step 10) computesa1and sends it toU.
+ -
+
+Ucomputesinner hashofp1.
+
Inside the circuit
+-
+
- To evaluate the circuit,
NinputsMSouter hash state(from Step 10) andUinputsinner hashofp1. The circuit outputsverify_dataforSFtoU.
+
The parties proceed to decrypt and authenticate the SF in 2PC. U checks that verify_data from SF matches verify_data from Step 25.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/searcher.js b/searcher.js
new file mode 100644
index 0000000..d2b0aee
--- /dev/null
+++ b/searcher.js
@@ -0,0 +1,483 @@
+"use strict";
+window.search = window.search || {};
+(function search(search) {
+ // Search functionality
+ //
+ // You can use !hasFocus() to prevent keyhandling in your key
+ // event handlers while the user is typing their search.
+
+ if (!Mark || !elasticlunr) {
+ return;
+ }
+
+ //IE 11 Compatibility from https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/startsWith
+ if (!String.prototype.startsWith) {
+ String.prototype.startsWith = function(search, pos) {
+ return this.substr(!pos || pos < 0 ? 0 : +pos, search.length) === search;
+ };
+ }
+
+ var search_wrap = document.getElementById('search-wrapper'),
+ searchbar = document.getElementById('searchbar'),
+ searchbar_outer = document.getElementById('searchbar-outer'),
+ searchresults = document.getElementById('searchresults'),
+ searchresults_outer = document.getElementById('searchresults-outer'),
+ searchresults_header = document.getElementById('searchresults-header'),
+ searchicon = document.getElementById('search-toggle'),
+ content = document.getElementById('content'),
+
+ searchindex = null,
+ doc_urls = [],
+ results_options = {
+ teaser_word_count: 30,
+ limit_results: 30,
+ },
+ search_options = {
+ bool: "AND",
+ expand: true,
+ fields: {
+ title: {boost: 1},
+ body: {boost: 1},
+ breadcrumbs: {boost: 0}
+ }
+ },
+ mark_exclude = [],
+ marker = new Mark(content),
+ current_searchterm = "",
+ URL_SEARCH_PARAM = 'search',
+ URL_MARK_PARAM = 'highlight',
+ teaser_count = 0,
+
+ SEARCH_HOTKEY_KEYCODE = 83,
+ ESCAPE_KEYCODE = 27,
+ DOWN_KEYCODE = 40,
+ UP_KEYCODE = 38,
+ SELECT_KEYCODE = 13;
+
+ function hasFocus() {
+ return searchbar === document.activeElement;
+ }
+
+ function removeChildren(elem) {
+ while (elem.firstChild) {
+ elem.removeChild(elem.firstChild);
+ }
+ }
+
+ // Helper to parse a url into its building blocks.
+ function parseURL(url) {
+ var a = document.createElement('a');
+ a.href = url;
+ return {
+ source: url,
+ protocol: a.protocol.replace(':',''),
+ host: a.hostname,
+ port: a.port,
+ params: (function(){
+ var ret = {};
+ var seg = a.search.replace(/^\?/,'').split('&');
+ var len = seg.length, i = 0, s;
+ for (;i
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Commitment to public data
+We describe an interactive protocol between the User U and the Notary N, whereby U can convert the authenticated AES ciphertext into a hash commitment to Garbled Circuits wire labels.
Creating the new commitment
+-
+
-
+
At the end of the TLSNotary session, both
+UandNknow the authenticated AESciphertext.
+ -
+
+Nreveals his TLS session key shares toU.
+ -
+
+Udecrypts theciphertextin the clear and learns the plaintextp.
+ -
+
+Npicks aseedand uses it as the source of randomness to generate (in the semi-honest model) a privacy-free garbled circuit whose functionality is to accept the plaintext input, encrypt it, and output the ciphertext.
+ -
+
With
+pas her circuit input,Ureceives input wire labelsIWLsvia Oblivious Transfer and then evaluates the circuit on thoseIWLs. The result of the evaluation are output wire labelsOWLswhichUdoes not know the decoding for.
+ -
+
+Usends two commitments:commitment to IWLsandcommitment to OWLstoN.
+ -
+
+Nreveals theseedandUchecks that the circuit (including itsIWLsandOWLs) was generated correctly and, if successful, reveals herOWLs.
+ -
+
+Nverifiescommitment to OWLsand then checks that decodedOWLsmatch theciphertext(from Step 0) and, if successful, signs (seed+commitment to IWLs).
+
++Now, (
+seed+commitment to IWLs) becomeU's new commitment top.
Verifying the commitment
+Verifier performs the following steps:
+-
+
-
+
Receives the following from
+U: plaintextp,signaturefor (seed+commitment to IWLs),seed,commitment to IWLs.
+ -
+
(using a trusted
+Ns pubkey) Verifies thesignature.
+ -
+
Re-generates the
+IWLsfrom theseed.
+ -
+
Picks only those
+IWLswhich correspond topand checks that the commitment to thoseIWLsmatchescommitment to IWLs.
+ -
+
Accepts
+pas authentic.
+
Dynamic commitment using a Merkle tree
+In situations where U does not know in advance which subset of the public data she will be revealing later to the Verifier, U can commit to the Merkle tree of all her input wire labels (from Step 4 above).
+Later, U can reveal only those Merkle leaves which she wants to make public to the Verifier.