Bifroest	Mr. Tines	CTC Home	CTClib	MacCTC	CTCjava	Manual

MacCTC: Original Specification

Introduction

This is a slightly reworked early specification for MacCTC. It describes how I believe MacCTC should work. This includes a number facilities not currently available in any version of PGP. Many of the facilities could, and my opinion should, be included in all versions.

General Approach

PGP will never be widely used, unless it is reasonably well integrated with an E-mail system. Whereas PGP can be used in other ways (e.g. PGPFone and encrypting disc files), it is first and foremost an e-mail encryption system. This requires a number of facilities that are currently not present.

PGP is a security tool. It provides privacy and authentication. The user interface and provided facilities should encourage secure working practices, and thereby guide the naive user into secure use.

Finally the security of PGP will all for nothing if the user of the system is forced to reveal the keys. Most notably PGP currently lacks damage limitation facilities.

Secret Key Management

This is primarily aimed at producing facilities and working practices which will minimise the danger of a court requiring the surrendering of a private key. There are three aspects to this:-

• Minimising the strength of arguments that could be put to a court to require the surrendering.
• Maximising the strength of the arguments against.
• Maximising the alternatives.

The most plausible scenario is that an organisation has obtained some messages encrypted with the defendant's public key, claims they have a right to read these messages and demands the private key to do so. There is of course no guarantee that the information cited in the case are the messages that the plaintive are really interested in. Indeed the plaintive could well have encrypted the messages themselves as an excuse to obtain the key.

The maximising the alternatives is very simple. PGP needs a method of surrendering session keys and decrypting using those session keys. This will allow a defendant to reveal the messages that are cited in the case, without revealing any others.

Minimising Opponents Argument

Minimising the strength of the arguments against is difficult. Probably the only one of real value is a lack of fault argument. The court is asking the defendant to reveal his key because of someone else's use of their key. For this to be effective the defendant should never use an encrypt-to-self option. A court seems more likely to be ready to demand that you decrypt messages that you encrypted yourself. This is only possible where you encrypt to yourself. For this reason it is proposed that MacCTC should not include such an option. Users wishing to do so must select their own key as they would any other.

Maximising Own Arguments

Maximising the strength of arguments against consists of showing the maximum harm that could be done to the abuse of the surrendered key. There are three arguments usable here:-

1. If the key is also used for my digital signature, the surrendered key could be used for forging. [The MIT v3.0 intends to allow separate keys for signature and encryption. This seems intended primarily to remove this argument and make PGP escrow-compatible.]
2. There is other confidential traffic which the plaintive should not be given access to.
   Examples are:-
   • Correspondence covered by a non-disclosure agreement (especially where the agreement is with a foreigner and the agreement specifies the foreigner's jurisdiction as the legal system to interpret the contract)
   • confidential medical correspondence with a doctor
   • confidential correspondence about minors or other vulnerable persons in the charge of one of the correspondents
   • privileged correspondence with a lawyer; particularly effective as the courts in most countries are very reluctant interfere with this.
   Of these I would expect the last to generally be the most effective.
3. the defendant may argue that it is unjust that the plaintive may have access to plaintext address to the defendant without it being revealed to the defendant. The defendant has no guarantee that the messages have been see all the messages the plaintive intends to decrypt. If the defendant is to extract the session key they need to see the messages.

Maximising Alternatives

The most obvious alternative is not handover the only session keys, and not the PKE secret keys. This is at best a damage limitation exercise. You are still handing over some keys. The people demanding your secret-keys are unlikely to be willing to accept this, especially if they aren't being honest about why they want your keys. Nevertheless it is very important be able to offer to do this. Facilities to allow this are vital.

Advanced Legal Abuse

Assuming that a crypto-user is a law abiding citizen protecting his/her privacy, it is unlikely that anyone honest and honourable will attempt to force them to hand-over their privacy keys. Accordingly we should not expect such people to obey any rules of decency. It is important to consider the tactics to that might be applied. For example, someone may have interpreted a message and prevented the intended recipient receiving it. Even if the court accept just session keys, there is a possible abuse by the plaintive. He may provide the messages with unchanged key blocks but corrupt message blocks so it decrypts to rubbish. The defendant has to hand over the session key to prove the message is rubbish. The plaintive then uses it to decrypt the real message. This is very difficult to avoid. It would be possible to detect this by include an MD5 hash of the convention cyphertext in the "nonce" the session key is encrypted with. However, there is no way of preventing a rogue variant of PGP always generating bad hashs. There is also no way of proving whether the `rubbish' in the message is a message encrypted with another crypto. system or not. I conclude that it is impossible under these circumstances to force an interceptor to reveal the message.

However, with a slight modification it would be possible to determine who had sent the message and hence have a chance of obtaining another copy from the sender. The "nonce" session key was encoded with could included the key Id of the sender, and potentially other information too. [A typical key block is 128 bytes of which 16 bytes are the IDEA key and about the same ought to be as random as possible (and different for each recipient). The remaining 96 bytes or so could include, date, subject & message digest for example.]

Message Handling

A conventional E-mail message contains a lot of information in the headers. A secure PGP message (sent via cypherpunk remailers) does not. Whereas the contents of a signed message is authenticated (to the extent the key can be trusted) the headers are not. I has been noted the elsewhere the danger of taking the headers (or any other information outside the signing delimiters) too seriously. To avoid this problem it is proposed that MacCTC should ignore encrypted parts of a message.

Integrated Address and Key handling

PGP (Public) keys include e-mail addresses. There should be no need to separately select the keys and addresses.

Pass-Phase Time-outs

It should not be necessary to enter a pass-phase every time one is used. However should PGP receive no user interaction for a user definable period of time, it should discard all pass-phases that it is using. Note that this should be done without warning so as not to alert any potential interloper that there is a copy PGP with unexpired pass-phases. Also not that it is PGP user interaction and not machine interaction. A user may interrupted running PGP and start up another application. The user may then forget PGP is running an leave someone else alone with the machine. Unlike the current version of MacPGP it should immediately discard a pass-phase if it proves to be incorrect.