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
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
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
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 would
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 number
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.
It
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
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 patch
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, 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
prepare
10 matches
Mail list logo
