I have mentioned this in passing in another thread and I thought it might be useful to someone.

For my encryption needs I use PGP 8 but I am still using Win XP SP3 and PGP8 will not run in newer versions of Windows so sooner or later I will have to give it up.

I have often thought of the need of an encryption system which is secure, simple and does not rely on a particular software or operating system. For example, if you want to write something which is meant to be disclosed many years in the future (like a will) you would not want to use software which will probably no longer be supported then. So I set out to create a system which depends only on a simple process which can be done with simple tools available today and in the future with the same or other tools.

It is based on the concept of the one-time pad. In cryptography, the one-time pad (OTP) is an encryption technique that cannot be cracked if used correctly. In this technique, a plaintext is paired with a random secret key (also referred to as a one-time pad). Then, each bit or character of the plaintext is encrypted by combining it with the corresponding bit or character from the pad using modular addition. If the key is truly random, is at least as long as the plaintext, is never reused in whole or in part, and is kept completely secret, then the resulting ciphertext will be impossible to decrypt or break.

So, provided we meet those conditions it is unbreakable but note that the key is of the same length or size as the document to be encrypted and this makes it not very practical for encrypting very large amounts of data but it is very well suited for a few files which do not need to be decrypted often. Even though the strict rule is that the same key should not be used more than once, in practical terms we can use the same key for several files, specially if we are just trying to keep the files from ordinary people and not from the Government. The Government don't care what encryption you use because they just beat you up until you tell them what they want to know.

The simple encryption system I propose works using the exclusive OR (XOR) operation and only needs a simple program which can XOR two files byte by byte. I am using Nirsoft XorFiles which is tiny (16 KB) and does not require any installation. You just copy it to a folder and it does its thing. There are many other programs which can do the same thing and we can be quite sure that many decades from now there will be programs which can do this.

This program with GUI runs well under WINE and there is also scangoe xorfiles which is linux native but is only command line.

These programs are tiny and stand-alone and do not need installation. You can carry them around in a pendrive and use them on any computer.

Practice 1: Take a small file doc01.txt containing your passwords or other secrets and XOR it with the file img_01.jpg of your aunt Bertha blowing the candles at her 80th birthday. The result is a totally encrypted file which we will call crypt1. Now if you do crypt1 XOR img_01.jpg the result is the original doc01.txt.

Due to the properties of the XOR operation the order of the files does not matter. File01 (XOR) file02 produces the same result as file02 (XOR) file01.

Also, the three files (plain file, encrypted file and key file) are related in such way that XORing any two of them will produce the third one. This is one reason to not reuse a key. If somebody has access to an encrypted file and the corresponding plain file then they can get the key by just XORing the two files. If the same key was used to encrypt other files then they can be decrypted.

Again, the three files (plain file, encrypted file and key file) are related in such way that XORing any two of them will produce the third one. This means the two original files are both "keys" and "plaintext". If I do doc01.txt XOR img_01.jpg and produce file crypt01 then having this crypt01 file any one of the original two allows me to obtain the other original file.

Ideally the plain file and the key file have the same number of bytes but as long as the original key file is longer it does not matter because XORFiles will truncate the output file to the length of the shortest file of the two. So if you want to encode a file of 56,866 bytes you should use as key a file at least that long and the resulting encrypted file will be 56,866 bytes long. Then you can XOR the original plain file with the encrypted file and obtain the key file of exactly the same length but you can also use the original, longer key file.

You can use this technique to encrypt any type of file but if you want it to be useful a long time in the future you are safer sticking with file formats which will not become obsolete. A plain text file is pretty much guaranteed to be readable into the distant future but a proprietary format may require special software to open it and that software may no longer be around then.

Say you want to encrypt a file that requires four keys held by four different people who each have key01, key02, etc. So key01 XOR key02 produces tempkey0102 which is then XORed with key03 and the result is then XORed with key04 and this produces the final key to be used in decrypting the file.

Again, the main advantage of this system is that XORing files is something very simple which will be possible to do in the future regardless of OS or platform changes.

It is not suited to large volumes of data but can be very practical for single files.

As I said, any file can be used as key but, obviously, the best key files would have random data. Files with compressed data such as .jpg, .avi, .zip, .mp3, .mpg, .mp4, etc. make good keys. You can XOR several of these files for even better randomness.

A practical example: I needed to send credit card information to someone. I could have just sent a txt document but I scanned the card and XORed it with a photo of my aunt Bertha. I emailed the encrypted file. Then from a different email account and to a different email account I emailed the picture of my aunt Bertha. Now the receiver can XOR both files and obtain the original scan.

If the sender and the receiver already have shared files then it is even easier. Hey, remember that picture of us together in the Eiffel tower? Yeah, that one!

As I said, any file can be used as key and any file with compressed data will provide decent security but now I will go into ways of creating files with truly random data.

One first approach is to XOR several files of different types. That is very easy and will produce a more random key. Now, the headings of those files have a certain structure but when XORed should be quite random. If you want to be more sure just delete the first few hundred bytes of the file. So, take a jpg and an mp3, delete the first few hundred bytes of each and now XOR them and you have a pretty good key.

