Cryptography: Beginning with a Simple Communication Game

This chapter is from the book

Modern Cryptography: Theory and Practice

Learn More Buy

This chapter is from the book

This chapter is from the book 

Modern Cryptography: Theory and Practice

Learn More Buy

We begin this book with a simple example of applying cryptography to solve a simple problem. This example of cryptographic application serves three purposes from which we will unfold the topics of this book:

• To provide an initial demonstration on the effectiveness and practicality of using cryptography for solving subtle problems in applications

• To suggest an initial hint on the foundation of cryptography

• To begin our process of establishing a required mindset for conducting the development of cryptographic systems for information security

To begin with, we shall pose a trivially simple problem and then solve it with an equally simple solution. The solution is a two-party game which is very familiar to all of us. However, we will realize that our simple game soon becomes troublesome when our game-playing parties are physically remote from each other. The physical separation of the game-playing parties eliminates the basis for the game to be played fairly. The trouble then is, the game-playing parties cannot trust the other side to play the game fairly.

The need for a fair playing of the game for remote players will "inspire" us to strengthen our simple game by protecting it with a shield of armor. Our strengthening method follows the long established idea for protecting communications over open networks: hiding information using cryptography.

After having applied cryptography and reached a quality solution to our first security problem, we shall conduct a series of discussions on the quality criteria for cryptographic systems (§1.2). The discussions will serve as a background and cultural introduction to the areas in which we research and develop technologies for protecting sensitive information.

1.1 A Communication Game

Here is a simple problem. Two friends, Alice and Bob^a, want to spend an evening out together, but they cannot decide whether to go to the cinema or the opera. Nevertheless, they reach an agreement to let a coin decide: playing a coin tossing game which is very familiar to all of us.

Alice holds a coin and says to Bob, "You pick a side then I will toss the coin." Bob does so and then Alice tosses the coin in the air. Then they both look to see which side of the coin landed on top. If Bob's choice is on top, Bob may decide where they go; if the other side of the coin lands on top, Alice makes the decision.

In the study of communication procedures, a multi-party-played game like this one can be given a "scientific sounding" name: protocol. A protocol is a well-defined procedure running among a plural number of participating entities. We should note the importance of the plurality of the game participants; if a procedure is executed entirely by one entity only then it is a procedure and cannot be called a protocol.

1.1.1 Our First Application of Cryptography

Now imagine that the two friends are trying to run this protocol over the telephone. Alice offers Bob, "You pick a side. Then I will toss the coin and tell you whether or not you have won." Of course Bob will not agree, because he cannot verify the outcome of the coin toss.

However we can add a little bit of cryptography to this protocol and turn it into a version workable over the phone. The result will become a cryptographic protocol, our first cryptographic protocol in this book! For the time being, let us just consider our "cryptography" as a mathematical function f(x) which maps over the integers and has the following magic properties:

Property 1.1: Magic Function f

1. For every integer x, it is easy to compute f(x) from x, while given any value f(x) it is impossible to find any information about a pre-image x, e.g., whether x is an odd or even number.

   Protocol 1.1: Coin Flipping Over Telephone

   PREMISE

   Alice and Bob have agreed:

   1. a "magic function" f with properties specified in Property 1.1

   2. an even number x in f(x) represents HEADS and the other case represents TAILS

   (* Caution: due to (ii), this protocol has a weakness, see Exercise 1.2 *)

   1. Alice picks a large random integer x and computes f(x); she reads f(x) to Bob over the phone;

   2. Bob tells Alice his guess of x as even or odd;

   3. Alice reads x to Bob;

   4. Bob verifies f(x) and sees the correctness/incorrectness of his guess.

2. It impossible to find a pair of integers (x, y) satisfying x ≠ y and f(x) = f(y).

In Property 1.1, the adjectives "easy" and "impossible" have meanings which need further explanations. Also because these words are related to a degree of difficulty, we should be clear about their quantifications. However, since for now we view the function f as a magic one, it is safe for us to use these words in the way they are used in the common language. In Chapter 4 we will provide mathematical formulations for various uses of "easy" and "impossible" in this book. One important task for this book is to establish various quantitative meanings for "easy," "difficult" or even "impossible." In fact, as we will eventually see in the final technical chapter of this book (Chapter 19) that in our final realization of the coin-flipping protocol, the two uses of "impossible" for the "magic function" in Property 1.1 will have very different quantitative measures.

