SplitCrypt is a demonstration of an approach to data privacy which works by creating two dependant copies of a file which are not useful until recombined. If one of the files is stolen, it is not useful to an attacker unless the other file is also stolen.

SplitCrypt has been implemented as a Java program (see below), but the underlying concept is quite simple.

This approach could be used to support a secure data transfer strategy. Note that SplitCrypt will provide only privacy to protect the data from theft. It will not provide integrity from malicious modification en-route (although such modifications may be unpredictable to an attacker, it is possible for the attacker to inject data by modifying the same bytes in both halves). End points should compare checksums and use other methods to detect tampering. SplitCrypt therefore does not provide repudiation, if one of the halves is modified then there is no proof that the output is the same as the input: use secure authentication for this.

If in doubt or unqualified, consult a security expert.

(Note that although the program theme is slightly related to my research, it is not an output from the research project.)

Example Application (Secure Disk Transfer)

• Create an archive file.
• Split it using SplitCrypt.
• Produce checksums for the original and each half.
• Burn each half onto an individual disk.
• Send the first disk.
• The recipient calls to let you know it has arrived, check the checksum and packaging.
• If the disk has not arrived, has been opened or the checksums disagree then destroy both disks and start again.
• Send the second disk.
• Now check the checksum of the second half.
• Combine the files.
• Check the final checksum.
• Use the archive.

Checksums and notifications should be sent via another means, such as telephone. Although the word checksum is used a lot here, there will be significant benefits to using a secure hash function instead.

This process only provides secrecy if nobody has been able to copy the disk en-route. You could use tamper evident packaging. If one of the disks is lost or has been copied, destroy both disks and start again.

Checksums only protect against accidental damage. An attacker might be able to make changes such that the same checksum is generated. For better security you could use digital signatures or symmetric message authentication codes (MACs).

The basic idea is that if an attacker is able to acquire the first disk, then it will not arrive. Thus the second disk is never sent and the original data cannot be recovered. This is quite an assumption, hence the need for tamper evident packaging.

A few important notes:

• If you delete the input file and subsequently lose one of the output files, you will be left in the same position as the attacker. Don't erase the input file until both disks have arrived at the destination and have been verified.
• If you run the program to split a file, it will generate different output halves each time (this is by design). Don't use the program more than once unless you need to start again.
• Don't mix up halves. They won't work together.
• Be careful if using to make backups: label them properly and test them.

FAQ

What are the internal workings?

SplitCrypt splits files using a form of stream cipher. A stream of bytes are generated using a pseudo-random number generator (PRNG) which is seeded using the date. A PRNG is not truely random as computers cannot be random. Use of a seed, combined with a user key helps to avoid prediction by an attacker.

The stream is applied to the input file using the XOR operation, producing one of the output halves. The other output half is the stream itself. Both halves are now seemingly random.

On arrival at the other end, the XOR operation is used again with both output files to produce an identical copy to the input file. Note that it is not necessary to use a PRNG or to have the user key for this operation: those facilities were merely used to produce a random stream.

Why is a key used?

Random number generators are not truly random and rely on algorithms that might be predictable. The key prevents this problem by adding additional variables that are not generated by the computer.

Once used, the key is not required and can be destroyed. If the key is left in a command cache it might partially assist a cryptanalyst, so it should be deleted. If you used a Linux console (ie. Bash) this can be achieved by using the 'history -c' command.

Is it safe?

To provide authentication, no. This requires digital signatures, but is obviously optional.

The process does not work if the data is copied en-route. It relies on the attacker having partial data. Tamper evident packaging should be used so that the receiver is aware that theft has occurred. In this case, just delete the outputs and run the program again. Then send the new first disk.

Although 'one-time pads' (random stream) offer 'perfect' security, they must be generated in a truly random way. Computers are not capable of this, unless connected to a peripheral that can detect random noise (such as nuclear decay). Therefore there is a risk of cryptanalysis on the half which has been produced using the input data.

Usage

SplitCrypt is implemented as a Java program. It is not required to recombine files as recombination is a simple XOR operation. The program, however, supports both operations.

The program is currently quite slow and will eventually be re-implemented in C.

java -jar SplitCrypt1.jar split filename key

 filename   The file to be split, the program will produce:
             filename.part1
             filename.part2

 key        The psuedo-random number generator is seeded
            with the system clock and each output is XORd
            with the next byte of the key. The key should
            be random and does not need to be retained.
            Infact it should never be retained or reused.

java -jar SplitCrypt1.jar combine filename1 filename2 filename3

 filename1  The first half of a split file.

 filename2  The second half of a split file.

 filename3  The combined output file.

Author

Tony Chung

Copyright

Provided as-is with absolutely no warranty. The code may be used for any legal purpose. The author accepts no liability whatsoever. Play nicely.

Download

Download - ver 1 - Java JAR - 8KB

MD5: 88cd1636ee3258da4e130cef2cfc9dc3

< Back to Downloads.