CTClib - PGP-compatible software.

This page

Available applications

(NEW) For Java 5+ for with pre-built Windows support

Currently in early beta (code is usable but is only at the first stable point of a significant refactoring and restructuring exercise) is a rework of the UI to use the now long established Java Swing UI widget set. With broadband now widespread, keeping to the <3Mb Java 1.1 run-time is less of a constraint than it was around the turn of the millennium.

The Beta 2 of CTCJava 2.0 release. The main feature of this release is simply the replacement of the UI widgets with Java Swing components; and the start of a rework of the way in which multiple open files are managed.

The release archive contains a 7-zip archive with detached signature; within that 4 other such archives, each containing a file and its detached signature. The files in the innermost archives, the ones with accompanying signature, are:

1. CTCJava.jar — the compiled file including icons (Both the “Dean's icons” set used before, and the preferred Tango Project set).
2. java.zip — the refactored source code
3. ctcjlib.dll — version 2.3.2192.30638; modified from the previous version to take into account changes in the names of classes and methods in the Java code
4. ctcjlib-src.zip — the modified source of the JNI layer used to build the above.

This is almost entirely a refactoring release - changing the UI widgets, renaming classes, and adjusting data encapsulation and class responsibilities (and tidying up a modiucum of the crap-ness of my last-century code).

There is no installer as such. Just place the .dll on the path and the jar on the classpath. If you unpack them to say C:\CTCJava, then a .bat file

cd C:\CTCJava
start javaw -cp ctcjava.jar com.ravnaandtines.ctcjava.CTC ctcjava.ini

with the path to your CTC config file (compatible from version 1.x) as the argument (ctcjava.ini, here) will do the job.

Maintenance information

Bug fixes in version 2.3.2178.34472

Remove the line

#define SMALL_MEM 

in ctccpa/gzip.h; and insert it here

#include <stdio.h>

/* this value matches that in ziputils.c - keep it that way.  --Tines 1-1-97 */
#define BITS 15

/* The following is necessary for use with the PGPclassic WSIZE of 0x2000.
** The buffer size comparison checks later in deflate.c are NOT adequate.
**   --Tines 17-Dec-05 */
#define SMALL_MEM

#define NO_ASM

#include "tailor.h"
#ifdef unix
  #include "gzip.h_ux"
#else
  #include "gzip.h"
#endif

in ctccpa/deflate.c. This allows inflate to use a 32k history buffer, while we stick with the PGP-compatible 8k while compressing

Bug fixes since 2.3 (in version 2.3.1044.27931)

• Rudimentary handling for OpenPGP multi-section packets to handle ciphertext and literal data packets. More general packet types (keyring packets in particular) will not in general be handled correctly if given in multiple section lengths.
• Storage alignment problem noted in determine_endianness(void) in CTClib file utils.c; replaced the line

      as_short = *((short*)buffer);
  by
      memcpy(&as_short, buffer, 2);

• Fencepost error in bignums.c routine s_m_mod()
  

           register unit divisor = topUnit + 1;
           assert(firstUnit < topUnit);     /* required for udiv_qrnnd */ 

  The assert changed to assert(firstUnit < divisor)

Bug fixes since 2.2

• The PRNG code no longer leaks state (ideas used are derived from the OpenSSL PRNG code).
• The correct bytes are checked if decrypting multiple reverse encryption
• The version byte is set for newly generated keys (RSA and the deprecated GF(2^255)) so as to get the PGP2.6 keyID, rather than the PGP5 one
• Input of revocation (and sub-key to key binding) signatures corrected
• Key generation should now be able to write the modified key-ring if the ring contains a PGP5-style public key. Key-rings containing secret keys in PGP5 format will be damaged; there is still no code for handling such keys.

Bug fixes since 2.1

• New format signature packets are now written correctly to keyrings
• Key-revocation-key signature removal bugfixed.
• Secret keys with no encryption set now handled correctly
• Fixed a potential bug in keyhash.c affecting signature verification on keyrings. Signatures on keys that do not have version byte value of 3 may not verify, as the value may be defaulted incorrectly.
• Fixed a potential near infinite loop in key generation in findPrime() in pkbignum.c
• extractKeyfrag() in pkcipher.c used the wrong test to determine the algorithm for generating key Id.
• A proper UTF-8 safe entrypoint added for passphrases (fixes a potential bug)

Bug fixes since 2.0

• Key schedule for TEA now fixed (at second time of trying)
• Signing of one key by another is now possible (the signed key can now differ from the verifying key).
• No instances of assert() now contain actual code
• Files including Key-Recovery Key packets can now be read (the KRK packets are discarded.
• Incorrect Sub-key packet constants (SUBPKT_*) corrected.
• Interoperability with PGP on 3DES conventional encryption fixed.by new entry point hashpassEx() for string to key conversion.

Known bugs and omissions - CTClib 2.3

• Non-IDEA conventional encryption is possible but currently signals an unrecognised packet (type3, secret key encrypted session packet).
• CTClib does not yet handle the use or generation of DSA/DH secret-keys (PGP 5.0 style)
• Many compilers make erroneous assumptions about unsigned values on optimisation; this leads to errors in the operation of the multiple-precision integer code when compiled with full optimisation. This applies to Symantec C++ on Mac and Borland C++Builder on PC at least.
• VC++ 5.0 at least also has problems simply compiling some code with optimisations : I killed an attempt to compile Haval with VC++ release optimizations on a Pentium2 300MHz machine after 20 minutes.
  It is recommended that compiler optimization is not used
• Not really a bug but... If you want use CTClib in a multi-threaded environment, then the simple-minded port_io sample implementation is not thread-safe, using as it does a single pool of handles. You will need to provide a per-thread pool, and some means of knowing which thread to look at when allocating or disposing a virtual file handle.

Mainstream source

This code is all freeware, with the source library offered under the conditions of the GPL "COPYING" (or in the case of some of the Java GUI code, under the GLPL "COPYING.LIB" ) : cryptographic software needs to be available for full public review, not hidden in anonymous commercial products. The code is broken into folders as follows

• ctcalg - library core conventional cryptographic algorithms
• ctccbk - trivial example of implementation dependent complex callback code
• ctccpa - library core compression algorithms
• ctcfyi - trivial example of implementation dependent informational callback code; plus string table
• ctcio - trivial example of implementation dependent I/O
• ctckey - library core key management
• ctclib - main application interface and binary file armouring
• ctcpka - library core public key encryption
• ctcran - trivial (and not to be used) example of implementation dependent entropy collection
• ctcusr - trivial example of implementation dependent user interrupt handling
• ctcutl - library core memory management and multiple precision integer code
• export - header files of most likely use to applications
• include - header files shared between the above libraries and of occasional use to applications.

Source archives are available as follows:-

• CTClib 'C' code core plus JNI layer in C++: as platform independent a C++ binding as possible (makes use of STL sets/lists and conditional use of namespaces) in the JNI, including a C++Builder5 project and a Makefile. The archive also contains a full documentation package.

  N.B.It is assumed that if you are building this library as-is, that you already have a copy of an appropriate Java Development Kit; the JDK header file "jni.h" is referred to from the files in this archive, but is not included. If you just want to take the project files and build CTClib, then remove all the .cpp files from the project roster.

  Download CTClib 2.3.1 source

• CTCjava: Java 1.1 code with calls to native methods.

  Download CTCjava 1.2 of 25/Mar/01 Java 1.1 code with native methods.

I would urge people who do download this source library to compile with NO_IDEA defined (which expunges all references to that algorithm) : they can then still communicate with PGP 5 users, without being in technical infringement of patent restrictions. If CTCjlib is built in this configuration, then the Java code will detect it and adjust itself accordingly.

Also available, but long abandoned

These are effectively orphaned, and may cease to work as the core library evolves.

• Minimal function command line source: only allows the common encryption and decryption operations, can be used as an almost plug-compatible PGP2.6 replacement for e-mail scripts.
• More extensible but incomplete command line source; derived from the PGP2.6ui command line. Last built using CTClib 2.0, and abandoned.
• The original motivation for the project, a complete native Macintosh application, along with relevant instructions. This is now effectively obsolete.

Future plans

Further enhancements would include

• Perhaps porting to C++ as most compilers are now capable of this (actually, as the code is not well encapsulated internally, this would be more in the nature of a complete rewrite, even if achieved through refactoring).
• Full OpenPGP (RFC2440) compatibility (the main next thrust of development) in the library core.
• Further compatibilty with other PGP2.6 derivatives such as GNUPG (a similar, GNU-sponsored, product)
• Possible non-backward compatible replacement of the current elliptic curve option with a DSS style signature and a different format for the public key and session key (to avoid possible patent infringement issues) This would use a different algorithm byte value from the current implementation.