ccrypt - encrypt and decrypt files and streams
ccrypt [mode] [options] [file...] ccencrypt [options] [file...] ccdecrypt [options] [file...] ccat [options] file...
ccrypt is a utility for encrypting and decrypting files and streams. It was designed to replace the standard unix crypt utility, which is notorious for using a very weak encryption algorithm. ccrypt is based on the Rijndael block cipher, which is the U.S. government's chosen candidate for the Advanced Encryption Standard (AES, see http://www.nist.gov/aes/). This cipher is believed to provide very strong security.
Unlike unix crypt, the algorithm provided by ccrypt is not symmetric, i.e., one must specify whether to encrypt or decrypt. The most common way to invoke ccrypt is via the commands ccencrypt and ccdecrypt.
Encryption and decryption depends on a keyword (or key phrase) supplied by the user. By default, the user is prompted to enter a keyword from the terminal. Keywords can consist of any number of characters, and all characters are significant (although ccrypt internally hashes the key to 256 bits). Longer keywords provide better security than short ones, since they are less likely to be discovered by exhaustive search.
ccrypt can operate in five different modes. If more than one mode is specified, the last one specified takes precedence. The aliases ccencrypt, ccdecrypt, and ccat are provided as a convenience; they are equivalent to ccrypt -e, ccrypt -d, and ccrypt -c, respectively.
The following options are supported in addition to the modes described above:
The user interface of ccrypt intentionally resembles that of GNU gzip, although it is not identical. When invoked with filename arguments, ccrypt normally modifies the files in place, overwriting their old content. Unlike gzip, the output is not first written to a temporary file; instead, the data is literally overwritten. For encryption, this is usually the desired behavior, since one does not want copies of the unencrypted data to remain in hidden places in the file system. The disadvantage is that if ccrypt is interrupted in the middle of writing to a file, the file will end up in a corrupted, partially encrypted state. However, in such cases it is possible to recover most of the data; see RECOVERING DATA FROM CORRUPTED FILES below.
When ccrypt receives an interrupt signal (Ctrl-C) while updating a file in place, it does not exit immediately, but rather delays the exit until after it finishes writing to the current file. This is to prevent files from being partially overwritten and thus corrupted. If you want to force ccrypt to exit immediately, just press Ctrl-C twice quickly.
The encryption algorithm used by ccrypt uses a random seed which is different each time. As a result, encrypting the same file twice will never yield the same result. The advantage of this method is that similarities in plaintext do not lead to similarities in ciphertext; there is no way of telling whether the content of two encrypted files is similar or not.
Because of the use of a random seed, decrypting and re-encrypting a file with the same key will not lead to an identical file. It is primarily for this reason that ccrypt refuses to decrypt files with a non-matching key; if this were allowed, there would be no way afterwards to restore the original file, and the data would be irretrievably lost.
When overwriting files, special care is taken with hard links and symbolic links. Each physical file (i.e., each inode) is processed at most once, no matter how many paths to it are encountered on the command line or in subdirectories traversed recursively. For each file which has multiple hard links, a warning is printed, to alert the user that not all paths to the file might have been properly renamed. Symbolic links are ignored except in cat mode, or unless the -l or -R option is given.
Unlike gzip, ccrypt does not complain about files that have improper suffixes. It is legal to doubly encrypt a file. It is also legal to decrypt a file which does not have the .cpt suffix, provided the file contains valid data for the given decryption key.
Regarding encryption and compression: encrypted data is statistically indistinguishable from random data, and thus it cannot be compressed. But of course it is possible to compress the data first, then encrypt it. Suggested file suffixes are .gz.cpt or .gzc.
Encrypted data might be corrupted for a number of reasons. For instance, a file might have been partially encrypted or decrypted if ccrypt was interrupted while processing the file. Or data might be corrupted by software or hardware error, or during transmission over a network. The encryption algorithm used by ccrypt is designed to allow recovery from errors. In general, only a few bytes of data will be lost near where the error occurred.
Data encrypted by ccrypt can be thought of as a sequence of 32-byte blocks. To decrypt a particular block, ccrypt only needs to know the decryption key, the data of the block itself, and the data of the block immediately preceding it. ccrypt cannot tell whether a block is corrupted or not, except the very first block, which is special. Thus, if the encrypted data has been altered in the middle or near the end of a file, ccrypt can be run to decrypt it as usual, and most of the data will be decrypted correctly, except near where the corruption occurred.
The very first block of encrypted data is special, because it does not actually correspond to any plaintext data; this block holds the random seed generated at encryption time. ccrypt also uses the very first block to decide whether the given keyword matches the data or not. If the first block has been corrupted, ccrypt will likely decide that the keyword does not match; in such cases, the -m option can be used to force ccrypt to decrypt the data anyway.
If a file contains some encrypted and some unencrypted data, or data encrypted with two different keys, one should decrypt the entire file with each applicable key, and then piece together the meaningful parts manually.
Finally, decryption will only produce meaningful results if the data is aligned correctly along block boundaries. If the block boundary information has been lost, one has to try all 32 possibilities.
Block ciphers operate on data segments of a fixed length. For instance, the Rijndael block cipher, also known as the U.S. government's Advanced Encryption Standard (AES, see http://www.nist.gov/aes/), has a block length of 32 bytes or 256 bits. Thus, the Rijndael block cipher encryptes 32 bytes at a time.
Stream ciphers operate on data streams of any length. There are several standard modes for operating a block cipher as a stream cipher. One such standard is Cipher Feedback (CFB), defined in FIPS 81 and ANSI X3.106-1983. ccrypt implements a stream cipher by operating the Rijndael block cipher in CFB mode.
Let P[i] and C[i] be the ith block of the plaintext and ciphertext, respectively. CFB mode specifies that
C[i] = P[i] ^ E(k,C[i-1])
Assuming that blocks are numbered starting from 0, a special "initial" ciphertext block C[-1] is needed to provide the base case for the above formula. This value C[-1] is called the initialization vector or seed. The seed is chosen at encryption time and written as the first block of the encrypted stream. It is important never to use the same seed more than once; otherwise, the two resulting C could be related by a simple xor to obtain information about the corresponding P. If the same seed is never reused, CFB is provably as secure as the underlying block cipher.
In ccrypt, the seed is constructed as follows: first, a combination of the host name, current time, process id, and an internal counter are hashed into a 28-byte value, using a cryptographic hash function. A fixed four-byte "magic number" is combined with this value, and the resulting 32-byte value is encrypted by one round of the Rijndael block cipher with the given key. The result is used as the seed and appended to the beginning of the ciphertext. The use of the magic number allows ccrypt to detect non-matching keys before decryption.
ccrypt is believed to provide very strong cryptographic secrecy, essentially equivalent to that of Rijndael. This means, without knowledge of the encryption key, it is effectively impossible to obtain any information about the plaintext from a given ciphertext. This is true even if a large number of plaintext-ciphertext pairs are already known for this key. Moreover, because ccrypt uses a key size of 256 bits, an exhaustive search of the key space is not feasible, at least as long as sufficiently long keys are actually used in practice. No cipher is secure if users choose insecure keywords.
On the other hand, ccrypt does not attempt to provide \fIdata integrity\fP, i.e., it will not detect whether the ciphertext was modified after encryption. In particular, encrypted data can be truncated, leaving the corresponding decrypted data also truncated, but otherwise consistent. If one needs to insure data integrity as well as secrecy, this can be achieved by other methods. The recommended method is to prepend a cryptographic hash (for instance, an MD5 or SHA-1 hash) to the data before encryption.
ccrypt does not claim to provide any particular safeguards against information leaking via the local operating system. While reasonable precautions are taken, there is no guarantee that keywords and plaintexts have been physically erased after encryption in completed; parts of such data might still exist in memory or on disk. ccrypt does not currently use priviledged memory pages.
When encrypting files, ccrypt accesses them in read-write mode. This normally causes the original file to be physically overwritten, but on some file systems, this might not be the case.
Note that the use of the -K option is unsafe in a multiuser environment, because the command line of a process is visible to other users running the ps command. The use of the -E option is potentially unsafe for the same reason, although recent versions of ps don't tend to display environment information to other users.
There is an emacs package for reading and writing encrypted files. This package hooks into the low-level file I/O functions of emacs, prompting the user for a password where appropriate. It is implemented in much the same way as support for compressed files; in fact, the package, whose name is jka-compr-ccrypt, is based directly on the jka-compr package which is part of GNU Emacs. It handles both encrypted and compressed files (although currently not encrypted compressed files).
To use the package, simply load jka-compr-ccrypt and edit as usual. When you open a file with the ".cpt" extension, emacs will prompt you for a password for the file. It will remember the password for the buffer, and when you save the file later, it will be automatically encrypted again (provided you save it with a ".cpt" extension). Except for the password prompt, the operation of the package should be transparent to the user. The package also handles compressed ".gz", ".bz2", and ".Z" files, and it should be used instead of, not in addition to, jka-compr. The command M-x ccrypt-set-buffer-password can be used to change the current password of a buffer.
The simplest way to use this package is to include the lines
(setq load-path (cons "path" load-path)) (require 'jka-compr-ccrypt "jka-compr-ccrypt.el")
Limitations of the emacs package: there is no guarantee that unencrypted information cannot leak to the file system; in fact, the package sometimes writes unencrypted data to temporary files. However, auto-saved files are normally treated correctly (i.e., encrypted). For details, see the comments in the file jka-compr-ccrypt.el.
The exit status is 0 on successful completion, and non-zero otherwise. An exit status of 1 means illegal command line, 2 is out of memory, 3 is an i/o error, 4 is a non-matching key, 5 is wrong file format, 6 is interrupt, 7 is mistyped key in --timid mode. Return values 4 and 5 only occur when running as a filter; when reading files, the respective conditions only generate a warning.
While ccrypt can handle keywords of arbitrary length, some operating systems limit the length of an input line to 1024 characters.
The renaming of files (adding or removing the .cpt suffix) can go wrong if a filename is repeated on the command line. In this case, the file is only encrypted/decrypted once, but the suffix may be added or removed several times. This is because ccrypt thinks it encountered different hardlinks for the same file.
The --strictsuffix option can behave unexpectedly if one file has several hardlinks of which some have the suffix and some don't. In this case, the inode will be encrypted/decrypted, but the suffix will be changed only for those filenames that allow it. Similarly, if a file cannot be renamed because a file of the given name already exists, the file may still be encrypted/decrypted if it has another hardlink.
Copyright (C) 2000-2001 Peter Selinger
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307,
USA. See also http://www.gnu.org/.
Copyright (C) 2000-2001 Peter Selinger
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA. See also http://www.gnu.org/.