FreeBSD Manual Pages
CCRYPT(1) Encryption CCRYPT(1) NAME ccrypt - encrypt and decrypt files and streams SYNOPSIS ccrypt [mode] [options] [file...] ccencrypt [options] [file...] ccdecrypt [options] [file...] ccat [options] file... DESCRIPTION ccrypt is a tool for encrypting and decrypting files and streams. It is based on the Rijndael block cipher, a version of which is also used in the Advanced Encryption Standard (AES, see http://www.nist.gov/aes). This ci- pher is believed to provide very strong cryptographic security. 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 ter- minal. 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. MODES ccrypt can operate in five different modes. If more than one mode is spec- ified, 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. -e, --encrypt Encrypt. This is the default mode. If filename arguments are given, encrypt the files and append the suffix .cpt to their names. Otherwise, run as a filter. -d, --decrypt Decrypt. If filename arguments are given, decrypt the files and strip the suffix .cpt from the filenames, if present. Otherwise, run as a filter. -c, --cat Decrypt one or more files to standard output. If no filename arguments are given, decrypt as a filter. A filename of "-" is interpreted as reading from standard input. Implies -l. -x, --keychange Change the key of encrypted data. In this mode, ccrypt prompts for two passwords: the old one and the new one. If filename arguments are given, modify the files. Otherwise, run as a filter. -u, --unixcrypt Simulate the crypt(1) command-line encryption tool that used to exist on very old Unix systems from about 1979 until the 1990s. Note: the cipher used by the old crypt(1) tool is not secure and has been broken. This option is provided only for decrypting existing files. If filename arguments are given, decrypt the files to stdout. Otherwise, run as a filter. A filename of "-" is interpreted as reading from standard in- put. Since there is no easy way to detect whether a given key matches or not, for safety, this mode does not overwrite files. OPTIONS The following options are supported in addition to the modes described above: -b, --brave When reading an encryption key from the terminal, ask the user only once for the key. By default, ccrypt will ask the user to enter such keys twice, as a safeguard against acci- dentally destroying data due to a mistyped key. Using the --brave option disables this safety check. Never use it, un- less you know what you are doing. See also --timid. -E var, --envvar var Read the keyword from the environment variable var. Note that this might be unsafe on certain systems, namely where users can use the ps command to see the environment of a process owner by another user. On most modern systems, how- ever, such behavior of ps is disabled and the -E option should be safe there. Also, as an added security measure, ccrypt erases the keyword from its environment immediately after reading it. -f, --force Overwrite existing files or operate on write-protected files without asking any questions. Also, override ccrypt's reluc- tance to write or read encrypted data to or from a terminal. -F var, --envvar2 var Same as -E, except for second keyword (in keychange mode). -h, --help Help. Print usage information and exit. -H key, --key2 key Same as -K, except for second keyword (in keychange mode). -k file, --keyfile file Read the keyword as the first line from the named file. In keychange mode, two keywords are read as the first two lines of the file. The filename "-" may be given for reading key- words from standard input. Using the -k - option and send- ing the keyword on stdin is probably the safest way to pass a keyword to ccrypt from another program or script. -K key, --key key Specify the keyword on the command line. This is unsafe, be- cause any other user can see the command line by running the ps command. Only use this option for testing purposes, and never with a real keyword. -y file, --keyref file In encryption or keychange mode, check the encryption key against the named file, which must have been previously en- crypted with the same key. Exit with an error message if the key does not match. This option is useful as an alternative to --timid, to guard against mistyped keys in situations where several files are encrypted with the same key. This option implies --brave, unless the --timid option is explic- itly given after the --keyref option. -l, --symlinks Force encryption/decryption of symbolic links. By default, symbolic links are ignored except in cat or unixcrypt mode. Note that with the -l option, encryption/decryption of a symbolic link causes the suffix .cpt to be added/removed from the name of the link, not the name of the file pointed to. -L, --license Print license info and exit. -m, --mismatch Normally, ccrypt refuses to decrypt data with a key that does not seem to match. The -m option overrides this re- striction. This can sometimes be useful in recovering data from a corrupted file (see RECOVERING DATA FROM CORRUPTED FILES). To avoid irretrievable loss of data when decrypting with a wrong key, this option cannot be used with modes that overwrite the input file. -P prompt, --prompt prompt Use prompt instead of the default prompt "Enter encryp- tion/decryption key: ". This may be useful in some shell scripts. -q, --quiet Suppress most warnings. -Q prompt, --prompt2 prompt Same as -P, except for second keyword (in keychange mode). -r, --recursive Traverse subdirectories recursively. -R, --rec-symlinks Traverse subdirectories recursively, and also follow sym- bolic links to subdirectories. -s, --strictsuffix Refuse to encrypt files that already have the .cpt suffix (or that selected with -S). This can be useful when adding some files to a directory of already encrypted files. This option has no effect in decryption or keychange mode. -S .suf, --suffix .suf Use the suffix .suf instead of the default suffix .cpt. -t, --timid When reading an encryption key from the terminal, ask the user to enter the key twice. If the two entered keys are not identical, abort. This is a safeguard against accidentally destroying data by encrypting it with a mistyped key. Note: this behavior is now the default, and can be overridden with the --brave option. -T, --tmpfiles This option causes ccrypt to use temporary files during en- cryption/decryption, rather than overwriting the file con- tents destructively. This method leaves the original file contents lying around in unused sectors of the file system, and thus is less secure than the default behavior. However, in situations where this loss of security is not important, the --tmpfiles option can provide a measure of protection against data being corrupted due to a system crash in the middle of overwriting a file. -v, --verbose Print progress information to stderr. -V, --version Print version info and exit. -- End of options. Any remaining arguments are interpreted as filenames. This also turns off filter mode, even if zero filenames follow. This might be useful in the context of shell pattern expansion; ccrypt -- * will behave correctly even if no files match the pattern *. NOTES ON USAGE The user interface of ccrypt intentionally resembles that of GNU gzip, al- though 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 possi- ble to recover most of the data; see RECOVERING DATA FROM CORRUPTED FILES below. If you want to force ccrypt to use temporary files, use the --tmp- files option. 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 be- ing 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 that is differ- ent 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 orig- inal 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 sub- directories traversed recursively. For each file that 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 suf- fixes. It is legal to doubly encrypt a file. It is also legal to decrypt a file that does not have the .cpt suffix, provided the file contains valid data for the given decryption key. Use the --strictsuffix option if you want to prevent ccrypt from encrypting files that already have a .cpt suf- fix. Regarding encryption and compression: encrypted data is statistically in- distinguishable from random data, and thus it cannot be compressed. But of course it is possible to compress the data first, then encrypt it. Sug- gested file suffixes are .gz.cpt or .gzc. RECOVERING DATA FROM CORRUPTED FILES Encrypted data might be corrupted for a number of reasons. For instance, a file might have been partially encrypted or decrypted if ccrypt was inter- rupted while processing the file. Or data might be corrupted by a software or hardware error, or during transmission over a network. The encryption algorithm used by ccrypt is designed to allow recovery from errors. In gen- eral, 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, ex- cept 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 ac- tually correspond to any plaintext data; this block holds the random seed generated at encryption time. ccrypt also uses the very first block to de- cide 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 en- crypted 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. DESCRIPTION OF THE CIPHER Block ciphers operate on data segments of a fixed length. For instance, the Rijndael block cipher used in ccrypt has a block length of 32 bytes or 256 bits. Thus, this cipher encrypts 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 NIST Special Publication 800-38A and ANSI X3.106-1983. ccrypt implements a stream cipher by operat- ing the Rijndael block cipher in CFB mode. Let P[i] and C[i] be the ith block of the plaintext and ciphertext, respec- tively. CFB mode specifies that C[i] = P[i] ^ E(k,C[i-1]) Here ^ denotes the bitwise exclusive or function, and E(k,x) denotes the encryption of the block x under the key k using the block cipher. Thus, each block of the ciphertext is calculated from the corresponding block of plaintext and the previous block of ciphertext. Note that in fact, each byte of P[i] can be calculated from the corresponding byte of C[i], so that the stream cipher can be applied to one byte at a time. In particular, the stream length need not be a multiple of the block size. Assuming that blocks are numbered starting from 0, a special "initial" ci- phertext block C[-1] is needed to provide the base case for the above for- mula. 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 en- crypted stream. It is important that the seed is unpredictable; in particu- lar, the same seed should never by used more than once. Otherwise, the two resulting ciphertext blocks C[0] could be related by a simple xor to obtain information about the corresponding plaintext blocks P[0]. If unpre- dictable seeds are used, CFB is provably as secure as the underlying block cipher. In ccrypt, the seed is constructed as follows: first, a nonce is contructed by hashing a combination of the host name, current time, process id, and an internal counter into a 28-byte value, using a cryptographic hash function. The nonce is combined with a fixed four-byte "magic number", and the re- sulting 32-byte value is encrypted by one round of the Rijndael block ci- pher with the given key. This encrypted block is used as the seed and ap- pended to the beginning of the ciphertext. The use of the magic number al- lows ccrypt to detect non-matching keys before decryption. SECURITY ccrypt is believed to provide very strong cryptographic security, equiva- lent to that of the Rijndael cipher with 256-bit block size and 256-bit key size. Another version of the Rijndael cipher (with a smaller block size) is used in the U.S. government's Advanced Encryption Standard (AES, see http://www.nist.gov/aes). Therefore, this cipher is very well studied and subject to intensive public scrutiny. This scrutiny has a positive effect on the cipher's security. In particular, if an exploitable weakness in this cipher were ever discovered, this would become widely publicized. In practical terms, the security of ccrypt means that, 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 the same 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 and hard-to-guess 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 data integrity, i.e., it will not attempt to detect whether the ciphertext was modified after en- cryption. In particular, encrypted data can be truncated, leaving the cor- responding decrypted data also truncated, but otherwise consistent. If one needs to ensure 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 SHA-1 hash) to the data before encryption. ccrypt does not claim to provide any particular safeguards against informa- tion 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 privileged memory pages. When encrypting files, ccrypt by default 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. The use of the -T option is unsafe for encryp- tion because the original plaintext will remain in unused sectors of the file system. EMACS PACKAGE There is an emacs package for reading and writing encrypted files. (Note that this package currently only works with emacs, not with xemacs.) 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. If you have both the ps-ccrypt and jka-compr packages installed, emacs can open encrypted files and compressed files; however, it does not currently work for files that are encrypted and compressed. To use the package, simply load ps-ccrypt, then 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 oper- ation of the package should be transparent to the user. 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 'ps-ccrypt "ps-ccrypt.el") in your .emacs file, where path is the directory that holds the file ps- 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 com- ments in the file ps-ccrypt.el. EXIT STATUS 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 or another system error, 3 is a fatal i/o error, 4 is a non-matching key or wrong file format, 6 is interrupt, 7 is mistyped key in --timid mode, 8 is a non-fatal i/o error, and 9 means that no key was obtained because the user failed to enter it, or because the specified keyfile or environment variable could not be read. An exit status of 10 means that the file specified by the --keyref option could not be read, or did not match the requested encryp- tion key. Fatal i/o errors are those that occur while processing a file that is al- ready open. Such errors cause ccrypt to abort its operation immediately with an exit status of 3. Non-fatal i/o errors are those that occur while handling files that are not already open; typically, such errors are caused by files that are missing, not readable, or can't be created. When encoun- tering a non-fatal i/o error, ccrypt simply continues to process the next available input file. The exit status of 8 is delayed until after all the files have been processed. Non-matching keys and wrong file formats are also considered non-fatal er- rors, and cause ccrypt to continue with processing the next available input file. In this case, an exit status of 4 is given after all the files have been processed. If there is a conflict between exit status 4 and 8, then 8 is returned. The former exit status 5 ("wrong file format") has been eliminated, and is now covered under exit status 4 ("non-matching key or wrong file format"). Note that ccrypt does not really have a "file format" in the proper sense of the word; any file of length at least 32 bytes is potentially a valid encrypted file. LIMITATIONS Like all encryption programs that depend on a user-supplied key, the en- cryption is only as strong as the key you provide. You must assume that ad- versaries have the ability to try billions of different keys per second, or more. So if you use a key that is too short, or a key that is long but easy to guess, you should assume that it can and will be broken. While ccrypt can handle keywords of arbitrary length, some operating sys- tems 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 in unexpected ways if one file has several hardlinks, some of which have the suffix and some of which 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. VERSION 1.11 AUTHOR Peter Selinger <selinger at users.sourceforge.net> COPYRIGHT Copyright (C) 2000-2018 Peter Selinger This program is free software; you can redistribute it and/or modify it un- der 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 FIT- NESS 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., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. See also http://www.gnu.org/. Version 1.11 July 2018 CCRYPT(1)
NAME | SYNOPSIS | DESCRIPTION | MODES | OPTIONS | NOTES ON USAGE | RECOVERING DATA FROM CORRUPTED FILES | DESCRIPTION OF THE CIPHER | SECURITY | EMACS PACKAGE | EXIT STATUS | LIMITATIONS | VERSION | AUTHOR | COPYRIGHT
Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=ccat&sektion=1&manpath=FreeBSD+Ports+15.1.quarterly>