Verifiable Secret Sharing

fork of : %hNnHqpw...

Have been reading up on @null_radix's https://www.npmjs.com/package/vss , and also trying to think anout what different things we have in our context which might make shards verifiable in different ways. Here's the current schema of a shard :

{
  "type": "dark-crystal/shard",
  "version": "1",
  "root": "%viiJnnnXjNkfCALivEZbrDe8UndkCCCNQ/CgBOWgJLw=.sha256",
  "shard": "Yn3foQzIrckEh139UbZ2JYuQI9FSJ3lBEV7wcePeFc/Eeo0t9kfrNp+9+bZio76RTJOM7pVEo1AUJFFupGStwNHtXmcQ9msnvnvR1RW5qLxX3luNMe+m45jcDLDCwPU237TJFIqYbUbd/DeI3YFiFH+AMU8XAPTV9scukFMVSTDrr/Li6fI=.box",
  "recps": ["@LA9HYf5rnUJFHHTklKXLLRyrEytayjbFZRo76Aj/qKs=.ed25519", "@95WQAJ1XZju4YFpLib3JYdbx//BCtr5dq3bR9jPxYWs=.ed25519"]
}

NOTE - this is very likely to change, because as we add forwarding we're probably going to _at least need to somewhere include a name for the secret this is part of so whoever re-assembles it has any idea what to do with this. Undecided whether this is part of the hidden message or part of the shard..._

current crude method for determining valid shard is that it ends with .box!

this method is good for checking if things are malformed if you're dealing with a good actor

what if the thing in the shard field is soemthing like:

hash(root * shard_content) + shard_content

no ... that doesn't work at all, it needs to be verifiably connected to the hidden secret ...

here's a thread @peg already started : %QuRPsH0...

hey @null_radix , @peg and I were reading over your module https://www.npmjs.com/package/vss which looks really neat. I'm a beginner in the cryptography space and I have what I hope is a simple question.

In our context on scuttlebutt, we're passing shards (shares) out to friends and later we may want to :

• 1. ask for them back
• 1. ask for them to be fwdd to a new account

It would be nice to be able to verify that the shares coming back are healthy and valid. To do that with vss, the person verifying the shares would need a copy of the verifcation vector. Who is it safe to give this to? e.g.

• encrypted to my initial account
• each shard holder
• another friend not holding any shards
• post it publicly

The Wikipedia page https://en.wikipedia.org/wiki/Verifiable_secret_sharing warns (I think) about how some pieces of this data might leak more data about the original secret. I could be wrong about that, I'm reading as an amateur
Trying to balance the affordance of verifiability against reducing the strength of the cryptography!

@mixmix

It would be nice to be able to verify that the shares coming back are healthy and valid. To do that with vss, the person verifying the shares would need a copy of the verifcation vector. Who is it safe to give this to? e.g.

it is safe to post the verification vector publicly. The shares in this schemes are essentially private keys and the vv is just an array of corresponding public keys. No information can obtained from them except to verify if a given share is correct.

@peg

its would be cool to use this vss module for dark-crystal. the thing that im a little bit unsure about is that it would mean we need to keep hold of the encrypted secret as well as the shares.

right so i would image you would encrypt the payload first with the secert generated by vss and post that somewhere public then distrubute the secret shares. But yes that doesn't make sense if your payload is below 32 bytes. Also I can add an option to vss to allow you to give it a 32 bytes secret that you whish to share... instead of just generating one for you.. if that is useful