Shamir secret sharing on secp256k1's field

[cubeyo]

Has just added shamir secret sharing as experimental module on secp256k1's field, at this commit

Currently support secret sharing creation and one party recovery based on lagrange interpolation polynomial.

Does anyone need that?

[apoelstra]

I think SSS is too difficult to use correctly, and has too few usecases, for it to be accepted here (or in secp256k1-zkp, which is much more willing to accept experimental things).

[Rspigler]

A potential usecase is for multisig wallet descriptors - while you can set up an M of N for spending, it is always a 1 of N for privacy w/ the people/places you store the N backups. [This is only an issue for a single party multisig - if it is a multiparty multisig, they should be able to view the balance etc]. SSS could create the same (or its own M2 of N) for privacy.

[apoelstra]

If you are just trying to split your backup non-redundantly you can split your seed words into 2 or 3 parts. If you're trying to split into more pieces than that or have different thresholds than 1 or 2, I'd consider this a very niche use-case.

In general SSS is worse than CHECKMULTISIG, except for blockchain cost (but if this is significant then why are you using complex high-security setups?) and privacy (but if you are transacting so frequently to worry about this then why are you using complex high-fragility setups?).

[Rspigler]

It's not about the seed words, it's about the descriptor.

In a single party multisig, all backup locations need their specific seed word and the wallet descriptor. The script handles the M of N spending policy, but the descriptor means that any backup location can see the balance etc.

If you want the privacy of the wallet to be a multisignature scheme as well, you need SSS.

[real-or-random]

If you want the privacy of the wallet to be a multisignature scheme as well, you need SSS.

Note that a somewhat naive method for small M and N is layered encryption. E.g., in the most common case of 2-of-3 with sk1, sk2, sk3, you can derive corresponding symmetric keys k1, k2, k3 and then store

Enc(k1, Enc(k2, desc))
Enc(k1, Enc(k3, desc))
Enc(k2, Enc(k3, desc))

If we had public key encryption (PKE) in this library, you could also use this... (Or roll your own PKE using the ECDH implementation here.) I think chosen ciphertext attacks are not an issue, so you wouldn't even need a full ECIES, even though it's not hard to implement. To be honest, PKE shows up in a number of scenarios in the Bitcoin space, so this may be another primitive to consider, in particular given that we have ECDH.

In the future with Schnorr sigs, we'll hopefully have "real" threshold schemes, e.g., FROST which anyway will use SSS under the hood. Assuming this exists, you could simply derive an encryption key from the FROST key generation. Having said this, we'll need some SSS implementation anyway but I'm really not sure if it should be user exposed.

[Rspigler]

Yes, we have been working on implementing something like what you suggested at Yeticold, but it gets difficult for larger M of N's (which we default to).

The privacy risk has been a concern of a number of our users, but perhaps we will have to wait for FROST.