more

disps.org

@@ -16,9 +16,11 @@
 - In both the simulated and real case, the values $r, v$ and $M_A[i,j]$ for all $(i,j) \neq (u,v)$ are chosen uni-randomly. 
 - The pair $(M_A[u,v], z_B) is in both cases a pair of random bits s.t. $z = M_A[u,v] \oplus z_B$
 
-*Bob* TODO
-1) The simulator gets as input $y \in \{0,1\}^n$ and $z \in \{0,1\}$
-2) Compute $u \in_R 
+*Bob*
+1) The simulator gets as input $y \in \{0,1\}^n$
+2) Compute $u \in_R \{0,1\}^n$
+3) Compute $M_B \in \{0,1\}^{2^n \times 2^n}$
+4) Send to Bob!
 
 *** Others
 - We have BeDOZa but due to the time limit on this, I will not go through it, but we can save it for after the presentation.
@@ -60,3 +62,97 @@
 - *Proof*:
   1) /The view of Bob/ is distributed as the normal scheme, since $M_B, r$ are uni-random in both experiments and $u = x+r$ with random $r$ in the actual protocol, $u$ is also random.
   2) The output of Alice is distributed identically, except for the case where corrupt Bob sends a triple s.t. $ver(K[u,v], t'_B, z'_B) = accept$ meanwhile $z'_B \neq M_B[u,v]$: in which case the real Alice would output $f(x,y) \oplus 1$ as previously discussed, but the ideal Alice would output $f(x,y_0)$. This Bob can however be turned into an adversary for the underlying MAC scheme, which is assumed to be secure, thus completing the proof.
