mhmughees / onion-pir Goto Github PK

In the paper of OnionPIR, the database is represented as a higher-dimensional cube, this will reduce noise in query compression procedure. If we put the noise aside, just focus on computational overhead, it seems that higher-dimensional database brings higher computation cost than lower-dimensional database such as two dimensions.
Is that right？

In this implementation, it seems that the computation between the query vector of first dimension and the database is done by the function "poc_nfllib_external_product()". However, in the paper, this procedure is done by BFV ciphertext-plaintext multiplication.

I wonder if there is any differences between these two implementations.

Hi, just wondering if there are any updates wrt to "--over the course of next few weeks this library will be updated to become more stable" (given last commit was 4 months ago)? I am working on adding basic serialization of the query and keys (I can create a PR once I finish) and just want to make sure I'm working with the latest/stable version of the library to avoid wasting work.

Also, I noticed that running the example with small item sizes causes the client to crash when generating a query.
Any ideas on what could be causing this?

With

uint64_t number_of_items = 1<<10;
uint64_t size_per_item = 30000; // in bytes

everything works fine.

With

uint64_t number_of_items = 1<<10;
uint64_t size_per_item = 256; // in bytes

Main: element index = 1010 from [0, 1023]
Main: FV index = 8, FV offset = 74
Client: index 1/ 1 = 8
terminate called after throwing an instance of 'std::runtime_error'
  what():  I/O error: input stream ended unexpectedly
Aborted

i found this is only for the know the element‘ index after i read the paper “OnionPIR: Response Efficient Single-Server PIR”. Can the OnionPIR use to keyword retrieval ?