mskd12

In many scenarios, I'd think that different user-specific secrets can be derived from the single secret stored, perhaps using a PRF. Why wouldn't this be enough?

Thanks!

The adversary in your statement seems like a static one. Given enough nodes in the committee (100's), it should be possible to make sure the case you specify never happens.

And, I'd think fixing the committee is worse, as it presents a static point of attack from adversarial POV. If you want any amount of decentralization, handling churn seems essential.

No, I was thinking about Devcon, but I don't want to travel half way across the world ;)

So, in vanilla SSS, committee is fixed and the adversary is allowed to corrupt t-out-of-n nodes over the entire lifetime of the secret.

In CHURP, committees are dynamic---changes at every epoch---and the adversary is allowed to corrupt t nodes in each epoch.

Thanks for the comment. We added a disclaimer!

One of the authors of the work here.

1. Thank you for your comments. The project is an early-stage research prototype, and we are soon going to add documentation and tests to the code.

2. In fact, not all functions in the API are fully implemented, the development is under process. At a high level, the functionality provided is to store and retrieve a secret key (SK). The function is denoted optional because in practice, the secret might not be inputted, instead it might be generated randomly.

3, 4. We appreciate the comments. At this point, we’re still adding more features and improving the documentation. We plan to release the code with tests in the future.

PS: Just added a disclaimer stating that the code is under development!

One of the authors of the work here. This work is an early-stage research prototype. The particular encryption module is currently unused, it is actually part of the pessimistic path of the protocol that is not yet implemented. The code corresponds to the optimistic path of the protocol.