diff --git a/graph/Fixed_8-bit_block_size.pdf b/graph/Fixed_8-bit_block_size.pdf deleted file mode 100644 index ac9b2a9..0000000 Binary files a/graph/Fixed_8-bit_block_size.pdf and /dev/null differ diff --git a/graph/Fixed_8-bit_block_size_-_simulated_1MiBs_tx,_5MiBs_rx.pdf b/graph/Fixed_8-bit_block_size_-_simulated_1MiBs_tx,_5MiBs_rx.pdf deleted file mode 100644 index 33ec6e9..0000000 Binary files a/graph/Fixed_8-bit_block_size_-_simulated_1MiBs_tx,_5MiBs_rx.pdf and /dev/null differ diff --git a/graph/Fixed_8-bit_block_size_-_simulated_1MiBs_tx,_5MiBs_rx_log.pdf b/graph/Fixed_8-bit_block_size_-_simulated_1MiBs_tx,_5MiBs_rx_log.pdf deleted file mode 100644 index 68dbc31..0000000 Binary files a/graph/Fixed_8-bit_block_size_-_simulated_1MiBs_tx,_5MiBs_rx_log.pdf and /dev/null differ diff --git a/graph/Fixed_8-bit_block_size_log.pdf b/graph/Fixed_8-bit_block_size_log.pdf deleted file mode 100644 index 069fedb..0000000 Binary files a/graph/Fixed_8-bit_block_size_log.pdf and /dev/null differ diff --git a/pir/src/main/java/dk/au/pir/databases/ListDatabase.java b/pir/src/main/java/dk/au/pir/databases/ListDatabase.java new file mode 100644 index 0000000..72c59a4 --- /dev/null +++ b/pir/src/main/java/dk/au/pir/databases/ListDatabase.java @@ -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 iterator() { + return null; + } +} diff --git a/pir/src/main/java/dk/au/pir/profilers/Profiler.java b/pir/src/main/java/dk/au/pir/profilers/Profiler.java index 7314dc6..45491cc 100644 --- a/pir/src/main/java/dk/au/pir/profilers/Profiler.java +++ b/pir/src/main/java/dk/au/pir/profilers/Profiler.java @@ -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; diff --git a/pir/src/main/java/dk/au/pir/protocols/xor/SqrtXORClient.java b/pir/src/main/java/dk/au/pir/protocols/xor/SqrtXORClient.java index 88d28f2..76261c4 100644 --- a/pir/src/main/java/dk/au/pir/protocols/xor/SqrtXORClient.java +++ b/pir/src/main/java/dk/au/pir/protocols/xor/SqrtXORClient.java @@ -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))); + + } } diff --git a/pir/src/main/java/dk/au/pir/protocols/xor/SqrtXORServer.java b/pir/src/main/java/dk/au/pir/protocols/xor/SqrtXORServer.java index cda447c..fb99776 100644 --- a/pir/src/main/java/dk/au/pir/protocols/xor/SqrtXORServer.java +++ b/pir/src/main/java/dk/au/pir/protocols/xor/SqrtXORServer.java @@ -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; + } } diff --git a/pres/pres.tex b/pres/pres.tex index e32d817..9e076ea 100644 --- a/pres/pres.tex +++ b/pres/pres.tex @@ -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}