+* Oblivious Transfer - Likely waay too long
+** What is an OT
+- Simple 1-out-of-2 example.
+- Something which lets Alice pick a thing out of 2, without knowing what the other thing is, that she does not pick and without Bob knowing what thing she picked
+** Pseudorandom Public key used in OT
+- Passive security with pseudorandom public keys
+- Simple in concept. Has fake public keys without a secret key, so she can't decrypt anything encrypted under this public key and Bob can't distinguish a fake key from a real key
+** Oblivious Key Generation
+- Passive security
+- Pseudorandom keys are in fact not required, but there should just be an alternative way of generating the public keys
+  1) Public keys generated like this looks like regular pks
+  2) It is not possible to learn the sk corresponding to the pks generated like this.
+    + Note that we can't simply let Alice erase the sk after having computed the pk. It might not be easy to securely erase data and there is no way to verify that Alice has properly erased it. A passive party has to follow the protocol correctly, but is still allowed to look at their view and learn from this. If they have a secret key, they are allowed to use this!
+- What is a PKE with Oblivious Key Generation?
+- A PKE with /oblivious key generation/ is a regular *IND-CPA-secure* PKE defined by three algos *Gen, Enc, Dec*, but with an additional algo /oblivious generation/ or *OGen*. OGen outputs strings which look like regular pks. OGen must satisfy:
+  1) Let b be a random bit, $pk_0 \leftarrow Gen(sk)$ is the regular pk gen algo and $pk_1 \leftarrow OGen(r)$ is the oblivious pk gen algo, where sk and r are chosen uni randomly. Then no PPT algo D, s.t. $D(pk_b) = b$ with prob larger than 1/2 (Should this not HAVE to be 1/2? Otherwise if it fails with larger prob, you can just reverse the answer???)
+  2) It is possible to *efficiently invert* $pk \leftarrow OGen(r)$, which is denoted $r \leftarrow OGen^{-1}(pk)$
+- These two props imply it's infeasible to find sk corresponding to obliviously generated pks, even if you know the randomness used to generate it;
+  3) There exists no PPT algo A, which can output $sk \leftarrow A(r)$ s.t. $Gen(sk) = OGen(r)$.
+- $OGen^{-1}$ must be able to "explain" real pks, as if they were generated by OGen, since a distinguisher can check if $$OGen(OGen^{-1}(pk)) = pk$$ This will apply to keys generated with OGen and thus it must also apply to keys generated by regular Gen, otherwise these two would not be indistinguishable. Therefore it must also hold that: $$OGen(OGen^{-1}(Gen(sk))) = Gen(sk)$$
+- However, as (Gen, Enc, Dec) is a secure scheme, then it MUST be hard to compute sk from pk generated with Gen, so $pk \leftarrow Gen(sk)$ has to be a one-way function. Thus, a contradiction; if there is an A who can break property 3, then we can invert $pk <- Gen(sk)$ by computing $$sk <- A(OGen^{-1}(pk))$$.
+- Thus, for the OT protocol to be secure, we need more. The encryption scheme is still IND-CPA secure, even if encryptions are performed using a pk which is the output from OGen, even if the adversary knows the randomness used by OGen to generate that specific key.
+  4) For all m; let b be a random bit, $m_0 = m$, $m_1$ is a random uniform message and $pk <- OGen(r)$, then there exists no PPT algo D s.t. $D(r, Enc(pk,m_b)) = b$ with prob significantly larger than 1/2.
+- This last point makes sense, as otherwise some algorithm D can just try to encrypt both messages under both public keys he is given. If he can distinguish between the two messages under the key, this key must be the OGen key, as the PKE system is otherwise IND-CPA, so we can never distinguish messages encrypted under regular keys!
+
+** Actual OGen with ElGamal
+- Given the description of a group where DDH assumption is believed to hold, (G,g,q), where g is gen for G and q is order of G, ElGamal is described:
+  + *Gen(sk):* Input secret key $sk = \alpha \in Z_q$, compute h = g^{\alpha}$ and out $pk = (g,h)$
+  + *$Enc_{pk}(m)$:* Input message $m \in G$, sample random $r \in Z_q$, parse $pk = (g,h)$, output $C = (g^r, m \cdot h^r)$
+  + *$Dec_{sk}(C)$:* parse C as $(c_1, c_2)$. Output $m = c_2 \cdot c_1^{-\alpha}$.
+- We thus need to construct $OGen(r)$ which outputs $pk = (g,h)$ which is invertible and indistinguishable from $Gen$. If we pick a group where DDH is assumed to be hard, the multiplicative subgroup of order q of $Z^*_p$, where $p = 2q+1$. Now to gen a random element, we use the random string $r$ to sample $s$ between $1$ and $p$ and output $h = s^2 \mod p$. This process is invertible, since it is easy to compute square roots modulo a prime), and we can check that $h$ is distributed uni-randomly among elements of order q, as required.
+** OT Protocol using OGen
+- *Choose:* Alice with choice bit b:
+  1) Samples random $sk, r$
+  2) Gens $pk_b <- Gen(sk)$, $pk_{1-b} <- OGen(r)$
+  3) Sends $(pk_0, pk_1)$ to Bob
+- *Transfer Phase:* Bob with $m_0,m_1$:
+  1) Computes $c_0 = Enc_{pk_0}(m_0,r_0)$ and $c_1 = Enc_{pk_1}(m_1,r_1)$, using random $r_0,r_1$
+  2) Sends $(c_0, c_1)$ to Alice
+- *Retrieve Phase:* Alice outputs $m_b <- Dec(sk, c_b)$
+- Has passive security. Proof is an exercise, but intuitively, if we assume corrupt Bob then there is no way he can distinguish between the OGen key and the actual public key, due to the first property of the OGen algorithm. If we assume corrupt Alice, she knows the randomness of the OGen key she has generated and she knows one of the messages is encrypted under this OGen PK, but due to the fourth property (the semantic security), she will not get any information from this. (Lasse)
+** GMW-Compiler
+- Will not cover in detail, but will note that this can be used to turn any passively secure OT protocol into an actively secure OT protocol via ZK proofs, Picking randomness in a good way and commitments. Essentially, we need to make sure that Alice does in fact produce one of the public keys via OGen. Then, we need to make sure that she does not pick her randomness in a clever way, allowing her to produce both public keys via regular Gen, but then using that OGen shall have an inverse function, even working on regular public keys, to "create" some randomness yielding the public key of which the adversary knows the corresponding secret key. This is accomplished via "Coin flip into the well" protocol, which essentially means Bob generates the randomness for Alice, without actually knowing the randomness he generated. Now, the ZK proof should be extended to also include that Alice did in fact use this randomness. This is shown by her committing to her randomness. The protocol can still be attacked, if the protocol is run twice, Alice can change her input bit from one turn to the other, without Bob knowing this, such that she can learn both messages, while the ZK proof will still parse as ONE of the keys are correctly generated by the OGen algo, however which one changes between runs. Thus, she also need to commit to her input bit! 
+- This is in theory very nice. It does however have a large overhead and is very inefficient. 
+** Actual efficient active protocol
+*** El Gamal based encryption scheme
+- (G,g,q) is a group where DDH is hard
+- *Key gen*: PKs are for group elements $(g,h,u,v)$ and sk is $x \in Z_q$ s.t. $u = g^x$, $v = h^x$.
+- *Enc*: To encrypt $m \in G$, choose random $r,s \in_R Z_q$ and out $(c,d) = (g^r h^s, m \cdot u^r v^s)$
+- *Dec*: $m = d \cdot c^{-x}$, so like El Gamal
+- What on the face of earth is this proof? Something with no one knowing if the pk is a DDH tuple
+*** The active secure OT proto
+- We assume existence of a trust dealer who can output a common random string to both parties. This dealer can be replaced with a secure coin-flipping protocol
+- *Setup*: Use group $(G,g,q)$ with order $q$, gen by $g$. Trusted Dealer outputs four random group elements: $crs = (g_0,h_0,g_1,h_1)$ to Alice and Bob
+- *Choose*: Alice with input $b \in \{0,1\}$, samples $x \in_R Z_q$, computes $(u,v) = (g^x_b, h^x_b)$, sends $(u,v)$ to Bob.
+- *Transfer*: Bob with $m_0, m_1 \in G$ defines $pk_0 = (g_0, h_0, u,v)$ and $pk_1 = (g_1,h_1,u,v)$, samples $r_0,s_0,r_1,s_1 \in_R Z_q$ and computes: $e_0 = Enc(pk_0,m_0;r_0,s_0)$ and $e_1 = Enc(pk_1,m_1;r_1,s_1)$ and sends these to Alice
+- *Retrieve*: Alice computes $m_b = Dec(x,e_b)$. 
+- Neither Alice nor Bob can determine if $(g_0,h_0,g_1,h_1)$ is a DDH tuple or not
+- if $(g_0,h_0,g_1,h_1)$ is not a DDH tuple, then at most one of $pk_0,pk_1$ is a DDH tuple, which implies that the encryption using the wrong key is information-theoretically secure.
+- If $(g_0,h_0,g_1,h_1)$ is a DDH tuple, then $(u,v)$ perfectly hides choice bit $b$; if $(g_0,h_0,g_1,h_1)$ is a DDH tuple, then $h_0 = g^\alpha_0$ and $h_1 = g^\alpha_1$, with the same $\alpha$, meaning that given $(u,v)$ there exists $x_0,x_1$ s.t. $(u,v) = (g^{x_0}_0,h^{x_0}_0) = (g^{x_1}_1,h^{x_1}_1)$
+*** Formal proof
+- When Alice is corrupted:
+  1) The sim choose $crs$ as a non-DDH tuple, it gens $(g_0,h_0,g_1,h_1)$ s.t. $h_0 = g^{\alpha_0}_0$, $h_1 = g^{\alpha_1}_1$, s.t. $\alpha_0 \neq \alpha_1$.
+  2) The sim extracts input bit of Alice from $(u,v)$ by finding $b$ s.t. $v = u^{\alpha_b}$ and if no such $b$ exists s.t. the relation holds, set $b=0$.
+  3) The sim inputs $b$ to the ideal func and learns $m_b$, defines $m_{1-b} = 0$. Sim sends $(Enc(pk_0,m_0), Enc(pk_1,m_1))$ to corrupt Alice
+- This sim is statistically indistinguishable from the protocol as most $crs$ are not a DDH tuple, in which case encryptions under $pk_{1-b}$ are perfectly secure
+- When Bob is corrupted:
+  1) The sim choose $crs$ as a DDH tuple, it gens $(g_0,h_0,g_1,h_1)$ s.t. $h_0 = g^{\alpha}_0$, $h_1 = g^{\alpha}_1$, and $g_1 = g^\beta_0
+  2) The sim computes random $x_1$ and $(u,v) = (g^{x_1}_1, h^{x_1}_1)$. The sim also defines $x_0 = x_1 \cdot \beta$, now $(u,v) = (g^{x_0}_0, h^{x_0}_0)$ due to the definition of $x_0$.
+  3) The sim receives $(e_0,e_1)$ from corrupt Bob, compute $m_0 = Dec(x_0,e_0)$ and $m_1 = Dec(x_1, e_1)$ and inputs them to ideal func.
+- View of Bob in sim is computationally indistinguishable from proto, only diff is the distribution of the crs. 
+- Showing that output of the honest Alice in the sim, is identical to the output of the honest alice in the proto, is left out of the proof.
+
+* Garbled Circuits
+** Introduction
+- Motivation for GC
+** Passive 2PC using GCs
+- Constant round
+** Instantiation of GCs
+- Long
+** Attacks
+- Alice can do selective opening attacks, but that's about it, due to Garbled Circuit Authenticity
+- Bob can change function - Cut and choose
+- Selective failure
+* Homomorphic Encryption
+** Motivation
+** Pailler is a thing, but we won't cover it in detail
+** FHE
+*** Definition
+*** Boostrapping
+- We need a d-HE scheme
+*** d-HE
+- Something which works "d" times
+- The scheme

notes.org

@@ -4,7 +4,6 @@
 - Protocols with passive security (One-time truth-tables, passive BeDOZa) and their security.
 - Active attacks against OTTT/BeDOZa.
 - Countermeasures (using information-theoretic MACs) and their security.
-
 ** Prelims
 - The whole passive security thing where we define views and that a simulator has to be computationally indistingushiable from the views of all parties.
 - The views contain the party input, internal randomness (if any), and all the messages received during the protocol