group: Implements Shamir and Feldman secret sharing. #348

armfazh · 2022-07-12T06:51:16Z

New:

Introduces Lagrange interpolation [1].
Shamir's secret sharing [2] on top of the group interface.
Feldman's verifiable secret sharing [3] on top of the group interface.

References:
[1] https://mathworld.wolfram.com/LagrangeInterpolatingPolynomial.html
[2] https://dl.acm.org/doi/10.1145/359168.359176
[3] https://ieeexplore.ieee.org/document/4568297

chris-wood

The ergonomics of the API seem good, but I think we can do better with the naming. I'm curious to hear what @cjpatton has to say about the names.

group/secretsharing/ss.go

group/secretsharing/ss_test.go

group/secretsharing/poly.go

group/secretsharing/ss.go

bwesterb · 2022-07-29T10:31:16Z

group/secretsharing/ss.go

+	vecComm := make(SharesCommitment, v.s.T+1)
+	for i, ki := range poly.coeff {
+		vecComm[i] = v.s.G.NewElement()
+		vecComm[i].MulGen(ki)


We need to add a big fat warning. If our secret is a small scalar, it can easily be recovered from the commitment. E.g., it's easy to see if our secret was 2 from vecComm[0].

secretsharing/ss.go

cjpatton

First pass focuses on API, I will look at the math next :)

High level questions about math/polynomial:

This is defined around the "scalars" of a "group". Do the operations in this package require the scalars to comprise a finite field, or more specifically, the group to have prime order?
If "yes" to (1.), why not define this package around a generic finite field?

It's a bit odd that constructing a new impl of SecretSharing requires a Group. Shamir's (and Feldman's I imagine, but I haven't checked) is well-defined for any finite field, hence this API is more restrictive than necessary.

If this API is only intended for use with cryptographic protocols built from an implementation of Group, then I would make this very clear in the documentation.

math/polynomial/polynomial.go

secretsharing/ss.go

armfazh · 2022-08-26T23:10:24Z

This is defined around the "scalars" of a "group". Do the operations in this package require the scalars to comprise a finite field, or more specifically, the group to have prime order?

If "yes" to (1.), why not define this package around a generic finite field?

It's true that secret sharing package can be defined over a finite field. In CIRCL, currently we have no such abstraction. This may require to gather all the field implementations we have in CIRCL.
For the purposes of threshold cryptography, we use ecc groups and its set of scalars. At this point we are covering this use case, but we can accommodate more use cases when needed.

secretsharing/ss.go

armfazh · 2022-10-10T17:54:48Z

Hi folks, to move forward with this PR, please leave your comments to the latest changes. And approve if you are ok with the current status.

cc: @bwesterb @chris-wood @cjpatton

chris-wood

Functionally, this seems correct, but I think we can still improve the API to make it easier to build things like STAR on top of this.

chris-wood · 2022-10-17T18:49:41Z

math/polynomial/polynomial.go

@@ -53,6 +56,15 @@ func (p Polynomial) Evaluate(x group.Scalar) group.Scalar {
 	return px
 }

