@dlubarov - thanks very much for your reflections
dlubarov: is it safe to assume the dealer is honest?
in this context, we are making a system where people can backup their secrets (typically private keys) by sending shamir’s shares to their friends. so yes we can assume the dealer is honest, as it is in their interest to facilitate recovering the original secret.
dlubarov: it might be good to use 32 bytes just in case?
the reason we have truncated it is too keep shares small. With the secret sharing implementation we are using, shares are roughly four times the length of the original secret. And Scuttlebutt messages (which we use to transmit shares) have a maximum size, meaning there is an upper limit on the secret size.
[Publishing share hashes] Could you elaborate on this? I don’t really understand the concerns. Assuming you just need to protect against malicious custodians and not malicious dealers, publishing share hashes seems as good as anything else AFAICT.
I’m pleased you brought this up as this is something I’d like to give more thought to, and it is an appealing option because it is so simple.
The concern was that each custodian now has their own share as well as hashes of the remaining shares. In my understanding of shamir’s scheme, this does not create a vulnerability, but I am a little unsure of this. At the very least, it exposes the number of custodians, and gives a way to brute-force the secret. But i expect any zero knowledge verification would do this. I’d love to hear your opinion on this.
The other concern was accountability - we do not want to publicly expose the identities of custodians, so we would need to publicly publish only the hashes, not who they were given to. If two custodians presented identical shares we would have no way to tell which one of them had originally received it.
My feeling is that I would prefer to use a verification scheme which is well documented and used by other projects, so I’d be interested to find examples where this, or something similar is being used.