• Nov. 08, 2005. New version for Linux: 6.0. Changes:
  
  1. Added Tiger 160 bit Secure Hash capability.
  2. Changed format of Key Certificate Files. Version 6.0 cannot read Key Certificate files of previous versions.
  3. In previous versions, an identical pass phrase and CD-ROM pair produced an identical unchanging Key Certificate. This has changed.
     -Starting with version 6.0, all generated Key Certificate files are now unique, even with identical pass phrase and CD-ROM pair.
     -Thus the Encryption Keys generated from different Key Certificates, even with identical pass phrase and CD-ROM pair are different and produce differing encryption of a given file. In previous versions only the pass phrase and CD-ROM pair were really needed to produce the Encryption key, since an identicle Key Certificate could generated from the pass phrase and CD-ROM pair as needed. This is no longer true. All three are now needed to generate an Encryption Key, thus enhancing the security of the Encryption Key.
     -To get identical Encryption Key content, the Key Certificate, pass phrase and CD-ROM must all be identical.
     -Each Encryption Key produced from identical Key Certificate, pass phrase and CD-ROM are encrypted differently, producing different file images for each such Encryption Key. However, Encryption keys produced from identical Key Certificate, pass phrase and CD-ROM are identical in content, only the encryption has changed. This has been done to further enhance the security of the Encryption Keys. Identical Encryption Keys cannot be identified from their file images.
     
  4. Changed format of Encryption Key files.Version 6.0 cannot read Encryption Key files of previous versions. Any Encryption Keys from previous versions should be deleted and re-generated with version 6.0.
     
  5. Use of Multiple Secure Hashes for encryting and/or signing documents/files. Version 6.0 uses six Secure Hashes by default. Thus, for files which are signed, separate signatures are generated for each Secure Hash. Six separate signatures are produced by default.
     
  6. Changed format of encrypted file to accomodate use of multiple hashes.Version 6.0 cannot read files encrypted by previous versions. Thus, any files needed for long term storage should be decrypted by the version used to encrypt and then encrypted with version 6.0.
     
  7. Master Key file format has been changed. Version 6.0 can read a Master Key Ring file written by previous versions, but will write any updated Master Key Ring file in the new format. Support for the format of previous version will be dropped in some future version. Signature Key file format has not changed.
  8. qtcalc_file_hash has changed considerably.The useage statement displayed has been changed to reflect the changes. Refer to the online usage documentation by running the new program with no command line options or input files. More on-line information has been written and can accessed through the program.
     
  9. the qtcalc_file_hash options have changed - refer to the online help.
  10. The method of storing and displaying the online help for qtencode, qtdecode and qtcalc_file_hash has been changed and the same system used in QTGrep utilized. This method separates writing the online help documentation from the source file. The online help documentation is written separately, compressed and then appended to the executable file. The executable file then detects the compressed documentation, decompresses the portion needed and displays that portion. The compression/decompression method is fairly good at compressing. The decompression method is very fast and un-noticable in action. Other compression methods produce more compression, but they are not as fast at de-compression.
      This method makes writing and updating and maintaining the onmline documentation much easier. Also, if anybody cares to translate the documentation to another language, this method facilitates that very easily since the execcutable need not be changed in any manner or re-compiled. Only the documentation is changed, compressed and appended to the executable. Thus, anybody desiring to change the documentation can do so without needing to learn anything about the source code.
  11. Strengthened the function to wipe input files. The function now
      
      1. writes random data to the complete file three times.
      2. writes 3 byte blocks of specified data (Gutman Wipe Data - 27 difierent 3 byte blocks) to the complete file.
         
      3. write random data to the complete file three times.
• March 11, 2005. Updated QTCrypt - qtkeys, qtencode, qtdecode and qtcalc_file_hash. Changes:
  
  1. Changed from version 4.0 to 5.0 under Linux.
  2. Changed format of encrypted file slightly to accomodate change in version to include version number of QTCrypt in the encrypted file and "new" features.
  3. Added Whirlpool Secure Hash function.
  4. Deprecated use of 160 bit SHA hashes. The 160 bit SHA hashes will not be picked automatically during encryption and cannot be forced in the configuration file. The user can still force their use if desired in qtencode by the command line option. I have added a note about the use of the 160 bit hashes and the current squabble over whether to continue using them or not.
     
  5. qtencode will only encrypt to the new format. qtdecode will decrypt both the old format and the new format.
  6. Fixed some minor issues with qtcalc_file_hash - the usage statement displayed is now more intelligible. Shell scripts are now available to compute hashes and check previously computed hashes against current files.
     
