On Wed, Nov 18, 2009 at 02:00:25PM +, Simon McVittie wrote:
> The mathematics of Shamir secret sharing do not work correctly with x_i = 0,
> i.e. a component foo.000, so the library should reject any sharenrs array
> that contains 0, and the utilities should not produce such arrays. I'll
> prep
On Wed, 18 Nov 2009 at 14:22:38 +, Daniel Silverstone wrote:
> Indeed, the zero-share is not useful since in theory it'd be the data
> unchanged.
Thankfully, due to an implementation quirk, the share 000 output is a copy
of share 001, so the only differences are:
* it's mislabelled and won't
On Wed, 18 Nov 2009 at 15:09:07 +, Daniel Silverstone wrote:
> If you lose a number of shares equal-to-or-greater-than the number
> required to reconstruct the share, it might arguably provide you with a
> short period of time in which to revoke those keys. I'd be quite happy
> to receive a pa
Hi,
> One thing that the two failures had in common is that component x.000 was
> produced and was used to remake the share; with the default 3-of-5 setting,
> this can be expected to happen in around 2% of calls to gfsplit.
That indeed seems to fit my observations.
> The mathematics of Shamir s
Hi,
> On Wed, Nov 18, 2009 at 03:36:37PM +0100, Florian Zumbiehl wrote:
> > Why is it "randomized" anyhow? Just numbering shares from 1 would produce
> > more reproducible results, thus making it more likely that problems
> > specific to a certain use case would get noticed before it's too late.
>
On Wed, Nov 18, 2009 at 04:05:20PM +0100, Florian Zumbiehl wrote:
> > Randomised so that you can easily strip the numbers and place them
> > elsewhere and thereby make it harder to guess the share numbers.
> And that is good for what?
If you lose a number of shares equal-to-or-greater-than the num
On Wed, Nov 18, 2009 at 03:36:37PM +0100, Florian Zumbiehl wrote:
> Why is it "randomized" anyhow? Just numbering shares from 1 would produce
> more reproducible results, thus making it more likely that problems
> specific to a certain use case would get noticed before it's too late.
> It probably
On Wed, 18 Nov 2009 at 14:00:25 +, Simon McVittie wrote:
> One thing that the two failures had in common is that component x.000 was
> produced and was used to remake the share
Forgot to mention: if you have lost data as a result of this bug, but you
still have access to *more than* the thresh
retitle 556939 libgfshare-bin: can produce broken shares containing foo.000
tags 556939 confirmed
forwarded 556939 dsilv...@digital-scurf.org
thanks
A modified version of your test case eventually failed for me: in the first
run it failed after 157 split/recombine attempts, and in the second run i
Processing commands for cont...@bugs.debian.org:
> retitle 556939 libgfshare-bin: can produce broken shares containing foo.000
Bug #556939 [libgfshare-bin] libgfshare-bin: reconstruction results in garbage
Changed Bug title to 'libgfshare-bin: can produce broken shares containing
foo.000' from 'l
10 matches
Mail list logo
