CCRYPT(1) Encryption CCRYPT(1)NAMEccrypt - encrypt and decrypt files and streams
SYNOPSISccrypt [mode] [options] [file...]
ccencrypt [options] [file...]
ccdecrypt [options] [file...]
ccat [options] file...
DESCRIPTIONccrypt is a utility for encrypting and decrypting files and streams. It
was designed to replace the standard unix crypt utility, which is noto‐
rious for using a very weak encryption algorithm. ccrypt is based on
the Rijndael block cipher, which was also chosen by the U.S. government
as the Advanced Encryption Standard (AES, see http://www.nist.gov/aes).
This cipher is believed to provide very strong cryptographic 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.
MODESccrypt can operate in five different modes. If more than one mode is
specified, the last one specified takes precedence. The aliases ccen‐
crypt, 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.
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. Oth‐
erwise, run as a filter.
Simulate the old unix crypt command. Note: the cipher
used by unix crypt has been broken and is not secure.
Please use this option only to decrypt existing files.
If filename arguments are given, decrypt the files to
stdout. Otherwise, run as a filter. Note that for the
unix crypt format, there is no easy way to detect
whether a given key matches or not; thus, for safety,
this mode does not overwrite files.
The following options are supported in addition to the modes described
-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 accidentally destroying data due to a mistyped
key. Using the --brave option disables this safety
check. Never use it, unless 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, however, 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 reluctance to write or read encrypted data to
or from a terminal.
-F var, --envvar2 var
Same as -E, except for second keyword (in keychange
-h, --help Help. Print usage information and exit.
-H key, --key2 key
Same as -K, except for second keyword (in keychange
-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 keywords from standard input. Using the -k-
option and sending the keyword on stdin is probably the
safest way to pass a keyword to ccrypt from another pro‐
gram or script.
-K key, --key key
Specify the keyword on the command line. This is unsafe,
because any other user can see the command line by run‐
ning 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 previ‐
ously encrypted 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 explicitly given after the
-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, encryp‐
tion/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
restriction. 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
-q, --quiet Suppress most warnings.
-Q prompt, --prompt2 prompt
Same as -P, except for second keyword (in keychange
Traverse subdirectories recursively.
Traverse subdirectories recursively, and also follow
symbolic links to subdirectories.
Refuse to encrypt files that already have the .cpt suf‐
fix (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 key‐
-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
encryption/decryption, rather than overwriting the file
contents 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 behav‐
ior. 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 con‐
text 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,
although it is not identical. When invoked with filename arguments,
ccrypt normally modifies the files in place, overwriting their old con‐
tent. 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. If you want to
force ccrypt to use temporary files, use the --tmpfiles 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 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 that is dif‐
ferent each time. As a result, encrypting the same file twice will
never yield the same result. The advantage of this method is that simi‐
larities in plaintext do not lead to similarities in ciphertext; there
is no way of telling whether the content of two encrypted files is sim‐
ilar 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 pri‐
marily 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 sym‐
bolic 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 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
suffixes. 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 --strictsuf‐
fix option if you want to prevent ccrypt from encrypting files that
already have a .cpt suffix.
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.
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 interrupted while processing the file. Or data might be cor‐
rupted 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 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 cor‐
rupted 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
Finally, decryption will only produce meaningful results if the data is
aligned correctly along block boundaries. If the block boundary infor‐
mation 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 FIPS 81 and ANSI
X3.106-1983. ccrypt implements a stream cipher by operating the Rijn‐
dael 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])
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
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 ciphertext blocks C could be
related by a simple xor to obtain information about the corresponding
plaintext blocks P. If the same seed is never reused, CFB is prov‐
ably 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.
SECURITYccrypt is believed to provide very strong cryptographic security,
equivalent 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 Encryp‐
tion 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 par‐
ticular, if an exploitable weakness in this cipher were ever discov‐
ered, this would become widely publicized.
In practical terms, the security of ccrypt means that, without knowl‐
edge 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 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 encryption. In particular, encrypted data can be truncated, leav‐
ing the corresponding decrypted data also truncated, but otherwise con‐
sistent. 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
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 plain‐
texts 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 overwrit‐
ten, but on some file systems, this might not be the case.
Note that the use of the -K option is unsafe in a multiuser environ‐
ment, 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 dis‐
play environment information to other users. The use of the -T option
is unsafe for encryption because the original plaintext will remain in
unused sectors of the file system.
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; 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 com‐
To use the package, simply load jka-compr-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 buf‐
fer, 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 trans‐
parent 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")
in your .emacs file, where path is the directory that holds the file
jka-compr-ccrypt.el. You may also need to disable loading of the old
jka-compr package, since the two packages are not compatible with each
other (and in any case, jka-compr-ccrypt contains all the functionality
Limitations of the emacs package: there is no guarantee that unen‐
crypted information cannot leak to the file system; in fact, the pack‐
age 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 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 encryption key.
Fatal i/o errors are those that occur while processing a file that is
already open. Such errors cause ccrypt to abort its operation immedi‐
ately 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 encountering a non-fatal i/o error, ccrypt simply con‐
tinues 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
errors, 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.
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 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. Simi‐
larly, 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
Peter Selinger <selinger at users.sourceforge.net>
Copyright (C) 2000-2009 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 MER‐
CHANTABILITY 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
Version 1.9 August 2009 CCRYPT(1)