• Feb 18, 2005. Updated qtcalc_file_hash to also check file hash. Application will either compute files hahses or check file hashes against previously computed hashes. By default, it will compute hashes. Use 'c' or 'r' command line options for checking file hashes.  The 'c' option outputs check results to the standard output and returns a zero, 0, value if hashes are valid and a non-zero value if one or more of the hashes are not valid. The 'r' option performs the same function except that no results are output, only the return value indicates the result.The 'r' option is useful in shell script files. Theshell script file "chk_hash_files.sh" is provided for this purpose. After the files are untarred, witch to the directory where they reside and perform the command "./chk_hash_filees" to ensure that all hashes are valid.
  
• Feb. 17, 2005, There are now two versions. One uses the GNU Multiple Precision Arthimetic Library, GMP, and the other uses the MIRACL library by Shamus Software. The GNU GMP version is totally uder the GPL. Both versions are at version number 4.00. The GMP version executables are slightly smaller than the MIRACL version executables. I could detect no difference in speed between the two. Note that the GMP library or the MIRACL library are only used by the Digital Signature functions. Otherwise there is no difference between the two versions.
  
• Feb. 5, 2005, Fix bug in 'i' option for qtencode/qtdecode. Add two directives for configuration file (Feb. 5, 2005)
• Version 4.0, Linux, Available: Feb 2, 2005.  Working on re-wrting the documentation. There is an option available under "qtencode", -r, that is not documented yet. This option allows one to encrypt directly from the Randomizer Key Certificate (with the Key CD-ROM and pass phrase) without having to explicitly create the randomizer key from the key certificate. If you encrypt only occassionally then this option enables you to encrypt without having to keep the full randomizer key on your disk at all times (or create it and wipe and delete it).
  

Executables (GMP version only - 566.4 KB) are now available for qtkey (key creation/maintenance, Document signing), qtencode (document/file encryption), qtdecode (document/file dencryption) and qtcalc_file_hash (compute/check file hashes). Source (690 KB) is available under the GPL. NOTE: the source includes both the GMP and the MIRACL versions.

The signature files for both the executables and the source are available.

QTCrypt utilizes a sophisticated adaptation of one-time pad encryption and is, to the best of my knowledge, unbreakable. Even upcoming Quantum computing probably will not be capable of breaking QTCrypt.

However, QTCrypt is a symmetric encryption program and not public key. Symmetric encryption places more of a burden on the users, since both the encryption party and the decryption party must have access to the secret key.

However, if you merely wish to encrypt/decrypt your private files such that nobody else may view sensitive information, then distributing the secret keys for encryption/decryption is not a problem simply because it is not done. For such a use QTCrypt is ideal.

BUT be very careful in storing or memorizing the secret pass phrases because without those pass phrases, the files are lost forever.

With public mass storage on the internet becoming more realizable every day, there may be a day in the near future when you may be storing or backing-up all of your sensitive files/data on such storage. More ISPs (Internet Service Providers) are providing more and more such mass storage. With broadband lines becoming more readily available, transferring such data to rented on-line storage for back-up purposes is probably realizable today. Or maybe you are already doing so.

If you are storing, for back-up purposes, sensitive files/data (financial files, tax files, legal documents/files, personal letters, etc.) on readily available on-line mass storage, have you ever wondered just how secure such data is from others who would really like to view such data?

Well by encrypting such data/documents/files with QTCrypt before transmitting to on-line mass storage you can prevent such un-authorized use.

Also, QTCrypt attempts to make distribution of the secret key needed for encryption/decryption somewhat easier. There are three elements used in making a secret key. The first is a CD-ROM (or DVD) of the originator's choice. The second is a pass phrase, also of the originator's choice. Using the first two elements, the CD-ROM and pass phrase, the originator creates a Key Certificate. The Key Certificate is encrypted using the pass phrase and the CD-ROM chosen. All three elements:

