I was wondering about the following as an alternative to secret sharing(shamir): Assuming that in order to gain access to some theoretical system, we'd be saving secrets on the system and we will monitor all the access attempts, in the following way: Every participant will get a different "secret", and the system will check if the conditions are valid.

For instance: If 3 out of 5 participants from a level 1, or one from level 1 and one from level 2 and similar.

Cryptographically speaking, what are the disadvantages of it? Isn't it a simpler way instead of shamirs secret sharing?

It would help me the most if you could explain it to me mathematically, so I can understand the how and why to better understand the words.

Thank you for helping me understand it better.

  • $\begingroup$ Please do capitalize your sentences and such, we do try and keep a professional looking site. $\endgroup$
    – Maarten Bodewes
    Apr 21, 2020 at 0:17

2 Answers 2


Many problems (if not all) in cryptography can be made "trivial" if you have a mutually trusted third party. The argument is something along the lines of:

  • Multi-party Computation can describe many (if not all) primitives within Cryptography as jointly computing some functionality
  • MPC is made trivial in the presence of a mutually trusted third party (this is the basis for the "ideal vs. real" proof strategy)
  • If given a mutually trusted third party, one can securely implement any function which can be implemented using Multi-Party Computation

Implementing access control as you describe is simply implementing access control with a mutually trusted third party. If you believe this exists in your situation then you can gain efficiency by using it. But if you are "wrong", and someone manages to corrupt your server, you "lose everything".

Note that this is somewhat the case for secret sharing already. Generally secret sharing schemes can be written as two functions: $\mathsf{MakeShares}$ and $\mathsf{Reconstruct}$. If a server which is running the $\mathsf{Reconstruct}$ protocol is compromised during reconstruction, you "lose everything" (under naive Shamir's secret sharing).

You're (essentially) suggesting implementing $\mathsf{Reconstruct}$ with a stateful trusted third party. You could even make this explicit by having your server first run Shamir's secret sharing on the secret, then "renaming" the Shamir's shares using some arbitrary encoding (which you "store" in a table on the Server to be able to undo later). But as your solution requires the state for correct reconstruction, if your server is ever compromised, you "lose everything" immediately.

Another application your algorithm can't replace Shamir's in is when the protocol participants don't trust eachother. Someone has to "have all the shares" to be able to implement the access control, and if there's no natural candidate then your protocol doesn't work, but Shamir's still does.

That all being said, for implementing access control where all participants are part of the same organization, you could use non-cryptographic techniques (such as yours) due to the presence of a mutually trusted third party.

  • $\begingroup$ thank you very much for your very elaborate answer, studying it $\endgroup$ Apr 20, 2020 at 20:33

cryptographically speaking, what are the disadvantages of it? isn't it a simpler way instead of shamirs secret sharing?

A lot of cryptographical problems become much easier if you assume a trusted third party. Of course, the downside is that you need such a trusted third party, who everyone trusts, and (in the case of Shamir) knows the secret and is willing to give it out if certain conditions is met.

Most of the time, we don't have such a third party (either because there's no one everyone trusts, or possibly because no one every had enough information to pick the shared secret in the first place).

  • $\begingroup$ thank you very much for your answer and explaining it so simply $\endgroup$ Apr 20, 2020 at 20:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.