Almost done with first topic
This commit is contained in:
=
parent
67580b0de7
commit
f56bbe4e7e
525
notes.html
Normal file
525
notes.html
Normal file
|
|
@ -0,0 +1,525 @@
|
||||||
|
<?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>
|
||||||
|
<title>notes</title>
|
||||||
|
<!-- 2019-12-10 Tue 00:36 -->
|
||||||
|
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
|
||||||
|
<meta name="generator" content="Org-mode" />
|
||||||
|
<meta name="author" content="alex" />
|
||||||
|
<style type="text/css">
|
||||||
|
<!--/*--><![CDATA[/*><!--*/
|
||||||
|
.title { text-align: center; }
|
||||||
|
.todo { font-family: monospace; color: red; }
|
||||||
|
.done { color: green; }
|
||||||
|
.tag { background-color: #eee; font-family: monospace;
|
||||||
|
padding: 2px; font-size: 80%; font-weight: normal; }
|
||||||
|
.timestamp { color: #bebebe; }
|
||||||
|
.timestamp-kwd { color: #5f9ea0; }
|
||||||
|
.right { margin-left: auto; margin-right: 0px; text-align: right; }
|
||||||
|
.left { margin-left: 0px; margin-right: auto; text-align: left; }
|
||||||
|
.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;}
|
||||||
|
pre.src-sh:before { content: 'sh'; }
|
||||||
|
pre.src-bash:before { content: 'sh'; }
|
||||||
|
pre.src-emacs-lisp:before { content: 'Emacs Lisp'; }
|
||||||
|
pre.src-R:before { content: 'R'; }
|
||||||
|
pre.src-perl:before { content: 'Perl'; }
|
||||||
|
pre.src-java:before { content: 'Java'; }
|
||||||
|
pre.src-sql:before { content: 'SQL'; }
|
||||||
|
|
||||||
|
table { border-collapse:collapse; }
|
||||||
|
caption.t-above { caption-side: top; }
|
||||||
|
caption.t-bottom { caption-side: bottom; }
|
||||||
|
td, th { vertical-align:top; }
|
||||||
|
th.right { text-align: center; }
|
||||||
|
th.left { text-align: center; }
|
||||||
|
th.center { text-align: center; }
|
||||||
|
td.right { text-align: right; }
|
||||||
|
td.left { text-align: left; }
|
||||||
|
td.center { text-align: center; }
|
||||||
|
dt { font-weight: bold; }
|
||||||
|
.footpara:nth-child(2) { display: inline; }
|
||||||
|
.footpara { display: block; }
|
||||||
|
.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; }
|
||||||
|
/*]]>*/-->
|
||||||
|
</style>
|
||||||
|
<script type="text/javascript">
|
||||||
|
/*
|
||||||
|
@licstart The following is the entire license notice for the
|
||||||
|
JavaScript code in this tag.
|
||||||
|
|
||||||
|
Copyright (C) 2012-2013 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/javascript" src="http://orgmode.org/mathjax/MathJax.js"></script>
|
||||||
|
<script type="text/javascript">
|
||||||
|
<!--/*--><![CDATA[/*><!--*/
|
||||||
|
MathJax.Hub.Config({
|
||||||
|
// Only one of the two following lines, depending on user settings
|
||||||
|
// First allows browser-native MathML display, second forces HTML/CSS
|
||||||
|
// config: ["MMLorHTML.js"], jax: ["input/TeX"],
|
||||||
|
jax: ["input/TeX", "output/HTML-CSS"],
|
||||||
|
extensions: ["tex2jax.js","TeX/AMSmath.js","TeX/AMSsymbols.js",
|
||||||
|
"TeX/noUndefined.js"],
|
||||||
|
tex2jax: {
|
||||||
|
inlineMath: [ ["\\(","\\)"] ],
|
||||||
|
displayMath: [ ['$$','$$'], ["\\[","\\]"], ["\\begin{displaymath}","\\end{displaymath}"] ],
|
||||||
|
skipTags: ["script","noscript","style","textarea","pre","code"],
|
||||||
|
ignoreClass: "tex2jax_ignore",
|
||||||
|
processEscapes: false,
|
||||||
|
processEnvironments: true,
|
||||||
|
preview: "TeX"
|
||||||
|
},
|
||||||
|
showProcessingMessages: true,
|
||||||
|
displayAlign: "center",
|
||||||
|
displayIndent: "2em",
|
||||||
|
|
||||||
|
"HTML-CSS": {
|
||||||
|
scale: 100,
|
||||||
|
availableFonts: ["STIX","TeX"],
|
||||||
|
preferredFont: "TeX",
|
||||||
|
webFont: "TeX",
|
||||||
|
imageFont: "TeX",
|
||||||
|
showMathMenu: true,
|
||||||
|
},
|
||||||
|
MMLorHTML: {
|
||||||
|
prefer: {
|
||||||
|
MSIE: "MML",
|
||||||
|
Firefox: "MML",
|
||||||
|
Opera: "HTML",
|
||||||
|
other: "HTML"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
});
|
||||||
|
/*]]>*///-->
|
||||||
|
</script>
|
||||||
|
</head>
|
||||||
|
<body>
|
||||||
|
<div id="content">
|
||||||
|
<h1 class="title">notes</h1>
|
||||||
|
<div id="table-of-contents">
|
||||||
|
<h2>Table of Contents</h2>
|
||||||
|
<div id="text-table-of-contents">
|
||||||
|
<ul>
|
||||||
|
<li><a href="#sec-1">1. Protocols with Trusted Dealer (week 2 & 3)</a>
|
||||||
|
<ul>
|
||||||
|
<li><a href="#sec-1-1">1.1. Curriculum</a></li>
|
||||||
|
<li><a href="#sec-1-2">1.2. Prelims</a></li>
|
||||||
|
<li><a href="#sec-1-3">1.3. Passively secure protocols</a>
|
||||||
|
<ul>
|
||||||
|
<li><a href="#sec-1-3-1">1.3.1. OTTT</a></li>
|
||||||
|
<li><a href="#sec-1-3-2">1.3.2. BeDOZa</a></li>
|
||||||
|
</ul>
|
||||||
|
</li>
|
||||||
|
<li><a href="#sec-1-4">1.4. Active Security</a>
|
||||||
|
<ul>
|
||||||
|
<li><a href="#sec-1-4-1">1.4.1. OTTT with MACs</a></li>
|
||||||
|
<li><a href="#sec-1-4-2">1.4.2. BeDOZa</a></li>
|
||||||
|
</ul>
|
||||||
|
</li>
|
||||||
|
</ul>
|
||||||
|
</li>
|
||||||
|
</ul>
|
||||||
|
</div>
|
||||||
|
</div>
|
||||||
|
<div id="outline-container-sec-1" class="outline-2">
|
||||||
|
<h2 id="sec-1"><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-sec-1-1" class="outline-3">
|
||||||
|
<h3 id="sec-1-1"><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-sec-1-2" class="outline-3">
|
||||||
|
<h3 id="sec-1-2"><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-sec-1-3" class="outline-3">
|
||||||
|
<h3 id="sec-1-3"><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-sec-1-3-1" class="outline-4">
|
||||||
|
<h4 id="sec-1-3-1"><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="sec-1-3-1-1" name="sec-1-3-1-1"></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="sec-1-3-1-2" name="sec-1-3-1-2"></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[u</sub>,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-sec-1-3-2" class="outline-4">
|
||||||
|
<h4 id="sec-1-3-2"><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>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 e\)
|
||||||
|
</li>
|
||||||
|
</ol>
|
||||||
|
</li>
|
||||||
|
</ol>
|
||||||
|
</li>
|
||||||
|
</ul>
|
||||||
|
</div>
|
||||||
|
</div>
|
||||||
|
</div>
|
||||||
|
<div id="outline-container-sec-1-4" class="outline-3">
|
||||||
|
<h3 id="sec-1-4"><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-sec-1-4-1" class="outline-4">
|
||||||
|
<h4 id="sec-1-4-1"><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="sec-1-4-1-1" name="sec-1-4-1-1"></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</sub>,…,t<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="sec-1-4-1-2" name="sec-1-4-1-2"></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, \epsilon)\)-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="sec-1-4-1-3" name="sec-1-4-1-3"></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="sec-1-4-1-4" name="sec-1-4-1-4"></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-sec-1-4-2" class="outline-4">
|
||||||
|
<h4 id="sec-1-4-2"><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>
|
||||||
|
<div id="postamble" class="status">
|
||||||
|
<p class="author">Author: alex</p>
|
||||||
|
<p class="date">Created: 2019-12-10 Tue 00:36</p>
|
||||||
|
<p class="creator"><a href="http://www.gnu.org/software/emacs/">Emacs</a> 25.2.2 (<a href="http://orgmode.org">Org</a> mode 8.2.10)</p>
|
||||||
|
<p class="validation"><a href="http://validator.w3.org/check?uri=referer">Validate</a></p>
|
||||||
|
</div>
|
||||||
|
</body>
|
||||||
|
</html>
|
||||||
118
notes.org
Normal file
118
notes.org
Normal file
|
|
@ -0,0 +1,118 @@
|
||||||
|
* Protocols with Trusted Dealer (week 2 & 3)
|
||||||
|
** Curriculum
|
||||||
|
- Model (trusted dealer).
|
||||||
|
- Protocols with passive security (One-time truth-tables, passive BeDOZa) and their security.
|
||||||
|
- Active attacks against OTTT/BeDOZa.
|
||||||
|
- Countermeasures (using information-theoretic MACs) and their security.
|
||||||
|
|
||||||
|
** Prelims
|
||||||
|
- The whole passive security thing where we define views and that a simulator has to be computationally indistingushiable from the views of all parties.
|
||||||
|
- The views contain the party input, internal randomness (if any), and all the messages received during the protocol
|
||||||
|
+ The messages sent do not need to be included, as these are a function of the randomness and the messages received
|
||||||
|
** Passively secure protocols
|
||||||
|
- A trusted dealer is essentially just a third-party who we assume we can trust
|
||||||
|
*** OTTT
|
||||||
|
- This protocols allows two parties to compute any function over their inputs. Thus: $f : \{0,1\}^n \times \{0,1\}^n \rightarrow \{0,1\}$.
|
||||||
|
- Rather than computing the function though, it's represented by a truth table (a matrix) $ T \in \{0,1\}^{2^n \times 2^n} $ where $T[i,j] = f(i,j)$.
|
||||||
|
- 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 /nothing/.
|
||||||
|
**** The protocol
|
||||||
|
- *The trusted dealer* /D/ does the following:
|
||||||
|
1) Choose two shifts $r \in \{0,1\}^n$ and $s \in \{0,1\}^n$ *uniformly at random*
|
||||||
|
2) Choose matrix $M_B \in \{0,1\}^{2^n \times 2^n}$ *uniformly at random*
|
||||||
|
3) 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]$
|
||||||
|
4) Output $(r,M_A)$ to Alice and $(s, M_B)$ to Bob.
|
||||||
|
- *The actual protocol*:
|
||||||
|
1) Alice computes $u = x+r \mod 2^n$ and sends $u$ to Bob
|
||||||
|
2) Bob computes $v = y+s \mod 2^n$ and $z_B = M[u,v]$ and sends $(v,z_B)$ to Alice
|
||||||
|
3) Alice outs $z = M_A[u,v] \oplus z_B$
|
||||||
|
- *Correctness*: $$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)$$
|
||||||
|
**** Security proof TODO: Figure out the simulator for Bob
|
||||||
|
- We need to construct a simulator that, given the input and output, is computationally indistinguishable from the views.
|
||||||
|
- The views for OTTT are defined as: $$ view_A = \{x, (r,M_A), (v, z_B) \} $$ and $$ view_B = \{y, (s, M_B), u \}$$
|
||||||
|
- According to the book, as this is a deterministic function, we can look at the distribution of outputs and the views separately.
|
||||||
|
- *Alice*:
|
||||||
|
1) The simulator gets as input $x \in \{0,1\}^n$ and $z \in \{0,1\}$
|
||||||
|
2) Sample uniformly a random $z_B \in \{0,1\}$, a random $v \in \{0,1\}^n$ and a random $r \in \{0,1\}^n$
|
||||||
|
3) Construct M_A : \forall (i,j) \neq (x+r,v): choose $M_A[i,j] \in \{0,1\}$ uniformly at random. Define $M_A[x+r,v] = z \oplus z_B$.
|
||||||
|
- In both the simulated and real case, the values $r, v$ and $M_A[i,j]$ for all $(i,j) \neq (u,v)$ are chosen uni-randomly.
|
||||||
|
- The pair $(M_A[u,v], z_B) is in both cases a pair of random bits s.t. $z = M_A[u,v] \oplus z_B$
|
||||||
|
+ This is an application of the "principle of deferred decision", i.e. it does not matter which order the random elements are sampled
|
||||||
|
- Has unconditional security, kind of the OTP of MPC
|
||||||
|
- Optimal round complexity, as it's only one message per party
|
||||||
|
- $2n+1$ bits are send, which is $1$ bit off the optimal communication complexity, which is $2n$
|
||||||
|
- Has a bad storage problem, as each party needs to receive an exponential of $n$ bits from the trusted dealer
|
||||||
|
+ 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.
|
||||||
|
*** BeDOZa
|
||||||
|
- Circuit based, still using a trusted dealer
|
||||||
|
- More complicated, as it has to support different operations, XOR and AND.
|
||||||
|
- *Circuit Notation*: 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.
|
||||||
|
- *Invariant*: The protocol works on secret shared bits.
|
||||||
|
- Has $6$ different layers or wires!
|
||||||
|
1) Input Wires: For each of the /n/ 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.
|
||||||
|
2) 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.
|
||||||
|
3) 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$.
|
||||||
|
4) 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$.
|
||||||
|
5) 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$.
|
||||||
|
6) AND of Two Wires: The only part which requires a trusted dealer. $[z] \leftarrow EvalAnd([x], [y])$, computes $z = x \cdot y$.
|
||||||
|
1) Dealer outputs a random triple $[u], [v], [w]$ s.t. $w = u \cdot v$.
|
||||||
|
2) Run subprotocol: $[d] = [x] \oplus [u]$
|
||||||
|
3) Run subproto: $[e] = [y] \oplus [v]$
|
||||||
|
4) Run subproto: $d \leftarrow Open([d])$
|
||||||
|
5) Run subproto: $e \leftarrow Open([e])$
|
||||||
|
6) Run subproto: $[z] = [w] \oplus e \cdot [x] \oplus d \cdot [y] \oplus e \cdot d$
|
||||||
|
- *Putting all of this together*: The circuit has /L/ 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])$.
|
||||||
|
**** Analysis TODO!
|
||||||
|
- 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.
|
||||||
|
- *Correctness*: All gates are trivially correct, apart from AND: $$ w \oplus e \cdot x \oplus d \cdot y \oplus e \cdot d = uv \oplus (xy \oplus vx) \oplus (xy \oplus uy) \oplus (xy \oplus vx \oplus uy \oplus uv) = xy$.
|
||||||
|
- *Simulation of the view of a corrupted Alice, having only access to her input/output*:
|
||||||
|
1) 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$.
|
||||||
|
2) 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\}$.
|
||||||
|
3) 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)
|
||||||
|
4)
|
||||||
|
** Active Security
|
||||||
|
- Message authentication codes!!
|
||||||
|
*** OTTT with MACs
|
||||||
|
- A malicious Bob can deviate from the original OTTT protocol in a few ways:
|
||||||
|
1) 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.
|
||||||
|
+ Since $v' = (y+diff) + s$ s.t. $y+diff = y'$, where $y'$ could might as well have been the original input.
|
||||||
|
2) Bob sends /nothing/ or /an invalid message/. 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\}$.
|
||||||
|
+ 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.
|
||||||
|
+ 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.
|
||||||
|
+ 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.
|
||||||
|
3) Bob /sends a wrong value/ $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.
|
||||||
|
+ Since $z'_B = z_B \oplus 1$ must be true, Alice will output $z' = z \oplus 1 = f(x,y) \oplus 1$.
|
||||||
|
+ This is *NOT* /input substitution/. 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.
|
||||||
|
- Does, we need to defend us against the third case!
|
||||||
|
**** Intro to MACs
|
||||||
|
- Message authenticaion code
|
||||||
|
- 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.
|
||||||
|
+ 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_1,...,t_q on messages x_1, ...., x_q. 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.
|
||||||
|
**** Enhancing OTTT
|
||||||
|
- *The dealer* does the following:
|
||||||
|
1) Choose two shifts $r \in \{0,1\}^n$ and $s \in \{0,1\}^n$ *uniformly at random*
|
||||||
|
2) Choose matrix $M_B \in \{0,1\}^{2^n \times 2^n}$ *uniformly at random*
|
||||||
|
3) 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]$
|
||||||
|
4) Generate $2^{2n}$ keys for a $(1, \epsilon)$-secure MAC i.e. \forall i,j \in {0,1}^n define $K[i,j] \leftarrow Gen()$.
|
||||||
|
5) Generate MACs for values in $M_B$; i.e. \forall i,j \in {0,1}^{n} define $T[i,j] \leftarrow Tag(K[i,j], M_B[i,j])$.
|
||||||
|
6) Output $(r, M_A, K)$ to Alice and $(s, M_B, T)$ to Bob.
|
||||||
|
- *The protocol*:
|
||||||
|
1) Alice computes $u = x+r \mod 2^n$ again and sends this to Bob
|
||||||
|
2) 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
|
||||||
|
3) 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$.
|
||||||
|
**** Proving security
|
||||||
|
- 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.
|
||||||
|
- The proof is a reduction to breaking the underlying MAC scheme, if we can break the OTTT protocol.
|
||||||
|
- *The simulator*:
|
||||||
|
1) 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).
|
||||||
|
2) Sample a random $u$ and send it to Bob (replacing the honest Alice)
|
||||||
|
3) 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.
|
||||||
|
- *Proof*:
|
||||||
|
1) /The view of Bob/ is distributed as the normal scheme, since $M_B, r$ are uni-random in both experiments and $u = x+r$ with random $r$ in the actual protocol, $u$ is also random.
|
||||||
|
2) The output of Alice is distributed identically, except for the case where corrupt Bob sends a triple s.t. $ver(K[u,v], t'_B, z'_B) = accept$ meanwhile $z'_B \neq M_B[u,v]$: in which case the real Alice would output $f(x,y) \oplus 1$ as previously discussed, but the ideal Alice would output $f(x,y_0)$. This Bob can however be turned into an adversary for the underlying MAC scheme, which is assumed to be secure, thus completing the proof.
|
||||||
|
**** Possible MAC scheme
|
||||||
|
- 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:
|
||||||
|
1) $k \leftarrow Gen()$: Sample $k = (\alpha, \beta) \leftarrow Z^2_p$ for a prime $p$
|
||||||
|
2) $t \leftarrow Tag(k, m)$: Compute a tag $t$ on a message $m$ with key $k = (\alpha, \beta)$; $t = \alpha \cdot m + \beta$
|
||||||
|
3) $\{accept, reject\} \leftarrow ver(k,t,m)$: Output accept if $t' = \alpha \cdot m + \beta$, reject ow.
|
||||||
|
*** BeDOZa
|
||||||
|
- Works with an $m$-homomorphic MAC scheme, so likely just bring this up for the last topic, which only has one paper otherwise!
|
||||||
Loading…
Reference in New Issue
Block a user