It is often said that the only people who need privacy programs are those with something to hide, like criminals or subversives. This is nonsense: if you would keep a paper document locked up in a filing cabinet, then its computer equivalent should be subject to a similar level of security. This is just basic common sense. I wrote KCrypt to protect examination papers that I was preparing on my PC from unauthorised access by students, and for other confidential documents like letters of reference. Before I wrote this program, I would have kept these documents on floppy disks locked in my desk, which is not very convenient.
However, KCrypt is not intended for use in communications (e.g., sending files by e-mail) as it uses a `symmetric' encryption scheme (that is, the same key is used for both encryption and decryption). There are far better tools for use in communications, such as PGP. The relationship between PGP and KCrypt is described in the `FAQ' section below.
KCrypt processes files `in place', that is, the encryption process replaces the plaintext file with an encrypted version, removing all trace of the original file, while the decryption process has the opposite effect. In encrypting, some trouble is taken to ensure that no part of a plaintext file is left on disk or in the computer's memory after encryption. Thus you can encrypt a file in confidence, knowing that the unecrypted version is gone forever (until you decrypt it).
KCrypt can process large batches of files in one invocation, and knows to avoid encrypting files that are already encrypted, or decrypting files that are not encrypted. This means that whole directories of files can be maintained in an encrypted state; it is easy to decrypt one or more files to work on them, then ensure that all files are encrypted by running KCrypt on the whole directory.
kcrypt -e *
encrypts all the files in the current directory that are not already encrypted, while
kcrypt -d fred
decrypts the file `fred'. In both cases, no extra files are created; the new file replaces the old one.
In all operations, KCrypt displays a status report, including the designation `pass', `skipped' or `fail'. To attract attention to potential problems, these are displayed in colour on suitably equiped hardware (provided you are using the colour version of KCrypt; a non-colour version is available for use on displays that behave oddly when sent colour information). `Pass' messages are displayed in green, `skipped' in orange and `fail' in red. The designation `skipped' means that the operation requested was not appropriate for the files specified. For example, KCrypt will not encrypt a file that is already encrypted; this is not considered an error but a skip. However, attempting to encrypt or decrypt a non-regular file (e.g., a device or directory name) would be considered an error and marked as `fail' (and displayed in red). In general, messages marked in orange may need attention, messages in red will need attention.
However, for an unauthorised person to use a recovery service he would first have to steal my computer, dismantle it, and send the disk away. Even then I believe the chances of recovery are fairly small, even with the non-paranoid method of deletion. Moreover, using paranoid mode increases the time taken by all KCrypt operations. Personally, I don't use it, because I'm not that paranoid.
Direct cryptanalysis
At present the evidence is that the encryption technique used by KCrypt is extremely robust; not because I designed it, but because world-leading cryptographers did. There are probably stronger schemes available to governments and the military, but IDEA seems to be as good as any non-military encryption, and much stronger than DES (Data Encryption Standard), the scheme most widely used until recently. In short, it is unlikely that, unless your documents are of interest to national governments or security agencies, there is any profit in an unauthorised person trying to `crack the code' directly.
Weak keys
KCrypt is able to detect and reject keys that are cryptographically weak, that is, combinations of characters that research has shown lead to a less robust encryption. However, it has no way of detecting keys that are weak in the sense of being easy to guess. For example, if you use `secret' as your password, then the best encryption techniques in the world will not help you. It also cannot prevent someone looking over your shoulder as you type the password.
Snoopers and Trojans
Any cryptographic scheme can be compromised by a knowledgeable person who has access to your computer. For example, he could install a piece of software which recorded every keystroke you typed, and saved them on disk. When you have left the office, he could then collect the file of keystrokes and sift through it for likely keys and passwords. Having extracted your encryption key he could use it to decode your encrypted files.
A knowledgeable person could even replace the KCrypt program file with another that looked just the same, but did something completely different. It might, for example, implement an encryption scheme that looked good, but was weak enough to crack, or responded to keys other than the one you know about.
If you think this type of attack is possible, the only way to prevent it is to make sure your computer is switched off and protected with a power-on password whenever you are away from it. The effectiveness of snoopers can be reduced if you don't generally use the same key for all your encryption operations. If you think your version of KCrypt might have been modified, you can generate an MD5 hash code for the program file and check it against a value obtained from the author (contact details are at the end of this document).
Temporary files
Many word processors and all Web browsers create `temporary' files to hold working data, and I guess most other major software packages do likewise. Some or all of your document will be in the temporary file. Software that uses temporary files should delete them afterwards, but they don't always, and they certainly don't if they crash. Moreover, they only delete temporary files at the operating system level: they don't wipe them as KCrypt does. This `insecure deletion' will generally only be a problem until the operating system gets round to reclaiming the space used by the deleted file, but this could take several days even on a busy computer, and years on an idle one. If your word processor crashes while editing a sensitive document that you intend to encrypt, it is worth having a look around for stray temporary files. In addition, it is worth wiping all the files in your system's temporary areas on a regular basis if you are using encryption. Regular defragmentation of your hard disk will also help to reclaim disk space used by deleted files, and therefore speed their demise.
Backup files
The problem with backup files is exactly the same as for temporary files, as discussed above. However, most software that creates backup files can be told not to; if this facility can't be disabled, you will need to find the backup files and wipe them yourself.
File transaction logging and roll-back
This is a big security problem on some networked file systems. What happens is that the network operating system detects changes to files and saves the old version somewhere. The old version can be restored using suitable system administration tools. What this means is that, when you encrypt a file and replace the unencrypted version, the unencrypted version is not really overwritten, it is stored somewhere on a file sever in case you ever want it again. This completely defeats the purpose of encryption. I understand that Windows NT servers are able to do this, and Novell Netware certainly can. If you want to keep encrypted files on a network file server, consult your system administrator about whether it stores old versions of files before you trust it.
Incomplete operation
KCrypt encrypts each file into a temporary file, then overwrites the plaintext with the encrypted version. If, for any reason, it is unable to complete this operation, the plaintext will probably be left as it is. A similar outcome will result if operation is interrupted during decryption. In either case, a plaintext file will be left in place that ought to have been overwritten.
In practice it is unlikely to be a problem; if KCrypt is unable to complete its operation it is likely to be because of a reboot or power down, and it will be obvious that something needs attention. In a few cases KCrypt has to create a plaintext temporary file; if there is a crash or reset and KCrypt was in the middle of an operation, it is worth checking for unexpected temporary files in the directory in which it was working.
KCrypt blocks hangup, terminate and interrupt signals when it is doing something that really ought not to be interrupted (such as copying a file or erasing a temporary file). When these signals are detected KCrypt should finish gracefully at a point where no stray files are likely to be left. However, it is not possible for a Unix process to catch a `kill' signal, or to prevent a shut-down.
Memory and swap traces
When a process finishes, the memory it occupied may be allocated to another process. This process could, in principle, scan for traces of the previous process and find keys or plaintext left in its memory space. In addition, a system-level (root) process may be able to examine the memory space of other processes. During the execution of any process, the memory may be swapped out to disk to make room for other processes. Again, traces of the process' memory space may turn up in the swap device. These issues are a theoretical problem, but are highly unlikely to be a problem in practice. As far as possible, KCrypt limits the time that keys and plaintext are resident in memory and, on termination, all these areas are cleared to zeros.
2. KCrypt only prompts for one key per invocation, regardless of the number of files that are to be processed. The same key will be applied in each operation. This means that it is sensible for all the files that are normally encrypted and decrypted together to have the same key. If you attempt to decrypt a group of files with the same key, but they were encrypted with different keys, no harm will result. You can repeat the decrypt operation as often as necessary, giving different keys, until all files are decrypted.
A. KCrypt is designed to be `unbreakable', that is, to use the best cryptographic techniques available outside of the military. It is extremely unlikely that standard `code breaking' techniques could be used to decrypt your files without the appropriate key. Of course, it is not impossible that this will happen in the future, especially as computers become more powerful. However, this is true of any encryption scheme, and there are currently some very weak ones available commercially. For example, I understand that it is now possible to buy a program that cracks the encryption schemes used by Microsoft Word and WordPerfect in a fraction of a second. KCrypt has to be an improvement on this, and is. KCrypt uses by default the IDEA algorithm, which has to date withstood all known attempts to crack it. IDEA is one of the class of encryption techniques that are `algorithmically secure'. This means that the security is provided by the process itself, not by secrecy about how it is implemented. The IDEA alogorithm is well-publicized and has been the subject of much research. Because this algorithm is used by PGP, it has received a lot of attention from cryptanalysts, and if there were any obvious weaknesses they would no doubt have come to light by now.
The major weakness of KCrypt, as it is of other programs of this sort, is inappropriate use. For example, you may use it to encrypt a file produced using your word processor, but forget to encrypt the backup copy it made. These issues are discussed in the section `vulnerabilities' and you should read this very carefully if security is really important to you.
Q. How do I know I can trust this program at all?
A. I distribute KCrypt because I needed it for myself, I like to be helpful and I can't legally sell it. I trust it because I wrote it, but why should you? How do you know that it doesn't leave `back doors' by which I can decipher your secret files? How do you know it doesn't transmit your secret files to me over the Internet? The simple answer, of course, is that you don't! Of course, this applies to any encryption product you buy or obtain free-of-charge, not just this one. If you want to be really sure you know what KCrypt is doing, you should get the source code and compile it yourself. You should be able to find the source code in the same place as you found the executable program, if you haven't already. You can then check the implementation of the IDEA algorithm in KCrypt against the sample code provided by the original designers (see references below).
Q. Why do I get the error message `current directory is not writeable', even when I am not encrypting or decrypting files in the current directory?
A.
KCrypt requires the current directory to be writable. It will use the current
directory for storing temporary files which are created during encryption and
decryption.
This strategy is followed because I felt it made sense to avoid using public
temporary areas, as there is a chance (I hope an outside chance) that the
program could crash and leave unencrypted data in the public area. This would
be a Bad Thing. Of course, I hope the program does not crash in use, and even
if it does this does not necessarily mean it will leave plaintext in view, but
it is better to be safe than sorry. Using the current directory means that it
is more likely that the user will spot an errant file if the program does
happen to crash, and therefore be able to delete it.
Q. How does the program know who has encrypted a file, and is this information trustworthy?
A. KCrypt uses environment variables LOGNAME and HOSTNAME to determine who is encrypting a file. These may not exist and, even if they do, they may not be meaningful. This does not affect the operation of the program at all, but the file info display will give nonsense information for the identity of the person who encrypted a file. This facility is provided for convenience, not as a security measure.
Q. Why do I need to enter a key just to get information about the file?
A. Because this information is itself encrypted in the file. There is no information about an unencrypted file that could not be easily obtained using the `ls' command, or whatever. KCrypt's `info' function provides information about encrypted files only. Specifically, it reports the original filename of a file whose name has been mangled. This information must be encrypted, otherwise there is no purpose in name mangling.
Q. Why does KCrypt ask for a key, even when I have accidentally specified a non-existent file and there is no way it could be processed?
A. KCrypt will ask for a key before starting any encrypt or decrypt operation. It will do this even if the specified files do not exist, or are impossible to read. The reason for this is that KCrypt is designed to operate on many files at a time, and a particular operation may fail on one file and succeed on the next. Thus the key has to be established first. It would be possible to update the logic such that it behaves differently if only one file is specified, but this is a serious drag, and makes operation inconsistent.
Q. What is filename mangling?
A. To further protect files from attack, KCrypt can conceal the original names of files. If your files are clearly named, then an unauthorised intruder knows at least which files to attack. If they are not, then he or she has to attempt to decrypt a heap of files to be sure to get the interesting one. Mangling should be applied after encryption, and unmangling before decryption, as explained below.
The mangled names are randomly generated, but have the prefix `KCR' so that they can be identified as mangled. To find out the true name of a mangled filename, use `kcrypt --info [filename]'
Q. How should I use mangling and unmangling?
A. Some care needs to be taken when using the mangling and unmangling facility for filenames. When an encrypted file is stored, its original filename is stored along with it. If the name of the file is changed (using the `mangle' function or otherwise) the original name can be restored. However, if you apply name mangling to a plaintext file (which is allowed), there is no way to restore the original filename (because it is not stored in the plain file). So when using mangling and encryption, the order of operations should be:
encrypting: mangle then encrypt
decrypting: umnangle then decrypt
Note also that for encryption it is perfectly valid to specify both mangle and encryption commands on the command line, like this:
kcrypt --encrypt --mangle [files]
(which can be shortened to `kcrypt -em [files]'), but the same approach must not be taken on unmangling and decryption. The is because the first operation (unmangling) changes the filenames, so that when the second operation (decryption) starts it will not be able to find the files to decrypt. So the correct sequence of operations for decrypting and demangling is:
kcrypt --unmangle [files]
kcrypt -- decrypt [files]
where `files' may not be the same each time.
Q. What information is provided by `KCrypt -- info'?
A. The format of information provided by `kcrypt --info' is as follows
current_filename: original_filename -- encypter_username@encrypter_host -- original_size -- date_and_time
Note that the username and hostname will only make sense if the operating system provided that information in the HOSTNAME and LOGNAME environment variables when the encryption was done.
Q. Can KCrypt read decrypt files encrypted by PGP, or vice versa?
A. At present, no. When I set out to write KCrypt originally I did not have access to information about PGP file formats, and even now I'm not sure that the way PGP saves data is optimal for personal (as opposed to communications) security. Moreover, although KCrypt and PGP both use IDEA in cipher-feedback mode, there are a number of slight technical differences in implementation that make it difficult to itegrate the two products. However, I would consider modifying KCrypt to read and write PGP files if there was sufficient demand for it. For myself, the ways in which I use KCrypt and PGP do not overlap at all, so there is no pressing hurry for this.
Permission is granted to any individual or institution to use, copy, or redistribute this software so long as all of the original files are included, that it is not sold for profit, and that this copyright notice is retained.
LIKE MOST FREE SOFTWARE, KCRYPT IS PROVIDED `AS IS' AND COMES WITH NO WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED. IN NO EVENT WILL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY DAMAGES RESULTING FROM THE USE OF THIS SOFTWARE.
Please send bug reports and comments by email to: k.boone@kzone.eu.org. For bug reports, please include the version of KCrypt (see kcrypt -v ), the machine and operating system in use, and as much additional information as possible.
The IDEA algorithm is subject to patent claims by Ascom Systec Ltd, but no licence fee is required for non-commercial use.