Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
CCRYPT(1)			  Encryption			     CCRYPT(1)

       ccrypt -	encrypt	and decrypt files and streams

       ccrypt [mode] [options] [file...]
       ccencrypt [options] [file...]
       ccdecrypt [options] [file...]
       ccat [options] file...

       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
       This cipher is believed to provide very strong cryptographic security.

       The algorithm provided by ccrypt	is not symmetric, i.e.,	one must spec-
       ify 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	 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. 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. Oth-
		      erwise, 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 input. Since there
		      is no easy way to	detect whether a given key matches  or
		      not, 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 en-
		      vironment	 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
		      --keyref option.

       -l, --symlinks Force  encryption/decryption  of	symbolic links.	By de-
		      fault, symbolic links are	ignored	except in cat or unix-
		      crypt mode. Note that with the -l	option,	encryption/de-
		      cryption 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

       -r, --recursive
		      Traverse subdirectories recursively.

       -R, --rec-symlinks
		      Traverse	subdirectories	recursively,  and  also	follow
		      symbolic links to	subdirectories.

       -s, --strictsuffix
		      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-
		      change 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
		      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 *.

       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 un-
       encrypted  data to remain in hidden places in the file system. The dis-
       advantage 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 un-
       til 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 de-
       crypt a file that does not have the .cpt	suffix,	provided the file con-
       tains 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 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.

       Encrypted  data	might  be  corrupted  for a number of reasons. For in-
       stance, 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.

       Block  ciphers  operate	on  data  segments of a	fixed length.  For in-
       stance, 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	Publi-
       cation 800-38A 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, re-
       spectively. 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"
       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 that the	seed is	unpredictable;
       in particular, the same seed should never by used more than once.  Oth-
       erwise,	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 unpredictable	seeds are used,	CFB is provably	as se-
       cure as the underlying block cipher.

       In ccrypt, the seed is constructed as follows: first, a nonce  is  con-
       tructed	by  hashing  a	combination  of	 the  host name, current time,
       process id, and an internal counter into	a 28-byte value, using a cryp-
       tographic  hash	function. The nonce is combined	with a fixed four-byte
       "magic number", and the resulting 32-byte value	is  encrypted  by  one
       round  of  the Rijndael block cipher with the given key.	This encrypted
       block is	used as	the seed and appended to the beginning of the  cipher-
       text.  The use of the magic number allows ccrypt	to detect non-matching
       keys before decryption.

       ccrypt 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 Therefore,  this  ci-
       pher  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 and	hard-to-guess keys are actually	used in	 prac-
       tice. 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  in-
       formation leaking via the local operating system. While reasonable pre-
       cautions	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  cur-
       rently 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  im-
       plemented  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 cur-
       rently 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 operation 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

       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 ps-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 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 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 oc-
       cur while handling files	that are not already open; typically, such er-
       rors 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  po-
       tentially a valid encrypted file.

       Like  all  encryption  programs that depend on a	user-supplied key, the
       encryption is only as strong as the key you provide.  You  must	assume
       that adversaries	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

       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 re-
       moved several times. This is because ccrypt thinks it encountered  dif-
       ferent 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 al-
       ready exists, the file may still	be encrypted/decrypted if it  has  an-
       other hardlink.


       Peter Selinger <selinger	at>

       Copyright (C) 2000-2018 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-
       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

Version	1.11			   July	2018			     CCRYPT(1)


Want to link to this manual page? Use this URL:

home | help