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

add Mpcot #87

Merged
merged 24 commits into from
Feb 8, 2024
Merged

add Mpcot #87

merged 24 commits into from
Feb 8, 2024

Conversation

xiangxiecrypto
Copy link
Collaborator

Add two versions of mpcot protocols, taking spcot as an ideal functionality.

  1. the chosen positions are under arbitrary distribution.
  2. the chosen positions are under regular distribution, i.e., evenly distributed.

@sinui0 sinui0 self-requested a review November 24, 2023 22:49
Copy link
Collaborator

@sinui0 sinui0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, and simpler than I thought. I'll stop this review here with the provided feedback and circle back once we encapsulate CuckooHash and Bucket a bit better. I think that will really help with duplication/readability.

ot/mpz-ot-core/src/ideal/ideal_spcot.rs Outdated Show resolved Hide resolved
ot/mpz-ot-core/src/ideal/ideal_spcot.rs Outdated Show resolved Hide resolved
ot/mpz-ot-core/src/ideal/ideal_spcot.rs Outdated Show resolved Hide resolved
ot/mpz-ot-core/src/ideal/ideal_spcot.rs Outdated Show resolved Hide resolved
ot/mpz-ot-core/src/ferret/utils.rs Outdated Show resolved Hide resolved
ot/mpz-ot-core/src/ferret/utils.rs Outdated Show resolved Hide resolved
ot/mpz-ot-core/src/ferret/utils.rs Outdated Show resolved Hide resolved
ot/mpz-ot-core/src/ferret/utils.rs Outdated Show resolved Hide resolved
ot/mpz-ot-core/src/ferret/utils.rs Outdated Show resolved Hide resolved
ot/mpz-ot-core/src/ferret/utils.rs Outdated Show resolved Hide resolved
@themighty1 themighty1 self-requested a review January 17, 2024 05:49
ot/mpz-ot-core/src/ferret/cuckoo.rs Show resolved Hide resolved
ot/mpz-ot-core/src/ferret/cuckoo.rs Show resolved Hide resolved
ot/mpz-ot-core/src/ferret/mpcot/receiver.rs Outdated Show resolved Hide resolved
ot/mpz-ot-core/src/ferret/mpcot/receiver.rs Outdated Show resolved Hide resolved
ot/mpz-ot-core/src/ferret/mpcot/receiver.rs Outdated Show resolved Hide resolved
ot/mpz-ot-core/src/ferret/mpcot/receiver.rs Outdated Show resolved Hide resolved
ot/mpz-ot-core/src/ferret/mpcot/receiver_regular.rs Outdated Show resolved Hide resolved
@xiangxiecrypto
Copy link
Collaborator Author

We need to determine if we keep cuckoo hash and buckets stuck to MPCOT or make them independent.
if we prefer the first case, then I can encapsulate Vec<Option<Item>> and Vec<Vec<Item>> inside. Otherwise, we need to expose them.

Copy link
Collaborator

@sinui0 sinui0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for adding the additional state. We just need to address the outstanding comments then we can merge 🚀

Regarding the encapsulation, I'm ok with putting that off to another PR so we can get this thing over the finish line

ot/mpz-ot-core/src/ferret/mpcot/receiver.rs Outdated Show resolved Hide resolved
ot/mpz-ot-core/src/ferret/mpcot/sender.rs Outdated Show resolved Hide resolved
ot/mpz-ot-core/src/ferret/mpcot/receiver.rs Outdated Show resolved Hide resolved
ot/mpz-ot-core/src/ferret/mpcot/receiver.rs Outdated Show resolved Hide resolved
Copy link
Collaborator

@sinui0 sinui0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💪

@sinui0 sinui0 merged commit 0f1b4e5 into privacy-scaling-explorations:dev Feb 8, 2024
3 checks passed
@sinui0 sinui0 mentioned this pull request Feb 8, 2024
Copy link
Collaborator

@themighty1 themighty1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the belated review. @xiangxiecrypto , could you pls clarify a few things.

let queries_length = if n % t == 0 {
vec![k as usize; t as usize]
} else {
let mut tmp = vec![k as usize; (t - 1) as usize];
Copy link
Collaborator

@themighty1 themighty1 May 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, @xiangxiecrypto , I only just now got around to reviewing this PR.
Could you please clarify the following:

The paper says all intervals must be of the same size.
What is the justification of having the last interval be of a different size?
What if the last interval happens to be of size 1?
If there is a justification, could you formulate it, so I could add it here as a comment.
Or maybe we can just stick to always requiring that arguments (n,t) are such that n % t == 0?

Copy link
Collaborator

@themighty1 themighty1 May 6, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider if n == 91 and t == 10 then the last interval will be 1, since k == 10.
But if k instead was set to 9, then all intervals (except the last one) would be of length 9 and the last one would be of length 10, which I think is what we want here.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the current choosing parameters, we actually have n % t == 0. But in order to select more other parameters, I make it a little bit more flexible here.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the following implementations, I will add a more general way to estimate different LPN parameters. If all the parameters we choose satisfy n % t == 0, I will remove the other part.

let mut tmp = vec![k as usize; (t - 1) as usize];
tmp.push((n % k) as usize);
if tmp.iter().sum::<usize>() != n as usize {
return Err(ReceiverError::InvalidInput(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, @xiangxiecrypto , I cant think of what values of (n,t) would cause this error to trigger. I think it never will.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, nvm, (101, 10) will trigger this error

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

Successfully merging this pull request may close these issues.

3 participants