U. Glaeser

Random Oracle Model
One direction of recent research is on the “random oracle model.” This is a design methodology for
protocols and primitives that make use of cryptographic hash functions. Pick a specific cryptographic
hash function such as MD-5. Its designers may believe that it is difficult to invert MD-5 or to find
collisions for it. However, this does not mean that MD-5 is a completely unpredictable function, with
no structure or regularity whatsoever. After all, the complete specification of MD-5 is publicly available
for inspection and analysis, unlike a truly random function that would be impossible to specify in a
compact manner. Nevertheless, the random oracle model asserts that a specific hash function like MD-5
behaves like a purely random function. This is part of a methodology for proving security properties of
cryptographic schemes that make use of hash functions.
This assumption was introduced by Fiat and Shamir [5] and later formalized by Bellare and Rogaway [6].
It has been applied to the design and analysis of many schemes (see, e.g., the discussion of optimal asymmetric
encryption padding in the subsection on “Chosen Ciphertext Security for Public Key Encryption”).
Recently, a cautionary note was sounded by Canetti, Goldreich, and Halevi [7]. They demonstrate by
construction that it is possible for a scheme to be secure in the random oracle model and yet have no secure
instantiation whatsoever when any hash function is substituted. This is a remarkable theoretical result;
however, the cryptographic community continues to base their designs on the random oracle model, and
with good reason. Although it cannot provide complete assurance about the security of a design, a proof
in the random oracle model provides confidence about the impossibility of a wide range of attacks. Specifically,
it rules out common attacks where the adversary ignores the inner workings of the hash function
and treats it as a “black box.” The vast majority of protocol failures are due to this kind of black box attack,
and thus the random oracle model remains an invaluable addition to the cryptographer’s tool kit.
43.3
© 2002 by CRC Press LLC
Symmetric Key Cryptographic Primitives
The main symmetric key cryptographic primitives are discussed including block ciphers, stream ciphers,
and message authentication codes.
Symmetric Key Block Ciphers
A symmetric key block cipher is a parameterized family of functions EK,
where each EK
is a permutation
on the space of bit strings of some fixed length. The input to EK
is called the “plaintext” block, the output
is called the “ciphertext” block, and K is called the “key.” The function EK
is called an “encryption”
function. The inverse of EK
is called a “decryption” function, and is denoted DK.
To encrypt a message that is longer than the fixed-length block, it is typical to employ a block cipher
in a well-defined “mode of operation.” Popular modes of operation include output feedback mode, cipher
feedback mode, and cipher block chaining mode; see [8] for a good overview. In this way, the plaintext
and ciphertext can be bit strings of arbitrary (and equal) length. New modes of operations are being
solicited in connection with the development of the Advanced Encryption Standard (see subsection
“Advanced Encryption Standard (AES)”).
The purpose of symmetric key encryption is to provide data confidentiality. Security can be stated at a
number of levels. It is always assumed that the attacker has access to a complete specification of the
parameterized family of encryption functions and to a ciphertext of adequate length. Beyond that, the
specific level of security depends on the goals and resources of the attacker. An attacker might attempt a
“total break” of the cipher, which would correspond to learning the key K.
An attacker might attempt a
“partial break” of the cipher, which would correspond to learning some or all of the plaintext for a given
ciphertext. An attacker might have no resources beyond a description of the block cipher and a sample
ciphertext, in which case he is mounting a “ciphertext-only attack.” An attacker might mount a “knownplaintext
attack,” if he is given a number of plaintext-ciphertext pairs to work with (input-output pairs for
the encryption function). If the attacker is allowed to choose plaintexts and then see the corresponding
ciphertexts, then he is engaged in a “chosen-plaintext attack.”