ccrypt man page on Cygwin

Man page or keyword search:  
man Server   22533 pages
apropos Keyword Search (all sections)
Output format
Cygwin logo
[printable version]


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 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, a version of 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.

MODES
       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.
		      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 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.

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  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
		      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 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
		      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
		      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 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 *.

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
       manually.

       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 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,
       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
       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
       secure 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.

SECURITY
       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  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
       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	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.

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 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
       ps-ccrypt.el.

       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.

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 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.

BUGS
       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
       another hardlink.

VERSION
       1.10

AUTHOR
       Peter Selinger <selinger at users.sourceforge.net>

COPYRIGHT
       Copyright (C) 2000-2012 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
       http://www.gnu.org/.

Version 1.10			 October 2012			     CCRYPT(1)
[top]

List of man pages available for Cygwin

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net