<< SHA1files | index | Astronomical Algorithms >>

SplitSecret

SplitSecret is a 32 bits console application that splits a file (the secret) into up to 255 shares. Unless all shares are available, there is no known way to reconstruct the secret from any combination of them.


SplitSecret implements a protocol described in Applied Cryptography
by Bruce Schneier.

See protocol description below.

Usage is :

   Usage : SplitSecret[/split /shares=NN | /merge] /secret=FILENAME

   Example :
   To split : SplitSecret /split /shares=3 /secret=OriginalSecret.ext
   To merge : SplitSecret /merge /secret=ReconstructedSecret.ext

   The shares are named SplitSecret.s01 to SplitSecret.sNN
   The parameters are case sensitive.

SplitSecret generates (/split) and reads (/merge) files named SplitSecret.sNN, where NN is the number
of the share in hex.

SplitSecret returns an errorlevel 0 if everything went OK, and a positive value otherwise.

SplitSecret is freeware.

Comments and suggestions are welcome : Christophe DAVID

Download SplitSecret.zip (+ 25 Kb - March 27, 2002)


From Applied Cryptography by Bruce Schneier, second edition,

3.6 Secret Splitting

Imagine that you have invented a new, extra gooey, extra sweet, cream filling for a burger sauce that is even more tasteless than your competitors'. This is important; you have to keep it secret. You could tell only your most trusted employees the exact mixture of ingredients, but what if one of them defects to the competiton ? There goes the secret, and before long every grease palace on the block will be making burgers as tasteless as yours.

This calls for secret splitting. There are ways to take a message and divide it up into pieces. Each piece by itself means nothing, but put them together and the message appears. If the message is the recipe and each employee has a piece, then only together can they make the sauce. If any employee resigns with is single piece of the recipe, his information is useless by itself.

The simplest sharing scheme splits a message between two people. Here's a protocol in which Trent can split a message between Alice and Bob:

(1) Trent generates a random-bit string R, the same length as the message, M.

(2) Trent XORs M with R to generate S.

        M[+] R = S

(3) Trent gives R to Alice and S to Bob.

To reconstruct the message, Alice and Bob have only one step to do:

(4) Alice and Bob XOR their peieces together to reconstruct the message:

        R[+] S = M

This technique, if done properly, is absolutely secure. Each piece, by itself, is absolutely worthless. Essentially, Trent is encrypting the message with a one-time pad and giving the ciphertext to one person and the pad to the other person. Section 1.5 discusses one-time pads; they have perfect security. No amount of computing power can determine the message from one of the pieces.

It is easy to extend this scheme to more people. To split a message among more than two people, XOR more random-bit strings into the mixture.

In SplitSecret, the random sequences are a mix of the output of two independent random generators, implemented in the ran2() and ran4() functions described in "Numerical recipes in C" (see chapter 7).

The quality of the random generators can be evaluated with the ent utility by John Walker.

The interested user can refer to KNUTH 1998 for more information on the subject.

The Cryptlib Security Toolkit by Peter Gutmann is also a very interesting source of information.

A "seed" must be supplied to initialize the random sequences generators. In cryptographic applications, the seed has to be random too, otherwise the whole random sequence could be "re-played" by an attacker knowing the original seed.

The current time is an easy value to use, but an attacker could guess when a sequence has been generated, and use brute force to determine the seed. Many other ways have been proposed like computing the time between keystroke hits, mouse position, disk fragmentation, network activity, etc.

However, most of these approaches are system dependent and/or require user input.

SplitSecret uses currently a seed based on the current time and the content of the input file (secret). As the secret is by definition not available to the attacker, and the seed used to generate the random sequences is partially based on it, this portable approach seems to be pretty secure. However, as always in this field, this should be taken with caution.

Help, comments and suggestions are welcome: write to Christophe DAVID .

<< SHA1files | index | Astronomical Algorithms >>


printer friendly view
PDF

   
Google
 
Web www.christophedavid.org