1. CD-ROM,
2. Pass Phrase, and
3. Key Certificate

are then used to create the secret key. The secret key is used with the CD-ROM for encryption/decryption. Thus, the three elements must be communicated to anybody else privledged to encrypt/decrypt files/documents with the secret key. All three elements must be possesed by anybody desiring to create the secret key. With only one or two of the elements, the secret key cannot be created and, thus, any files/documents encrypted with the secret key cannot be decrypted.

Thus, three independent channels may be used to communicate/transport the three elements to other parties. The three separate channels need not be secure if they are indeed independent. By "independent", I mean that anybody reading or having other access to one channel has no knowledge of or access to the other channels.

In this fashion, QTCrypt has reduced the need for truely "secure" channels of information or transport. But the need to insure channel independence is still of great concern. However, channel independence is much easier to ensure thn truely "secure" communication channels.

The secret key, once created in this manner can be used to encrypt/decrypt thousands (or possibly more) files/documents/messages.

The program was originally developed under OS/2 and was not working under Linux. It is has currently been fixed (Jan. 03, 2005) and working again under Linux.

As originally developed under OS/2, QTCrypt utilized the FIPS 160 bit Secure Hash Algorithm. Under Linux, it has been updated to the latest FIPS version, 180-2, 2002 August 1, with 160, 224, 256, 384 and 512 bit hashes. The 160, 224 and 256 bit hashes are designed by NIST to work with files/documents less than 2^64 bits (2^61 bytes) and create a message digest (one-way hash) of the file/document. The 384 and 512 bit hashes are designed by NIST to work with files/documents less than 2^128 bits (2^125 bytes) and create a message digest (one-way hash) of the file/document.

Also, the Digital Signature has been updated to the latest FIPS 186-2 Change notice 1, 2000 Janurary 27. For  QTCrypt, I have extended FIPS 186-2 Change notice 1 to work with secure hashes from 160 bits to 512 bits. FIPS 182 Change notice 1 uses a prime modulus group key parameter, p, of 1024 bits. NIST is currently working on FIPS 186-2 to change p from 1024 bits to 3072 bits to work with the 224 and 256 bits hashes. I have designed QTCrypt to work with group key parameters, p, of 3027 bits for the 160, 224 and 256 bits hashes and 4096 bits for the 384 and 512 bit hashes.

The Linux version utilizes either the the GNU Multiple Precision Arthimetic Library, GMP,  or the MIRACL (Multi-precision Integer and Rational Arithmetic C/C++ Library) Package.

The GNU GMP is distributed under the GPL and so the GMP version of QTCrypt is also distributed under the GPL.

MIRACL is not distributed under the GPL, but is available for download from Shamus Software. (The MIRACL library can be used freely for Academic, non-profit making or non-commercial use. Commercial Users must register.)

Thus, two files of the MIRACL version are not under the GPL. The two files are the C header file "miracl.h" which is totally copyrighted by Shamus software and the file is distributed here with their permission. The C source file "dss-miracl.c" is partially copyrighted by Shamus Software and that portion is distributed here with their permission.

For the GMP version of QTCrypt, the GNU GMP is avaible on many platforms and OSs including Linux. The GMP is distributed with most, if not all, Linux distributions. Thus, under Linux the user only needs to deal with the QTCrypt source files and need not be concerned with the mechanics of securing, and compiling the GMP library, since it will most liekly already be available on their systems.

For the MIRACL version of QTCrypt, the user must download the MIRACL package from Shamus software, compile the appropriate pieces of software and then create a software library for use by the program linker the user is using. The instructions for doing this are included in the QTCrypt file "dss-miracl.c". The comments in the source file detail how I accomplished these tasks and could be repeated by the user.

For those desiring to use only GPL'd software, the GMP version of QTCrypt would probably be the version of choice. I could measure no difference in the performance speed of either the GMP or MIRACL version of the Digital Signature portion of QTCrypt. The GMP version is slightly smaller in size. Thus, I know of no advantage to using either version from a performance standpoint.