changeset 273:cdbabd388ec7

provsec paper, made slight latex modifications
author Sigurd Meldgaard Thu, 11 Mar 2010 11:12:22 +0100 289611112829 3d30f2a64034 provsec/paper.tex 1 files changed, 5 insertions(+), 5 deletions(-) [+]
line wrap: on
line diff
--- a/provsec/paper.tex	Wed Mar 10 15:18:29 2010 +0100
+++ b/provsec/paper.tex	Thu Mar 11 11:12:22 2010 +0100
@@ -53,10 +53,10 @@
See CACE deliverable D4.1 for details on such applications.
If a completely trusted party was available, the problem could easily be solved by sending all
input to this party and let him compute the result. This is, however, usually an unrealistic assumption.
-A secure MPC protocol allows the players to do the computation securely {\em without} the help
+A secure MPC protocol allows the players to do the computation securely {\em without}\/ the help
of trusted parties. In other words, a secure protocol creates a situation that is equivalent to having a trusted party do the computation, without assuming such a party is actually available.

-To understand the analysis we plan to do of PySMCL programs, it is important to realize that the output of the intended computation of course may reveal information on the inputs supplied by the parties. But since this was the purpose of doing the computation in the first place, this is not a security breach. What we are concerned about is whether we reveal {\em more}  information than necessary. As an example, consider two parties $A,B$ who each have a private natural number as input $n_A, n_B$, respectively.
+To understand the analysis we plan to do of PySMCL programs, it is important to realize that the output of the intended computation of course may reveal information on the inputs supplied by the parties. But since this was the purpose of doing the computation in the first place, this is not a security breach. What we are concerned about is whether we reveal {\em more}\/information than necessary. As an example, consider two parties $A,B$ who each have a private natural number as input $n_A, n_B$, respectively.
Suppose they want to compare $n_A$, $n_B$ securely. This means the output is one bit that is 1 if
$n_A\geq n_B$ and 0 otherwise. Now, if the result is 1 and $n_A=1000$, say, then $A$ knows that
$0< n_B\leq 1000$, but $A$ should learn nothing further about $n_B$.
@@ -304,7 +304,7 @@
\verb|max=b + (a - b) * bigger|

This rewrite will mean that any side effect executed in one of the
-branches (by e.g. calling a function) will get executed no matter what
+branches (by e.g.\ calling a function) will get executed no matter what
the condition evaluates to. This is necessary since otherwise partial information
on the secret values could be inferred from the observed flow of the program.

@@ -429,7 +429,7 @@

\section{The preprocessor}
-During translation, the preprocessor transforms the PySCML into plain Python-VIFF.
+During translation, the preprocessor transforms the PySCML into plain Python-VIFF\@.
Apart from straightforward syntactic changes, it will:
\begin{itemize}
\item translate primitive operations into appropriate function calls in the VIFF framework.
@@ -493,7 +493,7 @@
\end{verbatim}

Notice that we need to take special care that the temporary variables
-\verb|a_then0|, \verb|cond0| etc. are not combined in the second step,
+\verb|a_then0|, \verb|cond0| etc.\ are not combined in the second step,
as they will never by used outside the transformed if.
\subsection{Output and Timing of Operations}
We compile PySMCL into VIFF programs. VIFF uses a system of