Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

An illegal memory access bug that leads to Wrong PSI Results or Segmentation fault #6

Open
Ni-kaFruit opened this issue Aug 5, 2022 · 2 comments

Comments

@Ni-kaFruit
Copy link

Hi, I am trying to run your code with different parameters presented in Table 1 of your paper.
However, there is an illegal memory access bug that leads to Wrong PSI Results or Segmentation fault.

The parameters I used are as follows:
senderSize = 1 << 16; receiverSize = 1 << 10; width = 632; logHeight = 11; height = 1.2 * receiverSize; hashLengthInBytes = 9;
The results are as follows:
1
2

I have fixed this bug and opened a pull request.

Thx :)

Ni-kaFruit added a commit to Ni-kaFruit/OPRF-PSI that referenced this issue Aug 5, 2022
@peihanmiao
Copy link
Owner

Hello,

Thank you for pointing this out.

Our code doesn't support the scenario of "height = 1.2 * receiverSize" (height is always set as 1 << logHeight and we always set logHeight = rs). This is because in all the experiments in our paper, we set m = n (where m is the height and n is the receiverSize) as it achieves nearly optimal communication among all choices of m and allows for optimal computation. The code is also designed and optimized for the setting where the height is a power of 2 (1 << logHeight).

I you would like to try other parameters, I just wanted to mention that other changes may need to be made (e.g. /PSI_test/main.cpp) and you may need to be careful.

Thanks,
Peihan

@Ni-kaFruit
Copy link
Author

Hi

Indeed, I'm now trying to run your code with arbitrary parameters that it wasn't originally designed to support (senderSize, height, and receiverSize are not always set as a power of 2 and the code for kkrt16 supports this scenario). Our tests show that your code is able to handle this situation with the revision of #7. I believe that supporting this arbitrary parameter scenario can bolster the impact of your open-source code.

I am grateful for your advice. I have implemented the calculation mentioned in "Section 3.3 Parameter Analysis" for a suitable width. If you wish, I could submit another pull request to add support for this part.

thx, :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants