diff options
| author | Bryan Bishop <kanzure@gmail.com> | 2019-09-04 06:56:53 -0500 |
|---|---|---|
| committer | Bryan Bishop <kanzure@gmail.com> | 2019-09-04 06:56:53 -0500 |
| commit | 692998fe39ef444b1b22c3a8c3132d014db930e3 (patch) | |
| tree | 87509b5edfdf51c9ee33022e39f60146a166de6b | |
| parent | f5d8ccf2170e1521ca774ddcd78420e0822ff4f6 (diff) | |
| download | diyhpluswiki-692998fe39ef444b1b22c3a8c3132d014db930e3.tar.gz diyhpluswiki-692998fe39ef444b1b22c3a8c3132d014db930e3.zip | |
more terms
| -rw-r--r-- | transcripts/rebooting-web-of-trust/2019-prague/shamir-secret-sharing.mdwn | 15 |
1 files changed, 15 insertions, 0 deletions
diff --git a/transcripts/rebooting-web-of-trust/2019-prague/shamir-secret-sharing.mdwn b/transcripts/rebooting-web-of-trust/2019-prague/shamir-secret-sharing.mdwn index 6ac3242..f4748b9 100644 --- a/transcripts/rebooting-web-of-trust/2019-prague/shamir-secret-sharing.mdwn +++ b/transcripts/rebooting-web-of-trust/2019-prague/shamir-secret-sharing.mdwn @@ -195,12 +195,22 @@ To a certain extent, we don't care about the derived secret. People are going to "Deck blob" might be too weird. We're calling that whole thing a "persona" in the wallet, instead of calling it a wallet or something. You might have a persona which is your personal funds, or a persona for your master key for your employer. +Are we going to assume that the person is going to store the secret in a second place? Like 1-of-1. This might be stupid, but can we do things to dissuade them from doing this? Are we eliminating the user in SLIP 39 from being able to see the secret? We allow them to split it only once, or extract it from the device only once. They can't extract a regular bip39 one... You can either recover with the share technique, or you can use the traditional, but not both. Nothing stops you from combining the shares on your computer and then doing whatever. Still, that's an interesting case. + +To a certain extent, in the smart custody book, we're basically telling you to put the 24 words onto a titanium key which can resist California fire. Yes, I have the risk that if I put it in the bank and it burns down then someone can break into the box and get the titanium key. I have this nice, absolutely cold, fire resistant thing that I will not have the equivalent by default with this approach. Well, you can store binary words into titanium. You can etch a QR code into titanium. You might need a machine to do it for you. You could sit there with a dremmel if you want. I don't necessarily want to forego a titanium recovery key backup system. In SLIP 39, they are doing a mutually exclusive recovery technique. For a user perspective, will we make that same decision? Or will some user wants to be able to do both? + +I think we're doing something different from that. We're building a Shamir secret sharing scheme that isn't necessarily dedicated to building an HD wallet. You want it for social key recovery, for example. What goes into the encrypted payload is whatever you want. It's potentially larger than you could expect to write down as wallet words. + # Terminology glossary Shard dealer: An individual that has a secret that is sharded using this secret sharing scheme. The user makes a number of shards that are dealt out to different users to turn each user into a shard custodian. Deck: A collection of shards that together can be combined (in at least one way) to reconstruct the original secret. +Script policy: A script that specifies a policy for how the deck's secret (seed entropy) can be reconstructed from some combination of shards. + +Quorum: Any set shards sufficient to meet the script policy for reconstruction. + Shard: A member of a deck, with both unencrypted visible information (including a shard value) and encrypted hidden information. The encrypted hidden information is encrypted by the original secret, and the dealer distributes the encrypted hidden information toe ach user. You want to know the unencrypted metadata, the identifier information, then there's private data which is encrypted with the key which gets derived from the secret. Then there's the y value, and then a checksum over all of this. Shard unencrypted metadata (public metadata): Data associated with a shard that describes the shard and the deck among other things. This includes birthdate, identifier information, and so on. @@ -213,5 +223,10 @@ Shard custodian: A user that holds a number of shards, possibly from multiple di Shard pool: A shard custodian can use software that implements a shard pool that contains their collection of shards they are responsible for. The shard pool allows for querying over the set of shards to find particular shards to respond to a request. +Seed entropy: Used to create the derived secret. + Derived secret: The derived secret is used to decrypt the shard encrypted blob or deck blob. + + + |