Hi, I happened to see this bug, and am the maintainer of libgfshare in Debian... I don't see any particular reason to remove ssss unless it develops RC bugs, but I thought I'd explain the difference between the two implementations. The reason the two packages don't interoperate is that they use Shamir's scheme in rather different ways.
On Wed, 02 Dec 2009 at 16:01:16 +0100, Jakub Wilk wrote:
> - libgfshare uses GF(256) fields, which imply that it needs to use
> some additional (undocumented!) means to deal with data more than 1
> byte long. On the other hand, ssss can use GF(2**n) for n up to 1024
> and it is documented how to work around 1024-bit limit.
libgfshare treats the secret as a sequence of bytes, and applies Shamir's
scheme to each byte individually; if you have a 2000-byte secret and you ask
for 5 shares, the output is a set of 5 2000-byte files, in which (for
instance) the 42nd byte of each file is one of 5 Shamir shares of the 42nd
byte of the secret. Merging the appropriate number of those files a byte at
a time yields the original secret.
As a result, it can split arbitrarily large secrets without using any external
cryptography, which is useful for (for instance) GPG secret keyrings or SSL
CA certificates, which are necessarily larger than 1024 bits (assuming you
have a 1024-bit or larger public key).
Meanwhile, ssss treats the secret as a single very large number, and
applies Shamir's scheme only once, to the whole thing. The documented
workaround for large secrets is to share a <1024 bit symmetric key, and
encrypt the real secret with that key.
On Wed, 02 Dec 2009 at 16:01:16 +0100, Jakub Wilk wrote:
> * Lucas Nussbaum <lu...@lucas-nussbaum.net>, 2009-08-11, 23:20:
> >A strong point in favor of removing it is that we should not mislead
> >users to software when a better alternative exists. Are there
> >reasons/use cases where ssss would be better than libgfshare-bin?
>
> - In my opinion, libgfshare has cumbersome user interface; on the
> other hand, you can easily use ssss in pipelines.
It's true that the libgfshare-bin command-line interface only deals with files,
not pipes; I believe it'll happily write to /dev/stdout when combining,
if that's any help? The underlying library deals with arbitrary byte sequences
for both input and output, so the current UI doesn't have to be the only
interface. I have a FUSE filesystem that uses the library[1], although I don't
think it's ready for production use.
Simon
[1] http://git.pseudorandom.co.uk/gfcombinefs.git
signature.asc
Description: Digital signature
