Terry Ritter Ciphers By Ritter...

Security Problems

Although my field is ciphers per se, I am concerned about some serious security problems in current e-mail protocols:

1. Announcing in open headers that a message is in cipher is a serious security problem. At certain times and places simply sending such a message could be a dangerous activity.

The issue is whether a user who wishes to use ciphering should be forced to *announce* that fact to the world. Even if it is possible technically to discover whether or not a message is enciphered, we should not force the user to *admit* to this.

Supporting this is very simple: We just transport a "black box" information payload. Normally I think of this as being Base64 ASCII, but the encoding is not the point. The payload should simply be a block of uninterpreted data which the receiving user is expected to know how to use.

2. Standardizing on a single cipher is a big problem. It seems to be impossible to prove that *any* practical cipher is strong, so we must assume that any particular cipher *may* *well* be broken someday. In practice, this would lead to massive chaos, unless various ciphers were already in use and could be easily selected by users within hours of such news.

The ability to use one of many ciphers is more than just "a few added key bits": Having a wide range of different ciphers can vastly reduce the amount and value of data under any one cipher, and so reduce the motivation and resources for attacking that particular cipher. This reduces overall risk.

Cipher selection can be negotiated between both parties. (I note that cipher selection negotiation was the way ANSI X9F3 was going in early 1994, and may still be, for all I know.) Typically, we use Triple-DES until agreement is reached. Ciphers are identified by a name assigned by the designer or manufacturer, thus avoiding the need for a central registry. Many private key ciphers can be interchanged simply by giving each a similar envelope for init, encipher, and decipher functions. (Key distribution is at a different level and irrelevant to this sort of cipher selection.)

My approach is to allow a different cipher in each direction. The sending side sends a list of ciphers it can use; the receiving side makes a selection and sends the selected name to the sending side. The next message from the sending side is in the newly-selected cipher. (Or negotiation continues.) The other direction performs similarly.

Within the enciphered payload, there is a control area for transporting the cipher lists and selections as text (much like HTML), and a customer data area, which is treated as binary data. The customer data is normally delivered as binary data, although this might well be interpreted by "type" information in the control area. Perhaps MIME header information could be held in the control area instead of open headers.

Terry Ritter Ciphers By Ritter