+// Coefficient returns a deep-copy of the n-th polynomial's coefficient.
+// Note coefficients are sorted in ascending order with respect to the degree.
+func (p Polynomial) Coefficient(n uint) group.Scalar {


It seems strange that this function takes a uint as input but Degree() outputs an int -- should they use the same type?

The odd case is Degree() returning -1 for the special case of the zero polynomial. We might remove this special case.
@bwesterb what do you think?

secretsharing/ss.go

chris-wood · 2022-10-17T18:56:25Z

secretsharing/ss.go

+// A (t,n) secret sharing allows to split a secret into n shares, such that the
+// secret can be only recovered from any subset of t+1 shares. Returns an error
+// if 0 <= t < n does not hold.
+func NewShamirSecretSharing(g group.Group, t, n uint) (SecretSharing, error) {


I would only pass t as the input here, and let the caller determine how many shares they need in order to split a secret by invoking Shard as many times as needed (though at least t times).

still needs to work on this
~~done~~

chris-wood · 2022-10-17T18:57:40Z

secretsharing/ss.go

+}
+
+// Shard splits the secret into n shares.
+func (s SecretSharing) Shard(rnd io.Reader, secret group.Scalar) []Share {


Can we split this up into the following two functions?

Shard, which takes as input a secret and a (set of points) at which to produce (a set of) share(s).

RandomShard, which takes randomness as input along with the secret and produces a random share.

That would be more useful for the STAR application.

secretsharing/ss.go

chris-wood

I think the interface still isn't quite right, so let me step back and identify the use cases I think are important to solve.

A user wants to share a secret with n other users with a recovery threshold of t. This is the classic secret sharing setting. The caller could provide "IDs," or they could be provided at random. I think it's probably easier if they're generated randomly and then the caller assigns these IDs to each user.
t users want to independently produce random shares of the same secret such that someone else (a collector or combiner) can recover the secret. Each user has to agree on the secret sharing polynomial independently and non-interactively, i.e., without communication, otherwise this doesn't work. This is the STAR use case.

Based on my understanding of this PR, it looks like (1) is partly addressed (though I would make the API somewhat different so as to not require a monotonically increasing selection of share input [x coordinates]), but (2) does not seem to be addressed.

It's fine if we want to address these in separate PRs, but I'd like to understand what the plan is for both. @armfazh, can you please clarify? In particular, if the plan is to do this in two separate PRs, can you please clarify how the use case in (1) is satisfied?

secretsharing/ss.go

chris-wood · 2022-10-19T22:27:28Z

secretsharing/ss.go

+// Share represents a share of a secret.
+type Share struct {
+	// ID uniquely identifies a share in a secret sharing instance.
+	ID group.Scalar


Can we rename this to something else? Maybe Input, and maybe rename Value to Output?

armfazh · 2022-11-24T00:17:53Z

I think the interface still isn't quite right, so let me step back and identify the use cases I think are important to solve.

A user wants to share a secret with n other users with a recovery threshold of t. This is the classic secret sharing setting. The caller could provide "IDs," or they could be provided at random. I think it's probably easier if they're generated randomly and then the caller assigns these IDs to each user.

t users want to independently produce random shares of the same secret such that someone else (a collector or combiner) can recover the secret. Each user has to agree on the secret sharing polynomial independently and non-interactively, i.e., without communication, otherwise this doesn't work. This is the STAR use case.

Based on my understanding of this PR, it looks like (1) is partly addressed (though I would make the API somewhat different so as to not require a monotonically increasing selection of share input [x coordinates]), but (2) does not seem to be addressed.

It's fine if we want to address these in separate PRs, but I'd like to understand what the plan is for both. @armfazh, can you please clarify? In particular, if the plan is to do this in two separate PRs, can you please clarify how the use case in (1) is satisfied?

The code I just pushed satisfy these cases:
a) both textbook Shamir and Feldman secret; and
b) the case when the share is generated with a prescribed ID (case 1).

For case 2: one solution is that rand (the first param of New(rand, ...)) can be passed as a PRNG with a seed, this makes the internals of the secret sharing deterministic (and reproducible).
Other solutions can be adopted later (but not in this PR).

armfazh added the new feature New functionality or module label Jul 12, 2022

armfazh requested review from bwesterb, chris-wood and cjpatton July 12, 2022 06:51

armfazh self-assigned this Jul 12, 2022

chris-wood suggested changes Jul 22, 2022

View reviewed changes

armfazh force-pushed the secretSharing branch from 44925f7 to 50afb71 Compare July 25, 2022 21:33

armfazh requested a review from chris-wood July 25, 2022 21:41

bwesterb requested changes Jul 29, 2022

View reviewed changes

armfazh force-pushed the secretSharing branch from 50afb71 to 175788f Compare July 30, 2022 03:18

armfazh changed the base branch from main to polynomial July 30, 2022 03:18

bwesterb approved these changes Aug 1, 2022

View reviewed changes

secretsharing/ss.go Outdated Show resolved Hide resolved

bwesterb self-requested a review August 1, 2022 08:30

armfazh force-pushed the polynomial branch from 2901247 to dc30325 Compare August 1, 2022 19:51

armfazh force-pushed the secretSharing branch from 175788f to 99716d8 Compare August 1, 2022 20:05

Base automatically changed from polynomial to main August 9, 2022 20:56

armfazh force-pushed the secretSharing branch from 99716d8 to 0122e3d Compare August 16, 2022 17:29

armfazh force-pushed the secretSharing branch 2 times, most recently from b0d84b5 to bb3e3e4 Compare August 24, 2022 22:58

cjpatton requested changes Aug 26, 2022

View reviewed changes

armfazh force-pushed the secretSharing branch from bb3e3e4 to 28db5bf Compare August 26, 2022 22:59

cjpatton reviewed Aug 30, 2022

View reviewed changes

cjpatton reviewed Aug 31, 2022

View reviewed changes

secretsharing/ss.go Outdated Show resolved Hide resolved

armfazh force-pushed the secretSharing branch from da1ac24 to 1b68fea Compare October 10, 2022 20:24

chris-wood suggested changes Oct 17, 2022

View reviewed changes

cjpatton approved these changes Oct 18, 2022

View reviewed changes

secretsharing/ss.go Outdated Show resolved Hide resolved

armfazh force-pushed the secretSharing branch from 98bfada to b0a42cb Compare October 19, 2022 08:38

armfazh requested a review from chris-wood October 19, 2022 08:39

chris-wood reviewed Oct 19, 2022

View reviewed changes

armfazh force-pushed the secretSharing branch from b0a42cb to bbaa64a Compare November 24, 2022 00:18

Implements Shamir and Feldman secret sharing.

9c3d94b

armfazh force-pushed the secretSharing branch from bbaa64a to 9c3d94b Compare November 24, 2022 00:22

armfazh requested a review from chris-wood November 24, 2022 00:24

armfazh merged commit 2a2b195 into main Feb 14, 2024

armfazh deleted the secretSharing branch February 14, 2024 19:32

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

group: Implements Shamir and Feldman secret sharing. #348

group: Implements Shamir and Feldman secret sharing. #348

armfazh commented Jul 12, 2022 •

edited

Loading

chris-wood left a comment

bwesterb Jul 29, 2022

cjpatton left a comment

armfazh commented Aug 26, 2022

armfazh commented Oct 10, 2022

chris-wood left a comment

chris-wood Oct 17, 2022

armfazh Oct 18, 2022

chris-wood Oct 17, 2022

armfazh Oct 18, 2022 •

edited

Loading

chris-wood Oct 17, 2022

chris-wood left a comment

chris-wood Oct 19, 2022

armfazh commented Nov 24, 2022

group: Implements Shamir and Feldman secret sharing. #348

group: Implements Shamir and Feldman secret sharing. #348

Conversation

armfazh commented Jul 12, 2022 • edited Loading

chris-wood left a comment

Choose a reason for hiding this comment

bwesterb Jul 29, 2022

Choose a reason for hiding this comment

cjpatton left a comment

Choose a reason for hiding this comment

armfazh commented Aug 26, 2022

armfazh commented Oct 10, 2022

chris-wood left a comment

Choose a reason for hiding this comment

chris-wood Oct 17, 2022

Choose a reason for hiding this comment

armfazh Oct 18, 2022

Choose a reason for hiding this comment

chris-wood Oct 17, 2022

Choose a reason for hiding this comment

armfazh Oct 18, 2022 • edited Loading

Choose a reason for hiding this comment

chris-wood Oct 17, 2022

Choose a reason for hiding this comment

chris-wood left a comment

Choose a reason for hiding this comment

chris-wood Oct 19, 2022

Choose a reason for hiding this comment

armfazh commented Nov 24, 2022

armfazh commented Jul 12, 2022 •

edited

Loading

armfazh Oct 18, 2022 •

edited

Loading