To edit files at the byte level I use XVI which has Windows and Linux versions. Personally, in Linux Mint I am running the Windows version under WINE because it was easier than figuring out how to install the Linux version. I'll get there some day.

There are many other ways of creating random data. You can record noise and compress it with MP3. You can search online for random data generators, noise generators, etc.

There is Quickhash which has the capability of generating random data even though the main function is computing hashes.

ETA: Sorry, the link to Quickhash was a brainfart. I meant to link to Ted's Tremendous Data Generator by the same author. Again, you can XOR random data with other random data and obtain double-barrel-random data.

Input a file to be encrypted. The file creates a (key) file of random bytes of the same size as the file to be encrypted. Then it XORs both files and the output is the key file and the result of the XOR operation. So you have two files which when XORed produce the original input file.

Maybe someone with programming skills can try it. I am not such a person.

A drawback of this encryption system is that it duplicates the amount of data. An advantage is that it does not require special software as XORing files is extremely simple.

There seems to be a bit of a meta-issue though. You in this setup generate a per-source key. In order to decrypt the encrypted file you need to keep that key around securely if for local use, send it securely if for remote. Given per-source and as large or larger than source why not just keep/send the source itself securely? If moreover you tweak things with a single/pre-shared key, bigger than any to be kept/send file, you do away with resistance to cryptanalysis: a, say, "e" xored with the same key byte becomes the same encrypted byte each time: two or more encrypted files will quickly show patterns.

There seems to be a bit of a meta-issue though. You in this setup generate a per-source key. In order to decrypt the encrypted file you need to keep that key around securely if for local use, send it securely if for remote. Given per-source and as large or larger than source why not just keep/send the source itself securely?

The security is in dividing the file in two. Suppose I have a file where I keep my passwords. If I keep it in my laptop and the laptop is stolen then the file is compromised. If I keep it in a pendrive and the file is lost then the file is compromised. If I keep one half in the laptop and the other half in the pendrive then losing one file does not compromise the data.

Another example I gave is where you want two or more people to cooperate in order to get to the information. I can write my will and encrypt it and give the key to my lawyer and the other file to my family. And I know that twenty years from now there will be no problem XORing the two whereas I know PGP running on Windows will be quite difficult to get to work.

Another case is where you use two different channels to send the "half-files" or where you already shared the key file with the receiver of the encrypted file.

If moreover you tweak things with a single/pre-shared key, bigger than any to be kept/send file, you do away with resistance to cryptanalysis: a, say, "e" xored with the same key byte becomes the same encrypted byte each time: two or more encrypted files will quickly show patterns.

I.e., not so sure about this...

I already mentioned you don't do that. And I already mentioned this is not a solution to important encryption needs nor is it a replacement for PGP. It is a strong encryption solution for a one time need for someone who does not use encryption software.

It does what it does and it solves what it solves. No more but no less. No, it does not vacuum the floor either.

TrueCrypt has 3 types or versions. One is Linux only, one is windows only, what you want is the dual purpose version which encrypts and decrypts the same way in both windows and linux. VeraCrypt is newer, but I don't know if it offers similar dual OS encryption method.

<Sigh> I guess it's too much for me to ask that people read and understand the point I am trying to make before they post.

Yes, I know full well that there is plenty of encryption software out there. Duh!

The point of what I am proposing is that it does not require any special software or OS. The XOR operation can be done easily by anything which might exist in the future and does not rely on any software or OS in existence today. In the worst of cases it could be done with pencil and paper. That is the entire point of this so proposing encryption software specific to an OS in existence today does not really meet the goal of what I want to do.

Mentioning something like a7crypt which is specific to some flavor of Linux and has several dependencies really misses the point by a very wide margin. That is exactly what I am trying to avoid.

The whole point is that my system "subdivides" the clearfile in two cryptofiles which are unusable separately but can easily be combined without any specific software, with something which can be written in a few minutes in any programming language which may exist in the future or which could even be done with pen and paper. That's the point!

OK, you seem concerned with password files. What I do is use double encrypted zip files for those. They will work in future on any new OS that comes along I'd think. You can right clk on a group of files in linux file managers and choose to put into encrypted zip file. You can then do it again using a second password for the zip file. Use "compress" and then will have chance for other options which will allow encrypted password protected if you wish.

a7crypt is pretty old software that doesn't need installation and runs executable in any linux.

Even if it ran in every Linux machine today it means it runs on something like 1.5% of all computers. Taking into account dependencies and whatever problems may come up the number is lower than that. And that is today. In twenty years it probably won't run on anything because whatever it depends on no longer exists. I mean touting a Linux-only program as an example of world-wide compatibility does not agree with the way I see the world. YMMV.

I guess people are more interested in threadshooting than in actually discussing what I presented so I guess we might as well just leave it here.

I guess people are more interested in threadshooting than in actually discussing what I presented so I guess we might as well just leave it here.

If that's also to me I more wonder what's left to discuss. I originally noticed this not being useful for (potential) personal encryption uses but queried on it you presented valid general uses, e.g., spreading a sensitive file over USB-stick and HD. So, sure. There's probably enough to be said about entropy of a general JPEG and all, but that's the kind of thing only crypto-fans enjoy. Generally, the system appears valid and appears to have uses. So, what do we discuss?