
Bifroest	Mr. Tines	CTC Home	CTClib	MacCTC	CTCjava	Manual

MacCTC 2.1: Known Bugs List

Updated 28^th October 1999

This is the list of known problems in MacCTC. Please check here before reporting a problem to save duplicate reporting. Please feel free to comment on them, if you have any suggestions, opinions on how it should be tackled, or opinions about priorities.

CTClib

These are bugs that are in the CTClib code so appear both in CTClib and MacCTC.

File type of Detacted Signatures

On generating a detacted signature, CTC treats it as whatever type of file it is (text or binary). However on verifying a signature, it always assumes that it is binary.

Get Round: MacCTC will produce verifiable signatures if the input is treated as Binary (in the Treat source as: menu, select Binary). However this has the disadvantage that if transferred as ASCII to Unix or PC the file will no longer match the signature.

Hopefully I have a solution that should allow verification of the MacCTC2.0 archives. Fixing: The difficulty here is being sure what the programs should do. Our best solution so far is to try both. See if the signature validates as a binary file. If not, try again as a text file.

Breaking Encryption does not abort completely

If the user aborts (by way of user_break) the PKE encryption operation in a hybrid encryption operation, this aborts only the PKE-operation not the whole encryption, even through aborting the PKE operation typically invalidates the whole hybrid encryption operation. This is only confirmed for MacCTC, but is probably a CTClib problem.

MacCTC bugs

These are bugs that appear in MacCTC code and hence do not affect CTClib.

Assert Failed

MacCTC is occasionally hitting an assertion (self-test) failure. The message reports the problem as being at Exceptions.cp, line 591, with the C fragment "!((long) ptr & ~sizeof(TestAlign) & 1)" quoted. What this means is that the program has attempted to deallocate a pointer which is misaligned (i.e. it points to an odd address; all such addresses should be even).

I had thought this would be a simple problem to fix, once I had caught it under the debugger. However, having done so I don't have the faintest idea what to do about it. The error is in the bowels of the Think-C library. It is an odd (i.e. not even) pointer. What is really bizarre is that it is an object member for an object that has just been created and is zeroed in the constructor. It is difficult to see how it can have got changed at all, in the meantime let alone how my code could have had anything to do with it. Accordingly I am not much further forward.

Line-wrapping breaks lines

When MacCTC performs its automatic line wrap before encryption it can split words in long paragraphs. (The problem has had some attention and could be fixed. However, as this has not been confirmed it is still listed as current.)

Zero length usernames

MacCTC does elegantly cope with a key that has a zero length username. (You can generate one if you put no text "Name of key" box on key generation.) The menu generation is confused by this and the menus can select the wrong key.

Historic Bugs

Bugs that have been (to the best of our knowledge fixed). Please report any occurance of these in the supposedly fixed version. However please verify that you are using the fixed version. If not, please upgrade and retest.

CTClib bugs

Key Generation Infinite Loop

There is a protracted (probably infinite) loop hazard in the prime number search routine. This can only occur when generating an RSA keys and using the 'random increment' search. It is much more likely to happen with very small exponent values.

This is fixed in 2.2.

Keys without a Pass-Phrase

There is a problem handling keys, with no pass-phrase, i.e. secret-keys that are not encrypted. This has yet to be fully characterised, but newly generated secret-keys which are not encrypted are not correctly re-read. Whereas this has only been observed with MacCTC, there is strong evidence that it is a general CTClib problem. This problem has now been investigated and it seems that most operations with these keys will fail. [At 2.0 there were some changes made to conventional encryption in general, which changed the handling of null-encryption (i.e. not encrypting). Regretably these changes were not correctly propagated to handling of secret keys.]

This is fixed in 2.2.

Wrong Id. Criterion

This is a very technical, and almost certainly entirely theoretical error. (It is more or less certain that no one has hit it yet.) PGP2.x key-packets (version=2 or 3) generate there key-Id.s by taking the last few bytes of the key modulus. PGP3.0 and later key-packets (version 4) use SHA-1 on the whole key to generate this. In practice all DH/DSA keys are version 4 and all RSA or elliptic curve are version 3. CTC currently (erroneously) checks the algorithm, not the version, to determine the Id. generation technique to use. This does not cause any problems will the vast majority of software available, but when an OpenPGP implementation is used to generate a version-4/RSA packet CTC will currently mis-calculate the Id.

This is fixed in 2.2.

Key Certificate Signature validation

