How to Create Encryption
by TheCrow
As hackers we invariably have data stored in various places that we don't want people to see. Maybe you are paranoid that Microsoft is secretly reading your hard drive, maybe you think the feds are after you, or maybe you run a BBS or web page that has some, well, gray area type of information on it.
An even more common situation occurs when you are fooling around with various networks, and maybe want to store some files on them. Maybe the Secret Service is planning to roam through your hard drive!
In all of the above cases, it would be nice if you could keep everyone out of them except you. Current strong encryption systems are all public-key systems, which are good, but are not very convenient for local file encryption.
Second, recently the government has been calling for back doors to be built in to these encryption schemes, so that the authorities can get into any file they want. Not only does this significantly reduce the security of the scheme, but it defeats the purpose of hiding the files from the feds.
So we need to make our own...
Lotus has already compromised their Lotus Notes encryption in this way, and the government Clipper Chip standard threatens to make everyone's hard drive an open book for our beloved federal government.
First, some no-brainer stuff for the uninformed. Encryption programs use a key to encrypt data. Every single piece of data in a file is stored as a byte. Bytes can be a value between 0 and 255. The key that someone enters is also going to be a string of bytes. The basic idea is to use the values from the key to change the contents of the file so that it can only be restored with that key.
Keys should be able to consist of any byte value, letters, numbers, and you can even use the Alt-### codes to get up there in the higher byte values.
A good key will always be eight characters or more, and will not simply be a word or name. A dictionary lookup can break those types of keys very easily. (Some programs use large prime numbers as keys, but we'll get into that later.) Also, it is a good idea to have at least one or two characters that are very high-byte values (Alt-255, Alt-253) or something fairly large. This makes brute-forces impossible as long as your key is eight characters long or so.
What language should you write it in? If you want to try assembly, be my guest, but since it will invariably make heavy use of string handling, complex mathematical formulas, and file handling, C/C++ or Pascal are the best choices. Visual Basic will be far too slow to make anything useful, so don't even bother (I have tried, trust me). If you are developing for Windows, Delphi is god.
Writing an encryption program from scratch isn't easy; many things can be overlooked. The basic idea is simple: you read in a block of bytes from a file, encrypt them given a certain key, and write them back again. To make it good though, you need to go further. The first thing you must make sure is happening is that whatever formula you choose to use is resulting in completely random encrypted values.
In addition, you must make sure these values never repeat. A good way to test this is to make a file and fill it up with the letter "a", then encrypt it with the single character "a".
The encrypted file should be totally random and never repeat. Two more advanced measures for determining the randomness of it all is graphing the resulting byte values against the originals, and against the key characters.
You may notice patterns. If you do, get rid of them. Secondly, you can keep a tally of how many times you hit each byte value.
If you encrypt your test file of aaaaaaaaaaaaaaaaaaaa and get back 15 byte values of 132, that is bad.
You should notice a fairly even distribution. To check to make sure your algorithm isn't ever repeating is fairly easy. Just look at it. If anyone writes a program that can find repeating patterns of various sizes, email it to me. I'd like to see it.
The second thing you must accomplish is to make sure that a close guess of your key won't result in a partially decrypted file. For instance, if all you do is cycle through the byte values of the key, say, 2600Man and someone guesses 2600man, that person will be able to read 6/7 of the file! This is bad, because they can then just brute-force that last little character in about ten seconds. (Brute-forcing a password is where one quickly tries every key combination and checks to see if it works - a key over eight characters long makes this take millions of years). You have to do something with the key values that will result in a totally unique value. Just adding them up will help, but is not totally unique. Using the average is also good, but again is not ideal. Use a creative combination of a variety of methods. Experiment.
Now, your encryption program is pretty good, but has a serious fatal flaw. Fixing it is a real hitch. Let's say you encrypt a network utility called GLOBAL.EXE with an eight-character password. Eight characters would take forever to brute-force, so you figure you are pretty safe. Now, a hacker comes along and he (or she) is very well aware of the fact that every .EXE file starts with the two bytes, MZ!
Now, this person needs only to figure out what your algorithm is and he can find the first two characters of your key by running the algorithm backwards! Now that he has your key down to six characters, he can brute-force it in a matter of hours, or less if he has access to a powerful machine.
No matter what little tricks you use, someone will always be able to find out what your algorithm is. If not by disassembling it, they can do it by encrypting files and examining the output. (This is painful but people actually make hobbies of this kind of thing.)
In many cases, a hacker will know more than just what two bytes of your file will be decrypted. To prevent this, the big name encryption products of today use formulas that are very hard to do backwards (factoring large prime numbers). This is effective, but it's slow, and there is an alternative.
If you choose, you can figure out your own algorithm that is difficult to find the reciprocal of, but if you are like me, you aren't that good at math.
The alternative is this: Before you encrypt the file, pull in some random values. There are all sorts of fun ways to do this. Here is a list of possible things to try:
- The current time
- Amount of free disk space.
- Amount of free memory or max memory.
- Pick 100 random bytes from the file in question (this is a good one to use).
- Use the included random number generator.
- Let the user bash on the keyboard a few times and record what they bashed and how long it took them to bash it.
- All of the above.
You can do whatever the hell you want, as long as you come up with a big string of byte values that nobody would ever be able to have any prior knowledge about. If you choose to use the time, make sure that once you write to the file you alter its time attributes by a few minutes and seconds, otherwise someone can use a timing approach and figure out what the time was when someone started encrypting.
You want to have a string of at least 20 bytes to make sure nobody ever brute-forces it. I use 100 just to be extra safe.
Now, you should incorporate these random values in your encryption algorithm. If a problem arises, you cannot decrypt with knowing these values!
O.K., so we need to append these bytes to the end of the encrypted file! Another problem, anyone with the IQ of a rat will realize that they can just use the string of bytes and do the same old backwards algorithm thing and you are screwed. What can you do?
Simple, encrypt that string of bytes with a new algorithm that uses only the key. This way, when you decrypt, you first use the key to decrypt the string of bytes at the end (since this string at the end is totally random, a known plaintext attack is impossible), then you use the key and the decrypted bytes to decrypt the whole file. (Be sure to delete the extra bytes from the end of the file - this probably means copying the whole file over.)
Someone trying to crack your encryption must first decrypt the string of bytes at the end. Since you have worked so hard to make sure your encryption has no patterns, and since the original values are totally unpredictable, they can't! Your file is perfectly safe. If you manage to make yourself a nice program, remember that encryption technology is considered a munition by our beloved federal government, therefore exporting it is illegal, and yes they really do go after people on this.
If you don't program and would like a copy of the program I wrote, just email me. I have a DOS version and am working on a UNIX version as well (do hold your breath). I'll give the program out for free. If you want the source code, well, that is another story. If I get any response from this article, I may write another with some specifics on certain aspects if anyone is confused.
The author can be reached at: thecrow@iconn.net