[tor-dev] PrivCount - Draft of secret-sharing specification

Carolin Zöbelein contact at carolin-zoebelein.de
Fri Sep 29 00:39:16 UTC 2017


thank you for your feedback!

I have to say this....

Am Donnerstag, den 28.09.2017, 14:35 -0400 schrieb Ian Goldberg:
> My earlier mail in this thread bounced for Reasons.  Here it is again.
>    - Ian
> Thanks for the writeup!  Some notes inline.
> On Mon, Sep 25, 2017 at 09:26:13AM +0200, Carolin Zöbelein wrote:
> > 1. Introduction
> > 
> > 	Assume, we have a given secret s which we want to share with a particular
> > 	number N of participants who are only together be able to reconstruct it.
> > 	To realize this, we can split our secret in n parts s_i. Our secret will be 
> > 	then the sum over all s_i. This is the simplest secret sharing scheme at all.
> > 	Since it needs all participants for the reconstruction, it is called a (N,N) 
> > 	treshold secret sharing algorithm.
> > 
> > 	But we also see that it has weaknesses. With every leaked share s_i, an 
> > 	adversary can reduce the number of possible soulutions for our secret very
> > 	easily. This leads to the group of more efficient secret sharing algorithms.
> This is not true.  Even if N-1 of the shares are exposed, *zero
> information* about the secret is leaked!

... is of course, very big trash which I wrote in the proposal.

Why did I write this? I don't know. I think I had Gaussian elimination
in my mind which is absolute nonsense if you only have one equation, of
course! *argh*

Sometimes, by brain does strange things ;)

I have some comments to the other things you pointed out. I will follow
up with some emails, tomorrow.

Bye and thank you for your help!
Carolin Zöbelein / Nick: Samdney
PGP: D4A7 35E8 D47F 801F 2CF6 2BA7 927A FD3C DE47 E13B

More information about the tor-dev mailing list