diff --git a/.vscode/settings.json b/.vscode/settings.json
index a8a25c45cc1a978ea49486827f6aa73a548ef551..a55948fb650e7c299790a41af7599a6499f116c3 100644
--- a/.vscode/settings.json
+++ b/.vscode/settings.json
@@ -25,6 +25,7 @@
"indistinguishability",
"keepaspectratio",
"midrule",
+ "negl",
"orams",
"parametrization",
"progressbar",
diff --git a/bibfile.bib b/bibfile.bib
index 6c62736187663e3e9ccfc32741b1d913986de2a2..3f36f0d97384fb5e8c0ecc6042d5a7858aa05276 100644
--- a/bibfile.bib
+++ b/bibfile.bib
@@ -36,3 +36,38 @@
acmid = {2994528},
publisher = {VLDB Endowment},
}
+
+@article{DBLP:journals/corr/abs-1202-5150,
+ author = {Emil Stefanov and Elaine Shi},
+ title = {Path {O-RAM:} An Extremely Simple Oblivious {RAM} Protocol},
+ journal = {CoRR},
+ volume = {abs/1202.5150},
+ year = {2012},
+ url = {http://arxiv.org/abs/1202.5150},
+ archivePrefix = {arXiv},
+ eprint = {1202.5150},
+ timestamp = {Wed, 07 Jun 2017 14:40:19 +0200},
+ biburl = {http://dblp.org/rec/bib/journals/corr/abs-1202-5150},
+ bibsource = {dblp computer science bibliography, http://dblp.org}
+}
+
+@mastersthesis{Maas:EECS-2014-89,
+ Author = {Maas, Martin},
+ Title = {PHANTOM: Practical Oblivious Computation in a Secure Processor},
+ School = {EECS Department, University of California, Berkeley},
+ Year = {2014},
+ Month = {May},
+ URL = {http://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-89.html},
+ Number = {UCB/EECS-2014-89},
+ Abstract = {
+ Confidentiality of data is a major problem as sensitive computations migrate to the cloud. Employees in a data center have physical access to machines and can carry out attacks that have traditionally only affected client-side crypto-devices such as smartcards. For example, an employee can snoop confidential data as it moves in and out of the processor to learn secret keys or other program information that can be used for targeted attacks.
+
+ Secure processors have been proposed as a counter-measure to these attacks -- such processors are physically shielded and enforce confidentiality by encrypting all data outside the chip, e.g. in DRAM or non-volatile storage. While first proposals were academic in nature, this model is now starting to appear commercially, such as in the Intel SGX extensions.
+
+ Although secure processors encrypt all data as it leaves the CPU, the memory addresses that are being accessed in DRAM are still transmitted in plaintext on the address bus. This represents an important source of information leakage that enables serious attacks that can, in the worst case, leak bits of cryptographic keys. To counter such attacks, we introduce PHANTOM, a new secure processor that obfuscates its memory access trace. To an adversary who can observe the processor's output pins, all memory access traces are computationally indistinguishable (a property known as obliviousness). We achieve obliviousness through a cryptographic construct known as Oblivious RAM (ORAM).
+
+ Existing ORAM algorithms introduce a large (100-200x) overhead in the amount of data moved from memory, which makes ORAM inefficient on real-world workloads. To tackle this problem, we develop a highly parallel ORAM memory controller to reduce ORAM memory access latency and demonstrate the design as part of the PHANTOM secure processor, implemented on a Convey HC-2ex. The HC-2ex is a system that comprises an off-the-shelf x86 CPU paired with 4 high-end FPGAs with a highly parallel memory system.
+
+ Our novel ORAM controller aggressively exploits the HC-2ex's high DRAM bank parallelism to reduce ORAM access latency and scales well to a large number of memory channels. PHANTOM is efficient in both area and performance: accessing 4KB of data from a 1GB ORAM takes 26.2us (13.5us until the data is available), a 32x slowdown over accessing 4KB from regular memory, while SQLite queries on a population database see 1.2-6x slowdown.
+ }
+}
\ No newline at end of file
diff --git a/preamble.tex b/preamble.tex
index 3df6bd40190251532c14c684bf55c15615800833..5cdc4f23ffc3b5bd431eac5512425ae3d6c43a6b 100644
--- a/preamble.tex
+++ b/preamble.tex
@@ -11,7 +11,7 @@
\title{Data-X Talk} % chktex 13
-\subtitle{Path ORAM:\@An Extremely Simple Oblivious RAM Protocol}
+\subtitle{Path ORAM:\@An Extremely Simple Oblivious RAM Protocol~\cite{DBLP:journals/corr/abs-1202-5150}}
\date{Built from \href{https://git.dbogatov.org/bu/PathORAM-Talk/commit/\version}{\emph{\version}} on \today}
diff --git a/sections/problem-definition.tex b/sections/problem-definition.tex
index 83b6f4cf910e47eca67d3f97aa42cf9df50efff8..94c6e2b9fc0dce42dc543ffa84269e9a250f4743 100644
--- a/sections/problem-definition.tex
+++ b/sections/problem-definition.tex
@@ -1 +1,79 @@
+% cSpell:ignore Maas EECS
+
\section{Problem definition}
+
+ \begin{frame}{Notations}
+
+ \begin{itemize}
+ \item
+ The client fetches/stores data in atomic units --- \emph{blocks} --- of size $B$ each
+ \item
+ Let $N$ be the working set --- number of distinct data blocks stored in ORAM
+ \end{itemize}
+
+ \note{
+ Let us start with some notation.
+ Assume that all data comes in atomic units called blocks and assume that we have $N$ distinct blocks in ORAM.
+ }
+ \end{frame}
+
+ \begin{frame}{Simplicity}
+
+ \begin{quote}
+ We aim to provide an extremely simple ORAM construction in contrast with previous work
+ \end{quote}
+
+ Can then be implemented in hardware~\cite{Maas:EECS-2014-89}.
+
+ \note{
+ Another goal is simplicity.
+ It not only allows us to analyze system easily.
+ In case of Path ORAM, it is so simple that it has been implemented in pure hardware.
+ }
+ \end{frame}
+
+ \begin{frame}{Security definitions}
+
+ \begin{block}{Formal security definition}
+
+ Data request sequence of length $M$, where each $\text{op}_i$ denotes a $\text{read}(\text{a}_i)$ or a $\text{write}(\text{a}_i, \text{data}_I)$ operation
+
+ \[
+ \vec{y} := ( (\text{op}_M, \text{a}_M, \text{data}_M), \ldots , (\text{op}_1, \text{a}_1, \text{data}_1) )
+ \]
+
+ Let $A(\vec{y})$ denote the (possibly randomized) sequence of accesses to the remote storage given the sequence of data requests $\vec{y}$.
+
+ \end{block}
+
+ \note{
+ Let us define what we mean by access pattern.
+ We mean a sequence of operation --- writes and reads --- one some blocks with identifiers $\text{a}_i$ reading or writing some $\text{data}_i$.
+ Say we have $M$ operation in sequence.
+ }
+ \end{frame}
+
+ \begin{frame}{Security definitions}
+
+ \begin{block}{Formal security definition}
+
+ An ORAM construction is said to be secure if
+
+ \begin{itemize}
+ \item
+ for any two data request sequences $\vec{y}$ and $\vec{z}$ of the same length, their access patterns $A(\vec{y})$ and $A(\vec{z})$ are computationally indistinguishable by anyone but the client
+ \item
+ the ORAM construction is correct with probability $p \ge 1 - negl(|\vec{y}|)$.
+ \end{itemize}
+
+ \end{block}
+
+ \note{
+ The most important one.
+ We call a construction secure if an adversary cannot tell, which sequence of operations really went through the construction.
+ Indistinguishability is a strong requirement --- it says that we leak absolutely no information about our patterns.
+ And indeed, we need to correctly respond to client requests.
+ Since we allow randomized algorithms, we set another requirement on error probability.
+ It has to be negligibly small.
+ }
+ \end{frame}