diff options
author | Bryan Bishop <kanzure@gmail.com> | 2019-09-04 06:46:26 -0500 |
---|---|---|
committer | Bryan Bishop <kanzure@gmail.com> | 2019-09-04 06:46:26 -0500 |
commit | f5d8ccf2170e1521ca774ddcd78420e0822ff4f6 (patch) | |
tree | b0443a1c921387b7e92d54b3e677e815b5eddb1d | |
parent | ab56874e917e4c1936d065a07666a06cce5311ae (diff) | |
download | diyhpluswiki-f5d8ccf2170e1521ca774ddcd78420e0822ff4f6.tar.gz diyhpluswiki-f5d8ccf2170e1521ca774ddcd78420e0822ff4f6.zip |
terminology
-rw-r--r-- | transcripts/rebooting-web-of-trust/2019-prague/shamir-secret-sharing.mdwn | 40 |
1 files changed, 40 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 a0c3fa4..6ac3242 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 @@ -173,5 +173,45 @@ A share custodian have a "share pool". I have heard decks, shards, shares, and all of these terms. We should define some of these terms. There's also containers. There's a shard, a share value, a checksum on the whole thing. There's public information on the share that allows the share custodian to identify what to return from his share pool, which is actually bigger than the full deck. No, it's something else. Then we have the authentication of the shard, we have the public stuff that anybody can view. There might need to be a public policy. There would have to be. Then within the thing that is encrypted, we have the fundamental Shamir, and then we have this encrypted blob that is based on the fundamental Shamir but there may also need to be some authentication check on that whole thing. When we come back, let's puzzle out our names and whether we have all the pieces. +# More terminology +What do we call the thing that we give to a share custodian? There could be shard and shard value. Or share and share value. I like shard over card. It has somehow resonated with lots of people. Shard is close to share, and close to card. It's close to both. I'm leaning in favor of shard. Also you can split something into shards. So the shard is given to the shard custodian. + +Ideally, it's the shard dealer that reconstructs the original secret. There is probably not a universal word for that. In bridge, when you clean up the pile of cards, what is that called? It's "collector" or "aggregator". Is partial a good description? A "partial" instead of a shard. For me, "partial" means "incomplete", but it also means "incomplete transmission" which is not the case here. You have your full transmission, it's just one part of a whole. + +Quorum is fine. Full deck is fine. The script policy describes what the quorum is going to be. A script policy (which is basically a predicate) can have many possible quorums. + +I think we should have a "shard pool" which is the sum of all of the shards from many decks. You can identify a shard by a hash, or a public key, or whatever else. + +We don't necessarily need to use the "persona" terminology but that might be of some value. There has to be some 256-bit identifier or hash, that has to do with the master secret as well as identification for each individual shard. So it would be within scope to specify how that hash is constructed, and then aspects of displaying it in a way that a user can identify it. + +The share value is-- the actual bytes that represent the words. We have a collision of names here. We were also calling that a "share value". That's what they are saying for SLIP 39. The share value he is talking about it, is before you have reconstructed it or after? Before. It's the y value. So there's no collision. + +There is an encrypted master secret in SLIP 39. This is encrypted by the passphrase, after the Shamir reconstruction. It's not encryption, it's derived from the passphrase. It's always derived from something. Given a master secret, you can't go back to the words, but you can construct a whole new set of shares. In SLIP 39, there's an element of randomness when you do the splitting. Shamir adds all this extra entropy on top of the--- but that can be done deterministically by seeding a random number generator. In SLIP 39, it's not done, but it could be. You shouldn't be worried about recreating shares; you want to be able to reconstruct the master secret. + +The master secret should be called the "derived secret". So we're doing bip32 derivation originally-- the origina lvalue can be "root secret" or "seed secret". So it's the seed entropy that goes into bip32. This is the initial value you created in some way. Then you applied the password to derive the derived secret, and then you split it out into shares? SLIP 39 bolts on top of bip39. You can roll it backwards from your wallet words to re-create the seed entropy, to go back to shares. SLIP 39 reconstructs, after the password derivation technique, the shared master secret-- is the same as the seed entropy. When you do the reconstruction, you get the seed entropy, which is then applied with the password derivation to get the derived seed. Okay, you're right. I'm mistaken. Because you use reversible direction, you can go in any direction. In bip32, you need 512 bits, so you run it through HMAC 512. + +To a certain extent, we don't care about the derived secret. People are going to use standard tools to take the seed entropy and turn it into a derived secret. We're not defining how to take this into a derived secret. Are you going to be using, in the binary format, and you're not going to save every bit of space, then it's an encryption key not the master secret. Then you encrypt the secret. We want to shard up the encryption key, so that the blob can be decrypted. + +"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. + +# 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. + +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. + +Shard value: The mathematical or cryptographic value that can be used in the secret sharing scheme to reconstruct the original secret. This is the y value. + +Private data (encrypted): Encrypted data transferred with each shard. The decryption key can be computed by recombining all the shares. + +Shard custodian: A user that holds a number of shards, possibly from multiple different decks. + +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. + +Derived secret: The derived secret is used to decrypt the shard encrypted blob or deck blob. |