915 lines
54 KiB
HTML
915 lines
54 KiB
HTML
<?xml version="1.0" encoding="utf-8"?>
|
||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
|
||
"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:47 -->
|
||
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
|
||
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
||
<title>‎</title>
|
||
<meta name="generator" content="Org mode" />
|
||
<meta name="author" content="Alexander Munch-hansen" />
|
||
<style type="text/css">
|
||
<!--/*--><![CDATA[/*><!--*/
|
||
.title { text-align: center;
|
||
margin-bottom: .2em; }
|
||
.subtitle { text-align: center;
|
||
font-size: medium;
|
||
font-weight: bold;
|
||
margin-top:0; }
|
||
.todo { font-family: monospace; color: red; }
|
||
.done { font-family: monospace; color: green; }
|
||
.priority { font-family: monospace; color: orange; }
|
||
.tag { background-color: #eee; font-family: monospace;
|
||
padding: 2px; font-size: 80%; font-weight: normal; }
|
||
.timestamp { color: #bebebe; }
|
||
.timestamp-kwd { color: #5f9ea0; }
|
||
.org-right { margin-left: auto; margin-right: 0px; text-align: right; }
|
||
.org-left { margin-left: 0px; margin-right: auto; text-align: left; }
|
||
.org-center { margin-left: auto; margin-right: auto; text-align: center; }
|
||
.underline { text-decoration: underline; }
|
||
#postamble p, #preamble p { font-size: 90%; margin: .2em; }
|
||
p.verse { margin-left: 3%; }
|
||
pre {
|
||
border: 1px solid #ccc;
|
||
box-shadow: 3px 3px 3px #eee;
|
||
padding: 8pt;
|
||
font-family: monospace;
|
||
overflow: auto;
|
||
margin: 1.2em;
|
||
}
|
||
pre.src {
|
||
position: relative;
|
||
overflow: visible;
|
||
padding-top: 1.2em;
|
||
}
|
||
pre.src:before {
|
||
display: none;
|
||
position: absolute;
|
||
background-color: white;
|
||
top: -10px;
|
||
right: 10px;
|
||
padding: 3px;
|
||
border: 1px solid black;
|
||
}
|
||
pre.src:hover:before { display: inline;}
|
||
/* Languages per Org manual */
|
||
pre.src-asymptote:before { content: 'Asymptote'; }
|
||
pre.src-awk:before { content: 'Awk'; }
|
||
pre.src-C:before { content: 'C'; }
|
||
/* pre.src-C++ doesn't work in CSS */
|
||
pre.src-clojure:before { content: 'Clojure'; }
|
||
pre.src-css:before { content: 'CSS'; }
|
||
pre.src-D:before { content: 'D'; }
|
||
pre.src-ditaa:before { content: 'ditaa'; }
|
||
pre.src-dot:before { content: 'Graphviz'; }
|
||
pre.src-calc:before { content: 'Emacs Calc'; }
|
||
pre.src-emacs-lisp:before { content: 'Emacs Lisp'; }
|
||
pre.src-fortran:before { content: 'Fortran'; }
|
||
pre.src-gnuplot:before { content: 'gnuplot'; }
|
||
pre.src-haskell:before { content: 'Haskell'; }
|
||
pre.src-hledger:before { content: 'hledger'; }
|
||
pre.src-java:before { content: 'Java'; }
|
||
pre.src-js:before { content: 'Javascript'; }
|
||
pre.src-latex:before { content: 'LaTeX'; }
|
||
pre.src-ledger:before { content: 'Ledger'; }
|
||
pre.src-lisp:before { content: 'Lisp'; }
|
||
pre.src-lilypond:before { content: 'Lilypond'; }
|
||
pre.src-lua:before { content: 'Lua'; }
|
||
pre.src-matlab:before { content: 'MATLAB'; }
|
||
pre.src-mscgen:before { content: 'Mscgen'; }
|
||
pre.src-ocaml:before { content: 'Objective Caml'; }
|
||
pre.src-octave:before { content: 'Octave'; }
|
||
pre.src-org:before { content: 'Org mode'; }
|
||
pre.src-oz:before { content: 'OZ'; }
|
||
pre.src-plantuml:before { content: 'Plantuml'; }
|
||
pre.src-processing:before { content: 'Processing.js'; }
|
||
pre.src-python:before { content: 'Python'; }
|
||
pre.src-R:before { content: 'R'; }
|
||
pre.src-ruby:before { content: 'Ruby'; }
|
||
pre.src-sass:before { content: 'Sass'; }
|
||
pre.src-scheme:before { content: 'Scheme'; }
|
||
pre.src-screen:before { content: 'Gnu Screen'; }
|
||
pre.src-sed:before { content: 'Sed'; }
|
||
pre.src-sh:before { content: 'shell'; }
|
||
pre.src-sql:before { content: 'SQL'; }
|
||
pre.src-sqlite:before { content: 'SQLite'; }
|
||
/* additional languages in org.el's org-babel-load-languages alist */
|
||
pre.src-forth:before { content: 'Forth'; }
|
||
pre.src-io:before { content: 'IO'; }
|
||
pre.src-J:before { content: 'J'; }
|
||
pre.src-makefile:before { content: 'Makefile'; }
|
||
pre.src-maxima:before { content: 'Maxima'; }
|
||
pre.src-perl:before { content: 'Perl'; }
|
||
pre.src-picolisp:before { content: 'Pico Lisp'; }
|
||
pre.src-scala:before { content: 'Scala'; }
|
||
pre.src-shell:before { content: 'Shell Script'; }
|
||
pre.src-ebnf2ps:before { content: 'ebfn2ps'; }
|
||
/* additional language identifiers per "defun org-babel-execute"
|
||
in ob-*.el */
|
||
pre.src-cpp:before { content: 'C++'; }
|
||
pre.src-abc:before { content: 'ABC'; }
|
||
pre.src-coq:before { content: 'Coq'; }
|
||
pre.src-groovy:before { content: 'Groovy'; }
|
||
/* additional language identifiers from org-babel-shell-names in
|
||
ob-shell.el: ob-shell is the only babel language using a lambda to put
|
||
the execution function name together. */
|
||
pre.src-bash:before { content: 'bash'; }
|
||
pre.src-csh:before { content: 'csh'; }
|
||
pre.src-ash:before { content: 'ash'; }
|
||
pre.src-dash:before { content: 'dash'; }
|
||
pre.src-ksh:before { content: 'ksh'; }
|
||
pre.src-mksh:before { content: 'mksh'; }
|
||
pre.src-posh:before { content: 'posh'; }
|
||
/* Additional Emacs modes also supported by the LaTeX listings package */
|
||
pre.src-ada:before { content: 'Ada'; }
|
||
pre.src-asm:before { content: 'Assembler'; }
|
||
pre.src-caml:before { content: 'Caml'; }
|
||
pre.src-delphi:before { content: 'Delphi'; }
|
||
pre.src-html:before { content: 'HTML'; }
|
||
pre.src-idl:before { content: 'IDL'; }
|
||
pre.src-mercury:before { content: 'Mercury'; }
|
||
pre.src-metapost:before { content: 'MetaPost'; }
|
||
pre.src-modula-2:before { content: 'Modula-2'; }
|
||
pre.src-pascal:before { content: 'Pascal'; }
|
||
pre.src-ps:before { content: 'PostScript'; }
|
||
pre.src-prolog:before { content: 'Prolog'; }
|
||
pre.src-simula:before { content: 'Simula'; }
|
||
pre.src-tcl:before { content: 'tcl'; }
|
||
pre.src-tex:before { content: 'TeX'; }
|
||
pre.src-plain-tex:before { content: 'Plain TeX'; }
|
||
pre.src-verilog:before { content: 'Verilog'; }
|
||
pre.src-vhdl:before { content: 'VHDL'; }
|
||
pre.src-xml:before { content: 'XML'; }
|
||
pre.src-nxml:before { content: 'XML'; }
|
||
/* add a generic configuration mode; LaTeX export needs an additional
|
||
(add-to-list 'org-latex-listings-langs '(conf " ")) in .emacs */
|
||
pre.src-conf:before { content: 'Configuration File'; }
|
||
|
||
table { border-collapse:collapse; }
|
||
caption.t-above { caption-side: top; }
|
||
caption.t-bottom { caption-side: bottom; }
|
||
td, th { vertical-align:top; }
|
||
th.org-right { text-align: center; }
|
||
th.org-left { text-align: center; }
|
||
th.org-center { text-align: center; }
|
||
td.org-right { text-align: right; }
|
||
td.org-left { text-align: left; }
|
||
td.org-center { text-align: center; }
|
||
dt { font-weight: bold; }
|
||
.footpara { display: inline; }
|
||
.footdef { margin-bottom: 1em; }
|
||
.figure { padding: 1em; }
|
||
.figure p { text-align: center; }
|
||
.inlinetask {
|
||
padding: 10px;
|
||
border: 2px solid gray;
|
||
margin: 10px;
|
||
background: #ffffcc;
|
||
}
|
||
#org-div-home-and-up
|
||
{ text-align: right; font-size: 70%; white-space: nowrap; }
|
||
textarea { overflow-x: auto; }
|
||
.linenr { font-size: smaller }
|
||
.code-highlighted { background-color: #ffff00; }
|
||
.org-info-js_info-navigation { border-style: none; }
|
||
#org-info-js_console-label
|
||
{ font-size: 10px; font-weight: bold; white-space: nowrap; }
|
||
.org-info-js_search-highlight
|
||
{ background-color: #ffff00; color: #000000; font-weight: bold; }
|
||
.org-svg { width: 90%; }
|
||
/*]]>*/-->
|
||
</style>
|
||
<script type="text/javascript">
|
||
/*
|
||
@licstart The following is the entire license notice for the
|
||
JavaScript code in this tag.
|
||
|
||
Copyright (C) 2012-2018 Free Software Foundation, Inc.
|
||
|
||
The JavaScript code in this tag is free software: you can
|
||
redistribute it and/or modify it under the terms of the GNU
|
||
General Public License (GNU GPL) as published by the Free Software
|
||
Foundation, either version 3 of the License, or (at your option)
|
||
any later version. The code is distributed WITHOUT ANY WARRANTY;
|
||
without even the implied warranty of MERCHANTABILITY or FITNESS
|
||
FOR A PARTICULAR PURPOSE. See the GNU GPL for more details.
|
||
|
||
As additional permission under GNU GPL version 3 section 7, you
|
||
may distribute non-source (e.g., minimized or compacted) forms of
|
||
that code without the copy of the GNU GPL normally required by
|
||
section 4, provided you include this license notice and a URL
|
||
through which recipients can access the Corresponding Source.
|
||
|
||
|
||
@licend The above is the entire license notice
|
||
for the JavaScript code in this tag.
|
||
*/
|
||
<!--/*--><![CDATA[/*><!--*/
|
||
function CodeHighlightOn(elem, id)
|
||
{
|
||
var target = document.getElementById(id);
|
||
if(null != target) {
|
||
elem.cacheClassElem = elem.className;
|
||
elem.cacheClassTarget = target.className;
|
||
target.className = "code-highlighted";
|
||
elem.className = "code-highlighted";
|
||
}
|
||
}
|
||
function CodeHighlightOff(elem, id)
|
||
{
|
||
var target = document.getElementById(id);
|
||
if(elem.cacheClassElem)
|
||
elem.className = elem.cacheClassElem;
|
||
if(elem.cacheClassTarget)
|
||
target.className = elem.cacheClassTarget;
|
||
}
|
||
/*]]>*///-->
|
||
</script>
|
||
<script type="text/x-mathjax-config">
|
||
MathJax.Hub.Config({
|
||
displayAlign: "center",
|
||
displayIndent: "0em",
|
||
|
||
"HTML-CSS": { scale: 100,
|
||
linebreaks: { automatic: "false" },
|
||
webFont: "TeX"
|
||
},
|
||
SVG: {scale: 100,
|
||
linebreaks: { automatic: "false" },
|
||
font: "TeX"},
|
||
NativeMML: {scale: 100},
|
||
TeX: { equationNumbers: {autoNumber: "AMS"},
|
||
MultLineWidth: "85%",
|
||
TagSide: "right",
|
||
TagIndent: ".8em"
|
||
}
|
||
});
|
||
</script>
|
||
<script type="text/javascript"
|
||
src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.0/MathJax.js?config=TeX-AMS_HTML"></script>
|
||
</head>
|
||
<body>
|
||
<div id="content">
|
||
<div id="table-of-contents">
|
||
<h2>Table of Contents</h2>
|
||
<div id="text-table-of-contents">
|
||
<ul>
|
||
<li><a href="#org341912d">1. Protocols with Trusted Dealer (week 2 & 3)</a>
|
||
<ul>
|
||
<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="#org914fdd8">1.3.1. OTTT</a></li>
|
||
<li><a href="#org0a53b40">1.3.2. BeDOZa</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#org2ff720b">1.4. Active Security</a>
|
||
<ul>
|
||
<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="#orgac56d39">2. Oblivious Transfer</a>
|
||
<ul>
|
||
<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="#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="#org3ed5041">2.4. The GWM-Compiler</a>
|
||
<ul>
|
||
<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="#org8127242">2.5. Efficient Active Secure OT</a>
|
||
<ul>
|
||
<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-org341912d" class="outline-2">
|
||
<h2 id="org341912d"><span class="section-number-2">1</span> Protocols with Trusted Dealer (week 2 & 3)</h2>
|
||
<div class="outline-text-2" id="text-1">
|
||
</div>
|
||
<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>
|
||
<li>Protocols with passive security (One-time truth-tables, passive BeDOZa) and their security.</li>
|
||
<li>Active attacks against OTTT/BeDOZa.</li>
|
||
<li>Countermeasures (using information-theoretic MACs) and their security.</li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
|
||
<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>
|
||
<li>The views contain the party input, internal randomness (if any), and all the messages received during the protocol
|
||
<ul class="org-ul">
|
||
<li>The messages sent do not need to be included, as these are a function of the randomness and the messages received</li>
|
||
</ul></li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
<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-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>
|
||
<li>Rather than computing the function though, it's represented by a truth table (a matrix) $ T ∈ \{0,1\}<sup>2<sup>n</sup> × 2<sup>n</sup></sup> $ where \(T[i,j] = f(i,j)\).</li>
|
||
<li>The ideal functionality is: Alice inputs \(x \in \{0,1\}^{n}\) and Bob inputs \(y \in \{0,1\}^{n}\). The protocols allows Alice to learn \(z = f(x,y)\) and Bob should learn <i>nothing</i>.</li>
|
||
</ul>
|
||
</div>
|
||
<ol class="org-ol">
|
||
<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:
|
||
<ol class="org-ol">
|
||
<li>Choose two shifts \(r \in \{0,1\}^n\) and \(s \in \{0,1\}^n\) <b>uniformly at random</b></li>
|
||
<li>Choose matrix \(M_B \in \{0,1\}^{2^n \times 2^n}\) <b>uniformly at random</b></li>
|
||
<li>Compute a matrix \(M_A\) s.t. \(M_A[i,j] = M_B[i,j] \oplus T[i-r \mod 2^n, j-s \mod 2^n]\)</li>
|
||
<li>Output \((r,M_A)\) to Alice and \((s, M_B)\) to Bob.</li>
|
||
</ol></li>
|
||
<li><b>The actual protocol</b>:
|
||
<ol class="org-ol">
|
||
<li>Alice computes \(u = x+r \mod 2^n\) and sends \(u\) to Bob</li>
|
||
<li>Bob computes \(v = y+s \mod 2^n\) and \(z_B = M[u,v]\) and sends \((v,z_B)\) to Alice</li>
|
||
<li>Alice outs \(z = M_A[u,v] \oplus z_B\)</li>
|
||
</ol></li>
|
||
<li><b>Correctness</b>: \[z = M_A[u,v] \oplus z_B = M_A[u,v] \oplus M_B[u,v] = T[u-r, v-s] = T[x,y] = f(x,y)\]</li>
|
||
</ul>
|
||
</div>
|
||
</li>
|
||
<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>
|
||
<li>The views for OTTT are defined as: \[ view_A = \{x, (r,M_A), (v, z_B) \} \] and \[ view_B = \{y, (s, M_B), u \}\]</li>
|
||
<li>According to the book, as this is a deterministic function, we can look at the distribution of outputs and the views separately.</li>
|
||
<li><b>Alice</b>:
|
||
<ol class="org-ol">
|
||
<li>The simulator gets as input \(x \in \{0,1\}^n\) and \(z \in \{0,1\}\)</li>
|
||
<li>Sample uniformly a random \(z_B \in \{0,1\}\), a random \(v \in \{0,1\}^n\) and a random \(r \in \{0,1\}^n\)</li>
|
||
<li>Construct M<sub>A</sub> : ∀ (i,j) ≠ (x+r,v): choose \(M_A[i,j] \in \{0,1\}\) uniformly at random. Define \(M_A[x+r,v] = z \oplus z_B\).</li>
|
||
</ol></li>
|
||
<li>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.</li>
|
||
<li>The pair $(M<sub>A</sub>[u,v], z<sub>B</sub>) is in both cases a pair of random bits s.t. \(z = M_A[u,v] \oplus z_B\)
|
||
<ul class="org-ul">
|
||
<li>This is an application of the "principle of deferred decision", i.e. it does not matter which order the random elements are sampled</li>
|
||
</ul></li>
|
||
<li>Has unconditional security, kind of the OTP of MPC</li>
|
||
<li>Optimal round complexity, as it's only one message per party</li>
|
||
<li>\(2n+1\) bits are send, which is \(1\) bit off the optimal communication complexity, which is \(2n\)</li>
|
||
<li>Has a bad storage problem, as each party needs to receive an exponential of \(n\) bits from the trusted dealer
|
||
<ul class="org-ul">
|
||
<li>One could gen \(M_B\) or \(M_A\) using a pseudorandom generator. This forces the protocol to only have computational security from the previous unconditional, but the storage complexity of one of the parties can be made small, while the other still needs exponential.</li>
|
||
</ul></li>
|
||
</ul>
|
||
</div>
|
||
</li>
|
||
</ol>
|
||
</div>
|
||
<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>
|
||
<li>More complicated, as it has to support different operations, XOR and AND.</li>
|
||
<li><b>Circuit Notation</b>: A circuit is a function \(C : \{0,1\}^n \times \{0,1\}^n \rightarrow \{0, 1\}\) where the first input bits comes from Alice and the seconds from Bob. Gates have unbounded fanout. No cycles are allowed.</li>
|
||
<li><b>Invariant</b>: The protocol works on secret shared bits.</li>
|
||
<li>Has \(6\) different layers or wires!
|
||
<ol class="org-ol">
|
||
<li>Input Wires: For each of the <i>n</i> wires belonging to Alice: Alice samples a random bit \(x_B \leftarrow \{0,1\}\), sets \(x_A = x \oplus x_B\) and then sends \(x_B\) to Bob. \(x\) is said to be "shared" or "x-in-a-box", using notation \([x] \leftarrow Share(A,x)\). Bob is symmetric to this.</li>
|
||
<li>Output wires: If Alice (resp. Bob), is supposed to learn [x], Bob sends \(x_B\) to Alice who can then output \(x = x_A \oplus x_B\). \((x, \perp) \leftarrow OpenTo(A, [x])\). \(x \leftarrow OpenTo([x])\) is written, if both is to learn.</li>
|
||
<li>XOR with Constant: Write \([z] = [x] \oplus c\) for a unary gate computing \(z = x \oplus c\) for some constant bit \(c \in \{0,1\}\). In reality, Alice computes \(z_A = x_A \oplus c\) while Bob simply sets \(z_B = x_B\).</li>
|
||
<li>AND with Constant: \([z] = [x] \cdot c\). Same as above, kinda, but multiply. Both Alice and Bob multiplies their share by c now. \(z_{A,B} = x_{A,B} \cdot c\).</li>
|
||
<li>XOR of Two Wires: \([z] = [x] \oplus [y]\). Alice computes \(z_A = x_A \oplus y_A\), Bob computes \(z_B = x_B \oplus y_B\).</li>
|
||
<li>AND of Two Wires: The only part which requires a trusted dealer. \([z] \leftarrow EvalAnd([x], [y])\), computes \(z = x \cdot y\).
|
||
<ol class="org-ol">
|
||
<li>Dealer outputs a random triple \([u], [v], [w]\) s.t. \(w = u \cdot v\).</li>
|
||
<li>Run subprotocol: \([d] = [x] \oplus [u]\)</li>
|
||
<li>Run subproto: \([e] = [y] \oplus [v]\)</li>
|
||
<li>Run subproto: \(d \leftarrow Open([d])\)</li>
|
||
<li>Run subproto: \(e \leftarrow Open([e])\)</li>
|
||
<li>Run subproto: \([z] = [w] \oplus e \cdot [x] \oplus d \cdot [y] \oplus e \cdot d\)</li>
|
||
</ol></li>
|
||
</ol></li>
|
||
<li><b>Putting all of this together</b>: The circuit has <i>L</i> wires; \(x^1, ..., x^L\), there is only one output wire; \(x^L\). First Alice and Bob run the subproto Share for each of the 2n input wires in the circuit; Then for each layer in the circuit \(1,\dots,d\) alice and bob securely evaluate all gates at that layer using the subprotos XOR and AND and gates can only get input from gates at a lower level. Eventually, the value at the output wire will be ready and it can be opened to Alice, \((x, \perp) \leftarrow OpenTo(A, [x^L])\).</li>
|
||
<li>OT can be used to remove the trusted dealer from BeDOZa.</li>
|
||
</ul>
|
||
</div>
|
||
<ol class="org-ol">
|
||
<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>
|
||
<li><b>Correctness</b>: All gates are trivially correct, apart from AND: $$ w ⊕ e ⋅ x ⊕ d ⋅ y ⊕ e ⋅ d = uv ⊕ (xy ⊕ vx) ⊕ (xy ⊕ uy) ⊕ (xy ⊕ vx ⊕ uy ⊕ uv) = xy$.</li>
|
||
<li><b>Simulation of the view of a corrupted Alice, having only access to her input/output</b>:
|
||
<ol class="org-ol">
|
||
<li>For each invocation of \([x^i] = Share(x^i, A)\), the simulator (like an honest Alice would), samples random \(x^i_B\) and sets \(x^i_A = x^i \oplus x^i_B\).</li>
|
||
<li>For each invocation of \([x^i] = Share(x^i, B)\), the simulator includes in the view a message from Bob with a random bit \(x^i_A \leftarrow \{0,1\}\).</li>
|
||
<li>When \([x^k] = [x^i] \oplus [x^j]\) is invoked, the sim (like an honest Alice) computes \(x^k_A = x^i_A \oplus x^j_A\); (Simulation for XOR with constant and AND with constant is done similarly)</li>
|
||
<li></li>
|
||
</ol></li>
|
||
</ul>
|
||
</div>
|
||
</li>
|
||
</ol>
|
||
</div>
|
||
</div>
|
||
<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-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:
|
||
<ol class="org-ol">
|
||
<li>Bob can send the wrong value \(v'\), rather than \(v = y+s\). This means that Bob sends some arbitrary \(v' \in \{0,1\}^n\). However, this can be seen as input substitution, since it's based on \(y\), which is a value only Bob knows regardless.
|
||
<ul class="org-ul">
|
||
<li>Since \(v' = (y+diff) + s\) s.t. \(y+diff = y'\), where \(y'\) could might as well have been the original input.</li>
|
||
</ul></li>
|
||
<li>Bob sends <i>nothing</i> or <i>an invalid message</i>. This will happen if Bob either does not send anything or Bob sends a pair which is not the right format; i.e. \((v', z'_B) \not\in \{0,1\}^n \times \{0,1\}\).
|
||
<ul class="org-ul">
|
||
<li>The second condition can be checked by Alice and the first can be solved by adding a timer at which point Alice will time out.</li>
|
||
<li>At this point, Bob has learned nothing but the value \(u\), which is just a random value, as such we will not consider this cheating.</li>
|
||
<li>So we account for this by modifying the protocol in such a way that if Alice detects an invalid message or receives none, she simply outputs \(z = f(x, y_0)\) where \(y_0\) is just some default input. This can be computed efficiently in the simulated world by having the simulator give \(y_0\) to the ideal world.</li>
|
||
</ul></li>
|
||
<li>Bob <i>sends a wrong value</i> \(z'_B\). Since \(z_B\) is the value we XOR with in the end, if it's flipped, Alice will get the wrong result, but will not know this.
|
||
<ul class="org-ul">
|
||
<li>Since \(z'_B = z_B \oplus 1\) must be true, Alice will output \(z' = z \oplus 1 = f(x,y) \oplus 1\).</li>
|
||
<li>This is <b>NOT</b> <i>input substitution</i>. If Alice and Bob were to compute \(f(x,y) = 0\) for all values of \(x\) and \(y\), this would get fucked by Bob flipping his \(z_B\), as Alice would always end up XORing \(0\) and \(1\), giving \(1\) instead of \(0\) as the result.</li>
|
||
</ul></li>
|
||
</ol></li>
|
||
<li>Does, we need to defend us against the third case!</li>
|
||
</ul>
|
||
</div>
|
||
<ol class="org-ol">
|
||
<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>
|
||
<li>Has three algos: (gen, tag, ver), where gen produces a MAC key k which can then be used to compute a tag on messages: \(t = tag(k,m)\). The verification function ver(k,t,m) outputs accept if t is a valid tag for message m under key k and rejects otherwise.
|
||
<ul class="org-ul">
|
||
<li>Security of a MAC is defined as a game between a challenger C and an adversary A. C samples a key k and then A is alllowed to query q times for tags t<sub>1,…,t</sub><sub>q</sub> on messages x<sub>1</sub>, …., x<sub>q</sub>. The adversary then outputs a pair (t', x') for a message x' which he has not already queried for. A MAC scheme is then (q, eps) secure if the adversary is allowed <= q queries and his probability of t' being a valid tag for x' is >= eps.</li>
|
||
</ul></li>
|
||
</ul>
|
||
</div>
|
||
</li>
|
||
<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:
|
||
<ol class="org-ol">
|
||
<li>Choose two shifts \(r \in \{0,1\}^n\) and \(s \in \{0,1\}^n\) <b>uniformly at random</b></li>
|
||
<li>Choose matrix \(M_B \in \{0,1\}^{2^n \times 2^n}\) <b>uniformly at random</b></li>
|
||
<li>Compute a matrix \(M_A\) s.t. \(M_A[i,j] = M_B[i,j] \oplus T[i-r \mod 2^n, j-s \mod 2^n]\)</li>
|
||
<li>Generate \(2^{2n}\) keys for a $(1, ε)$-secure MAC i.e. ∀ i,j ∈ {0,1}<sup>n</sup> define \(K[i,j] \leftarrow Gen()\).</li>
|
||
<li>Generate MACs for values in \(M_B\); i.e. ∀ i,j ∈ {0,1}<sup>n</sup> define \(T[i,j] \leftarrow Tag(K[i,j], M_B[i,j])\).</li>
|
||
<li>Output \((r, M_A, K)\) to Alice and \((s, M_B, T)\) to Bob.</li>
|
||
</ol></li>
|
||
<li><b>The protocol</b>:
|
||
<ol class="org-ol">
|
||
<li>Alice computes \(u = x+r \mod 2^n\) again and sends this to Bob</li>
|
||
<li>Bob computes \(v = y+s \mod 2^n\), \(z_B = M_B[u,v]\) and \(t_B = T[u,v]\) and then sends \((v, z_B, t_B)\) to Alice</li>
|
||
<li>If \(ver(z_B, t_B, K[u,v]) = reject\) or no valid message is received, Alice outputs \(f(x, y_0) = z\), else \(z = M_A[u,v] \oplus z_B\).</li>
|
||
</ol></li>
|
||
</ul>
|
||
</div>
|
||
</li>
|
||
<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>
|
||
<li>The proof is a reduction to breaking the underlying MAC scheme, if we can break the OTTT protocol.</li>
|
||
<li><b>The simulator</b>:
|
||
<ol class="org-ol">
|
||
<li>Sample random \(s, M_B\), generate keys \(K\) for the MAC scheme and compute MACs \(T = Tag(K, M_B)\) (for all entrances) and send \((s, M_B, T)\) to Bob (so the simulator replaces the trusted dealer).</li>
|
||
<li>Sample a random \(u\) and send it to Bob (replacing the honest Alice)</li>
|
||
<li>If Bob does not output anything or output an invalid message, or output a triple \((v', z'_B, t'_B)\) s.t. \(z'_B \neq M_B[u,v]\), the simulator inputs \(y_0\) to the ideal func. Else the sim inputs \(y = v' - s\) to the ideal func.</li>
|
||
</ol></li>
|
||
<li><b>Proof</b>:
|
||
<ol class="org-ol">
|
||
<li><i>The view of Bob</i> 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.</li>
|
||
<li>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.</li>
|
||
</ol></li>
|
||
</ul>
|
||
</div>
|
||
</li>
|
||
<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:
|
||
<ol class="org-ol">
|
||
<li>\(k \leftarrow Gen()\): Sample \(k = (\alpha, \beta) \leftarrow Z^2_p\) for a prime \(p\)</li>
|
||
<li>\(t \leftarrow Tag(k, m)\): Compute a tag \(t\) on a message \(m\) with key \(k = (\alpha, \beta)\); \(t = \alpha \cdot m + \beta\)</li>
|
||
<li>\(\{accept, reject\} \leftarrow ver(k,t,m)\): Output accept if \(t' = \alpha \cdot m + \beta\), reject ow.</li>
|
||
</ol></li>
|
||
</ul>
|
||
</div>
|
||
</li>
|
||
</ol>
|
||
</div>
|
||
<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>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<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-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>
|
||
<li>Protocols with passive security (from public-key encryption with random looking keys).</li>
|
||
<li>The GMW compiler (3 steps: zero-knowledge proofs, coin-flip into the well, input commitment) and how to use it to construct active secure oblivious transfers - OR -</li>
|
||
<li>Explicit constructions of active secure oblivious transfer in the common reference string (PVW protocol).</li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
<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:
|
||
<ol class="org-ol">
|
||
<li>Alice inputs a choice bit \(b \in \{0,1\}\)</li>
|
||
<li>Bob inputs two messages \(m_0, m_1\)</li>
|
||
<li>Alice learns \(z = m_b\)</li>
|
||
</ol></li>
|
||
<li>A secure OT should not let Alice learn anything about unchosen bit and Bob should not learn which bit Alice desires.</li>
|
||
<li><i>1-out-of-n</i> is exactly what it sounds like.
|
||
<ul class="org-ul">
|
||
<li><i>1-out-of-n</i> OT directly implies single two-party secure computation for some function \(f(x,y)\) for \(x <= n\), as Bob can create his messages \(M_0, ..., M_{n-1}\) as \(M_i = f(i,y)\), using his own input \(y\) and Alice will then use \(x\) as the choice bit, giving her \(M_i\) for \(i=x\), \(f(x,y)\).</li>
|
||
</ul></li>
|
||
<li>OT can be used to remove the trusted dealer from BeDOZa.
|
||
<ul class="org-ul">
|
||
<li>Specifically, for the multiplication (AND) gate, the trusted dealer had to samle bits \(u_a,v_a,u_b,v_b,w_b\), had to compute $w<sub>a</sub> = (u<sub>a</sub> ⊕ u<sub>b</sub>) ⋅ (v<sub>a</sub> ⊕ v<sub>b</sub>) ⊕ w<sub>b</sub> and then send all the subscript \(A\) to Alice and vice versa for Bob.</li>
|
||
<li>This dealer can be replaced by a (4 1)-OT protocol:
|
||
<ol class="org-ol">
|
||
<li>Alice samples random bits \(u_A, v_A\) and inputs \(i=2 \cdot u_a + v_a\) to the OT</li>
|
||
<li>Bob samples \(u_B, v_B, w_B\) and inputs to the OT: \[M_0 = (0 \oplus u_B) \cdot (0 \oplus v_B) \oplus w_B\] \[M_1 = (0 \oplus u_B) \cdot (1 \oplus v_B) \oplus w_B\] \[M_0 = (1 \oplus u_B) \cdot (0 \oplus v_B) \oplus w_B\] \[M_0 = (1 \oplus u_B) \cdot (1 \oplus v_B) \oplus w_B\]</li>
|
||
<li>Alice then sets \(w_A = M_i\)</li>
|
||
</ol></li>
|
||
</ul></li>
|
||
<li>There exists something called <b>Random OT</b>, which is a randomized functionality where parties have no input. The functionality samples random bits \(b,s_0,s_1\) and outputs \((b,z=s_b\) to Alice and \(s_0,s_1\) to Bob.</li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
<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-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:
|
||
<ul class="org-ul">
|
||
<li><b>Choose</b>: Alice (who has a choice bit b) generates a public key \(pk_b\) with a secret key \(sk_b\) and samples another random string \(pk_{1-b}\) whose secret key she does not know. She sends \((pk_0, pk_1)\) to Bob.</li>
|
||
<li><b>Transfer</b>: Bob (with messages \(m_0,m_1\)) creates two ciphertexts \(c_0,c_1\) where \(c_i\) is an encryption of \(m_i\) under \(pk_i\). He sends \((c_0,c_1)\) to Alice.</li>
|
||
<li><b>Retrieve</b>: Alice can only decrypt \(c_b\), as she only knows \(sk_b\). She learns \(m_b\).</li>
|
||
</ul></li>
|
||
<li>Since keys are pseudorandom, Bob can not distinguish between the fake PK and the real one. Alice does not know the sk for the fake pk and thus she can not decrypt the undesired message.</li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
<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:
|
||
<ol class="org-ol">
|
||
<li>Public keys generated like this looks like regular pks</li>
|
||
<li>It is not possible to learn the sk corresponding to the pks generated like this.
|
||
<ul class="org-ul">
|
||
<li>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!</li>
|
||
</ul></li>
|
||
</ol></li>
|
||
<li>A PKE with <i>oblivious key generation</i> is a regular <b>IND-CPA-secure</b> PKE defined by three algos <b>Gen, Enc, Dec</b>, but with an additional algo <i>oblivious generation</i> or <b>OGen</b>. OGen outputs strings which look like regular pks. OGen must satisfy:
|
||
<ol class="org-ol">
|
||
<li>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???)</li>
|
||
<li>It is possible to <b>efficiently invert</b> \(pk \leftarrow OGen(r)\), which is denoted \(r \leftarrow OGen^{-1}(pk)\)</li>
|
||
</ol></li>
|
||
<li>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;
|
||
<ol class="org-ol">
|
||
<li>There exists no PPT algo A, which can output \(sk \leftarrow A(r)\) s.t. \(Gen(sk) = OGen(r)\).</li>
|
||
</ol></li>
|
||
<li>\(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)\]</li>
|
||
<li>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))\].</li>
|
||
<li>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.
|
||
<ol class="org-ol">
|
||
<li>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.
|
||
<ul class="org-ul">
|
||
<li>This can be proven using property 1, 2 and that PKE is IND-CPA</li>
|
||
</ul></li>
|
||
</ol></li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
<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>
|
||
<li>Think of a pseudorandom generator PRG, which expands n-bit long seed s into a 2n bit long string y=PRG(s). A trivial sampler for PRG is the identity function which maps 2n bit strings into 2n bit strings. This function is invertible and the security of the PRG implies that the output of the PRG is indistinguishable from uniformly random 2n-bit strings.</li>
|
||
</ul>
|
||
</div>
|
||
<ol class="org-ol">
|
||
<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:
|
||
<ul class="org-ul">
|
||
<li><b>Gen(sk):</b> Input secret key \(sk = \alpha \in Z_q\), compute h = g<sup>α</sup>$ and out \(pk = (g,h)\)</li>
|
||
<li><b>\(Enc_{pk}(m)\):</b> Input message \(m \in G\), sample random \(r \in Z_q\), parse \(pk = (g,h)\), output \(C = (g^r, m \cdot h^r)\)</li>
|
||
<li><b>\(Dec_{sk}(C)\):</b> parse C as \((c_1, c_2)\). Output \(m = c_2 \cdot c_1^{-\alpha}\).</li>
|
||
</ul></li>
|
||
<li>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.</li>
|
||
</ul>
|
||
</div>
|
||
</li>
|
||
</ol>
|
||
</div>
|
||
<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:
|
||
<ol class="org-ol">
|
||
<li>Samples random \(sk, r\)</li>
|
||
<li>Gens \(pk_b <- Gen(sk)\), \(pk_{1-b} <- OGen(r)\)</li>
|
||
<li>Sends \((pk_0, pk_1)\) to Bob</li>
|
||
</ol></li>
|
||
<li><b>Transfer Phase:</b> Bob with \(m_0,m_1\):
|
||
<ol class="org-ol">
|
||
<li>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\)</li>
|
||
<li>Sends \((c_0, c_1)\) to Alice</li>
|
||
</ol></li>
|
||
<li><b>Retrieve Phase:</b> Alice outputs \(m_b <- Dec(sk, c_b)\)</li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<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-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>
|
||
<li>Simple protocol based on DL:
|
||
<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>
|
||
</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-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.
|
||
<ul class="org-ul">
|
||
<li>Such as Graph Nonisomorphism</li>
|
||
</ul></li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
<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
|
||
<ul class="org-ul">
|
||
<li>Is only passive though, as Alice could just sample both PKs using Gen. Bob would not know this, as OGen and Gen should be indistinguishable from each other.</li>
|
||
</ul></li>
|
||
<li>Simply adding a ZK proof that some \(r\) is used to generate either key.
|
||
<ul class="org-ul">
|
||
<li>\(x = (pk_0,pk_1)\), \(w=r\), the relation would accept if \((pk_0 = OGen(r) \text{ or } pk_1 = OGen(r))\). This can be attacked, by computing \(pk_0 = Gen(sk_0), pk_1 = Gen(sk_1), r=OGen^{-1}(pk_0)\) s.t. \(pk_0 = OGen(r)\), and then use \(r\) for the ZK proof.</li>
|
||
</ul></li>
|
||
<li>Issue arises as Alice can choose her own randomness, however, on the other hand we can not let Bob choose this for her either.</li>
|
||
<li><b>Coin flip into the well</b> is a fix for this. Essentialy, it allows Bob to participate, without having access to the end result. Bob will choose some \(r_B\) and Alice will choose some \(r_A\) and these can be XORed, when Bob sends \(r_B\) to Alice.
|
||
<ol class="org-ol">
|
||
<li>Alice choose random string \(r_A\) and randomness \(s\) for the commitment scheme. She computes \(c = Com(r_A, s)\) and sends \(c\) to Bob.</li>
|
||
<li>Bob choose random \(r_B\) and sends this to Alice.</li>
|
||
<li>Alice computes \(r = r_A \oplus r_B\) and \(s\), Bob has \((c,r_B)\) in the end.</li>
|
||
</ol></li>
|
||
<li>Finally, \(r\) is random, \(c\) is hiding, so Bob can not base \(r_B\) on \(r_A\) and c is also binding, so Alice can not choose a new \(r_A\).</li>
|
||
<li>Now Alice can compute \(pk_b = Gen(sk)\), \(pk_{1-b} = OGen(r)\) using the \(r\) from the coinflipping protocol. Alice will then send \((pk_0, pk_1)\) to Bob and Alice and Bob will then use ZK box for the following relation: \(x = (pk_0, pk_1, c, r_B)\), witness \(w = (r,s)\) and the relation outputs \(1\) if: \(c = Com(r \oplus r_B, s) \text{ and } (pk_0 = OGen(r) \text{ or } pk_1 = OGen(r))\).</li>
|
||
<li>This addition suffices to make the aforementioned protocol actively secure. It is not always enough though, as such, a third step might be required.</li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
<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
|
||
<ol class="org-ol">
|
||
<li>Alice gens \(pk^1_b = Gen(sk^1)\) and \(pk^1_{1-b} = OGen(r^1)\) and sends \((pk^1_0, pk^1_1)\) to Bob</li>
|
||
<li>Bob computes \(e^1_0 = Enc(pk^1_0, m_0), e^1_1 = Enc(pk^1_1, m_1)\). Sends \((e^1_0, e^1_1)\) to Alice</li>
|
||
<li>Alice gens \(pk^2_b = Gen(sk^2)\) and \(pk^2_{1-b} = OGen(r^2)\) and sends \((pk^2_0, pk^2_1)\) to Bob</li>
|
||
<li>Bob computes \(e^2_0 = Enc(pk^2_0, m_0), e^2_1 = Enc(pk^2_1, m_1)\). Sends \((e^2_0, e^2_1)\) to Alice</li>
|
||
<li>Alice outputs \(m_b = Dec(sk^1, e^1_b)\)</li>
|
||
</ol></li>
|
||
<li>So the protocol simply runs two copies of the original protocol <i>using the same inputs</i>. This protocol is still secure against passive corruption. If we simply compile this the same way as before (so only two steps), we get something which is not actively secure:
|
||
<ol class="org-ol">
|
||
<li>Run coin-flip proto; Alice gets \((r,s)\), parse \(r = (r^1, r^2)\), bob gets \((c, r_B)\)</li>
|
||
<li>Alice gens \(pk^1_{1-b} = OGen(r^1)\), sends (\(pk^1_0, pk^1_1)\) to Bob.</li>
|
||
<li>Alice and Bob runs ZK proof where Alice proves that \((pk^1_0 = OGen(r^1) \text{ or } pk^1_1 = OGen(r^1))\)</li>
|
||
<li>Bob computes and sends \((e^1_0,e^1_1)\)</li>
|
||
<li>Alice gens \(pk^2_{1-b} = OGen(r^2)\), sends (\(pk^2_0, pk^2_1)\) to Bob.</li>
|
||
<li>Alice and Bob runs ZK proof where Alice proves that \((pk^2_0 = OGen(r^2) \text{ or } pk^2_1 = OGen(r^2))\)</li>
|
||
<li>Bob computes and sends \((e^2_0,e^2_1)\)</li>
|
||
</ol></li>
|
||
<li>Clearly not secure, as Alice can change which bit she is interested between step 2 and 5. This results in her having Bob encrypt both \(m_0\) and \(m_1\) using the actual encryption key, so she can learn both.</li>
|
||
<li>Is fixed by having Alice also commit to her input bit.
|
||
<ol class="org-ol">
|
||
<li>Alice with input \(b\) choosen random \(r_A,s,t\), computes \(c = Com(r_A,s)\) and \(d = Com(b,t)\). Sends \((c,d)\) to Bob.</li>
|
||
<li>Alice and Bob perform ZK proof where \(x = (c,d)\), \(w = (b,r_A,s,t)\) and \(R(x,w)=1\) if \(c = Com(r_A,s) \text{ or } d = Com(b,t)\).</li>
|
||
<li>Bob choose \(r_B\) and sends to Alice</li>
|
||
<li>Alice computes \(r = r_A \oplus r_B\), choose random \(sk\) and computes \(pk_b = Gen(sk)\) and \(pk_{1-b} = OGen(r)\). Sends \((pk_0,pk_1)\) to Bob</li>
|
||
<li>Alice and Bob perform another ZK proof; \(x = (c,d,r_B,pk_0,pk_1)\), \(w = (b,r_A,s,t)\), \(R(x,w) = 1\) if: \(c = Com(r \oplus r_B, s) \text{ and } d = Com(b,t) \text{ and } pk_{1-b} = OGen(r_A \oplus r_B)\). Note that the final and can be computed due to the simulator learning the witness.</li>
|
||
<li>Bob sends \((e_0,e_1)\) to Alice, \(e_i = Enc(pk_i,m_i)\).</li>
|
||
<li>Alice outputs \(m_b = Dec(sk, e_b)\).</li>
|
||
</ol></li>
|
||
<li>The protocol is proven secure against an actively corrupted Alice by constructing a simulator. Remember that in the hybrid model the simulator simulates all calls to the ZK box. In other words, every time Alice inputs something to the ZK box the simulator learns w. The simulator uses the corrupted A as a subroutine and works as follows:
|
||
<ol class="org-ol">
|
||
<li>S receives \((c,d)\) from A</li>
|
||
<li>S receives \(w = (b,r_A,s,t)\) from A</li>
|
||
<li>S sends random \(r_B\) to A</li>
|
||
<li>S receives \((pk_0, pk_1)\) from A</li>
|
||
<li>S receives \(w' = (b', r'_A, s', t')\) from A</li>
|
||
<li>If \(w' \neq w\) or \(pk_{1-b} \neq OGen(r_A \oplus r_B)\) (which we have access to through the witness), then abort. O.w. sim inputs \(b\) to the ideal func and learns \(m_b\).</li>
|
||
<li>The sim computes \(e_b = Enc(pk_b, m_b)\) and \(e_{1-b} = Enc(pk_{1-b}, 0)\) (we don't know the other message, but since the Enc system is neat, we're guchi) and outputs the view for Alice \((b,t,r,s,r_B,e_0,e_1)\).</li>
|
||
</ol></li>
|
||
<li>Informally, there are only two differences from the view of the simulator and of Alice;
|
||
<ol class="org-ol">
|
||
<li>The simulation aborts if \(w' \neq w\) while real proto continues as long as \(Com(b',t') = Com(b,t)\) and \(Com(r'_A,s') = Com(r_A,s)\). However, if this happens in the protocol, then A can be used to break the binding property of \(Com\), thus reaching a contradiction of \(Com\) being a nice.</li>
|
||
<li>In the sim, \(e_{1-b} = Enc(pk_{1-b},0)\), while in the proto \(e_{1-b} = Enc(pk_{1-b}, m_{1-b})\). If the distinguisher succeeds, then we can break the IND-CPA (chosen plaintext attack) security of the underlying scheme.
|
||
<ol class="org-ol">
|
||
<li>Receive pk from the ind-cpa challenger</li>
|
||
<li>Query the ind-cpa challenger with messages (case 0) \(m_{1-b}\) and (case 1) \(0\) and receive a challenge text \(e^*\)</li>
|
||
<li>Construct a simulated view where \(r_B = r_A \oplus OGen^{-1}(pk)\) and \(e_{1-b} = e^*\) and give these to the distinguisher. If the distinguisher thinks the view is from a real proto, guess case 0, o.w. guess case 1.</li>
|
||
</ol></li>
|
||
</ol></li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<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-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>
|
||
<li><b>Key gen</b>: PKs are for group elements \((g,h,u,v)\) and sk is \(x \in Z_q\) s.t. \(u = g^x\), \(v = h^x\).</li>
|
||
<li><b>Enc</b>: 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)\)</li>
|
||
<li><b>Dec</b>: \(m = d \cdot c^{-x}\), so like El Gamal</li>
|
||
<li>What on the face of earth is this proof? Something with no one knowing if the pk is a DDH tuple</li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
<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>
|
||
<li><b>Setup</b>: 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</li>
|
||
<li><b>Choose</b>: 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.</li>
|
||
<li><b>Transfer</b>: 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</li>
|
||
<li><b>Retrieve</b>: Alice computes \(m_b = Dec(x,e_b)\).</li>
|
||
<li>Neither Alice nor Bob can determine if \((g_0,h_0,g_1,h_1)\) is a DDH tuple or not</li>
|
||
<li>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.</li>
|
||
<li>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)\)</li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
<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:
|
||
<ol class="org-ol">
|
||
<li>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\).</li>
|
||
<li>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\).</li>
|
||
<li>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</li>
|
||
</ol></li>
|
||
<li>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</li>
|
||
<li>When Bob is corrupted:
|
||
<ol class="org-ol">
|
||
<li>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<sub>1</sub> = g^β<sub>0</sub></li>
|
||
<li>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\).</li>
|
||
<li>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.</li>
|
||
</ol></li>
|
||
<li>View of Bob in sim is computationally indistinguishable from proto, only diff is the distribution of the crs.</li>
|
||
<li>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.</li>
|
||
</ul>
|
||
</div>
|
||
</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:47</p>
|
||
<p class="validation"><a href="http://validator.w3.org/check?uri=referer">Validate</a></p>
|
||
</div>
|
||
</body>
|
||
</html>
|