Very simple file encryption
Posted: Tue May 22, 2018 4:02 am
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!
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!