8 ms·
CHURP: Dynamic-Committee Proactive Secret Sharing
- dkoston 7y agoNot sure if OP is the author but thanks for sharing. Secret management is a challenge for a lot of folks. 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#L5 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.
- brachi 7y ago> No tests yikes, that's hard to justify.
- javert 7y agoNo, no it's not. The product here is an academic paper. The code is just kind of a sanity check for the concepts in the paper. That's how academia works.
- jMyles 7y agoI don't really agree that "that's how academia works". What other recent reference papers for cryptographic primitives are you thinking about when you say that?
- javert 7y agoI don't have any in mind, but this paper struck me as being in "distributed systems" more than in "cryptographic primitives." That is totally debatable, though. 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!
- sverhagen 7y agoIf you're positioning it as a product, which is how many here perceived it, that reasoning doesn't hold. Not that every product has good testing, but they should...
- javert 7y agoIt's not a "product." It's an academic research paper.
- mskd12 7y agoOne 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!
- sverhagen 7y agoI know that this isn't universally accepted, but in significant parts of the industry, we consider it vaporware if there's no tests... FWIW.
- dkoston 7y agoAppreciate the disclaimer. 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.
- dkoston 7y agoFor #2, it seems unlikely that people would have a single secret. 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!
- mskd12 7y agoIn 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!
- cjslep 7y agoThis plus ActivityPub and data that's content addressed would be neat.
- jfindley 7y agoEven a very very cursory review of the code turns up giant red flags. As another comment noted it lacks tests, uses poor project structure and has private deps. Much more seriously, though, the encryption looks very very unsafe. 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/encryption/encryption.go https://github.com/CHURPTeam/CHURP/blob/master/src/utils/enc...
- jrpt 7y agoIt's clearly research code meant as a proof-of-concept of their paper, not something to take and use in production. 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.
- jfindley 7y agoThe link was to www.churp.io which looks to me much more like a product than a research paper. 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.
- leetrout 7y agoWe posted at the same time. This is exactly right. It looks like it’s trying to be a marketed, accepted solution.
- leetrout 7y ago
- faeyanpiraat 7y agodeleted (salty comment not adding anything to the discussion)
- DoctorOetker 7y agoTheres a big difference between a brilliant protocol and a safe implementation. It's clear from the other comments that the implementation does not live up to their expectation, but what about the theoretical algorithm?
- javert 7y agoAlmost every comment here is complaining about the code. This is based on a misconception. The "product" here is an academic paper, not the code. 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.)
- jMyles 7y ago> This is how academia works. 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.
- dkoston 7y agoThere’s no misconception. Until I commented, there was no disclaimer stating that the code was not ready for production use and was for research purposes only. 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.
- javert 7y ago> it’s a lack of clarity by both OP and the project website about what’s important 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.
- kang 7y agoThis paper relies on an assumption: At a given time, either there exists a blockchain, by virtue of which participants can talk freely or everyone knows everyone.
- earthtolazlo 7y agoWhen’s the ICO?
- jMyles 7y agoI read the entire website, then spent a few minutes looking at the code, then a few minutes at the paper. So far, I don't understand the exact nature of the proposition here. 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.
- mskd12 7y agoSo, 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.
- jMyles 7y agoSure, got that. 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?
- mskd12 7y agoThe 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 ;)
- nullc 7y agoIn industry "secret sharing" has essentially become a good indicator for snakeoil. 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.
- deleted 7y ago[deleted]
- baby 7y agoThis is the right timing as I was looking into Secret Splitting/Sharing schemes today. Does anybody know a good survey? It seems like there are several types of schemes: * 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.
- abdullahkhalids 7y agoThanks for just listing these out. I have worked on quantum secret sharing of the SSS type during my PhD. In QSS, the secret is not a bit-string, but a ordered set of qubits in some state. Now, I am thinking whether there exists quantum analogs of these generalized classical secret sharing tasks you have listed.
- AlexCoventry 7y agoI wrote an overview of DKG, here: https://blog.chain.link/threshold-signatures-in-chainlink/ https://blog.chain.link/threshold-signatures-in-chainlink/
- keldefrawy 7y agoThis is a good (academic) survey on secret sharing: https://www.cs.bgu.ac.il/~beimel/Papers/Survey.pdf https://www.cs.bgu.ac.il/~beimel/Papers/Survey.pdf
- EGreg 7y agoWhat's wrong with just Shamir Secret Key Sharing?