Suppose that the two friends have agreed on the magic function f. Suppose also that they have agreed that, e.g., an even number represents HEADS and an odd number represents TAILS. Now they are ready to run our first cryptographic protocol, Prot 1.1, over the phone.

It is not difficult to argue that Protocol "Coin Flipping Over Telephone" works quite well over the telephone. The following is a rudimentary "security analysis." (Warning: the reason for us to quote "security analysis" is because our analysis provided here is far from adequate.)

1.1.1.1 A Rudimentary "Security Analysis"

First, from "Property II" of f, Alice is unable to find two different numbers x and y, one is odd and the other even (this can be expressed as x ≠ y (mod 2)) such that f(x) = f(y). Thus, once having read the value f(x) to Bob over the phone (Step 1), Alice has committed to her choice of x and cannot change her mind. That's when Alice has completed her coin flipping.

Secondly, due to "Property I" of f, given the value f(x), Bob cannot determine whether the pre-image used by Alice is odd or even and so has to place his guess (in Step 2) as a real guess (i.e., an uneducated guess). At this point, Alice can convince Bob whether he has guessed right or wrong by revealing her pre-image x (Step 3). Indeed, Bob should be convinced if his own evaluation of f(x) (in Step 4) matches the value told by Alice in Step 1 and if he believes that the properties of the agreed function hold. Also, the coin-flipping is fair if x is taken from an adequately large space so Bob could not have a guessing advantage, that is, some strategy that gives him a greater than 50-50 chance of winning.

We should notice that in our "security analysis" for Prot 1.1 we have made a number of simplifications and omissions. As a result, the current version of the protocol is far from a concrete realization. Some of these simplifications and omissions will be discussed in this chapter. However, necessary techniques for a proper and concrete realization of this protocol and methodologies for analyzing its security will be the main topics for the remainder of the whole book. We shall defer the proper and concrete realization of Prot 1.1 (more precisely, the "magic function" f) to the final technical chapter of this book (Chapter 19). There, we will be technically ready to provide a formal security analysis on the concrete realization.

1.1.2 An Initial Hint on Foundations of Cryptography

Although our first protocol is very simple, it indeed qualifies as a cryptographic protocol because the "magic function" the protocol uses is a fundamental ingredient for modern cryptography: one-way function. The two magic properties listed in Property 1.1 pose two computationally intractable problems, one for Alice, and the other for Bob.

From our rudimentary security analysis for Prot 1.1 we can claim that the existence of one-way function implies a possibility for secure selection of recreation venue. The following is a reasonable generalization of this claim:

The existence of a one-way function implies the existence of a secure cryptographic system.

It is now well understood that the converse of this claim is also true:

The existence of a secure cryptographic system implies the existence of a one-way function.

It is widely believed that one-way function does exist. Therefore we are optimistic on securing our information. Our optimism is often confirmed by our everyday experience: many processes in our world, mathematical or otherwise, have a one-way property. Consider the following phenomenon in physics (though not an extremely precise analogy for mathematics): it is an easy process for a glass to fall on the floor and break into pieces while dispersing a certain amount of energy (e.g., heat, sound or even some dim light) into the surrounding environment. The reverse process, recollecting the dispersed energy and using it to reintegrate the broken pieces back into a whole glass, must be a very hard problem if not impossible. (If possible, the fully recollected energy could actually bounce the reintegrated glass back to the height where it started to fall!)

In Chapter 4 we shall see a class of mathematical functions which provide the needed one-way properties for modern cryptography.

1.1.3 Basis of Information Security: More than Computational Intractability

We have just claimed that information security requires certain mathematical properties. Moreover, we have further made an optimistic assertion in the converse direction: mathematical properties imply (i.e., guarantee) information security.

However, in reality, the latter statement is not unconditionally true! Security in real world applications depends on many real world issues. Let us explain this by continuing using our first protocol example.

