Pownie
/
crying_computers_prep
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

almost done

This commit is contained in:
Alexander Munch-Hansen 2019-12-29 15:04:04 +01:00
parent 34717a3dcc
commit 760fb008ac
2 changed files with 301 additions and 90 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

213
notes.html
View File

@ -3,7 +3,7 @@
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<!-- 2019-12-14 Sat 18:35 -->
<!-- 2019-12-14 Sat 18:47 -->
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>&lrm;</title>
@ -255,62 +255,68 @@ for the JavaScript code in this tag.
<h2>Table of Contents</h2>
<div id="text-table-of-contents">
<ul>
<li><a href="#org6fa8a80">1. Protocols with Trusted Dealer (week 2 &amp; 3)</a>
<li><a href="#org341912d">1. Protocols with Trusted Dealer (week 2 &amp; 3)</a>
<ul>
<li><a href="#org83974e7">1.1. Curriculum</a></li>
<li><a href="#orgb018a57">1.2. Prelims</a></li>
<li><a href="#orgd33370c">1.3. Passively secure protocols</a>
<li><a href="#org0496cf6">1.1. Curriculum</a></li>
<li><a href="#org4b4e144">1.2. Prelims</a></li>
<li><a href="#org1e57e40">1.3. Passively secure protocols</a>
<ul>
<li><a href="#orgbdd8087">1.3.1. OTTT</a></li>
<li><a href="#org23cd6ea">1.3.2. BeDOZa</a></li>
<li><a href="#org914fdd8">1.3.1. OTTT</a></li>
<li><a href="#org0a53b40">1.3.2. BeDOZa</a></li>
</ul>
</li>
<li><a href="#orgf086731">1.4. Active Security</a>
<li><a href="#org2ff720b">1.4. Active Security</a>
<ul>
<li><a href="#org48a4136">1.4.1. OTTT with MACs</a></li>
<li><a href="#orge6fed38">1.4.2. BeDOZa</a></li>
<li><a href="#orgd64d520">1.4.1. OTTT with MACs</a></li>
<li><a href="#org58f7867">1.4.2. BeDOZa</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#org2a86b1b">2. Oblivious Transfer</a>
<li><a href="#orgac56d39">2. Oblivious Transfer</a>
<ul>
<li><a href="#org6cc4bcb">2.1. Curriculum</a></li>
<li><a href="#org784b165">2.2. Introduction</a></li>
<li><a href="#org0b329ac">2.3. OT from Public Key Crypto</a>
<li><a href="#orgb56e27f">2.1. Curriculum</a></li>
<li><a href="#org85599de">2.2. Introduction</a></li>
<li><a href="#org91c927d">2.3. OT from Public Key Crypto</a>
<ul>
<li><a href="#org0880381">2.3.1. With passive security and pseudorandom public keys</a></li>
<li><a href="#orgc2e35c2">2.3.2. Passive security with oblivious key generation</a></li>
<li><a href="#org93ead3c">2.3.3. Constructing Oblivious Key Gen</a></li>
<li><a href="#orgb3ce6fb">2.3.4. The protocol</a></li>
<li><a href="#orgfe65cff">2.3.1. With passive security and pseudorandom public keys</a></li>
<li><a href="#orgf0704ef">2.3.2. Passive security with oblivious key generation</a></li>
<li><a href="#orgcc8c420">2.3.3. Constructing Oblivious Key Gen</a></li>
<li><a href="#org887c85b">2.3.4. The protocol</a></li>
</ul>
</li>
<li><a href="#org774d190">2.4. The GWM-Compiler</a>
<li><a href="#org3ed5041">2.4. The GWM-Compiler</a>
<ul>
<li><a href="#org1da7afb">2.4.1. Note on commitments</a></li>
<li><a href="#org64a9b91">2.4.2. Note on ZK</a></li>
<li><a href="#orgcd3dd29">2.4.3. The compiler</a></li>
<li><a href="#org096313e">2.4.4. The fucking-up protocol</a></li>
<li><a href="#orgf97d0b6">2.4.1. Note on commitments</a></li>
<li><a href="#org009bdd4">2.4.2. Note on ZK</a></li>
<li><a href="#org4c937a5">2.4.3. The compiler</a></li>
<li><a href="#org57b70e3">2.4.4. The fucking-up protocol</a></li>
</ul>
</li>
<li><a href="#org5baa74a">2.5. Efficient Active Secure OT</a>
<li><a href="#org8127242">2.5. Efficient Active Secure OT</a>
<ul>
<li><a href="#orgac8321f">2.5.1. El Gamal based encryption scheme</a></li>
<li><a href="#org7dafa5b">2.5.2. The active secure OT proto</a></li>
<li><a href="#org52b74f5">2.5.3. Formal proof</a></li>
<li><a href="#org92730b8">2.5.1. El Gamal based encryption scheme</a></li>
<li><a href="#orgd8724fa">2.5.2. The active secure OT proto</a></li>
<li><a href="#org2729060">2.5.3. Formal proof</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#org7a456d4">3. Garbled Circuits</a>
<ul>
<li><a href="#org2f46740">3.1. Curriculum</a></li>
<li><a href="#org977b179">3.2. Intro</a></li>
</ul>
</li>
</ul>
</div>
</div>
<div id="outline-container-org6fa8a80" class="outline-2">
<h2 id="org6fa8a80"><span class="section-number-2">1</span> Protocols with Trusted Dealer (week 2 &amp; 3)</h2>
<div id="outline-container-org341912d" class="outline-2">
<h2 id="org341912d"><span class="section-number-2">1</span> Protocols with Trusted Dealer (week 2 &amp; 3)</h2>
<div class="outline-text-2" id="text-1">
</div>
<div id="outline-container-org83974e7" class="outline-3">
<h3 id="org83974e7"><span class="section-number-3">1.1</span> Curriculum</h3>
<div id="outline-container-org0496cf6" class="outline-3">
<h3 id="org0496cf6"><span class="section-number-3">1.1</span> Curriculum</h3>
<div class="outline-text-3" id="text-1-1">
<ul class="org-ul">
<li>Model (trusted dealer).</li>
@ -321,8 +327,8 @@ for the JavaScript code in this tag.
</div>
</div>
<div id="outline-container-orgb018a57" class="outline-3">
<h3 id="orgb018a57"><span class="section-number-3">1.2</span> Prelims</h3>
<div id="outline-container-org4b4e144" class="outline-3">
<h3 id="org4b4e144"><span class="section-number-3">1.2</span> Prelims</h3>
<div class="outline-text-3" id="text-1-2">
<ul class="org-ul">
<li>The whole passive security thing where we define views and that a simulator has to be computationally indistingushiable from the views of all parties.</li>
@ -333,15 +339,15 @@ for the JavaScript code in this tag.
</ul>
</div>
</div>
<div id="outline-container-orgd33370c" class="outline-3">
<h3 id="orgd33370c"><span class="section-number-3">1.3</span> Passively secure protocols</h3>
<div id="outline-container-org1e57e40" class="outline-3">
<h3 id="org1e57e40"><span class="section-number-3">1.3</span> Passively secure protocols</h3>
<div class="outline-text-3" id="text-1-3">
<ul class="org-ul">
<li>A trusted dealer is essentially just a third-party who we assume we can trust</li>
</ul>
</div>
<div id="outline-container-orgbdd8087" class="outline-4">
<h4 id="orgbdd8087"><span class="section-number-4">1.3.1</span> OTTT</h4>
<div id="outline-container-org914fdd8" class="outline-4">
<h4 id="org914fdd8"><span class="section-number-4">1.3.1</span> OTTT</h4>
<div class="outline-text-4" id="text-1-3-1">
<ul class="org-ul">
<li>This protocols allows two parties to compute any function over their inputs. Thus: \(f : \{0,1\}^n \times \{0,1\}^n \rightarrow \{0,1\}\).</li>
@ -350,7 +356,7 @@ for the JavaScript code in this tag.
</ul>
</div>
<ol class="org-ol">
<li><a id="org4abe157"></a>The protocol<br />
<li><a id="org2dc8439"></a>The protocol<br />
<div class="outline-text-5" id="text-1-3-1-1">
<ul class="org-ul">
<li><b>The trusted dealer</b> <i>D</i> does the following:
@ -370,7 +376,7 @@ for the JavaScript code in this tag.
</ul>
</div>
</li>
<li><a id="orga6b6e08"></a>Security proof TODO: Figure out the simulator for Bob<br />
<li><a id="org48da287"></a>Security proof TODO: Figure out the simulator for Bob<br />
<div class="outline-text-5" id="text-1-3-1-2">
<ul class="org-ul">
<li>We need to construct a simulator that, given the input and output, is computationally indistinguishable from the views.</li>
@ -399,8 +405,8 @@ for the JavaScript code in this tag.
</li>
</ol>
</div>
<div id="outline-container-org23cd6ea" class="outline-4">
<h4 id="org23cd6ea"><span class="section-number-4">1.3.2</span> BeDOZa</h4>
<div id="outline-container-org0a53b40" class="outline-4">
<h4 id="org0a53b40"><span class="section-number-4">1.3.2</span> BeDOZa</h4>
<div class="outline-text-4" id="text-1-3-2">
<ul class="org-ul">
<li>Circuit based, still using a trusted dealer</li>
@ -429,7 +435,7 @@ for the JavaScript code in this tag.
</ul>
</div>
<ol class="org-ol">
<li><a id="orgd691f91"></a>Analysis TODO!<br />
<li><a id="orgde2e689"></a>Analysis TODO!<br />
<div class="outline-text-5" id="text-1-3-2-1">
<ul class="org-ul">
<li>We consider only semi-honest (or passive) at this point and this function is deterministic, so it's enough to prove that the output is correct and the view of a corrupted party can be simulated.</li>
@ -447,15 +453,15 @@ for the JavaScript code in this tag.
</ol>
</div>
</div>
<div id="outline-container-orgf086731" class="outline-3">
<h3 id="orgf086731"><span class="section-number-3">1.4</span> Active Security</h3>
<div id="outline-container-org2ff720b" class="outline-3">
<h3 id="org2ff720b"><span class="section-number-3">1.4</span> Active Security</h3>
<div class="outline-text-3" id="text-1-4">
<ul class="org-ul">
<li>Message authentication codes!!</li>
</ul>
</div>
<div id="outline-container-org48a4136" class="outline-4">
<h4 id="org48a4136"><span class="section-number-4">1.4.1</span> OTTT with MACs</h4>
<div id="outline-container-orgd64d520" class="outline-4">
<h4 id="orgd64d520"><span class="section-number-4">1.4.1</span> OTTT with MACs</h4>
<div class="outline-text-4" id="text-1-4-1">
<ul class="org-ul">
<li>A malicious Bob can deviate from the original OTTT protocol in a few ways:
@ -480,7 +486,7 @@ for the JavaScript code in this tag.
</ul>
</div>
<ol class="org-ol">
<li><a id="org9466e1a"></a>Intro to MACs<br />
<li><a id="orgfd06e32"></a>Intro to MACs<br />
<div class="outline-text-5" id="text-1-4-1-1">
<ul class="org-ul">
<li>Message authenticaion code</li>
@ -491,7 +497,7 @@ for the JavaScript code in this tag.
</ul>
</div>
</li>
<li><a id="org3003871"></a>Enhancing OTTT<br />
<li><a id="org2fb6ecb"></a>Enhancing OTTT<br />
<div class="outline-text-5" id="text-1-4-1-2">
<ul class="org-ul">
<li><b>The dealer</b> does the following:
@ -512,7 +518,7 @@ for the JavaScript code in this tag.
</ul>
</div>
</li>
<li><a id="orgbe7744a"></a>Proving security<br />
<li><a id="orgea6cd04"></a>Proving security<br />
<div class="outline-text-5" id="text-1-4-1-3">
<ul class="org-ul">
<li>This is no longer strictly deterministic, most likely since the MAC scheme fails with probability epsilon, thus we have to show this works for the joint probability of the views and the output.</li>
@ -531,7 +537,7 @@ for the JavaScript code in this tag.
</ul>
</div>
</li>
<li><a id="org25cbc88"></a>Possible MAC scheme<br />
<li><a id="orgf20ac45"></a>Possible MAC scheme<br />
<div class="outline-text-5" id="text-1-4-1-4">
<ul class="org-ul">
<li>As Bob only sees a single MAC for each key, we can use a simple information theoretic MAC scheme which is simply a linear function:
@ -545,8 +551,8 @@ for the JavaScript code in this tag.
</li>
</ol>
</div>
<div id="outline-container-orge6fed38" class="outline-4">
<h4 id="orge6fed38"><span class="section-number-4">1.4.2</span> BeDOZa</h4>
<div id="outline-container-org58f7867" class="outline-4">
<h4 id="org58f7867"><span class="section-number-4">1.4.2</span> BeDOZa</h4>
<div class="outline-text-4" id="text-1-4-2">
<ul class="org-ul">
<li>Works with an $m$-homomorphic MAC scheme, so likely just bring this up for the last topic, which only has one paper otherwise!</li>
@ -555,12 +561,12 @@ for the JavaScript code in this tag.
</div>
</div>
</div>
<div id="outline-container-org2a86b1b" class="outline-2">
<h2 id="org2a86b1b"><span class="section-number-2">2</span> Oblivious Transfer</h2>
<div id="outline-container-orgac56d39" class="outline-2">
<h2 id="orgac56d39"><span class="section-number-2">2</span> Oblivious Transfer</h2>
<div class="outline-text-2" id="text-2">
</div>
<div id="outline-container-org6cc4bcb" class="outline-3">
<h3 id="org6cc4bcb"><span class="section-number-3">2.1</span> Curriculum</h3>
<div id="outline-container-orgb56e27f" class="outline-3">
<h3 id="orgb56e27f"><span class="section-number-3">2.1</span> Curriculum</h3>
<div class="outline-text-3" id="text-2-1">
<ul class="org-ul">
<li>Definition and applications.</li>
@ -570,8 +576,8 @@ for the JavaScript code in this tag.
</ul>
</div>
</div>
<div id="outline-container-org784b165" class="outline-3">
<h3 id="org784b165"><span class="section-number-3">2.2</span> Introduction</h3>
<div id="outline-container-org85599de" class="outline-3">
<h3 id="org85599de"><span class="section-number-3">2.2</span> Introduction</h3>
<div class="outline-text-3" id="text-2-2">
<ul class="org-ul">
<li>Main variant of Oblivious Transfer (OT) is the <i>1-out-of-2</i> OT or (2 1)-OT for short. It's described by the functional functionality:
@ -599,12 +605,12 @@ for the JavaScript code in this tag.
</ul>
</div>
</div>
<div id="outline-container-org0b329ac" class="outline-3">
<h3 id="org0b329ac"><span class="section-number-3">2.3</span> OT from Public Key Crypto</h3>
<div id="outline-container-org91c927d" class="outline-3">
<h3 id="org91c927d"><span class="section-number-3">2.3</span> OT from Public Key Crypto</h3>
<div class="outline-text-3" id="text-2-3">
</div>
<div id="outline-container-org0880381" class="outline-4">
<h4 id="org0880381"><span class="section-number-4">2.3.1</span> With passive security and pseudorandom public keys</h4>
<div id="outline-container-orgfe65cff" class="outline-4">
<h4 id="orgfe65cff"><span class="section-number-4">2.3.1</span> With passive security and pseudorandom public keys</h4>
<div class="outline-text-4" id="text-2-3-1">
<ul class="org-ul">
<li>The Public-key Encryption Scheme (PKE) has pseudorandom public-keys. Then the following OT-protocol has passive security:
@ -617,8 +623,8 @@ for the JavaScript code in this tag.
</ul>
</div>
</div>
<div id="outline-container-orgc2e35c2" class="outline-4">
<h4 id="orgc2e35c2"><span class="section-number-4">2.3.2</span> Passive security with oblivious key generation</h4>
<div id="outline-container-orgf0704ef" class="outline-4">
<h4 id="orgf0704ef"><span class="section-number-4">2.3.2</span> Passive security with oblivious key generation</h4>
<div class="outline-text-4" id="text-2-3-2">
<ul class="org-ul">
<li>It is not required that public keys are pseudorandom, but merely that there should be an alternative way of generating the public-keys such that:
@ -650,8 +656,8 @@ for the JavaScript code in this tag.
</ul>
</div>
</div>
<div id="outline-container-org93ead3c" class="outline-4">
<h4 id="org93ead3c"><span class="section-number-4">2.3.3</span> Constructing Oblivious Key Gen</h4>
<div id="outline-container-orgcc8c420" class="outline-4">
<h4 id="orgcc8c420"><span class="section-number-4">2.3.3</span> Constructing Oblivious Key Gen</h4>
<div class="outline-text-4" id="text-2-3-3">
<ul class="org-ul">
<li>Not all functions admit an oblivious sampler, which is due to <a href="http://cs.au.dk/~orlandi/asiacrypt-draft.pdf">http://cs.au.dk/~orlandi/asiacrypt-draft.pdf</a></li>
@ -659,7 +665,7 @@ for the JavaScript code in this tag.
</ul>
</div>
<ol class="org-ol">
<li><a id="orgbbd65b9"></a>El Gamal sampler<br />
<li><a id="org2ad557f"></a>El Gamal sampler<br />
<div class="outline-text-5" id="text-2-3-3-1">
<ul class="org-ul">
<li>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:
@ -674,8 +680,8 @@ for the JavaScript code in this tag.
</li>
</ol>
</div>
<div id="outline-container-orgb3ce6fb" class="outline-4">
<h4 id="orgb3ce6fb"><span class="section-number-4">2.3.4</span> The protocol</h4>
<div id="outline-container-org887c85b" class="outline-4">
<h4 id="org887c85b"><span class="section-number-4">2.3.4</span> The protocol</h4>
<div class="outline-text-4" id="text-2-3-4">
<ul class="org-ul">
<li><b>Choose:</b> Alice with choice bit b:
@ -694,15 +700,15 @@ for the JavaScript code in this tag.
</div>
</div>
</div>
<div id="outline-container-org774d190" class="outline-3">
<h3 id="org774d190"><span class="section-number-3">2.4</span> The GWM-Compiler</h3>
<div id="outline-container-org3ed5041" class="outline-3">
<h3 id="org3ed5041"><span class="section-number-3">2.4</span> The GWM-Compiler</h3>
<div class="outline-text-3" id="text-2-4">
<ul class="org-ul">
<li>Uses two tools from CPT, commitments and ZK-PoK</li>
</ul>
</div>
<div id="outline-container-org1da7afb" class="outline-4">
<h4 id="org1da7afb"><span class="section-number-4">2.4.1</span> Note on commitments</h4>
<div id="outline-container-orgf97d0b6" class="outline-4">
<h4 id="orgf97d0b6"><span class="section-number-4">2.4.1</span> Note on commitments</h4>
<div class="outline-text-4" id="text-2-4-1">
<ul class="org-ul">
<li>Hiding, Binding</li>
@ -710,15 +716,15 @@ for the JavaScript code in this tag.
<ol class="org-ol">
<li>R chooses random \(h\) which gens \(G\)</li>
<li>S wants to commit to a value \(x \in Z_q\). S chooses random \(r \in Z_q\), computes \(c = g^x h^r\) and sends \(c\) to \(R\)</li>
<li>S sends \(R\) \((x',r')\). If \(c = g^{x'}h^{r'}\), \(R\) outputs \(x^'\) or \(turnstile\) ow.</li>
<li>S sends \(R\) \((x',r')\). If \(c = g^{x'}h^{r'}\), \(R\) outputs \(x'\) or \(turnstile\) ow.</li>
</ol></li>
<li>Is unconditionally hiding, as \(h^r\) is uni random in \(G\).</li>
<li>Is comp binding as given two pairs \((x,r),(x',r')\), one can compute the DL of \(h\) in base \(g\).</li>
</ul>
</div>
</div>
<div id="outline-container-org64a9b91" class="outline-4">
<h4 id="org64a9b91"><span class="section-number-4">2.4.2</span> Note on ZK</h4>
<div id="outline-container-org009bdd4" class="outline-4">
<h4 id="org009bdd4"><span class="section-number-4">2.4.2</span> Note on ZK</h4>
<div class="outline-text-4" id="text-2-4-2">
<ul class="org-ul">
<li>Use ideal ZK-functionalities, i.e. a model where parties have access to ideal boxes which on common input \(x\) and private input \(w\) from one of the parties outputs \(R(x,w)\). This kind of box can in practice be replaced with any of the ZK protocols for NP-complete languages from CPT.
@ -728,8 +734,8 @@ for the JavaScript code in this tag.
</ul>
</div>
</div>
<div id="outline-container-orgcd3dd29" class="outline-4">
<h4 id="orgcd3dd29"><span class="section-number-4">2.4.3</span> The compiler</h4>
<div id="outline-container-org4c937a5" class="outline-4">
<h4 id="org4c937a5"><span class="section-number-4">2.4.3</span> The compiler</h4>
<div class="outline-text-4" id="text-2-4-3">
<ul class="org-ul">
<li>We can build passive OT using any PKE scheme with OGen
@ -753,8 +759,8 @@ for the JavaScript code in this tag.
</ul>
</div>
</div>
<div id="outline-container-org096313e" class="outline-4">
<h4 id="org096313e"><span class="section-number-4">2.4.4</span> The fucking-up protocol</h4>
<div id="outline-container-org57b70e3" class="outline-4">
<h4 id="org57b70e3"><span class="section-number-4">2.4.4</span> The fucking-up protocol</h4>
<div class="outline-text-4" id="text-2-4-4">
<ul class="org-ul">
<li>Proto
@ -810,16 +816,16 @@ for the JavaScript code in this tag.
</div>
</div>
</div>
<div id="outline-container-org5baa74a" class="outline-3">
<h3 id="org5baa74a"><span class="section-number-3">2.5</span> Efficient Active Secure OT</h3>
<div id="outline-container-org8127242" class="outline-3">
<h3 id="org8127242"><span class="section-number-3">2.5</span> Efficient Active Secure OT</h3>
<div class="outline-text-3" id="text-2-5">
<ul class="org-ul">
<li>GMW compiler has massive overhead and leads to very inefficient protocols</li>
<li>Thus, we have to come up with another way of making sure that Alice does not know the secret key of the fake public key.</li>
</ul>
</div>
<div id="outline-container-orgac8321f" class="outline-4">
<h4 id="orgac8321f"><span class="section-number-4">2.5.1</span> El Gamal based encryption scheme</h4>
<div id="outline-container-org92730b8" class="outline-4">
<h4 id="org92730b8"><span class="section-number-4">2.5.1</span> El Gamal based encryption scheme</h4>
<div class="outline-text-4" id="text-2-5-1">
<ul class="org-ul">
<li>(G,g,q) is a group where DDH is hard</li>
@ -830,8 +836,8 @@ for the JavaScript code in this tag.
</ul>
</div>
</div>
<div id="outline-container-org7dafa5b" class="outline-4">
<h4 id="org7dafa5b"><span class="section-number-4">2.5.2</span> The active secure OT proto</h4>
<div id="outline-container-orgd8724fa" class="outline-4">
<h4 id="orgd8724fa"><span class="section-number-4">2.5.2</span> The active secure OT proto</h4>
<div class="outline-text-4" id="text-2-5-2">
<ul class="org-ul">
<li>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</li>
@ -845,8 +851,8 @@ for the JavaScript code in this tag.
</ul>
</div>
</div>
<div id="outline-container-org52b74f5" class="outline-4">
<h4 id="org52b74f5"><span class="section-number-4">2.5.3</span> Formal proof</h4>
<div id="outline-container-org2729060" class="outline-4">
<h4 id="org2729060"><span class="section-number-4">2.5.3</span> Formal proof</h4>
<div class="outline-text-4" id="text-2-5-3">
<ul class="org-ul">
<li>When Alice is corrupted:
@ -869,10 +875,39 @@ for the JavaScript code in this tag.
</div>
</div>
</div>
<div id="outline-container-org7a456d4" class="outline-2">
<h2 id="org7a456d4"><span class="section-number-2">3</span> Garbled Circuits</h2>
<div class="outline-text-2" id="text-3">
</div>
<div id="outline-container-org2f46740" class="outline-3">
<h3 id="org2f46740"><span class="section-number-3">3.1</span> Curriculum</h3>
<div class="outline-text-3" id="text-3-1">
<ul class="org-ul">
<li>Definition and high-level view.</li>
<li>How to garble individual gates.</li>
<li>Application to constant-round secure two-party computation with passive security.</li>
<li>Attacks against the passive secure protocol (garbling wrong functions, selective failure attacks) and (brief) sketch of possible countermeasures (simple cut-and-choose strategy).</li>
</ul>
</div>
</div>
<div id="outline-container-org977b179" class="outline-3">
<h3 id="org977b179"><span class="section-number-3">3.2</span> Intro</h3>
<div class="outline-text-3" id="text-3-2">
<ul class="org-ul">
<li>The topic of this week is “garbled circuits” and how they can be used (together with oblivious transfer), to achieve passive secure two-party computation with only constant round, aka “Yao’s protocol” (as opposed to the BeDOZa-protocol, where the number of rounds was proportional to the circuit depth).</li>
<li>A garbling scheme is a crypto primitive which allows to evaluate encryptions functions on encrypted inputs.</li>
<li>Garbled circuits allow to perform secure comp in constant rounds and Yao (combined with a 2-message OT proto) use only two rounds.
<ul class="org-ul">
<li>The 2-rounds is crucial for some applications, as it allows a user A to pubish some kind of encryption of her input and then anyone else can send her a single message that allows her to recover the result of the computation</li>
</ul></li>
</ul>
</div>
</div>
</div>
</div>
<div id="postamble" class="status">
<p class="author">Author: Alexander Munch-hansen</p>
<p class="date">Created: 2019-12-14 Sat 18:35</p>
<p class="date">Created: 2019-12-14 Sat 18:47</p>
<p class="validation"><a href="http://validator.w3.org/check?uri=referer">Validate</a></p>
</div>
</body>

178
notes.org
View File

@ -185,7 +185,7 @@
- Simple protocol based on DL:
1) R chooses random $h$ which gens $G$
2) S wants to commit to a value $x \in Z_q$. S chooses random $r \in Z_q$, computes $c = g^x h^r$ and sends $c$ to $R$
3) S sends $R$ $(x',r')$. If $c = g^{x'}h^{r'}$, $R$ outputs $x^'$ or $turnstile$ ow.
3) S sends $R$ $(x',r')$. If $c = g^{x'}h^{r'}$, $R$ outputs $x'$ or $turnstile$ ow.
- Is unconditionally hiding, as $h^r$ is uni random in $G$.
- Is comp binding as given two pairs $(x,r),(x',r')$, one can compute the DL of $h$ in base $g$.
*** Note on ZK
@ -272,3 +272,179 @@
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
** Curriculum
- Definition and high-level view.
- How to garble individual gates.
- Application to constant-round secure two-party computation with passive security.
- Attacks against the passive secure protocol (garbling wrong functions, selective failure attacks) and (brief) sketch of possible countermeasures (simple cut-and-choose strategy).
** Intro
- The topic of this week is “garbled circuits” and how they can be used (together with oblivious transfer), to achieve passive secure two-party computation with only constant round, aka “Yao’s protocol” (as opposed to the BeDOZa-protocol, where the number of rounds was proportional to the circuit depth).
- A garbling scheme is a crypto primitive which allows to evaluate encryptions functions on encrypted inputs.
- Garbled circuits allow to perform secure comp in constant rounds and Yao (combined with a 2-message OT proto) use only two rounds.
+ The 2-rounds is crucial for some applications, as it allows a user A to pubish some kind of encryption of her input and then anyone else can send her a single message that allows her to recover the result of the computation
** Abstract Desc of Garbling Circuits
# TODO: Is this a spelling mistake, Ev ev? - NO!
- A garbling scheme is defined by a tuple $G = (Gb, En, De, Ev, ev)$
+ Gb is the garbling circuit generation function. It is randomized and on input $1^k$ plus the description of a boolean circuit $f : \{0,1\}^n \rightarrow \{0,1\}$ (while both $n$ and $|f|$ must be polynomially bounded in $k$), outputs a triple of strings $(F,e,d)$ which represents the garbled circuit, the encoding information and the decoding information.
+ $ev$ allows the evaluation of the plaintext circuit $f$, so $ev(f,x) = f(x)$, i.e. it takes $f$, which is the ungarbled function, and some input $x$ and runs $f$ on $x$.
+ $En$ is the encoding function. It's deterministic and uses $e$ (the encoding information) to map some input $x$ to a garbled circuit $X$. A simple garbling scheme for $2PC$ is a projective scheme where $e = (\{K_i^0, K_i^1\}_{i \in [1,n]})$ and the garbled input $X$ is then simply $\{K_i^{x_i}\}_{i \in [1,n]}$, so the encoding information is a set of $n$ pairs of keys, one for each possible value for each bit of the input and the garbled input $X$ is then simply a subset of those strings.
+ $Ev$ is the garbled evaluation function. It is deterministic and it evaluates a garbed circuit F on garbled input X and it produces a garbled output Z'.
+ $De$ is the decoding function, it uses decoding information $d$ and it decodes the garbled output $Z'$ into some plaintext output $z$. In the projective schemes, $d$ consists of two strings, $d = (Z_0, Z_1)$ and $De$ then outputs $z = 0$ if $Z' = Z_0$, $z = 1$ if $Z' = Z_1$ and otherwise $\perp$ if $Z' \not\in \{Z_0, Z_1\}$, i.e. if some error occured.
+ Correctness is defined like so: Let $G$ be a garbling schemes. $G$ then enjoys correctness if for all $f : \{0,1\}^n \rightarrow \{0,1\}$ and all $x \in \{0,1\}^n$ the following probability is negligible:
$$Pr(De(d,Ev(F,En(e,x))) \neq f(x) : (F,e,d) \leftarrow Gb(1^k, f))$$
I.e. the probability that the decoding function run on the evaluation function, which is run on the garbled circuit and the garbled input, is not the result of the plaintext function simply run on the ungarbled input x, should be very low.
*** Formal description of passive 2PC based on garbled circuits
- 2PC = 2-party computation
- So projective garbling schemes as described above can be used to accomplish 2PC like so:
1) Setup: Alice and Bob have inputs $x,y \in \{0,1\}^n$ and wishes to compute some function $f(x,y)$ where $f : \{0,1\}^{2n} \rightarrow \{0,1\}$ describes a circuit where the first $n$ inputs come from Alice and the last $n$ come from Bob. We split $e = (e_x, e_y)$ to divide the input encoding information in a part belonging to Alice and one to Bob.
2) Garble: Bob will run $(F, e_x, e_y, d) \leftarrow Gb(1^k, f)$ and send $F$ to Alice. Note that $e_x$ and $e_y$ do not by themselves describe the input, they are just used to encode the input bits later.
3) Encode Bob's Input: Bob runs $Y \leftarrow En(e_y, y)$ and sends $Y$ to Alice. So Bob sends his garbled input to Alice, which will at this point simply be a list of keys.
4) Encode Alice's Input: Alice and Bob run a secure 2PC where Bob inputs $e_x$, Alice inputs $x$ and Alice learns $X \leftarrow En(e_x, x)$. For the projective scheme where $e_x = \{K_0^i, K_1^i\}_{i \in [1,n]}$, Bob knows these $n$ keys or strings, and Alice has her bit vector $x = \{0,1\}^n$ and Alice should end up with $X = \{K_{x_i}^i\}_{i \in [1,n]}$ where $x_i$ is the $i$'th input bit. This can easily be accomplished by running $n$ OT protocols, where alice will input the bit she is interested in and Bob will input both of the keys corresponding to the i'th bit.
5) Evaluation: Alice can now compute $Z \leftarrow Ev(F,X,Y)$
+ Bob output: Alice sends $Z$ to Bob who can output $z \leftarrow De(d,Z)$
+ Alice output: Bob sends $d$ to Alice who can output $z \leftarrow De(d,Z)$
- Which sub bullet of step 5 is run depends on who is to get the output of the function.
- Messages 1,2,5b can be sent together. Also, if one uses a 2-messages OT protocol in step 3, the protocol can be compressed to two messages. In the first message Alice sends to Bob the first message of the OT protocol, in the second message Bob sends Alice the second message of the OT protocol together with 1,2,5b.
- Security: The protocol is only secure against passive corruption, i.e. you get nothing from simply seeing the views. If we consider the protocol where alice gets output, so the one using 5b, we can simulate it like so: Bob is trivial, as Alice does not send anything to Bob, other than the OT protocols. So, what does Bob see? Bob has to compute the garbled circuit as this has to be sent to Alice. I imagine this can simply be random though, as well, it is garbled. Furthermore the sim has the output bit already, so we can just compute $d$ to be what we need I guess. In regards to a simulation of Alice. Given the input and output of Alice, x and $z = f(x,y)$, but not $y$, the sim garbles the circuit $f'$ that always outputs $z$. Now the sim creates a view using a dummy input $x$ and $y$ and includes $F', X', Y', d$ in the view (and also sims the OTs). The indistinguishability between the real view and the ideal view of the adversary is due to the following property of garbling schemes:
+ (Garbled Circuit Privacy) Let $G$ be a garbling scheme. $G$ then enjoys privacy if there exists a sim $S$ s.t. for all $f : \{0,1\}^n \rightarrow \{0,1\}$ and all $x \in \{0,1\}^n$, the output of the sim on input the structure of the circuit (what?) $struct(f)$ and the output $(F', X', d') \leftarrow S(1^k, struct(f), f(x))$ is indistinguishable from $(F,X,d)$ where $(F, e,d) \leftarrow Gb(1^k, f)$, $X \leftarrow En(e,x)$.
- Essentially, a garbled circuit and a garbled input will only leak info on the output of the circuit evaluated on the garbled input as well as some partial information on the structure of the circuit computing $f$, $struct(f)$. This structure includes the number of gates, the number of wires, the number of input and output bits and the wiring of the circuit, but can still hide all other information about the input and the function which is being computed. Essentially, everything about the circuit is leaked, except what function is computed. One can however hide the structure of the circuit, by applying a standard transformation to the circuit (garbling the universal circuit (whatever this means), which takes as input the description of a circuit of size $n$ and evaluates it, which will only an upper bound on the size of the circuit). This is used for private function evaluation, where Alice knows $x$, Bob knows $f$, alice should learn $f(x)$ without learning $f$.
** TODO: The actual protocol
*** Circuit Notation
- Use notation $f : \{0,1\}^n -> \{0,1\}$ for a circuit. A circuit has T wires. The wires $w_i$ with index $i \in [1,n]$ are called input wires. The wire $w_i$ with index $i = T$ is the output wire and all other wires $w_i$ with $i \in [n+1, T-1]$ are internal wires. We can asssume the circuit is composed of (so all internal + output wire) NAND gates, as we can build any function from NAND gates. Thus, for all $i \in [n+1, T], w_i = \not (w_{L(i)}\ AND\ w_{R{i)})$, where $L : [n+1, T] -> [1,T]$ and $R : [n+1, T] -> [1,T]$ are functions specifying left and right input wire of the gate. It must be true that $L(i) <= R(i) < i$, since the value on each wire is a function of the values of wires with lower indices. The input wire values are given as input and are not computed from other values. As such, $L$ and $R$ are not defined for these.
*** Underlying Crypto Primitives
- Only require a pseudorandom function: $G : \{0,1\}^k x \{0,1\}^k x [1,T] -> \{0,1\}^{2k}$ (It should be efficient and be difficult to distinguish from random stuff).
- We then use this PRF: $G(A,B,i)$ where $A$ and $B$ are two $k-bit$ keys and $i$ is the input. As a minimum requirement, we need that as long as at least one of the two keys is unknown to the adversary, then the output of the PRF is unpredictable.
*** Circuit generation
- To generator garblec circuit $(F,e,d)$ from some boolean circuit $f$ with $T$ wires, the algo $Gb$ is defined like so:
1) For each wire $i \in [1,T]$ in the circuit: Choose two random strings $(K^i_0, K^i_1)$ <- \{0,1\}^k x \{0,1\}^k$. T is the index of the output wire, then $d = (Z_0, Z_1) = (K^T_0, K^T_1)$. For $n$ input wires; $e = \{K^i_0, K^i_1\}_{i \in [1,n]}$.
2) For $i \in [n+1, T]$ (all internal wires), define a garbled table $(C^i_0, C^i_1, C^i_2, C^i_3)$ like the following:
a) For all $(a,b) \in \{0,1\} x \{0,1\}$ compute: $$C^'_{a,b} = G(K^{L(i)}_a, K^{R(i)}_b, i) XOR (K^i_{\not (a\ AND\ b)}, 0^k)$$ (the not AND in the subscript means taking the NAND of the two values a and b, thus, if we use other gates than NAND, we should perform this computation instead)
b) Choose random perm $\pi : \{0,1,2,3\} -> \{0,1\} x \{0,1\}$ and add: $$(C^i_0, C^i_1, C^i_2, C^i_3) = (C^i_{\pi(0)}, C^i_{\pi(1)}, C^i_{\pi(2)}, C^i_{\pi(3)})$$ to F.
*** Encoding
- The function $En(e,x)$ parses $e = \{K^i_0, K^i_1\}_{i \in [1,n]}$ and outputs $X = \{K^i_{x_i}\}_{i \in [1,n]}$.
*** Evaluation
- The function $Ev(F,X)$ parses $X = \{K^i_{x_i}\}_{i \in [1,n]}$ and does for all $i \in [n+1, T]$:
1) Recover $(C^i_0, C^i_1, C^i_2, C^i_3)$ from F. (Essentially just fetch them, so Alice finds the circuit F and loops through it
2) For $j = 0,1,2,3$ compute: $(K'_j, \tau_j) = G(K^{L(i)}, K^{R(i)}, i) XOR C^i_j$
3) If there is a unique $j$ s.t. $\tau_j = 0^k$, define $K^i = K'_j$, else abort and output $\perp$. So essentially we try each value for $C$ (as we do not know the permutation), until we find one which gives a "correct" value. Keep in mind that the values of $C$ are already "evaluated" in the circuit generation, so we essentially just pick the correct evaluations now.
- Output $Z' = K^T$.
*** Decoding
- The function $De(d,Z)$ parses $d = (Z_0, Z_1)$ and outputs $0$ if $Z' = Z_0$, $1$ if $Z' = Z_1$, else $\perp$.
*** Correctness
Why is the $0^k$ there to look for, to find the correct gate evaluations (We append $0^k$ in the generation step, to the key we XOR with)? During the garbling, the circuit generator encrypts the output keys of each gate under all four combinations of the input keys, then during evaluation, the circuit eval only has two of the input keys, as there is one for each wire and will need to find the correct key corresponding to the output wire for the right value. Thus, the eval dude knows that $K^{L(i)} = K^{L(i)_a$ for $a \in \{0,1\}$, but does not know $a$, and the same for $b$, but he still needs to compute the output key $k^i_c$ for $c= \not (a\ AND\ b)$. This is however possible due to the $0^k$ added in the gen step, as we will only find this redundancy if the eval dude decrypts the right entry in the garbled table, as he will then find $(K, 0^k)$, since: $$G(K^{L(i)}_a, K^{R(i)}_b, i) \oplus C^i_{\pi^{-1}(a,b)} = (K^i_{\not(a \and b)}, 0^k)$$.
If however $\pi(j) = (a', b') \neq (a,b)$, then:
$$G(K^{L(i)}_a, K^{R(i)}_b, i) \oplus C^i_j = G(K^{L(i)}_a, K^{R(i)}_b, i) \oplus G(K^{L(i)}_{a'}, K^{R(i)}_{b'}, i) \oplus (K^i_{\not(a' \and b')}, 0^k)$$
and intuitively, since $G$ is PRF, we expect the last $k$ bits of $$G(K^{L(i)}_a, K^{R(i)}_b, i) \oplus G(K^{L(i)}_{a'}, K^{R(i)}_{b'}, i)$$ to be different than $0^k$ with high probability, when $(a,b) \neq (a', b')$, so we will notice when the decryption isn't successful, allowing us to simply check all possibilities.
*** Privacy (Why we need the PRF)
Alice shold never be allowed to learn both keys for any wire. By construction, this holds for input wires (as Alice only ever recieve a single key) and it is also true for the internal wires.
- Assume for wire $i$ that Alice knows $K^{L(i)}_1,, K^{R(i)}_1$ (Note that for most internal wires Alice will not know the values corresponding to his keys, in this case (1,1), but for gates
connected only to input wires Alice might actually know these values.), and let her know the perm $\pi$. Alice must then not be able to compute $K^i_1$, since she does not know $K^{L(i)}_0,, K^{R(i)}_0$, she does not know at least $k$ bits for all other evaluations of $G$ and therefore we expect all the other $C^i_j$ s.t. $\pi(j) \neq (1,1)$ to be indistinguishable from random, in Alice's view (As $G$ is PRF). So we need for all $i$ that
$$(i, K^{L(i)}_1, K^{R(i)}_1, G(K^{L(i)}_0, K^{R(i)}_0, i), G(K^{L(i)}_0, K^{R(i)}_1, i), G(K^{L(i)}_1, K^{R(i)}_0, i))$$
and
$$(i, K^{L(i)}_1, K^{R(i)}_1, s_1, s_2, s_3)$$ are indistinguishable for $s_1, s_2, s_3 \in_R \{0,1\}^{2k}.$$
*** Privacy (Why we need the perm)
If the permutation did not happen, then during eval of any given gate, Alice learns $j$ s.t. $\tau_j = 0^k$. If Alice knew the permutation for that wire, Alice would learn the values of the input wires to that gate neing $\pi(j) = (a,b)$, which would be quite unfortunate.
*** Privacy definition
We defined privacy by asking that there exists a sim that on input $struct(f)$ and $z = f(x)$ can simulate $F, X, d.
1) Parse $struct(f)$ as the number of wires $T$, the number of inputs $n$ and the wiring functions $L$, $R$.
2) Choose $T+1$ random keys $K^i \in \{0,1\}^k$. Define $X = \{K^i\}_{i \in [1,n]}$, define $d = (Z_0, Z_1) = (K^T, K^{T+1}$
3) For $i \in [n+1, T]$ (all internal wires), choose random $h \in \{0,1,2,3\}$ and three random strings $C^i_k <- \{0,1\}^{2k}$ for $j \in \{0,1,2,3\}, j \neq h$. Define:
$$C^i_h = G(K^{L(i)}, K^{R(i)}, i) \oplus (K^i, 0^k)$$
for all $i \in [n+1, T-1]$ and define $$C^T_j = G(K^{L(T)}, K^{R(T)}, T) \oplus (K^{T+z}, 0^k)$$ (What is this $T+z$, should it be something different??)
So the sim creates a garbled circuit s.t. there exists a single key for each write and each garbled table contains a single encryption and 3 random ciphertexts. Note there is something different for the final gate, as we need to make sure it outputs the right value as defined by the decoding table $d$.
** Active Security
- Yao's protocol is only passively secure
*** Active Alice
- An actively corrupted Alice can't do much, as long as the OT protocol is actively secure. This is due to:
+ Garbled Circuit Authenticity: $G$ is said to enjoy authenticity if for all PPT $A$ (adversaries?), for all $f: \{0,1\}^n \rightarrow \{0,1\}$ and all $x \in \{0,1\}^n$: $Pr(De(d,A(F,X)) \not\in \{f(x), \perp\} < negl(k)$, where $(F,e,d) \leftarrow Gb(1^k, f)$, $X \leftarrow En(e,x)$.
+ This essentially states that an adversary on input a garbled circuit $F$ and a garbled input $X$, can only compute the right garbled output or compute something which will fail (the $\perp$). This implies that even an actively corrupted Alice can't cheat Yao's protocol, i.e. Alice won't be able to affect the output of the evaluation function beyond computing an error. This property is also used in Verifiable Delegation of Computation.
- In the protocol as described above, a corrupted Alice will see the garbled circuit F before she has to choose her input and feed it into the OT protocol. This allows her to pick her input based on F such that she can perform so called "selective opening attacks". (TODO: Perhaps write up the rest of this, I don't really care ..)
This can be easily fixed by changing the order of the messages in the protocol, so instead of sending $F,Y$ and then running the OT, you can simply run the OT first.
*** Active Bob
Bob can attack this protocol in several ways. He can change the function and encrypt a different $f^*$, than the one they had originally agreed on. Due to the privacy properties of the garbled circuit, Alice has no idea which function is garbled, so she can't tell $F$ and $F^*$ from each other, as long as they have the same structure. Particularly, $F^*$ could be a function allowing Bob to pick the output or make it leak something regarding the input of Alice.
*** Cut-and-choose
Similiar to what is done in ZK proofs. The protocol has Bob garble the function $f$ multiple times, say s, with independently chosen randomness and then send $F_1, \dots, F_s$ to Alice. Alice will then choose at random some of these garbled circuits and have Bob provide her with the randomness he used to generate them, s.t. Alice can verify it is the correct function he has garbled. (How is it proven that Bob did in fact choose the randomness correctly (the coin down a well thing??), because otherwise he could likely construct it such that two different randomness could construct the same circuit for the two different functions. This would completely break security, as the garbled circuit could now "open" to 2 different functions.. Do note that it would likely require a fuckton of compute power to pull this off, so it might just be written off as not plausible) Now, if Alice does not detect any cheating, she assumes the rest of the unopened circuits are correctly produced, so Alice and Bob will evaluate the remaining circuits. The amount evaluated allows for two main classes of cut-and-choose protocols:
1) "All-but-one" cut-and-choose: Alice chooses one index $j \in [1,s]$ at random. Bob sends the randomness used to garble all circuits $F_i$ s.t. $i \neq j$. If Alice does not find any function $f^*$ s.t. $f \neq f^*$, the protocol proceeds with the remaining circuit. This stills allows Bob to cheat with prob $1/s$, as he can garble a single malicious circuit and pray that Alice picks this. Thus, the security is only $1 - (1/s)$, which is not negligible.
2) "Majority" cut-and-choose: Alice chooses a subset $J \subset [1,s]$ of size $|J| \approx \frac{s}{2}$, leaving $|J|$ circuits to be checked, afterwards the protocol proceeds with evaluating the remaining unopened $s/2$ circuits. If the circuits output different values, Alice outputs the value output by the majority. This solves the "single malicious circuit" problem. However, even if Alice does detect any cheating, she does not complain to Bob. Complaining opens up for a /selective-failure/ attack: Bob garbles two functions $f_1, f_2$ s.t. they output same value if the first bit of $x$ is $0$ and different values otherwise. Now, depending on if Alice abort/complains or not, Bob will learn one bit of Alices input.
There is one last problem with this majority protocol. Now that Alice and Bob evaluate $s/2$ different circuits, we need to make sure that the inputs used in all evaluations are the same. Otherwise then Alice or Bob can learn the evaluation of the function on up to $s/2$ different outputs, which is an issue, as $f(x,y_1), \dots, f(x,y_{s/2})$ might leak more information than only running the protocol ones on $f(x,y)$.
*** Another selective failure attack
Bob can use the "wrong" input during the OT phase. Assume that for some position $i$, Bob inputs to the OT the pair $(m_0, m_1) = (K^i_0, R)$ for some random string $R$. Now, if the i-th bit of Alice's input is equal to $0$, Alice will learn $K^i_0$ from the OT, which allows correct evaluation, otherwise, she will get a random string and the $Ev$ algo will fail and Alice will abort. By observing whether Alice aborts or not, Bob will learn input bit $y_i$.
** Verifiable Delegation of Computation Using Garbled Circuits
A computationally limited client (such as a smartphone) wants to delegate the computation of a circuit $f$ on input $x$ to a powerful server. The client is afraid that the server might produce a wrong output. Thus, the client wants to verify that the output $z$ that he receives from the server is such that $z = f(x)$. The naive solution would be to compute $f(x)$ yourself, so we wish a solution faster than this. Garbled Circuits can be used to achieve a partial solution, delegation with preprocessing:
1) Preprocessing: Client computes $(F,e,d) <- Gb(f, 1^k)$ and sends $F$ to the server.
2) Online phase: When input $x$ becomes available, the client generates $X <- En(e,x)$ and sends $X$ to the server. The server computes $Z <- Ev(F,X)$ and returns $Z$ to the client, who outputs $z <- De(d,Z)$.
Due to authenticity, the client is sure that if $z \neq \perp$, then $z = f(x)$. The running time of online phase is independent of circuit size (size of $f$).
However, the complexity of preprocessing (running time of $Gb$) is proportional to $|f|$, which is why this is only a partial solution.
* Homomorphic Encryption
- Definition and applications.
- Pailler encryption (additively homomorphic).
- Bootstrapping: from bounded homomorphic encryption to unbounded homomorphic encryption.
- (Brief) Example of bounded homomorphic encryption scheme "with noise"
** Pailler's Cryptosystem
- Variant of the RSA encryption scheme, uses modulo $n^2$ rather than $n$.
- Allows to encrypt messages in $Z_n$.
- Uses two mappings from $Z_n$ to $Z_{n^2}$.
+ First mapping takes care of messages and ensures the scheme is homomorphic
+ Second takes care of randomness and makes sure scheme is secure
+ The two mappings can be combined in $Z_{n^2}$.
- The first mapping is an additively homomoprhic mapping of elements of $Z_n$ into $Z_{n^2}$.
+ $a(x) = (1 + x*n) \mod n^2$
+ TODO: Solve exercise to show this is homomorphic
+ Also this has an inverse s.t. for all elements of $Z_{n^2}$ in the image of $a$, it is possible to compute $x$ in $(1+x*n) \mod n^2$. (It is an exercise to show what it is)
- The second mapping, b, also maps from elements in $Z_n$ to $Z_{n^2}$, an it is essentially the same as RSA encryption function, but modulo $n^2$ and public exponent $e$ is fixed to $n$:
+ $b(x) = x^n \mod n^2$
+ TODO: Solve exercise showing this is multiplicatively homomorphic. I'd imagine it's the same as RSA
- Security of Pailler encryption is based on the assumption that it is hard to distinguish between uniformly random elements in $Z_{n^2}$ and the results of $b(x)$. Which is also just the semantic proof for RSA
- To this end, it is very easy to dinstinguish, if you know the factorisation of $n$ (as is also true for RSA), since you can compute $\phi(n) = (p-1)(q-1)$ if $pq = n$ which allows you to compute if a given ciphertext $y$ is within the image of $b$:
+ $y^{\phi(n)} = 1 \mod n^2$
+ If $y = b(x)$, then: $b(x)^{\phi(n)} = (x^n)^{\phi(n)} = x^{n * \phi(n)} = x^{\phi(n^2)} = 1 \mod n^2$
+ This follows from you having found the inverse, if you can factor $n$. Also, since every element of a group raised to the group order is $1$. However, most elements of $Z_{n^2}$ will not give $1$ if raised to $\phi(n)$.
*** The construction
Keygen:
- Sample primes $p,q$ of equal length.
- Set $n = pq$
- Output $sk = \phi(n) = (p-1)(q-1)$ and $pk = n$
Encryption:
- Given $m \in Z_n$, sample random $r \in_R Z^*_n$
- Outputs $C = a(m) * b(r) = (1 + m*n)*r^n \mod n^2$
Decryption:
- Compute $m = a^{-1}(C^{sk} \mod n^2) * sk^{-1} \mod n$
Correctness:
- Follows from the exercises showing that $a$ is invertible and where you find the specific function
- Perhaps the inverse of $a$ is just $(x-1)/n
Security:
- Follows from $b(r)$ and $Z_{n^2}$ being indistinguishable
- The scheme is additively homomorphic, thus:
+ $E(m_1, r_1) * E(m_2, r_2) = a(m_1)b(r_1)a(m_2)b(r_2) = a(m_1 + m_2)b(r_1 * r_2) = E(m_1+m_2, r_1*r_2) \mod n^2$
*** Using in arithmetic bedoza-protocol
- Can be used to replace dealer in bedoza with a two-party multiplication protocol based on Pailler cryptosystem, if we use BeDOZa over $Z_n$ where $n$ is the public parameter of Pailler and only Alice knows the factorisation of $n$.
- If we recall how mul works in BeDOZa:
+ Alice has $(x_A, y_A) \in Z_n \times Z_n$ and Bob has $(x_B, y_B) \in Z_n \times Z_n$ and in the end Alice and Bob has $(z_A, z_B) \in Z_n \times Z_n$ s.t. $z_A * z_B = (x_A+x_B)*(y_A+y_B) = (x_A*y_A+x_A*y_B+x_B*y_A+x_B*y_B$
- So Alice can compute $x_A*y_A$ locally and Bob can compute $x_B*y_B$, but they will need to interact to compute $x_A*y_B$ and $x_B * y_A$. To compute the shares of $x_A*y_B$:
1) Alice sends $U = E_n(x_a)$ to Bob
2) Bob samples a random $s_B \in_R Z_n$ and computes $V = U^{y_B} * E_n (-s_B) \mod n^2$ and then sends $V$ to Alice
3) Alice computes $s_A = D_{\phi(n)} (V)$ (whatever $D_{\phi(n)}$ means..
- Due to homomorphic property of $E$, it holds that $s_A + s_B = x_A*y_B \mod n$. Shares of $x_B*y_A$ can be computed similarly.
+ Is passively secure, as the simulator for a corrupted Bob would set $U = E(0)$ and it will be indistinguishable due to semantic security of Pailler. For corrupted Alice the simulator would encrypt $V = E(s_A)$ and this is distributed like $V$ in the real protocol.
+ Bob learns nothing about $x_A$ from $U$, unless he breaks security of Pailler. Alice learns nothing about $y_B$ because given that $s_B$ is uniformly random, $s_A$ is uniformly distributed in $Z_n$, in Alice's view.
+ The protocol can be compilted to active security via ZK proofs in multiplication protocol and MACs to ensure authenticitiy.