In industry "secret sharing" has essentially become a good indicator for snakeoil.<p>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.<p>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.<p>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".<p>Academic work on building blocks is useful, but its another thing to promote something as directly useful industrially.
Not sure if OP is the author but thanks for sharing. Secret management is a challenge for a lot of folks.<p>For the authors, here are a couple of items that made it hard for me to evaluate the project:<p>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 (<a href="https://github.com/CHURPTeam/CHURP/blob/master/src/cmd/bb.go#L5" rel="nofollow">https://github.com/CHURPTeam/CHURP/blob/master/src/cmd/bb.go...</a>)<p>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.<p>For example, `(Optional) storeSecret(SK)`. What does "optional" mean? What's the return value? What's SK?<p>(Optional) retrieveSecret() -> SK: What? I can only store a single secret? Without passing params to this, it seems so.<p>3. Project structure is not conventional (cmd/ inside src/)<p>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?<p>4. No tests<p>Again, doubtful I'm going to trust my secrets to a distributed network that's not tested.
This 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:<p>* SSS: (threshold) Shamir Secret Sharing scheme. split a key into m-of-n keys.<p>* 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.<p>* DCPSS: Dynamic-Committee Proactive Secret Sharing. This is CHURN. You can update the partial keys with a different m-of-n.<p>* VSS: Verifiable Secret Sharing. SSS doesn't seem to hold when participants are not all honest. This one fixes that.<p>* PVSS: Publicly Verifiable Secret Sharing. ?<p>* APSS: Asynchronous Proactive Secret Sharing. ?<p>* SVSS: Strong Verifiable Secret Sharing. ?<p>* SVPSS: Strong Verifiable Proactive Secret Sharing. ?<p>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.
I 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.<p>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.<p>Disclaimer: I work at NuCypher; our Ursula Character is probably reasonably regarded as occupying a similar space to this.
This 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.
Almost every comment here is complaining about the code. This is based on a misconception. The "product" here is an academic paper, not the code.<p>The code is just a kind of sanity check for the ideas in the paper.<p>This is how academia works.<p>Please comment on the ideas embodied in the paper, not the quality of the code, which is almost entirely irrelevant at this point.<p>(No affiliation with the authors, here.)
Even 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.<p>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.<p>1: <a href="https://github.com/CHURPTeam/CHURP/blob/master/src/utils/encryption/encryption.go" rel="nofollow">https://github.com/CHURPTeam/CHURP/blob/master/src/utils/enc...</a>
Theres 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?