Signatures on a key generated by PGP2.3 (or an immediate derivative such as PGP2.6ui, with the appropriate backward compatibility option set) fail to correctly verify. This only occurred if the keys where imported in a specific order.
This is fixed in 2.2

Key-Recovery Key packets

This was actually two separate problems. However one partially masked the other.

CTC2.0 did not process the Key-Recovery Key information in signatures hence did not know to discard. In fact, as there were sub-keys CTC would have assumed that they were the one-and-only key to encrypt to, as it assumed this was true of all sub-keys.
The Key-Recovery-Key sub-packet (with the signature packet) was larger than anything we had expected in a sub-packet and caused a buffer overflow. This stopped processing of the file dead, with the happy consequence that the KRK key was discarded. The main key being discarded too was the problem.

Both of these sub-problems are fixed in 2.1.

3DES-PGP interoperability

CTC 2.0 was not interoperable with PGP5 on triple-DES password (conventional) encryption. This was due to a different method of expanding the key from the pass-phrase generated MD5 hash (128-bits) to the encryption key size (168-bits). At 2.1 we now use the OpenPGP method. This has solved the interoperability problem between CTC2.1 and PGP5. However it has the side-effect that CTC2.1 is not inter-operable with CTC2.0 for this type of encryption. Any conventionally encrypted files generated with CTC2.0, must be decrypted with CTC2.0.

Bignums bugs

A couple of bugs in the Multiple-precision arithmetic were discovered and corrected:-

The short remainder operation mod_short() could occasionally return the incorrect result. The known effect of this was a low frequency failure in the prime search that would appear as a near-infinite loop. (It wasn't actually an infinite loop but could have been long enough to make this academic.)
There were a couple of serious bugs that appeared if CTC was built with a compiler that optimised out assert() calls in production code, as there were two cases were necessary operations were executed within asserts. This was known to result in a true infinite-loop in key generation, and could have cause other problems.

Both are fixed in 2.1.

TEA key schedule

There was a bug in the generation of the TEA key schedule. This would not only have made the TEA implementation incapable with other implementations, but potentially made it non-reproducable, hence not inter-operable with itself.
Fixed in 2.1

Third-party key signing

CTC 2.0 did not allow key to be signed except by themselves. (A rather theoretical limitation as no user-interface existed to attempt to do this.)
Fixed in 2.1

MacCTC bugs

These are bugs that appear in MacCTC code and hence do not affect CTClib.

Wrong Clock

MacCTC generates time-stamps in localtime not UTC. (My localtime is UTC, so I didn't notice.)
Fixed in 2.1.

UUencode Armouring does not work

Selecting UUencode format ASCII-armour produces not output. (This is a simple coding error handling the menu. The UUencode item is return ARM_MIME, not ARM_UUENCODE and as MIME isn't implemented, there is no output.)
[This does not apply to the 68k version.]
Fixed in 2.1.

Changing key-ring not immediate

A change of key-ring does not seem to be immediately effective. You need to restart the program.
Fixed in 2.1.

Ignoring unsaved changes

If a text window has a disc file associated with it, and unsaved changes in the window, then "encrypt window" operations may take the data from the disc file thereby ignoring the unsaved changes.
Fixed in 2.1.

2.0

2.0 (not 2.0A) was withdrawn due to a serious bug in CTClib. This was concerned with the writing of secret key-rings. 2.0 was only available for about 48 hours, prior to the announcement. To the best of my knowledge only one copy was downloaded and the user concerned has been informed.

Any other user who has downloaded a copy is strongly recommended to upgrade to 2.0A. (The version number is displayed both in the About panel and Finder file information.)

User Interface Problems

There are a number of annoyances with the user interface.

The information panel (top centre screen; informing you of progress) should disappear automatically after a few second. However sometimes it does not. (Get round: click on the panel. Then it will go way.)
The menu enabling sometimes fails resulting in very few menus being abled. (Get round: select another application; and then select MacCTC again.)
Especially on a small screen, the windows can overlap adversely.

It is not obvious how to add keys to the key-ring. (You "decrypt" the file.) There is now a 'hint' to this effect in the manual.

Eudora Interface Problems

Sometimes when sending an message straight to Eudora, a blank e-mail message with the Eudora settings file as an attachment is produced. (Get round: delete it again.) However this is in addition to rather than instead of posting the message into the out mail-folder. [Believed fixed in 2.1]
If several message arrive from Eudora at once, it does not always decrypt all of them.

fixed

If messages arrive as "application/pgp" MIME attachments they are not automatically processed by MacCTC.

webmaster@bifroest.demon.co.uk