User Guide
Chapters
Table of Contents
Key Maintenance
Decrypting a File

QTEncode

QTEncode is used to encrypt files. The process of encrypting a file, transforms that file so that it appears as random bytes. QTCrypt uses special files created by QTKey, called key files, to process a file and encrypt it. QTCrypt uses a special process called a Secure Hash Algorithm to create a special code or "message digest" for each file. The Secure Hash Algorithms used by QTCrypt are:

  1.  the Secure Hash Algorithms described and defined in Federal Information Processing Standards Publication, 180-2, 2002 August 1. The Standard defines 3 hash aloritms. The first with a 160 bit hash, the second with 224 bit and 256 bit hashes and the third with 384 bit and 512 bit hashes.
  2. the RIPEMD-160 (RMD-160). RMD-160 has been described in Dr. Dobbs Journal, January 1997 issue and defined by Antoon Bosselaers, Dept. Electrical Eng.-ESAT/COSIC,
  3. the Whirlpool Secure Hash Algorithm as defined by Taizo Shirai and Kyoji Shibutani, of the Ubiquitous Technology Laboratories, Sony Corp., in their paper "On the diffusion matrix employed in the Whirlpool hashing function", and
  4. the Tiger 192 bit Secure Hash Function as defined by Ross Anderson, Cambridge University, England, and Eli Biham, Technion, Haifa, Isreal, in their paper: "Tiger: A Fast New Hash Function".
The output of the Secure Hash Algorithm is called a message digest and identifies the contents of the file. In addition, it is very difficult to deduce the message from the message digest and, for a good Secure Hash Algorithm, it is computationally infeasible to find two files with equal message digests. The message digest is then encrypted and appended to the encrypted file. The message digest is used by the decryption process to verify the decrypted file contents and encryption date/time.

Recent research has found that the 160 bit hashes above are not as secure as previously thought in that it is possible to find more than one message with the same 160 bit hash. For this reason, QTEncode does not use the 160 bit hashes unless specifically commanded to do so by the user. Also, QTEncode uses a minimum of 2 hashes (4 by default: either the FIPS SHA 224 bit or 256 bit hash, either the FIPS SHA 384 or 512 bit hash, the Whirlpool 512 bit hash and the Tiger 192 bit hash) to verify and sign all documents.

Message Digest Contents

QTCrypt includes the following information in the message digest for each encrypted file:

  1. Last write date/time of file encrypted
  2. encryption date/time
  3. Group Key ID if signed
  4. Public Key ID if signed
  5. File contents
  6. File size in bytes (twice)

Thus, if QTCrypt verifies a decrypted file, the receiver knows not only the contents of the file have been verified, but also the date/time when the file was last modified before encryption and the date/time when the file was encrypted.

Secure Digital Signature

QTCrypt also allows the use of Secure Digital Signatures. A Secure Digital Signature allows the person encrypting a file to apply a signature to the encrypted file which is unique to the person, the encrypted file and the date and time of encryption and which cannot be duplicated by anybody else. QTCrypt uses the Digital Signature Algorithm described and defined in the Digital Signature Standard, Federal Information Processing Standards Publication, 186, 1994 May 19. The Secure Digital Signature defined by the Digital Signature Algorithm defines both private keys and public keys for each person. The private key and public key are created by QTCrypt for anybody desiring to sign an encrypted file. The private key is kept private and secret by the person for whom it was created. The corresponding public key is disseminated widely to anybody who would want to decrypt and verify the contents of a file encrypted by that person and authenticate the Secure Digital Signature. QTCrypt uses the message digest computed for an encrypted file and the private key of the person encrypting the file to compute a Secure Digital Signature. The Secure Digital Signature is then encrypted and appended to the encrypted file. When the encrypted file is decrypted by QTCrypt, the message digest is again computed and used with the group key and public key corresponding to the Group Key ID and Public Key ID included in the encrypted file to recompute the Secure Digital Signature of the received file. If the recomputed Secure Digital Signature equals the decrypted Secure Digital Signature, then QTCrypt verifies the decrypted file contents, the date and time of the encrypted file, the encryption date and time and authenticates the Secure Digital Signature of the person encrypting the file.

QTCrypt transforms the input file so that it appears to be stream of random bytes. Indeed, attempting to compress a file encrypted with QTCrypt will fail. File compression programs use redundancy or repeated byte sequences in a file for compression. It replaces the redundant or repeated byte sequences with shorter codes, thus compressing the file. Files which have been encrypted with QTCrypt will appear not to have any such redundancy or repeated byte sequences and thus cannot be compressed. The encrypted file output by QTCrypt will be longer that the input file.

Overhead

