12

Let's say $k$ users have shares to a $(k,n)$ secret sharing scheme, and they want to issue new shares. How can they do this without collecting the shares together?

In particular, no set of $k-1$ users (including the new users) should be able to learn the shared secret during or after the share generating process. There is also no trusted third party.

One way to do this is by doing a secure multiparty computation. Is there a way to accomplish the task without a general multiparty computation scheme?

e-sushi
  • 17,891
  • 12
  • 83
  • 229
Christopher King
  • 819
  • 5
  • 19
  • 1
    What adversary model (semi-honest or malicious)? Can up to k-1 parties be corrupt? Can you bound k as a fraction of n? – mikeazo Sep 04 '16 at 23:39
  • @mikeazo malicious, but they won't do anything to get caught. – Christopher King Sep 05 '16 at 00:34
  • So maybe more of a covert adversary model. – mikeazo Sep 05 '16 at 02:17
  • @mikeazo I may be wrong, but this reads a bit like “How do you distribute secret shares without knowing who to first distribute them to?” They seem to be dupes since both practically ask if it’s possible to compute secret shares and distribute them at a later stage – while avoiding multiparty computation. Because this question reads a bit more on-point, would it make sense to close the other one (which has received zero answers since 2013) as a dupe of this one? – e-sushi Sep 05 '16 at 06:28
  • You could go with the simple asymmetric workaround. Everybody has an asymmetric key pair and knows each other's public key. The sender generates ephemeral shares for each message and encrypts them to the receivers' public keys. – CodesInChaos Sep 05 '16 at 07:04
  • Should the new shares also be in a (k,n)-secret sharing scheme? – Guut Boy Sep 05 '16 at 07:57
  • Couldn't each of the $k$-players simply make and distribute a shares of their original share? This way you have a sharing of the $k$ original shares, which can be reconstructed in order to reconstruct the original secret. To get malicious security you may need some sort of verifiable sharing, but I think something along these lines could work. – Guut Boy Sep 05 '16 at 08:04
  • Read this answer to a different question for some thoughts on why what you want to do might not work. – Dilip Sarwate Sep 06 '16 at 01:52
  • 1
    When you say "issue new shares" do you mean new shares for everyone involved (which may include additional users), or do you mean the existing users keep the same shares they currently have and new users get fresh shares that could work with existing shares to reconstruct the original secret? – mikeazo Sep 07 '16 at 12:29
  • 1
    @mikeazo new users get new shares – Christopher King Sep 07 '16 at 12:30
  • 1
    I'm assuming another requirement would be that none of the existing users learn the shares of the new users. I'm assuming given your requirements that a general MPC protocol is the best you will get. If you allow for everyone to get new shares, that would likely make things easier. – mikeazo Sep 07 '16 at 12:37
  • 1
    @mikeazo if old users see new shares, they can learn the secret with less than k of them. – Christopher King Sep 07 '16 at 12:38
  • 1
    The following paper seems very relevant: https://eprint.iacr.org/2016/194.pdf Quote: "In this work we consider the well motivated, yet almost unexplored, case where the set of parties is not known in advanced and could potentially be infinite. Our goal is to give the t-th party arriving the smallest possible share as a function of t. We require that in each round, as a new party arrives, there is no communication to the parties that have already received shares, i.e. the dealer distributes a share only to the new party". – Cryptonaut Sep 13 '16 at 09:43
  • @simkin: That seems like almost exactly the opposite of what the OP wants: the paper you linked to assumes that only the dealer distributes new shares, while the OP is asking for a scheme that doesn't need a dealer at all to distribute new shares. (Also, it seems to me that the paper is mostly of theoretical interest. Sure, using Shamir's secret sharing, the field size puts an upper bound on the number of participants. But if you're working in, say, $GF(2^{256})$, that upper bound is $2^{256}-1$. Even if you assigned a share to every atom in our galaxy, you still wouldn't reach it.) – Ilmari Karonen Dec 21 '16 at 21:29

2 Answers2

4

Here is the setup I am assuming, in the beginning you have a dealer who distributes $k$ shares from a $k$ out of $n$ secret sharing (e.g., Shamir) to the $k$ parties currently present.

What you would like is that if at some point in the future the $k$ parties want to add an additional party, they can do so, without requiring the dealer to cooperate at that moment in time.

As you mention, one way to do this would be with a general MPC. Another way to do this, would be, if the dealer agrees at the start that some additional shares should be available so that if the $k$ parties want to let another person in, they can, the dealer can generate a few additional shares right off the bat (say $k+t$ instead of just $k$ shares). Distribute $k$ shares to the $k$ parties, then secret share the remaining $t$ shares with the $k$ parties. That way, each of the $k$ parties has their own share, and shares of the remaining $t$ shares. If they want to give someone else a share, they send them a share of one of the $t$ shares. That party reconstructs to get a share of the original secret.

This allows the $k$ original parties to keep their original shares, while giving a new share to a new party. The dealer can also set thresholds on how many of the $k$ parties need to come together to pass out additional shares (it doesn't have to be all $k$).

As I mentioned in my comment, if you remove the requirement that the original $k$ parties can keep their original shares, i.e., you allow them to get a fresh share at the same time that you are generating a new share for the incoming party, Desmedt and Jadjodia's paper on redistributing secret shares is the way to go (malicious model variants have been proposed if necessary).

mikeazo
  • 38,563
  • 8
  • 112
  • 180
  • If we use genric MPC wouldn't the existing participants learn the new share? – Meir Maor Jul 02 '18 at 05:11
  • @MeirMaor, no. This one is kind of old, but what I think I was referring to was that they could compute on their existing shares to do an MPC computation to generate a new share. Since they are using MPC, each participant would learn a share of the new share (which they would pass to the new party). But they would definitely not learn the new share. – mikeazo Jul 02 '18 at 12:55
1

A proactive and dealer free protocol is described in this paper.

"Novel Adaptive Proactive Secret Sharing without a Trusted Party" - Xiuqunn Wang

This is ideal for the initiation of an smpc protocol.

Erik Aronesty
  • 440
  • 2
  • 14
  • This is ideal for the initiation of an smpc protocol seems to miss the fact the question asks Is there a way to accomplish the task without a general multiparty computation scheme? Since OP abviously wants to avoid smpc all together, that last line of the 3-line answer is somewhere between "superfluous" and "missing the point". Maybe you could edit your answer to clarify how the fact that it may be ideal to initialize a smpc protocol helps the asker, who wants to specifically avoid taking the smpc path? – e-sushi Jul 08 '18 at 01:42