Recursion returning extra elements

[ewust]

I'm trying to play around with recursion using the simple_pir.cpp example with libPIR. Specifically, I've been modifying Test 3/7. I've changed the database size to be 1<<13, still with 100 files. This means each file is now 82 bytes, which should fit inside the absorption size for LWE. I then set params.d = 2, and set params.n[0] = 10 and params.n[1] = 10.

I expect that the reply generator should return only a single reply of ciphertext size (65536 bytes), but instead, I receive back 6 replies. Why is this? Given that I'm requesting only one file that fits within absorption size, why does using recursion give me these 5 additional blocks?

I verified with the same database size but without recursion (using params.d = 1 and params.n[0] = 100) that this only returns a single reply, but I can't figure out why with recursion it returns multiple blocks.

Am I missing something on how recursion works, or is this a bug?

[carlosaguilarmelchor]

Hi Erik, it is nice to have you among the XPIR users :) ! You have requested the database to be in two dimentsions (params.d=2) which means that the PIR protocol will recurse once:

• first it will represent the db in ten rows and ten columns as you asked
• then it will use a ten ciphertext PIR query to process each column, generating one PIR result (whose size is the one of a ciphertext) per each processed column
• finally it will use another ten ciphertext PIR query to process these ten intermediate results and send back the final result

Roughly the first query lets you choose a line and the second let's you choose an element of that line.

The key point is that the second PIR query uses as DB the intermediate results, whose size is the one of a ciphertext. This is too large to fit in another ciphertext so it is split in 6 smaller chunks and each of them is absorbed into a different ciphertext that is sent back.

I hope my explanation is clear...

In this very specific case my intuition would be to increase alpha to 10 and take d=1 and n[0]=1 by modifying test 2/7.

If you want to know which is the optimal parameters for a setting you can run the optimizer with the client (element size is in bits) :

./pir_client --dry-run -n 100 -l 656 

Note however that this will propose optimal parameters to reduce RTT if you want to minimize communication you can set the upload and download bandwidt to a very low value (e.g. 1bit/s)

./pir_client --dry-run -n 100 -l 656 -u 1 -d

the results for LWE are in this case

LWE:97:1024:60
d=1
alpha=54

for which you will have to send 262kbits and receive 262kbits

Note that alpha=54 has been chosen by a convex optimization algorithm, but it clearly can be changed to alpha=50.

If you cannot use aggregation due to privacy issues you can force the value of alpha

./pir_client --dry-run -n 100 -l 656 -u 1 -d -a 1

and you'll have as optimal parameters

LWE:97:1024:60
d=2
alpha=1

With 2.6Mbits sent and 1Mbit received.

This can be potentially very optimized, specially if you are not trying to get 82 bytes you do not know but to check whether some known 82 bytes are in a database or not.

Best,

Carlos

[carlosaguilarmelchor]

Closing this issue.