Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Super Shamir" support? #8

Open
cyphar opened this issue Dec 24, 2021 · 2 comments
Open

"Super Shamir" support? #8

cyphar opened this issue Dec 24, 2021 · 2 comments

Comments

@cyphar
Copy link
Owner

cyphar commented Dec 24, 2021

Trezor finally has developed SSS support (though it lacks some of the expansion and strong verification features we have -- their design where they use interpolation as part of their polynomial generation also looks a little strange). They've also implemented an interesting mode called "super shamir" where after creating key shards for your bitcoin key, you then further split the shards into sub-shards.

I suspect this was done in order to work around their 16-share limitation by making reconstruction more performant. But the interesting aspect of this feature is it allows you to create segregated groups of shard holders that may completely betray you and still would not gain any information.

However I'm not entirely convinced that this is solving a real threat model -- if you can confidently segregate N people into A group of size B, where you will never have inter-group betrayals above the threshold you could create the same amount of shares but use a B*2 or higher threshold (the bound is probably lower depending on the thresholds of each group but this is the worst case).

@BenWestgate
Copy link

BenWestgate commented Apr 23, 2022

This solves a threat model where you want recovery to absolutely require a third party or an international flight.

Example 1:
2 shares; local, international, threshold 2
4 sub-shares in country of residence, threshold 2
4 sub-shares abroad, threshold 2

Were it 4 of 8, the secret can be recovered without the flight. While 5-6 of 8 are easier to lose.

Example 2:

3 shares; personal, heir; executors, threshold 2
5 personal sub-shares, threshold 3
5 heir sub-shares, threshold 3
5 executor sub-shares, threshold 3

Were it 6 of 15, one betraying executor could collude with heir to inherit early or 5 betraying executors could steal one share from you or your heir to recover. This requires stealing 3. Raising threshold to 8 of 15 would be easier to lose; any of the 3 groups could then only lose 2 shares Total and recover rather than lose 2 Each and recover.

@cyphar
Copy link
Owner Author

cyphar commented Jul 15, 2024

Aside from some minor quibbles about how we would store the structure (and whether/how we would want to hide the structure of the sharing setup), my main concern is the UX for doing this. At the moment all shares are identical and we can use the same format (both in terms of line format and the PDF version) for all of them.

But if we have to do a recovery of multiple layers of shares then each share would need to provide printed information about how it fits into the share structure (in a way that a non-technical user could understand). I'm not sure if there is a nice way of doing that... You don't want to end up in a situation where you have 12 people coming together but it turns out that they don't have enough shares, and there was no way for them to figure that out beforehand.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants