CHURP: Dynamic-Committee Proactive Secret Sharing
eprint.iacr.org
eprint.iacr.org
Virtually all applications people argue for the direct use of secret sharing make limited sense under plausible threat models. The implementations are usually flawed, almost universally containing at least certificational issues like timing/emi channels (which are likely worse threats than the things they protect against in most cases) and it's not that uncommon to find implementations which are broken in ways that completely undermine their security.
An intuitive way to understand why this is so is that secret sharing can be fairly seen as a generalization of one-time-pad encryption to support thesholds, and so the same (and worse) fragility that is widely understood to exist for OTP encryption exists for SSS.
To be useful secret sharing needs to take place as part of a greater protocol-- and it does, but then it doesn't get called secret sharing-- it gets called whatever the greater thing is like "multiparty threshold signatures".
Academic work on building blocks is useful, but its another thing to promote something as directly useful industrially.
For the authors, here are a couple of items that made it hard for me to evaluate the project:
1. This project doesn't build for me and some of the dependencies don't exist or are private repos which prevent me from building the project (https://github.com/CHURPTeam/CHURP/blob/master/src/cmd/bb.go...)
2. It's lacking godoc documentation which means it's hard for me to quickly see how the API works. As such, some of the API methods seem less than useful.
For example, `(Optional) storeSecret(SK)`. What does "optional" mean? What's the return value? What's SK?
(Optional) retrieveSecret() -> SK: What? I can only store a single secret? Without passing params to this, it seems so.
3. Project structure is not conventional (cmd/ inside src/)
This may not seem like a big deal but am I really going to trust my secrets without someone who didn't learn enough about go to use godoc and use a conventional project structure?
4. No tests
Again, doubtful I'm going to trust my secrets to a distributed network that's not tested.
yikes, that's hard to justify.
Anyway, I have experience in the former field (and adjacent fields) but not the latter, so that's where my cynicism is coming from, if you are wondering.
You are probably right that there are higher standards for papers dealing with cryptographic primitives. That would be nice!
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 challenges you are facing is that people consume software illogically based on marketing and popularity rather than code review and fit.
Making sure to market and disclaim that this is a research implementation and should not be used in production is important, especially in cryptography where most people are novices and wouldn’t be qualified to review the code either way.
I’m not sure if the codebase is more just to prove the concept from the paper or to potentially get adoption. If you are looking for people to adopt the project, I’d suggest a way to store and retrieve multiple secrets.
Best of luck with the research and project!
Thanks!
For example: if your user base is cryptocurrency wallet holders who have multiple secrets for each wallet, will they construct a secondary library on top of yours to manage those additional secrets? Why wouldn’t they choose to derive each secret independently? If millions of dollars are at stake, would you risk any shared state from your secret derivation function?
It would be unnecessary to derive additional secrets with this library to prove the concept in the paper so I don’t think it’s necessary if that’s the goal of the code. However, if mass adoption of the techniques you’ve created is your goal, a more user friendly API which doesn’t require each end user to “roll their own code” to manage multiple secrets should be a goal.
One of the first major projects I worked on was essentially a wrapper around open source software that provided “ease of use APIs and UIs”. Because the average user was not technical, the convenience wrapper became highly valuable and is used by hundreds of millions of sites today (cPanel).
One of the biggest challenges as a technologist is to understand to what degree most people are not technologists, even fellow programmers. For example, I’ve worked with skilled programmers with impressive resumes who had issues troubleshooting CORS because they never learned how headers are defined and where to look up the RFCs.
As mentioned above, providing an API for multiple secrets could be out of scope for a bunch of reasons. If you’re looking for mass adoption by developers, I’ll wager an Omakase at the sushi place of your choosing that it’ll be required.
* SSS: (threshold) Shamir Secret Sharing scheme. split a key into m-of-n keys.
* PSS: Proactive Secret Sharing. You can rotate the partial keys with new independent ones, and participants can delete their previous partial keys. This is good in case you someone gets their share compromised at some point.
* DCPSS: Dynamic-Committee Proactive Secret Sharing. This is CHURN. You can update the partial keys with a different m-of-n.
* VSS: Verifiable Secret Sharing. SSS doesn't seem to hold when participants are not all honest. This one fixes that.
* PVSS: Publicly Verifiable Secret Sharing. ?
* APSS: Asynchronous Proactive Secret Sharing. ?
* SVSS: Strong Verifiable Secret Sharing. ?
* SVPSS: Strong Verifiable Proactive Secret Sharing. ?
There is also another branch of secret sharing called DKG for Distributed Key Generation . Participants collaborate to generate a key, and to asymmetrically decrypt a ciphertext or sign a message. At no point in time does the full private key exist.
Now, I am thinking whether there exists quantum analogs of these generalized classical secret sharing tasks you have listed.
Specifically: is there any difference in the collusion profile with CHURP vs. vanilla SSS? If this is not an area of dramatic distinction, then it's a little hard to understand how this might end up underwriting key management technology.
Disclaimer: I work at NuCypher; our Ursula Character is probably reasonably regarded as occupying a similar space to this.
In CHURP, committees are dynamic---changes at every epoch---and the adversary is allowed to corrupt t nodes in each epoch.
But doesn't it also mean that, as the committee cycles, the likelihood of compromised nodes eventually being part of the cohort increases?
If you have a minute, maybe evaluate this statement to see if I've got it right: The attack surface presented by CHURP, in contrast to vanilla SSS, is more robust against an attacker who, throughout the lifecycle of the secret, begins with few compromised nodes and increases her circle of influence throughout? It is, at least in some cases, weaker against an established attacker who begins the lifecycle already having compromised several nodes and who can afford to wait until the right combination of nodes is selected for committee participation.
Do I have that right?
Interesting stuff, either way.
Have we ever met? Were you at EthBerlin last week?
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 ;)
> 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.
Interesting; I have often had the opposite sense: that involving a larger cohort of nodes generally increases the risk of collusion.
Of course, the consequences of collusion with Ursula are quite a lot less (she can refuse to revoke, but cannot recover the secret). This comes at a cost of needing to know Bob's public key prior to access being granted. It's really a very different formula.
We have often pondered (sometimes out loud) about adding some variety of Shamir's Character after Ursula hits mainnet.
The code is just a kind of sanity check for the ideas in the paper.
This is how academia works.
Please comment on the ideas embodied in the paper, not the quality of the code, which is almost entirely irrelevant at this point.
(No affiliation with the authors, here.)
This has not been my experience.
Solid reference implementations for papers typically highlight the novel or outstanding logic amidst a backdrop of established best-practices. That doesn't look like the case here.
Very few people are qualified to review and critique this type of codebase so it’s dangerous to market a repository backed by multiples professors and PhDs as “it does X, Y, and Z”
It would be great to live in a world where people did a serious review of projects before downloading them but that’s not the reality we live in.
OP didn’t provide any context either that this was focused on reviewing the paper and concepts in it so I think what you mean is that “you think people should focus on the paper” but “we focused on the code”, that’s not a misconception, it’s a lack of clarity by both OP and the project website about what’s important.
If the code was irrelevant, it should be removed from the website so that the audience could focus solely on the paper.
As a former academic, I can immediately spot this website as an academic paper with a bit of code on the side. Academics do this kind of thing constantly because they get kudos for it in academic circles. Yes, there is a lack of clarity (if you are not an academic). That's why I pointed this out for what it is.
> If the code was irrelevant, it should be removed from the website so that the audience could focus solely on the paper.
I mean, you're not wrong. But then they wouldn't get as many kudos from their academic buddies.
I was glad to see them add the disclaimer as hopefully it’ll turn away people who see “hey, here’s this secret management project made by a bunch of professors and PhDs, I should use it because they are super qualified”.
My goal was to provide feedback to the students about how people evaluate code “in the real world”. It’s not helpful for them to be applauded for “sub par” code but you raise a good point that it can seem harsh to not provide feedback on the “meat of the project” which is their paper and research.
The encryption uses math/rand. This alone clearly shows the authors have absolutely no clue what they are doing. The encryption itself is also very unsafe - loads of obvious side channel attacks and really far too many flaws to cover here. This isn't just a few mistakes, this is a group of people who don't know enough to do this safely. Sorry, this stuff is hard and this project doesn't come close to meeting even the lowest bar.
1: https://github.com/CHURPTeam/CHURP/blob/master/src/utils/enc...
If you're going to criticize it, maybe do it more respectfully, and also focus on the paper, ideas, and motivation, not the particular proof-of-concept code.
I'm decently familiar with this space and haven't read the paper yet, but the problem it's addressing is important.
One of the authors helpfully clarified below, but at least to me it was extremely unclear that this was the case - had it been more obvious I'd have phrased my original comment very differently. On second inspection one of the blue links does point to "full paper" but there's still lots of words that imply that it's a viable working product, which it really isn't.
It even invites developers to “give it a try”.
Not even research code should use rand and if you are, you have just lost half of your credibility.
Whether their students use rand in their demo code has zero impact on their credibility.
There are no lessons to be learned here.
There is plenty of of lessons to be learned here
- Code involving cryptography should be written with some level of basic rigor, even at that prototype phase, otherwise you lose credibility (evidence above)
- Code involving cryptography that's in a prototype phase should not be marketed in a bubbly 'use this now' fashion
- Academics should be aware that their code is likely to be taken and used as is
I could go on all day.
EDIT: I left this out initially, then edited it in, then edited it out, but to claim that "they know what they are doing" so whatever their students do doesn't impact their credibility is so bizarre.
Surely these students are supposed to be being taught to go and become implementators or advise implementators. So maybe they should be taught to not use rand(), to have a clear and reproducible project build, to not provide prototype work marketed as usable, etc, etc. Cryptography is usually broken (bypassed) by implementation flaws, afaik, and I'm not even an expert.
I'm not taking a position on this code base or paper because I haven't looked much, just on the argument that "they know what they are doing so its fine" and "it's fine that academics can't implement, they are only working on cryptography"