moserware / secretsplitter Goto Github PK

Changing the sample from

var masterPassword = HexadecimalPasswordGenerator.GeneratePasswordOfBitSize(bitSize: 128);

to

var masterPassword = HexadecimalPasswordGenerator.GeneratePasswordOfBitSize(bitSize: 256);

will exhibit the problem.

Could you please provide me a strong named DLL file?

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 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

There are two demonstrable flaws in the secret generation process (for files) and the secret recovery process (files & text secrets):

1. If a binary secret begins with 0x00, the generated shares are not valid, in that they do not recover the secret.
2. Secrets have about a .4% probability of generating shares which, though valid, do not result in recovery of the secret when input to the program's recovery process.

Case 1 is the more serious bug, because the program generates a binary secret to serve as the master password when encrypting files. The generated secret has a 1/256 probability of starting with 0x00, in which case the file cannot be recovered with the shares the program creates. There is no workaround to recover the file given only the encrypted file and the shares.

Case 2 behavior creates shares properly, but when input to the program cause the wrong secret to be produced. The shares themselves are provably correct, since they produce the proper output when input to another ssss implementation (ssss-combine, for example). Since case 2 occurs with about the same probability as case 1 (1/256 = .39%), this may be related in some way to the leading zero problem.

In the case of text secrets, the workaround is to use another ssss implementation to recover the secret (e.g. ssss-combine).

I am not aware of any workaround for case 1, since the shares themselves are invalid. This is unfortunate because it likely means there is no fix to the program which will enable it to recover a file encrypted using the damaged shares, nor will any 3rd party tool help. On the other hand, the program could be modified to prevent use of 0x00 as the leading byte of the master encryption key for files, which would at least in theory prevent the creation of invalid file shares in future use.

EDIT: Here are some samples of secret strings which reproduce the case 2 scenario (split into 3 pieces such that any 2 can be used to restore the secret).

    suqlxK5FeWDH
    DFXKY6cxehBW
    1XhbBgRYrQ0k
    exROzCAEFDqC
    ipLph6AT43TF
    PM5QuqUiGCT4

The shares created will properly reconstruct the secret in ssss-combine, but not in this Secret Splitter program. You can use the ssss demo program here:http://point-at-infinity.org/ssss/demo.html to see what the proper reconstruction of the secret looks like using shares created by Secret Splitter.

Interestingly, the shares created by the Web demo of ssss also fail to recreate the secret in Secret Splitter, resulting in the same garbled output value. Hence, the shares are valid, but the recovery process is flawed.