>> ------------------------------- >> XOR File Destroyer >> VERSION 2 >> File corruption made easy >> June 2011 >> ------------------------------- _______________ [ WHAT IS THIS? ] ################# XOR-FD is a utility for XOR-encrypting your files. XOR encryption is quite weak despite the cool-sounding name. Actually it is only as weak as the encryption key. If the key is as big as the file-to-be-encrypted, a phenomena called "one-time padding" will occur. One-time padding is unbreakable, because there's nothing to break. If you don't have the key there's no way you can un-pad the original data. (Remember: the key must be totally "unguessable" for OTP to happen.) _____________ [ THE LICENSE ] ############### See the file `copying.txt' which should be in the same directory as this file, for the license of this Software (which is the source-code, documentation, and other related data including the executables). _______________________ [ HOW CAN I COMPILE IT? ] ######################### First you need an operating system which is POSIX-compliant to a fair degree. I am unsure whether Windows fits the bill, it might. Then the chain for tools to compile it, GNU C Compiler (gcc) and the Make utility. On Windows you might want to try DJGPP or MinGW which are both ports of GCC and related utilities, or Cygwin which emulates a Unix environment. You can use `build.sh' or `build-nomake.sh' to generate the binary in the `build' folder. The "no-make" version does not use the Make utility. Or you can go inside the `source' directory and run the `make' command manually. _____________________________________________ [ WHAT ARE ALL THESE FILES AND FOLDERS ABOUT? ] ############################################### I decided to present them as a list, `+' (plus sign) marks directories, and `-' (minus sign) marks files. Additional text files (mostly "readme" files) could be found inside any given directories offering more detailed information on that specific folder's contents. + build = will contain executable program after compilation succeeded + docs = contains developer documentation + source = contains the actual source-code of the program + test = contains the tests used to ensure that components from `source' worked correctly - bugs.txt = lists found bugs and their fixes - build-nomake.sh = script which compiles the source code (`gcc' needed) - build.sh = script which automatically runs make utility (`gcc' and `make' needed) - clean.sh = script which cleans backup files, object files and executable files from `source', `build' and current directory - copying.txt = the license of this Software - readme.txt = TODO: figure it out yourself - ID file = allows for easy identification of the project through its name and version ______________________________________________ [ HOW CAN I GENERATE HUGE KEYS FOR HUGE FILES? ] ################################################ Either with a customised version of CrazySumForPasswords, or by using another file as the key. CSFP is why I started this project. You may find other XOR encrypting programs out there, with a fancy User Interface, or written in a fancy bloated way. My version is an attempt to simplicity and robustness. And interoperability with CSFP. ________________ [ USAGE EXAMPLES ] ################## Synopsys is as follows (the order of the arguments must be respected): (NOTE: `./' means that the file whose name it precedes is in the current directory.) program_name [file_to_be_encrypted] <[resulting_file] [file_used_as_key]> "stdin" Standard Input examples: echo "This text is the key" | ./xorcorrupt file.txt file.txt.xorred echo "This text is the key" | ./xorcorrupt file.txt IMPORTANT: In the second example above, the original file will be overwritten. Also, if you fail to provide standard input data, the program will jam. (Translation: don't start it with one or two arguments but without a pipe.) Filename example: ./xorcorrupt ABIGISOOFSOMETHING.ISO ABIGISOOFSOMETHING.ISO.x keyfile.txt ______________________________________________________ [ YOUR PROGRAM IS BLOATED AND YOUR STYLE IS UGLY. WHY? ] ######################################################## We do not (yet) have perfect computers. And if hardware can't be perfect, neither can software. My program is bloated in order to compensate for the imperfections found in the real world. Hardware failures can occur, which could prevent accessing a file. Hardware is also slow. The perfect, flawless way of reading or writing files would be by the smallest amount possible per cycle, that amount being one byte. But if you do that, you'll notice your program is painfully slow, because of hardware. So you need to use buffers, thereby increasing the complexity of your code. Finally, there are users who will try to take advantage of the real world imperfections of hardware and software. This means you need to add input sanity checking and validation. That's why my program is bloated and my style is ugly; error checking, performance tuning and sanity checking had to be added. More modern programming languages (and their compilers) partially take care of this, automatically. Which is why I'm planning to switch to C++. Oldskool C is good for quick projects, but wastes your time when quality is desired. Not talking about driver and kernel programming where C remains an excellent choice, but about small utilities. Such as this one... ___________________________________________________________________________________ [ WHEN WILL YOU CODE A GRAPHICAL USER INTERFACE BECAUSE I'M TOO LAZY TO TYPE STUFF? ] ##################################################################################### I probably never will. Do-It-Yourself, that's what open-source is about! There are dangers in coding a GUI. Not only are you relying on others' sometimes poorly designed framework, you also taint your code so that users may not be able to run or even compile your program in their environment... at least not without having to install a myriad of extra libraries they don't even need for anything else. I prefer a "self-sufficient" model. A second line of developers can "improve" my program into a dependency monster if they so choose; my hands are clean. UPDATE: A project named "wxWidgets" stirred up my interest. I guess it would be fun but I'll have to split the versions. _______________________________ [ HOW DOES THE XOR METHOD WORK? ] ################################# XOR comes from "eXclusive OR", and it's the logical operator which returns a value of True (one) if and only if operands are unequal, and returns a value of False (zero) if the operands are equal. All possible bitwise operations are: OP1 OP2 RESULT ------------------ 0 ^ 0 = 0 0 ^ 1 = 1 1 ^ 0 = 1 1 ^ 1 = 0 Two properties are evident from the table above. First, the order of the Operands is irrelevant, and second, if you XOR one Operand with the Result you get the other Operand. In other words, the XOR encryption is symmetrical. In practical terms, encryption cancels itself when applied twice (or an even number of times). And as you probably already know, digital computers store all information as a sequence of 1's and 0's. So until quantum desktop computers come along, we can all happily use XOR. __________________________________________ [ WHY USE XOR INSTEAD OF... ANYTHING ELSE? ] ############################################ The way I see it, the "real" ciphers out there are nothing more than glorified math tricks, adapted to a world in which genuine one-time padding is too cumbersome for practical applications... if you want to encrypt a CD image that way you'd have to store a padding information its size! Ciphers try to emulate the strength of one-time padding by using algorithmic padding. It's neat but fake, and sooner or later they will all be broken. I still have some reading to do on the subject, so who knows, maybe I'm just another ignoramus who's wrong. -RF