QTCrypt uses one of 5 methods or a combination of the five methods to encrypt a file. In addition, QTCrypt outputs overhead to identify certain knowledge about the file encrypted. The overhead contains the following information:

  1. if encrypted file is not armored, then output an 18 byte QTCrypt signature identifying the file as an encrypted file produced by QTCrypt.
  2. a single byte flag with one of the following possible values:
    1. '\x00' - indicates that the file has been encrypted using a CD-ROM encryption key. The following five values are then output. These values are not included in the message digest of the encrypted file. They are encrypted using the Byte Shift Encryption, BSE,. A Special Pass Phrase derived from a series of pseudorandom numbers is used for the encryption. The Pass Phrase was derived at the time the Encryption Key was created.
      1. Randomizer Unique ID. A Pseudorandom Number that has been assigned as the unique ID for the randomizer key derived from a specified CD-ROM. The ID is written "in the clear", i.e., unencrypted.
      2. random number - a pseudorandom number derived at the time of file encryption. The value is encrypted.
      3. Randomizer Line Number #1 - a Pseudorandom Number derived at the time of file encryption. Used as an index into the Encryption Key file table for the name of the first randomizer file byte stream.
      4. Randomizer Line Number #2 - a Pseudorandom Number derived at the time of file encryption. Used as an index into the Encryption Key file table for the name of the second randomizer file byte stream.
      5. Parameter Line Number - a Pseudorandom Number derived at the time of file encryption. Used as an index into the Encryption Key parameter table.
    2. '\x01' - indicates that the file has been encrypted using a pass phrase. A single byte is written to indicate the Secure Hash Algorithm used for encryption the file.
      1. '\x00' - use Secure Hash Algorithm, Federal Information Processing Standards Publication, 180-1, 1995 April 17
      2. '\x01' - use RIPEMD-160
  3. a pseudorandom number used to indicate whether the file is Signed or not. If the low order bit is set, the file is Signed otherwise it is not Signed.
  4. Forced Secure Hash Algorithm flag. Value included in file message digest. This is a single byte with the following values:
    1. '\x00' - Use Secure Hash Algorithm specified in Encryption Key parameter table
    2. '\x01' - Force the use of Federal Information Processing Standards Publication, 180-1, 1995 April 17
    3. '\x02' - Force the use of RIPEMD-160
  5. Original file size. If the file is compressed prior to encryption, this is the size of the encrypted file. The value is written twice. Upon decryption, if the two values do not agree, then the decryption mistake is caught early. Both values are include in the file message digest.
  6. Forced Encoding Scheme - overrides parameter file. Value not included in file message digest. This field has the following values:
    1. '\x00' - use encryption method specified in parameter table
    2. '\x01' - use Alternating Encryption, ALE,
    3. '\x02' - use Relative Offset Encryption, ROE,
    4. '\x03' - use Byte Shift Encryption, BSE,
    5. '\x04' - use Permutation Change Encryption, PCE,
    6. '\x05' - use Bit Mix Encryption, BME,
    7. '\x06' - use Byte Mix Encryption, BYE,
  7. Flag to indicate forcing decrypted output. Value not included in file message digest. This field has the following values:
    1. '\00' - use file specified at time of decryption
    2. '\01' - force decrypted output to filename the same as encryption input filename
    3. '\02' - force decrypted output to standard output file - usually the console. May be redirected.
  8. Input File Name length. Value included in file message digest.
  9. Input File Name. Value included in file message digest.
  10. Input file date as Julian Day Number. Value included in file message digest.
  11. Input file time as seconds since midnight. Value included in file message digest.
  12. Encryption date as Julian Day Number. Value included in file message digest.
  13. Encryption time as seconds since midnight. Value included in file message digest.
  14. If the encrypted file is Signed, then the following values are output:
    1. Group Key ID string length. Value included in file message digest.
    2. Group Key ID string. Value included in file message digest.
    3. Private Key ID string length. Value included in file message digest.
    4. Private Key ID string. Value included in file message digest.
  15. single byte indicating whether input file compressed prior to encryption. Value not included in file message digest.
    1. '\x00' - file not compressed
    2. '\x01' - file compressed. When compressing the input file, the following values are included in the file overhead. All values are included in the file message digest.
      1. Uncompressed file size,
      2. rle run threshold
      3. Block size for compression in 100K byte blocks

Note: All date/times included in the header information are treated as Co-ordinated Universal Time by all QTCrypt programs. This, however, does depend upon the time settings used in the computer used for encrypting files by QTCrypt.

Compression

The overhead will add a minimum of approximately 100 bytes to the length of the encrypted file. Depending on the encryption method used, the encrypted text can be exactly equal in length to the input file or up to 3 times longer. Thus, the encrypted file will vary from approximately equal in size to the input file to approximately 3 times as big. Since the encrypted file cannot be compressed, any compression must be done prior to encryption. If compressed prior to encryption by any of the popular compression programs, usually more than one file may be compressed and included in the output of the compressor.

QTCrypt will automatically compress the input file if so desired by the user. Input file compression can be designated as the default in the configuration file or signaled on the command line. If the input file is compressed by QTCrypt, the Burroghs-Wheeler file transformation is performed, variable run length compression is then performed followed by a variation of arithmetic compression. The compression method has been adapted from that designed and written for the 'bzip' utility.

Options

QTCrypt includes several options for:

  1. specifying the encryption method to be used,
  2. specifying that the encrypted file should be output in a special form for transmission as an e-mail message, i.e., "armored",
  3. specifying the encrypted file should include a Secure Digital Signature,
  4. specifying the decrypted output should be displayed on the console and not written to a file,
  5. specifying the decrypted output should be output only to a file with the same name as the input file to QTEncode,
  6. specifying the input file should be overwitten in such a manner as to attempt to erase it from the storage medium,
  7. specify the name of the Master Key Ring file to be used.


User Guide
Chapters
Table of Contents
Key Maintenance
Decrypting a File