From d0cd510401b2780ed394ff8a498bf6cae612a51c Mon Sep 17 00:00:00 2001
From: Dmytro Bogatov <dmytro@dbogatov.org>
Date: Fri, 1 Dec 2017 23:45:04 -0500
Subject: [PATCH] Fix Kollios' suggestions except diagram.
---
bibfile.bib | 35 ++++++++++++++++++++++++
sections/applications-and-extensions.tex | 5 +++-
sections/evaluation.tex | 1 +
sections/overview-of-other-orams.tex | 4 +--
sections/problem-definition.tex | 2 +-
5 files changed, 43 insertions(+), 4 deletions(-)
diff --git a/bibfile.bib b/bibfile.bib
index cb15ea2..c716fea 100644
--- a/bibfile.bib
+++ b/bibfile.bib
@@ -201,3 +201,38 @@
biburl = {http://dblp.org/rec/bib/journals/corr/abs-1105-4125},
bibsource = {dblp computer science bibliography, http://dblp.org}
}
+
+@inproceedings{Fletcher:2012:SPA:2382536.2382540,
+ author = {Fletcher, Christopher W. and Dijk, Marten van and Devadas, Srinivas},
+ title = {A Secure Processor Architecture for Encrypted Computation on Untrusted Programs},
+ booktitle = {Proceedings of the Seventh ACM Workshop on Scalable Trusted Computing},
+ series = {STC '12},
+ year = {2012},
+ isbn = {978-1-4503-1662-0},
+ location = {Raleigh, North Carolina, USA},
+ pages = {3--8},
+ numpages = {6},
+ url = {http://doi.acm.org/10.1145/2382536.2382540},
+ doi = {10.1145/2382536.2382540},
+ acmid = {2382540},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+ keywords = {encrypted computation, secure processors},
+}
+
+@phdthesis{fletcher2013ascend,
+ title={Ascend: An architecture for performing secure computation on encrypted data},
+ author={Fletcher, Christopher Wardlaw},
+ year={2013}
+}
+
+@article{ren2013design,
+ title={Design space exploration and optimization of path oblivious ram in secure processors},
+ author={Ren, Ling and Yu, Xiangyao and Fletcher, Christopher W and Van Dijk, Marten and Devadas, Srinivas},
+ journal={ACM SIGARCH Computer Architecture News},
+ volume={41},
+ number={3},
+ pages={571--582},
+ year={2013},
+ publisher={ACM}
+}
diff --git a/sections/applications-and-extensions.tex b/sections/applications-and-extensions.tex
index de16f78..cc37c89 100644
--- a/sections/applications-and-extensions.tex
+++ b/sections/applications-and-extensions.tex
@@ -30,11 +30,14 @@
PathORAM is particularly amenable to hardware design because of its simplicity and low on-chip storage requirements.
- For example,~\textcite{Maas:EECS-2014-89} built a hardware implementation of a Path ORAM based secure processor using FPGAs and the Convey platform. % chktex 8
+ \textcite{Maas:EECS-2014-89} built a hardware implementation of a Path ORAM based secure processor using FPGAs and the Convey platform. % chktex 8
+
+ \textcite{Fletcher:2012:SPA:2382536.2382540, fletcher2013ascend} and \textcite{ren2013design} built a simulator for a secure processor based on PathORAM\@.
\note{
Due to its simplicity, PathORAM is particularly good for silicon implementations.
For example, Martin Mass has build such implementation using FPGAs.
+ Fletcher and Ren built a simulator for a processor based on PathORAM\@.
}
\end{frame}
diff --git a/sections/evaluation.tex b/sections/evaluation.tex
index 383eff8..8def544 100644
--- a/sections/evaluation.tex
+++ b/sections/evaluation.tex
@@ -78,6 +78,7 @@
\item
For $Z \ge 5$, the usage of a subtree is close to the number of buckets in it.
Also holds for $Z = 4$.
+ % TODO
\item
For the levels close to the root, the bucket load is indeed 1 block.
\item
diff --git a/sections/overview-of-other-orams.tex b/sections/overview-of-other-orams.tex
index 45fce60..115b0ea 100644
--- a/sections/overview-of-other-orams.tex
+++ b/sections/overview-of-other-orams.tex
@@ -41,9 +41,9 @@
They analyzed space and time complexity of the systems.
The result is on the table.
- Computational overhead is a composite of communication, encryption/decryption and client running overheads.
- Communication overhead measures how much information is transmitted during a round of read and write.
+ Communication overhead measures the number of rounds of communication for one access.
Server and client respectively show how much space is used by an ORAM on the server and on the client.
+ Computational overhead is a composite of communication, encryption/decryption and client running overheads \emph{per access}.
I am not going to elaborate on all ORAMs, but it is clear that one of them wins in every category.
This is why we have chosen it for our secure cloud.
diff --git a/sections/problem-definition.tex b/sections/problem-definition.tex
index bc50533..f5f1ea5 100644
--- a/sections/problem-definition.tex
+++ b/sections/problem-definition.tex
@@ -6,7 +6,7 @@
\begin{itemize}
\item
- The client fetches/stores data in atomic units --- \emph{blocks} --- of size $B$ each
+ The client fetches/stores data in atomic units --- \emph{blocks} --- of size $B$ bytes each
\item
Let $N$ be the working set --- number of distinct data blocks stored in ORAM
\end{itemize}
--
GitLab