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

Problems in common.h #231

Closed
maths644311798 opened this issue Jan 22, 2024 · 2 comments
Closed

Problems in common.h #231

maths644311798 opened this issue Jan 22, 2024 · 2 comments
Assignees

Comments

@maths644311798
Copy link
Contributor

maths644311798 commented Jan 22, 2024

In yacl/crypto/tools/common.h,

uint128_t inline SyncSeedSend(const std::shared_ptr<link::Context>& ctx) {
  uint128_t seed = SecureRandSeed();
  ctx->SendAsync(ctx->NextRank(), SerializeUint128(seed), "SyncSeed");
  return seed;
}

uint128_t inline SyncSeedRecv(const std::shared_ptr<link::Context>& ctx) {
  auto buf = ctx->Recv(ctx->NextRank(), "SyncSeed");
  return DeserializeUint128(buf);
}

In which scenario do these two function work? One party or every party generates a seed?
The parameters used in SendAsync and Recv are both NextRank(). Why? I doubt if Recv should use PrevRank.

@Jamie-Cui
Copy link
Collaborator

Hi, those two functions are used to generated a synchronized, and public random seed, which is used in our two-party protocols. Since most of the protocol implementations in yacl focuses on the two-party scenario, so there is not much difference between NextRank() and PrevRank().

And if you are planing to synchronize a seed over multiple parties, the sender should broadcast the seed, and the API should be designed different as it is now.

Anyway, you're right that our implementation only works in two-party scenarios, and there's still some work to be done to make it a proper seed-sync function. Feel free to open a PR for this. :)

@Jamie-Cui Jamie-Cui self-assigned this Jan 22, 2024
@maths644311798
Copy link
Contributor Author

Thanks. These functions are far away from multi-party scenario. Since I do not have a good idea about a multi-party version, I will not open a PR.

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