We should point out that many important issues have not been considered in our rudimentary security analysis for Prot 1.1. In fact, Prot 1.1 itself is a much simplified specification. It has omitted some details which are important to the security services that the protocol is designed to offer. The omission has prevented us from asking several questions.

For instance, we may ask: has Alice really been forced to stick to her choice of x? Likewise, has Bob really been forced to stick to his even-odd guess of x? By "forced," we mean whether voice over telephone is sufficient for guaranteeing the strong mathematical property to take effect. We may also ask whether Alice has a good random number generator for her to acquire the random number x. This quality can be crucially important in a more serious application which requires making a fair decision.

All these details have been omitted from this simplified protocol specification and therefore they become hidden assumptions (more on this later). In fact, if this protocol is used for making a more serious decision, it should include some explicit instructions. For example, both participants may consider recording the other party's voice when the value f(x) and the even/odd guess are pronounced over the phone, and replay the record in case of dispute.

Often cryptographic systems and protocols, in particular, those introduced by a textbook on cryptography, are specified with simplifications similar to the case in Protocol "Coin Flipping Over Telephone." Simplifications can help to achieve presentation clarity, especially when some agreement may be thought of as obvious. But sometimes a hidden agreement or assumption may be subtle and can be exploited to result in a surprising consequence. This is somewhat ironic to the "presentation clarity" which is originally intended by omitting some details. A violation of an assumption of a security system may allow an attack to be exploited and the consequence can be the nullification of an intended service. It is particularly difficult to notice a violation of a hidden assumption. In §1.2.5 we shall provide a discussion on the importance of explicit design and specification of cryptographic systems.

A main theme of this book is to explain that security for real world applications has many application related subtleties which must be considered seriously.

1.1.4 Modern Role of Cryptography: Ensuring Fair Play of Games

Cryptography was once a preserve of governments. Military and diplomatic organizations used it to keep messages secret. Nowadays, however, cryptography has a modernized role in addition to keeping secrecy of information: ensuring fair play of "games" by a much enlarged population of "game players." That is part of the reasons why we have chosen to begin this book on cryptography with a communication game.

Deciding on a recreation venue may not be seen as a serious business, and so doing it via flipping a coin over the phone can be considered as just playing a small communication game for fun. However, there are many communications "games" which must be taken much more seriously. With more and more business and e-commerce activities being and to be conducted electronically over open communications networks, many cases of our communications involve various kinds of "game playing." (In the Preface of this book we have listed various business and services examples which can be conducted or offered electronically over open networks; all of them involve some interactive actions of the participants by following a set of rules, which can be viewed as "playing communication games".) These "games" can be very important!

In general, the "players" of such "games" are physically distant from each other and they communicate over open networks which are notorious for lack of security. The physical distance combined with the lack of security may help and/or encourage some of the "game players" (some of whom can even be uninvited) to try to defeat the rule of game in some clever way. The intention for defeating the rule of game is to try to gain some unentitled advantage, such as causing disclosure of confidential information, modification of data without detection, forgery of false evidence, repudiation of an obligation, damage of accountability or trust, reduction of availability or nullification of services, and so on. The importance of our modern communications in business, in the conduct of commerce and in providing services (and many more others, such as securing missions of companies, personal information, military actions and state affairs) mean that no unentitled advantage should be gained to a player who does not conform the rule of game.

In our development of the simple "Coin-Flipping-Over-Telephone" cryptographic protocol, we have witnessed the process whereby an easy-to-sabotage communication game evolves to a cryptographic protocol and thereby offers desired security services. Our example demonstrates the effectiveness of cryptography in maintaining the order of "game playing." Indeed, the use of cryptography is an effective and the only practical way to ensure secure communications over open computers and communications networks. Cryptographic protocols are just communication procedures armored with the use of cryptography and thereby have protective functions designed to keep communications in good order. The endless need for securing communications for electronic commerce, business and services coupled with another need for anticipating the ceaseless temptation of "breaking the rules of the game" have resulted in the existence of many cryptographic systems and protocols, which form the subject matter of this book.