Introduction - Contemporary Cryptography - page 6

Remember the definition for a cryptographic system (or cryptosystem) given
in RFC 2828 and quoted on page 3. According to this definition, a cryptosystem
may comprise more than one algorithm, and the algorithms may not necessarily be
executed by the same entity (i.e., they may be executed by multiple entities in a dis-
tributed way). Consequently, this notion of a cryptosystem comprises the notion of
a cryptographic protocol as suggested in Definition 1.4. Hence, another way to look
at cryptographic algorithms and protocols is to say that a cryptographic algorithm
is a single-entity cryptosystem , whereas a cryptographic protocol is a multientity or
multiple entities cryptosystem . These terms, however, are less frequently used in the
literature. We don't use them in this topic either.
In either case, it is important to note that cryptographic applications may
consist of multiple (sub)protocols, that these (sub)protocols and their concurrent
executions may interact in some subtle ways, and that these interactions and interde-
pendencies may be exploited by various chosen-protocol attacks (see, for example,
[7] for the notion of a chosen-protocol attack). As of this writing, we are just at the
beginning of properly understanding chosen-protocol attacks and what they can be
used for in cryptanalysis. These attacks are not further addressed in this topic.
In the cryptographic literature, it is quite common to use human names to refer
to the entities that take part and participate in a cryptographic protocol (e.g., a Diffie-
Hellman key exchange). For example, in a two-party protocol the participating
entities are usually called Alice and Bob . This is a convenient way of making things
unambiguous with relatively few words, since the pronoun she can then be used for
Alice, and he can be used for Bob. The disadvantage of this naming scheme is that
people assume that the names are referring to people. This need not be the case, and
Alice, Bob, and all other entities may be computer systems, cryptographic devices,
or anything else. In this topic, we don't follow the tradition of using Alice, Bob, and
the rest of the gang. Instead, we use single-letter characters, such as A, B, C, ... ,to
refer to the entities that take part and participate in a cryptographic protocol. This is
less fun (I guess), but more appropriate (I hope).
The cryptographic literature is also full of examples of more or less useful
cryptographic protocols. Some of these protocols are overviewed, discussed, and
put into perspective in this topic. To formally describe a (cryptographic) protocol in
which two parties (i.e., A and B) take part, we use the notation sketched in Protocol
1.1. Some input parameters may be required on either side of the protocol (note that
the input parameters are not necessarily the same). The protocol then includes a set
of computational and communicational steps. Each computational step may occur
only on one side of the protocol, whereas each communicational step requires data
to be transferred from one side to the other. In this case, the direction of the data
transmission is indicated with a directed arrow. Finally, some parameters may be
output on either side of the protocol. These output parameters actually represent