Security Problems
Terry Ritter (ritter@io.com)
Mon, 04 Mar 1996 00:26:00 -0600
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 http://www.io.com/~ritter/