Home Man
Today's Posts

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:
Select Section of Man Page:
Select Man Page Repository:

Linux 2.6 - man page for ccat (linux section 1)

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  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  encryp-
       tion  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

       Unlike unix crypt, 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 com-
       mands 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  inter-
       nally  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.

       -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

       -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. 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 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 std-
		      out. 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 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 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 sys-
		      tems, 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 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 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 program 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 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 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

       -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

       -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 use-
		      ful in recovering data from a corrupted file (see RECOVERING DATA FROM COR-
		      RUPTED  FILES).  To avoid irretrievable loss of data when decrypting with a
		      wrong key, this option cannot be used with modes that overwrite  the  input

       -P prompt, --prompt prompt
		      Use  prompt instead of the default prompt "Enter encryption/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 symbolic links to sub-

       -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 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/decryp-
		      tion,  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 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 *.

       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  usu-
       ally  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  inter-
       rupted  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  cor-
       rupted. 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 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 cipher-
       text; there is no way of telling whether the content of two encrypted files is similar  or

       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 after-
       wards 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  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
       --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  com-
       press 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 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 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 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 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])

       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 cal-
       culated 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 never to use the same  seed  more
       than  once; otherwise, the two resulting ciphertext blocks C[0] could be related by a sim-
       ple xor to obtain information about the corresponding plaintext blocks P[0].  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, cur-
       rent 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

       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
       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
       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, leaving the corresponding 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 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
       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 com-
       mand 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 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  pack-
       age  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 compressed files).

       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 buffer, and when you save the file later, it will	be  auto-
       matically  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 pack-
       age  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 of jka-compr).

       Limitations of the emacs package: there is no guarantee that unencrypted information  can-
       not  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 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 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
       encountering  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 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.  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.


       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 ver-
       sion 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/.

Version 1.9				   August 2009					CCRYPT(1)

All times are GMT -4. The time now is 12:30 PM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
Show Password