Implemented block-version of the good XOR scheme, properly.

This commit is contained in:
Alexander Munch-Hansen 2019-12-10 18:24:46 +01:00
parent 6e5fcd013b
commit 9c0fdb0cff
9 changed files with 145 additions and 32 deletions

Binary file not shown.

Binary file not shown.

View File

@ -0,0 +1,26 @@
package dk.au.pir.databases;
import dk.au.pir.settings.PIRSettings;
import java.util.Iterator;
public class ListDatabase implements Database {
private final int[] db;
private final PIRSettings settings;
public ListDatabase(PIRSettings settings, int[] db) {
this.db = db;
this.settings = settings;
}
@Override
public int get(long index) {
return db[(int) index];
}
@Override
public Iterator<Byte[]> iterator() {
return null;
}
}

View File

@ -95,6 +95,13 @@ public class Profiler {
return numbers;
}
public int[][] clientReceive(int[][] numbers) {
for (int[] n: numbers) {
this.clientReceive(n);
}
return numbers;
}
public FieldElement clientReceive(FieldElement element) {
this.received += element.getValue().bitLength();
return element;

View File

@ -1,8 +1,11 @@
package dk.au.pir.protocols.xor;
import dk.au.pir.databases.Database;
import dk.au.pir.databases.ListDatabase;
import dk.au.pir.profilers.Profiler;
import dk.au.pir.settings.PIRSettings;
import java.util.Arrays;
import java.util.Random;
public class SqrtXORClient {
@ -54,5 +57,44 @@ public class SqrtXORClient {
}
return result;
}
public int[] receiveBlock(int index) {
/**
* PLAN:
* Divide n into sqrt(n)
* Compute which index we want find this within a block
* Send block
*/
boolean[] S1 = selectIndexes(this.sqrtSize);
boolean[] S2 = S1.clone();
int impBlock = (int) Math.floor(index/this.sqrtSize);
S2[index % this.sqrtSize] = !S1[index % this.sqrtSize]; // Remove the index, if it's contained in S.
int[][] resBit1 = this.profiler.clientReceive(this.servers[0].computeBlock(this.profiler.clientSend(S1)));
int[][] resBit2 = this.profiler.clientReceive(this.servers[1].computeBlock(this.profiler.clientSend(S2)));
int[] res = new int[this.settings.getBlocksize()];
for (int i = 0; i < this.settings.getBlocksize(); i++) {
res[i] = ((resBit1[impBlock][i] + resBit2[impBlock][i]) % 2);
}
return res;
}
public static void main(String[] args) {
PIRSettings settings = new PIRSettings(9, 2, 3);
SqrtXORServer[] servers = new SqrtXORServer[settings.getNumServers()];
Database database = new ListDatabase(settings, new int[] {1,0,1,0,1,0,0,0,1,1,0,1,0,1,0,0,0,1,1,0,1,0,1,0,0,0,1});
for (int i = 0; i < settings.getNumServers(); i++) {
servers[i] = new SqrtXORServer(database, settings);
}
SqrtXORClient client = new SqrtXORClient(settings, servers, null);
System.out.println(Arrays.toString(client.receiveBlock(1)));
}
}

View File

@ -31,4 +31,28 @@ public class SqrtXORServer {
}
return resList;
}
public int[][] computeBlock(boolean[] indexes) {
int[][] resList = new int[this.sqrtSize][this.settings.getBlocksize()];
for (int i = 0; i < this.sqrtSize; i++) {
int[] tmpRes = new int[this.settings.getBlocksize()];
for (int j = 0; j < this.sqrtSize; j++) {
try {
if (indexes[j]) {
for (int indi=0; indi < this.settings.getBlocksize(); indi++)
// We then wish to loop over j*blockSize + indi
// for j = 0; we want 0,1,2
// for j = 1; we want 3,4,5 and so on..
tmpRes[indi] = (tmpRes[indi] + this.database.get(((j*this.settings.getBlocksize()) + indi)
+ (this.sqrtSize * i))) % 2;
}
} catch (ArrayIndexOutOfBoundsException ignored) {
}
}
resList[i] = tmpRes;
}
return resList;
}
}

View File

