ccencrypt man page on AIX

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

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

       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.

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

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

       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.

       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
       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 simple xor to obtain information about  the	 corresponding
       plaintext  blocks P[0].	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.

       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
       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‐
       pressed 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 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
       of jka-compr).

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


       Peter Selinger <selinger at>

       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‐
       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)
                             _         _         _ 
                            | |       | |       | |     
                            | |       | |       | |     
                         __ | | __ __ | | __ __ | | __  
                         \ \| |/ / \ \| |/ / \ \| |/ /  
                          \ \ / /   \ \ / /   \ \ / /   
                           \   /     \   /     \   /    
                            \_/       \_/       \_/ 
More information is available in HTML format for server AIX

List of man pages available for AIX

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