Using the HardEncrypt Package


For more information about HardEncrypt and other HardenedCriminal open-source software projects, visit the HardenedCriminal website at http://www.csuglab.cornell.edu/Info/People/jcr13/HardenedCriminal/
For questions, comments, and bug reports (or if you're having trouble getting to the website), email jcr13@cornell.edu



The HardEncrypt package contains three pieces of software. All three are needed if you're planning to encrypt and decrypt files. However, if you're only on the decryption end, HardDecrypt is the only necessary piece of software.

All three programs run in a command prompt user interface. Only a keyboard and a terminal are necessary to use this package. This implementation option was chosen with portability and convenience of use in mind.

The three included programs:
GenKeyFile -- generates a series of key files from a user-provided seed file
HardEncrypt -- encrypts a file using a key file
HardDecrypt -- decrypts an encrypted file using the same key file



*** Generating Key Files ***

Before you encrypt anything, you need a key file. HardEncrypt uses a key file that you provide to encrypt files. HardEncrypt uses a symmetric encryption scheme, which means that the same key file is used to both encrypt and decrypt a file. This implies that anyone who has a copy of your key file can decrypt your files. Keeping your key files in a safe place is of utmost importance, and destroying old key files after you're finished using them is highly recommended. But, as long as no one can get a copy of your key files, no one can read your encrypted files.

Because HardEncrypt uses a one-time pad encryption scheme, the key file you use to encrypt a file must be at least as large as the file itself. The best key files are filled with an even distribution of completely random numbers. Pseudo-random numbers (those generated by random number generators) don't cut it. Also, a key file with patterns or holes (large sections containing a single, repeated value) can degrade the strength of the encryption.

Each encrypted transmission that you send must be encrypted with a different key file. Using the same key file for two different messages can open your messages up to attack. In other words, if you reuse a key file, the HardEncryption of your same-key messages can be cracked.

So, not only must you keep your key files safe, you must also keep them well organized. You must make sure that you never use the same key file twice. We recommend keeping a series of numbered key files to be used one at a time. After each key file is used, it can be deleted. If you stick to this routine rigorously, you will never make an error that may weaken your encryption.

GenKeyFile is a utility for generating a series of good, solid key files for HardEncrypt. Actually, any file can be used as a key file, and GenKeyFile doesn't need to be involved in the process at all. But most files don't make excellent key files: for instance, most files have headers, and these headers are often the similar for all files of the same type. An attacker would simply have to figure out what kind of file you used for your key to decrypt at least the first portion of your encrypted file.

To use GenKeyFile to make key files, you must provide a seed file. GenKeyFile mixes a user-provided file up in a pseudo-random way to add a layer of extra security. If the file has a header, for instance, it will be mixed in with the rest of the file data. GenKeyFile also pads the file with pseudo-random values--an extra, though thin, layer of added security.

From a single seed file, GenKeyFile can output a series of numbered key files. These can be used to encrypt a series of future messages. GenKeyFile uses data sequentially from the seed when producing the key files. In other words, the key files produced each contain a unique portion of data from the seed (none of the seed is repeated between different key files).

During a single execution of GenKeyFile, each key file produced in the series must be of the same size (e.g., 10 files each 100K in size). The seed file you provide must be at least as large as the total size of the files you'd like to produce in a single GenKeyFile execution. For example, if you want to produce 10 files that are each 100K in size, you must use a seed file that is at least 1000K. Aside from the size requirements, any kind of file will work as a seed file, as long as a potential attacker cannot get a copy of it.

Though any file will work, some seed files are much better than others are. Files containing truly random, irreproducible data are the best. For this we recommend an audio file of some sort, one created by the user and impossible for an attacker to reproduce. A novice user can simply record speech into a microphone for as long as necessary to make a seed file of a required length. For an in-depth discussion on making the ultimate seed files, refer to the "Tips for good key seed files" section.

After you have a decent seed file, place it in the same directory as GenKeyFile and then launch the GenKeyFile program. The program prompts for the following user input:

the number of key files to produce
..(how many numbered key files you want GenKeyFile to output)
the postfix name of the key files
..(entering "myKey" will produce a series of key files like: 0myKey, 1myKey, 2myKey,...etc.)
the name of the seed file
..(the name of the input seed file you want GenKeyFile to use)
the size of the key files in bytes
..(the size of each key file you want GenKeyFile to make)

After you enter the required values, GenKeyFile generates a series of key files from your seed.

You should use a different seed file for each set of keys that you generate, and destroying a seed file after using it is recommended. If attackers get a copy of your seed file, they can potentially recreate your key files.

After making a series of key files, you can use them for a series of transmissions. Destroying a key file after it has been used is recommended, and reusing a key file will reduce the strength of the encryption drastically. You might want to make a separate series of key files for each person with whom you want to exchange encrypted files. If more than one party has copies of the same key files, then they can potentially intercept and read files that they weren't supposed to read. If all parties you exchange with are trusted by you and by each other, then a single series of key files may be sufficient.

Of course, if the recipients of your encrypted files are going to be able to decrypt and read them, they need to have copies of your key files. The reason you're interested in encrypting files in the first place is probably because you fear that your transmissions aren't secure. Thus, you can't simply send your message recipient the key files by the same means you'll use to send the encrypted files--an attacker who can intercept a message can also intercept your key files. You need to find a completely secure way to get key files to your recipient. The most secure way is a face-to-face hand-off on floppy disk (or on Zip disk if a floppy is too small). If you can trust your recipient (and if you don't get robbed during the hand-off), then this method is foolproof. A less secure, but more convenient, method is to send a disk by mail. If someone is already intercepting and reading your mail, then you're really in trouble. But, assuming your situation is not this grim, the mail service is a lot more secure than electronic transmission, especially since mail contents aren't monitored by anyone in the same way that the NSA monitors all electronic transmissions.

If you want to send secure messages to a single party for an extended period of time, you'll need to give them copies of a very large series of key files. If most of your transmissions will consist of text messages, you may want to set a ceiling on how large each message will be. If you anticipate exchanging 1000 messages within the next year that will each be less than 100K in size (very large for text messages, actually), then you could simply burn a series of 1000 keys onto a CD for the hand-off. Your secure communications would be set for the next year. Though this is less convenient than the public-key model, a yearly face-to-face meeting is a small price to pay for excellent security (and meeting them in person once in a while will assure you that they haven't been killed off and replaced by an agent netting your none-the-wiser transmissions).

There are a few potential problems with the above 1000-key system. First of all, if one party makes a mistake and uses the same key twice, at least some of your messages will be potentially endangered. However, if the same key is used twice by one party, the other party will recognize the error: when they try to decrypt the message with the correct key, it won't work. They'll have to go back one key in the series to decrypt the message. Also, a problem could occur if both parties try to send a message using the same key at the same time. Normally, with a back-and-forth (or one-way) communication style, this won't happen: party 1 will use key 1 to send the first message, party 2 will use key 2 for the reply, party 1 will use key 3 for the next message, etc. If one party breaks this rhythm and sends two messages in a row, problems could result if the other party is trying to respond to the first message at the same time.

This can be avoided by keeping two series of keys, one for party 1 transmissions and another set for party 2 transmissions. Both parties will have both sets, but they will use different sets when sending and receiving. Messages could be labeled to denote which key number was used to encrypt, though deleting each key after using it is wise to prevent key reuse. With this system, you could burn a CD with 500 keys for each party.



*** Encrypting Files ***

After you've generated a good series of key files and given a copy to your recipient, the hardest part is over. Encrypting files is a simple process by comparison.

Before encrypting a file, you should make sure that it is "ready" for encryption. On most platforms, all files are suitable for encryption. However, on the MacOS platform, files have two forks (data and resource) as well as a file type and creator type. The resource fork is discarded during encryption to maintain platform independence. If you're using a Mac, the file you want to encrypt may depend on data in the resource fork, and if you're trying to encrypt an application or other special file type, the file may not work at all without the resource fork. On Macs, all "special" files should be archived before encryption using either Stuffit or a .ZIP utility. This technique is also useful on all platforms to encrypt a group of files together. On any platform, to determine if a file needs to be archived before encryption, try encrypting and decrypting the file. If the decrypted file is still usable, then no archival is necessary. In general, most data files on most platforms shouldn't need to be archived before encryption. Text files are almost always okay. However, if you want to maintain the file type on a Mac, then archival is necessary for all files before encryption.

When you have a file that's ready to be encrypted, place it and the key file in the same directory as HardEncrypt and launch the HardEncrypt program. The program prompts for the following user input:

the name of the file to encrypt

the name of key file

the name of output file

After you enter the required values, HardEncrypt encrypts the input file with the key file.

If you're planning to transmit the encrypted file through some medium that cares about the difference between text and binary files (email, web, ftp, etc.), it's important that you transmit the encrypted file as a BINARY file. If you're on a platform that cares about file extensions, it may be helpful to name your encrypted files with and extension of .BIN. FTP clients and email programs may recognize this file extension and send the file as binary automatically.

After encrypting a file, it is ready to be sent through an insecure medium.

To decrypt the file, the recipient needs both the encrypted file and the key file. A file name will also be of use to the recipient, especially if the file is not simply a text message. The encryption and decryption process does not preserve the file name, only the file contents.



*** Decrypting Files ***

When you receive an encrypted file that you have a key file for, decrypting it is a simple process.

Place the encrypted file and the key file in the same directory as HardDecrypt and launch the HardDecrypt program. The program prompts for the following user input:

the name of the file to decrypt
..(the name of the encrypted file)
the name of the key file
..(the name of the key file to decrypt with)
the name of the output file
..(the name of the decrypted file you want HardDecrypt to output)

After you enter the required values, HardDecrypt decrypts the input file with the key file.