@ -45,11 +45,21 @@
\item The block size
\end{itemize}
\item We have benchmarked on the same parameters
\item Reached the conclusion again, that oftentimes big-O notation seldomly gives the correct, most practical, result.
\item Reached the conclusion again, that oftentimes big-O notation won't give the most practical solution.
\end{itemize}
\end{frame}
\subsection{Protocols}
\subsection{Blockification}
\begin{frame}
\frametitle{Turning single-bit PIR into block schemes}
\includegraphics[width=\textwidth]{graphics/blockProp.png}
\begin{itemize}
\item TLDR; Run the scheme blocksize amount of times, asking for consecutive bits is not ideal
\end{itemize}
\end{frame}
\subsubsection{Simple}
\begin{frame}
\frametitle{The most simple protocol}
@ -118,35 +128,11 @@
\includegraphics[width=\textwidth]{graphics/MathStuff.png}
\end{frame}
\subsubsection{Interpolation based}
\begin{frame}
\frametitle{Interpoly scheme}
Won't introduce again, however, we expect it to be worse in almost all metrics:
\begin{itemize}
\item We have to send BigIntegers from client to server, as the scheme relies on large polynomials
\item We have to send either all of the random sequences or the seed from which they originate
\begin{itemize}
\item This can be seen as a balancing act. If sequences are sent, server does not have to compute, but heavy on bandwidth
\item If seed is sent, low on bandwidth but the server also has to compute the sequences
\end{itemize}
\item In general, all of the computations regarding the polynomials, are likely to slow down the response time of the servers
\end{itemize}
\end{frame}
\subsection{Blockification}
\begin{frame}
\frametitle{Turning single-bit PIR into block schemes}
\includegraphics[width=\textwidth]{graphics/blockProp.png}
\begin{itemize}
\item TLDR; Run the scheme blocksize amount of times, asking for consecutive bits
\end{itemize}
\end{frame}
\section{Expected Results}
\begin{frame}
\frametitle{Overall expected results}
\begin{itemize}
\item We expect the scheme which we have yet to implement, to perform the best
\item We expect the scheme before to perform the best
\begin{itemize}
\item The client has to sent less, so less bandwidth
\item The client has to compute less
@ -154,24 +140,52 @@
\end{itemize}
\item We expect the simple scheme of $2$ databases to be outperformed by the scheme where the server simply sends the entire database
\begin{itemize}
\item This is due to the client still sending expected $n$ bits, but both server and client has to perform a computation
\item Client has to compute randomness
\item Server has to XOR
\item User sending data of expected size n
\item Both server and user has to do XOR computations
\end{itemize}
\item We expect the Interpoly scheme to be the worst in all regards, as mentioned in previous slide
\item We expect the Interpoly scheme to be the worst in all regards
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Interpoly scheme}
Won't cover again, but expected to be worse:
\begin{itemize}
\item We have to send BigIntegers from client to server
\item We have to send either all of the random sequences or the seed
\begin{itemize}
\item If sequences are sent, server does not have to compute, but heavy on bandwidth
\item If seed is sent, low on bandwidth but the server also to compute the sequences
\end{itemize}
\item In general, all of the computations regarding the polynomials, are likely to slow down the response time of the servers
\end{itemize}
\end{frame}
\section{Results}
\begin{frame}
\frametitle{Initial Results}
\begin{itemize}
\item Booleans we like - much faster
\item Block indices are found by division - not modulus - correct code is good code
\item Storage issues
\item Bit-vectors of length database are nice in theory
\end{itemize}
\end{frame}
\begin{frame}
\includegraphics[width=0.5\textwidth]{graphics/Fixed_8-bit_block_size.pdf}
\includegraphics[width=0.5\textwidth]{graphics/Fixed_8-bit_block_size_log.pdf}
\end{frame}
\begin{frame}
\includegraphics[width=0.5\textwidth]{graphics/Fixed_8-bit_block_size_-_simulated_1MiBs_tx,_5MiBs_rx.pdf}
\includegraphics[width=0.5\textwidth]{graphics/Fixed_8-bit_block_size_-_simulated_1MiBs_tx,_5MiBs_rx_log.pdf}
\end{frame}
\section{Future Work}
\begin{frame}
\frametitle{Future Work}