By J. H. Saltzer, March 19, 1997; updated, January 2001, 2002, 2003, and 2006.

The terminology used in describing cryptographic systems has evolved over the decades to leave behind a non-mnemonic, non-intuitive, and pedagogically confusing shambles. Although it would be nice to burn the history and start over, that doesn't seem to be possible, because there are too many books, papers, and lecturers that use terms in the various ways that have evolved.

In the face of this situation, in 6.033 we provide a set of preferred terms, a set of acceptable synonyms, and a set of terms to avoid. It is recommended that in class one try very hard to use only the preferred terms. When students respond or ask questions using one of the acceptable synonyms, respond in turn or answer the question using the preferred term (and noting the synonym), and when a student uses a term in the disparaged list, take the opportunity to point out why it has potential for confusion.

The first major area of confusion in cryptographic terminology has to do with the use of cryptographic transformations for two quite distinct purposes:

• to keep data confidential, and
• to authenticate the origin and integrity of data.

Traditional usage labels the cryptographic transformations "encryption" and "decryption". If those terms were applied only to transformations used for confidentiality there would be no problem. The trouble is that the same transformations are sometimes used for authentication. When that happens, describing the transformations as "encryption" and "decryption" creates a badly misleading intuition. One problem is that because the requirements on confidentiality transformations are quite different from the requirements on authentication transformations, even though the transformations performed by the underlying cryptographic engine may be identical, they are applied in subtly different ways, described in chapter 11 of the notes. Another problem is that in some authentication systems, the "encryption" transformation is used twice and the "decryption" transformation not at all; in other authentication systems the "decryption" transformation is applied to plaintext, which confounds the intuition associated with the label.

To avoid misleading intuition, in 6.033 we follow the lead of modern, careful cryptographers: use the terms encrypt and decrypt exclusively to describe cryptographic transformations used for confidentiality, and the terms sign and verify for cryptographic transformations used for authentication. When discussing the underlying transformations performed by a cryptographic engine, we use the words "apply a cryptographic transform" or "apply the inverse cryptographic transform". This labeling scheme requires some attention on the part of the instructor to avoid accidentally using "encrypt" to mean "apply a cryptographic transform".

The function labeled "sign" is also slightly problematic, because we use it for all authentication, in both public-key and shared-secret systems. As a result, we lose the distinctive idea that is supposed to go with the word "sign": that a "signature" can be used to convince a third party that the sender signed the message. In shared-secret systems, both the sender and the recipient know the key, so the recipient could also have signed it. When the sender's and receiver's interests are aligned, the distinction doesn't matter, but when their interests conflict, the distinction becomes important. In the technical literature the distinction is maintained, with some awkwardness, by using the verb "to sign" in public-key systems and the invented verb "to MAC" (from the acronym for a Message Authentication Code) in shared-secret systems.

(One can argue that this distinction is just a bit flaky, since even the best signature systems have concerns about how one balances the goal of non-repudiation against the goal of recovering gracefully from an accidentally exposed key; there always seems to be some compromise with the absolute ability to prove things to a third party. But that argument isn't the reason we use the term "sign".)

For both public-key and shared-secret systems we have the pair "encrypt" and "decrypt" for the functions that provide confidentiality. We need a similar pair of named functions for authentication. "verify" is pretty good for the second one, and "sign" is currently standing in as a name for the first function. "authenticate" might seem plausible but it doesn't work, because it is frequently also used in the sense of "verify". (As in "The first thing the recipient should do is authenticate the origin of the message.") So we continue to look for a good solution to this problem; suggestions are welcome.

The second major area of terminology trouble lies in the labels for the two major kinds of cryptographic systems. The label "public-key system" is by now too firmly attached to be dislodged (the 1970 inventors used the label "non-secret encryption," but their work was classified, so no one found out about that label until too late), so the issue is what label to use for the other kind of system. The obvious opposite, "private-key system" leads to confusion, because the public key system involves key pairs, one of which is identified as the "private key", the other as the "public key". Workers in the field recognized that confusion immediately, and began using the term "secret-key system". But that label has the problem that most people have trouble kenning a difference between "private" and "secret". The most popular work-around is to invent a completely distinct term: call a system that uses shared keys a "symmetric-key system". Unfortunately, there is not much intuition accompanying the adjective "symmetric", so it is hard to keep in mind.

In 6.033 we instead use a term that appeals much more strongly to the intuition. We call these systems "shared-secret systems". This label has the advantage that the words strongly reinforce the fundamental distinction between the two systems; public-key systems do not have shared secrets, shared-secret systems do.

With this one departure, the 6.033 preferred terms match those used in (and defined in section 1.1 of):

Bruce Schneier. Applied Cryptography. John Wiley and Sons, second edition, 1996. ISBN: 0-471-11709-9 (paperback). 758 pages.