SecretSplitter icon indicating copy to clipboard operation
SecretSplitter copied to clipboard

Problem with SecretSplitter/SecretCombiner when secretMessage starts with zeros

Open waldemarburaczewskiiq5 opened this issue 7 years ago • 5 comments

If byte array parameter secretMessage has zeros at start then reconstructed secret doesn't have those leading zeros. Example code byte[] secret = new byte[] { 0x00, 0x00, 0x00, 0x05 }; SplitSecret splitSecret = SecretSplitter.SplitMessage(secret, 3); IEnumerable<SecretShare> secretShares = splitSecret.GetShares(5); List shares = secretShares.Select(i => i.ToString()).ToList(); CombinedSecret combinedSecret = SecretCombiner.Combine(shares.Take(3)); byte[] result= combinedSecret.RecoveredBytes; //result length is 1

waldemarburaczewskiiq5 avatar Apr 28 '17 13:04 waldemarburaczewskiiq5

Has this been looked at yet? Not recovering the correct secret is a huge issue.

BlueRaja avatar Mar 15 '18 21:03 BlueRaja

Very old comment, and even much older project.

However, I can say that ssss-split and ssss-combine, on which this project is based, are not designed to fully support binary secrets of arbitrary length, though they do appear to handle leading zeros better than this project. Ultimately secrets are considered "numbers", and as such leading zeros are insignificant. This probably explains why leading zeros in the output are removed.

You must avoid leading binary zeros in secrets. Typically this is done by converting binary secrets to hex strings before splitting. In fact that is the way this program handles file-based secrets: it generates a binary secret to serve as an encryption key and converts it to a hex string before splitting. Another option is to prepend a non-zero byte to the secret and remove it after the secret is recovered.

That said, although this project was a very fine piece of work I'd recommend Bouncy Castle or an alternative for serious crypto work, as that library has significant support. Bouncy unfortunately doesn't appear to support Shamir's secret sharing, though.

lellis1936 avatar Sep 11 '19 15:09 lellis1936

While my previous comment is true, the loss of leading binary zeros is a bug that has a simple fix. I have a working modification.

lellis1936 avatar Sep 16 '19 16:09 lellis1936

I have a working modification.

Nice! Would you mind sending a PR? Hopefully @moserware is still around to look at it.

BlueRaja avatar Sep 16 '19 16:09 BlueRaja

I have done so. In the meantime my fork has the fix.

lellis1936 avatar Sep 16 '19 16:09 lellis1936