Rheinische Friedrich-Wilhelms-Universitat Bonn Institute of Computer Science III Prof. Armin B.

Cremers Adrian Spalka

Basics of Computer Security

Cryptographic Protocols
Peter Simons <simons@cs.bonn.edu>

October 20, 1996

Contents
1 Introduction to Cryptographic Protocols
1.1 1.2 1.3 1.4 Overview of the paper . . . . . . . . . . . De nition of a \protocol" . . . . . . . . . How protocols are described in this paper Di erent kinds of protocols . . . . . . . . 1.4.1 Arbitrated protocols . . . . . . . . 1.4.2 Adjudicated protocols . . . . . . . 1.4.3 Self-enforcing protocols . . . . . . 1.5 Fundamental cryptography . . . . . . . . 1.5.1 One way functions . . . . . . . . . 1.5.2 Conventional encryption . . . . . . 1.5.3 Public key encryption . . . . . . . 1.5.4 Digital Signatures . . . . . . . . . 1.6 Attacking a protocol . . . . . . . . . . . . 1.6.1 Eavesdropping and monitoring . . 1.6.2 Cheating . . . . . . . . . . . . . . 1.6.3 Denial of service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3 4 5 5 6 6 7 7 7 7 10 10 10 11 12

2 Simple cryptographic protocols 3 Secure Communication

3.1 3.2 3.3 3.4 3.5

2.1 Fair coin ip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2 Blind Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Secure key exchange using symmetric encryption . Secure key exchange using asymmetric encryption Interlock Protocol . . . . . . . . . . . . . . . . . . Getting a Receipt . . . . . . . . . . . . . . . . . . . Covert Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13 16

16 17 17 18 19

4 Digital Cash

4.1 A simple digital cash protocol . . . . . . . . . . . . . . . . . . . . 22 4.2 The perfect crime . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

22 25 29

5 Practical issues when using cryptographic protocols 6 References

Chapter 1

Introduction to Cryptographic Protocols

A few years ago, the eld of cryptography was of interest only for security agencies, governments, companies and criminals. With the growing signi cance of electronic communication, this interesting science became the subject of major research and popular attention. Astonishingly, most followers of recent developments seem to concentrate on the security of encryption algorithms. The theory of scrambling bits and byte in the most complicated fashion is, what most people understand under the term \cryptography". Nowadays, encryption algorithms are available, that are commonly regarded as \relatively secure". DES, IDEA or RSA are well known examples. But, now that we have secure encryption, what can we use it for? It is a curious thing that encryption by itself is not very useful in most cases. Processes, we all are performing numerous times a day, seem to be impossible in the telecommunication world. A very good example is the coin ip as a decision maker. Two friends want to go to the cinema together. The problem is just, that they can not agree on a lm to see. So they agree to let a coin decide the argument. One of them picks a side of the coin. The other one tosses the coin in the air. Then they both look which side of the coin landed on top. If the \chosen" side is on top, the one who chose may decide which lm to see. If the other side of the coin lands on top, the one other friend decides about the lm. Everybody has done something like that before and we all know that this is a fair way to decide an argument, because both outcomes are equally likely. Now imagine you are trying to use this method while talking to a friend on the phone. He o ers you: \You pick a side. Then I will throw the coin and tell you whether you have won or not." Of course you will not agree, because you can not verify the outcome of the coin toss. Cryptographic protocols are the solution for this situation.

1.1 Overview of the paper

Chapter 1 will serve as an introduction to the topic of cryptographic protocols, explaining the purpose of a protocol itself and explaining fundamental cryptog2

raphy as required and used by the protocols described later. Furthermore, the chapter will deal with ways of attacking a protocol. In Chapter 2, two rather simple cryptographic protocols will be described, including a detailed analysis of possible attacks and how the protocols protects the participants from these attacks. Chapter 3 describes various protocols dealing with secure communication, what is not just raw encryption of the communication, but smart ways of exchanging the encryption keys over insecure channels, getting receipts or completely covert communication. A protocol implementing digital cash is introduced in chapter 4. While the protocol is relatively simple, compared to other digital cash protocols, it is still quite powerful and ful lls requirements, such as anonymity of the moneyspender, todays credit cards do not ful ll. Practical issues of the protocols introduced in this paper will nally be discussed in chapter 5. \Practical issues" includes an analysis of how usable the protocols are and whether they can realistically solve real world problems. A brief list of references and other resources will be presented in chapter 6. During the researches for this paper, certain books and Internet URLs have been particularly helpful and here the authors of these resources is given credit. Furthermore, the references are meant as a recommended list of reading for the reader who wants to know more about this exciting eld of science.

1.2 De nition of a \protocol"

A protocol is an agreement between two or more parties. An example is the business man who is invited to a formal dinner by his boss. Even though he and his boss did not explicitly agree on a certain protocol, there is a well de ned series of steps that have to be performed: 1. The business man has to show up at an agreed time. He absolutely has to arrive at the boss' house at a certain time, he must not be too early, neither must be be too late. 2. The business man introduces the lady, he brought with him, to his boss. 3. The boss is delighted, likes the appearance and the dress of the lady. Then he carefully kisses her hand. 4. The lady is very happy to have the chance of nally getting to know the boss of her husband or boy-friend. 5. For obscure reasons the dinner is not nished yet and the boss and the guests are standing around for a moment. Hence, everybody gets himself something to drink and performs another protocol known as \small talk". Common examples of small talk are \weather", \politics" and other protocols, that are beyond the scope of this paper. 6. and so on. .. If any of the involved parties does not follow these steps, it is regarded as a violation of the protocol. Just imagine that the businessman brought a football 3

team mate with him, rather than a lady. Or imagine the boss making remarks about the lady's face being very pale and ugly! A cryptographic protocol, nally, is absolutely the same. A cryptographic protocol is a series of steps that have to be performed in order to get a certain task done. The problems cryptographic protocols solve do usually not include getting a promotion during a formal dinner, though, but they deal with issues of authentication, privacy and secrecy. A protocol has the following characteristics: The protocol solves a certain problem or produces a certain result. The protocol consists of a well de ned series of steps. \Well de ned" in this context means, that the protocols covers all possible situations, that may arise during its execution. At all times, it must be clear what has to be done next. The steps have to be known in advance. Furthermore, the protocol must nally terminate. When all steps have been followed exactly, the given problem has been solved. The protocol involves two or more parties. A receipt for baking cakes is a series of well de ned steps, too, and a person can dedicatedly follow these steps to bake the cake. But that is not a protocol, it's just a receipt. All involved parties know the protocol and have agreed to follow it. Obviously the protocol is worthless if a party involved in its execution does not know the steps to perform. It is equally worthless, it one or several parties have no interest in following the protocol. If the business men wants to quit his job anyway, it is pointless to invite him to a formal dinner. A party that pretends to follow the protocol, but actually does not is cheating. The protocol clearly de nes what every involved party gains by its execution. A protocol that is designed to transfer money from one person to another by electronic means is not a very good protocol if the recipient learns the account number and the password of the sender during the protocol execution. If that happens, though, it must at least be clear to both of the involved parties before performing the protocol. Both parties should know the risks they accept by performing a protocol.

1.3 How protocols are described in this paper

Unfortunately, there is no fool-proof notation to describe a protocol in a way that everybody understands it easily. Thus, protocols in this paper will be described in a series of numbered steps, like the dinner example above, which can be executed linearly, unless a branch or loop is explicitly stated otherwise. Experience has shown that protocols, especially the more complicated ones, are not quite easy to understand just by looking at them. It is recommended to try the protocol with a pencil and a piece of paper in a notation that seems 4

natural to the reader. Actually performing the protocol step by step, makes the concept behind the di erent steps clearer to the reader than a thousand words of text could do. To help demonstrating the protocols, the following persons will be used throughout the paper: Alice First participant in all the protocols Bob Second participant in all the protocols Mallory Malicious active attacker Trent Trusted arbitrator Walter Warden he will be guarding Alice and Bob in some protocols The acting persons will be introduced in greater detail soon.

1.4 Di erent kinds of protocols

Basically, there are three di erent kinds of protocols.

1.4.1 Arbitrated protocols

Arbitrated protocols

rely on a third, trusted party to complete. The arbitrator is trusted not to prefer any of the involved parties in any way. In real life, this part is played by a disinterested third party, like an independent lawyer. A good example is the situation where Alice wants to sell her car to Bob. Bob wants to pay by check. She does not know Bob, though, and does not trust his check to be good. So she does not want to give Bob the car until the bank has approved the check. Bob, on the other hand, does not trust Alice any farther than she trusts him and is afraid that he will hand Alice the check without ever getting the keys and the papers for the car. The funny thing is that Alice really wants to sell Bob the car and that Bob really wants to buy it. Yet, they can not complete the deal without help. Here Trent, an independent lawyer comes into play. With Trent's help, Alice and Bob can perform the deal securely: 1. Alice gives the keys and papers for the car to Trent. 2. Bob gives the check to Alice. 3. Alice deposits the check at the bank. 4. If the check clears, Trent gives the papers and keys to Bob. If the check does not clear, Trent returns the items to Alice. Of course Alice has to show a proof to Trent in case the bank denied cashing the check. This is an arbitrated protocol, because both Alice and Bob rely on the trusted arbitrator not to cheat. In general, Trent has no interest in cheating. He is paid in either case, no matter whether the deal works out or not. Arbitrated protocols work ne if the arbitrator is trustworthy. Alice should be suspicious about performing this protocol, though, if the name of the lawyer is not \Trent" but \Bobs Brother". 5

These kind of protocols are usually impractical in the computer world, where it is hard to nd a trusted party that acts neutral. For some purposes a lawyer or a governmental institution may be tting, for others it is highly inappropriate.

1.4.2 Adjudicated protocols

Adjudicated protocols

are a variation of arbitrated protocols. They do also rely on a third, trusted party. In an adjudicated protocol, this party is not always required, though. The involved parties execute the protocol as speci ed. If all parties follow the protocol, the result is achieved without the help of the third party, usually called the adjudicator. Only in case an involved party thinks, one or several other parties are cheating, it calls the adjudicator for help. The adjudicator will then analyze the dispute and rule who is right and what has to be done. In our car-selling example, this protocol would look as follows: Alice gives the keys and papers for the car to Bob. Bob gives the check to Alice. If the check does not clear, or if the keys and papers turn out to be faked, Bob and Alice appear before a judge and both present their evidence. The judge rules on the evidence and the party that cheated is cast to jail. This protocol comes closest to what we all are doing in everyday life. We trust each other to a certain degree, because we know that a court full of judges exists and will rule disputes. These kind of protocols are, as has been said above, very similar to arbitrated protocols, because they rely on a third party. An enhancement is, though, that this third party is only required in case of a dispute. Given the high costs for lawyers, this can be a signi cant advantage. If we assume that both parties want to ful ll the protocol, adjudicated protocols will do ne in most cases. A serious disadvantage is, though, that judging the dispute might not always be very easy. Depending on the quality of the evidences, the party that has been cheated on might very well not get its right. Obviously, it is the task of the protocol to produce good evidences if one or several parties are cheating. Another aspect of adjudicated protocols is the penality, that is cast on the cheating party. In nowadays society, this is usually a certain amount of money, or even a few months (or more) in jail. This penality has to mean enough to scare people away from cheating the protocol.

1.4.3 Self-enforcing protocols

Self-enforcing protocols

are the \best" protocols. Such a protocol is designed in a way, that makes cheating virtually impossible. No arbitrator is required, neither is a judge. The protocol guarantees the following quality: If any of the involved parties cheats, the cheating is immediately discovered by the other party or parties. Whatever the cheaters tried to achieve by not following the protocol does not happen. No party is able to gain any advantage by cheating. 6

In an ideal world, all protocols would be self-enforcing. Not necessarily in a judge's ideal world, though. Unfortunately, not every problem has a selfenforcing solution yet. And many self-enforcing protocols are a lot of work for all participants. For all these reasons, arbitrated and especially adjudicated protocols are commonly used, even though a self-enforcing protocols for the same task is available.

1.5 Fundamental cryptography

Before discussing the various protocols in detail, a number of cryptographic concepts has to be explained, because the presented protocols rely on them. One of the most important concept in cryptographic protocols is the one way . Given x, f (x) = x is relatively easy to compute. Given x , though, f 1 (x ) = x is very hard or even impossible to compute. Furthermore it is very di cult, to nd an x2 that ful lls f (x2 ) = f (x) within reasonable time, even if x is known. One way functions are commonly used as checksums in telecommunication, for example. Well known and proven algorithms are the Cyclic Redundancy Check (CRC) or the message digest, MD5.
function
; 0 0 0

1.5.1 One way functions

is almost as old as mankind itself. Given an algorithm f , a message m and a key k, an enciphered message is computed as follows:
Conventional encryption

1.5.2 Conventional encryption

f (m k ) = m . The original message can be recovered by computing

0

f (m k) = m. Examples for conventional, or symmetric encryption algorithms, that are commonly regarded as secure, are the Digital Encryption Standards (DES) or the International Data Encryption Algorithm (IDEA).
0

1.5.3 Public key encryption

Public key encryption, also called asymmetric encryption has been discovered in 1976 by Martin Hellman and Whit eld Di e, and independently by Ralph Merkle. Public key encryption uses not one, but two keys to perform encryption and decryption. If the two keys are called a and b, then encryption is performed by calculating

f (m a) = m , and decryption is done by calculating

0

f (m b) = m. This process works also vice versa:

0

f (m b) = m f (m a) = m. The two keys a and b are related in a certain mathematical way, which depends on the used algorithm. The most popular one, RSA, will be introduced later in the section. Vital is, in any case, that it is very di cult to calculate b, even if a is known, and vice versa. The name \public key encryption" describes the strategy used with this system very well: Alice generates a pair of keys and calls one key her \public key" and the other one her \secret key". Now she openly distributes her public key. Everybody who wants to send Alice an enciphered message can obtain her public key through insecure channels and encrypt a message using this key. Then he sends the encrypted message to Alice, who uses her secret key to recover the plain-text. Bob, for example, would be able to send a secure message to Alice, even though the two of them have never met, maybe even do not know each other by now. Because Alice keeps the second key of the pair secret, nobody else is able to decrypt the enciphered message. A well known algorithm for public key encryption is RSA, which is named after its three inventors: Ron Rivest, Adi Shamir and Leonard Adleman. RSA uses primes to archive the public key e ect and works as follows:
0 0

1. Choose two primes p and q. In todays real life applications, these primes should be at least 512 bit long. 2. Calculate N = pq. This value N is called the modulus of RSA. When both p and q are 512 bits long, N will be 1024 bit long. These 1024 bits are commonly referred to as the key length or modulus length. 3. Calculate m = (p ; 1)(q ; 1). 4. Choose your encryptor E . Usually E has the value 216 + 1, but RSA will work with any E you will choose. 5. Now you have to nd a number d which is relatively prime to E and m, what means that it ful lls this equation: Ed mod m = 1. With a chosen E , you can calculate d using the extended Euclidean algorithm, which will not be described here but can be found in the mathematical literature. 6. Now your public key consists of E and N , while your secret key consists of d and N . Once you have your key generated, you can encrypt a message with someone's public key as follows: m = mE mod N . m can be any numerical representation of the message you want to encrypt. For encrypting texts, the ASCII code is well suited for this purpose.
0

The recipient of the encrypted message m can now recover the plain text by calculating: m = m d mod N . Encryption and decryption work in both ways. What is encrypted with E will be decrypted with d and vice versa. It is just a convention that the encryptor is E . The big advantage of this encryption scheme is, that you can openly distribute your public key E and N . You could upload these two numbers to a public key server and everybody could obtain them and use the key to encrypt a message. Only the person who knows d is able to recover the plain text. Even though you're distributing your key through insecure channels, the encrypted message for you is secure as long as nobody is able to steal your secret key d. Obviously, this system can be attacked quite easily. An attacker knows E and N , so all he has to do is to factorize N for p and q. Then he can calculate m, quickly nd your d and read your encrypted mail. The problem is just, that no algorithm to factor N e ciently is known today. Generating the large prime numbers p and q is very easy, calculating with them is something every personal computer is capable of. But going the other way of nding a certain pair of p and q when only their product is known, is virtually impossible. A modern PC can do all required calculations to generate a 2048 bit key in very short time. But factoring this 2048 bit number is way beyond the scope of what can be done. Not only would the calculations require dozens of centuries, but memory is also an important factor. Using the most e cient number sieve known today, the factoring would result in a matrix with 10150 elements. Unfortunately, the Universe features only approximately 10100 atoms! Even if we could store a multi-digit number in a single atom, the calculation could not be done. Cryptoanalysts have proposed numerous ways to crack RSA, including quantum computers and biological calculation machines, but none of these attacks looks likely within the next hundred years or beyond. RSA, and public key encryption in general, does have a few disadvantages, though. First of all, the required calculations are very slow. Even using short cuts like the Chinese Remainder Theorem, Smith's fast modulus and other algorithms, a Pentium 120 requires several seconds to en-/decrypt a message with a 1024 bit RSA key. One trick to use RSA in reasonable time, though, is a hybrid system. That means that the actual message is encrypted using a conventional algorithm such as DES or IDEA. The key for the conventional algorithm is created randomly and is called a session key. Then this session key is encrypted with RSA and appended to the message. The advantage is that a session key is only, say, 128 bit long, depending on the used algorithm, while the actual message may be several kilobyte long. Another disadvantage is that all RSA encrypted messages will fall once an e cient factoring algorithm is discovered. Rumor has it that the National Security Agency (NSA) is already able to crack RSA, but no evidence was ever shown. However, whether the NSA can factor large numbers or not, it is absolutely possible that such an algorithm will be discovered in the very near future. Last but not least, it is not proven yet, that factoring N is the only way to crack RSA. There might well be a di erent attack, which is able to calculate d
0 0

without having to factor N . It just has not been discovered yet.

1.5.4 Digital Signatures

Next to secrecy, authenticy is one of the prime goals of cryptography. A digital signature is a proof that a certain message was really written by Alice, for example. Furthermore, signatures usually guarantee that a message has not been tampered with. Using one-way hash functions and public key encryption, a signature can, for example, be issued as follows: 1. Calculate a certain one-way function over the to-be-signed message (checksum). 2. Encrypt this checksum using your secret key. 3. Append the encrypted checksum to the document. Now, anybody who knows the appropriate public key, is able to verify who wrote the document. Using the public key of, say, Alice, Bob is able to recover the checksum. Then he calculates the checksum, over the message he received and compares it with the checksum that was appended to the message. If the two checksums are identical, he knows for sure that the owner of the secret key, matching the public key he used, has created this signature.

1.6 Attacking a protocol

Like any other cryptographic concept, a cryptographic protocol is subject of attack by outsiders or even involved parties. A good protocol resists all attempts to cheat and to gain an advantage over the other participants. Each attack comes in two versions: An active attack or a passive attack. The di erence will be explained brie y in the following sections. Often, cryptography is used to secure an electronic conversation two people are having. An example are two business men or women discussing the details of a huge deal. Some people would be very interested in the information exchanged in these talks. May it be the boss of a third company who is in the same business as the other two, may it be a stock broker who can make millions of dollars by obtaining the right shares at the right time. Then these interested parties would certainly try to espionage the details of the deal. One possibility is by eavesdropping the telephone lines the two company bosses are using. This is considered a passive attack, because the attacker is merely listening. He or she does not actively disturb the protocol. This kind of attack is very di cult to discover. For years, conventional encryption was the only way to defend against eavesdropping. Still the weak point is the exchange of the keys for the algorithm, because the eavesdropper will certainly read the keys, too, and will be able to decrypt the conversation. Public key encryption solves this problem to a certain extent. 10

1.6.1 Eavesdropping and monitoring

But often, the mere knowledge that a conversation takes place is all the attacker needs to know. If an eavesdropper notices that the bosses of two big companies are talking to each other very often, he might be able to guess what is happening. This is called monitoring or traffic analysis. The person monitoring the telephone line might not be able to recover the contents of the message, but he knows that an encrypted conversation is taking place. An active eavesdropper might even be able to recover the contents of the encrypted conversation by using the so called man in the middle attack. Let's assume the two company bosses use public key encryption to protect themselves from a passive eavesdropper. Mallory, the mean active attacker, sits in the middle of the line between Boss Alice and Boss Bob. Now Alice sends Bob her public key to enable him to answer her with an enciphered message. Mallory intercepts the public key, generates a new one and sends it to Bob. Bob receives a key that pretends to be Alice's. So he sends his public key back over the same line. Mallory intercepts and replaces this key, too, by one of his own. Now Alice and Bob will start their message exchange. Mallory intercepts a message from Alice, which is encrypted with the key, she assumes to be Bob's. In fact, though, it is one of Mallory's keys and he can contently decrypt the message. Then he encrypts the recovered plain-text with Bob's real public key and sends the resulting cipher-text to Bob. Bob receives a valid message encrypted with his public key and assumes the sender to be Alice, and so on. . . Alice and Bob will never notice, that someone else is reading their messages. It comes even worse. Not only can Mallory read the encrypted conversation, he can even modify or completely re-write the text of the messages, preventing Alice and Bob from agreeing on a deal. Not even signed messages pose a problem for Bob, because he can sign the faked messages with the key, the recipient believes to be the other one's secret key. This attack is quite vicious and it is very hard to defend against. In fact, this attack is quite easy to do, considering the structure of todays distributed computer networks.

1.6.2 Cheating
Cheating

is an attack that can only be done by parties involved in the protocol. A cheating party does knowingly not follow the protocol. Mallory could, for example, knowingly distribute incorrect data, or he could simply abort the protocol during execution. In any case, this will make the protocol fail. Good protocols, especially self-enforcing ones, will make the cheating obvious, so that Mallory can not gain any advantage by doing so. Other protocols may very well leave him with more information, money or whatever the protocol is about, than the other participating parties would like to. Even though almost any protocol detects cheating quickly, not all protocols reveal the cheater. In these kind of protocols, the cheater does not even risk a penality of violating the protocol. A passive cheater is a participant of the protocol, who follows the de ned steps, but tries to obtain more information than the protocol intends him to. An active cheater tries to disrupt the protocol in progress, either for obtaining 11

more information than intended, or for other reasons, such as a denial of service attack.

1.6.3 Denial of service

The denial of service attack is very hard to defend against. \Denial of service" means, that an attacker tries to make the protocol fail in any way. Assume, for example, that Alice has to call Bob urgently, to let him know that a mean Ma a killer is going to murder him. Mallory, another mean Ma a killer, though, simply cuts her telephone cables, so that she is not able to perform the protocol. That is denial of service. Another, less violent, example is, that Alice maintains an enciphered conversation with Bob, her boy-friend. Bob is on travel and encrypted e-mail is the only channel he has to reach his girl. Mallory, who has been in love with Alice for months, sits in the middle and ips a few bits in the enciphered message. He can not read the contents of the message, but he can simply destroy it. Alice and Bob can not \talk" to each other. Alice, who is very alone now, spends a lot of time with Mallory, nally falls in love with him and leaves Bob. That is an even worse denial of service.

12

Chapter 2

Simple cryptographic protocols

2.1 Fair coin ip
A very impressive protocol is the fair coin ip, which has been mentioned in chapter 1, page 2 already. Alice and Bob would like to go the cinema. Alice calls Bob on the phone and asks him, what lm they are going to see and proposes to watch \Attack of Killer-Mallory", a shockingly violent horror lm. Bob on the other hand favors \Eve alone in paradise". Alice and Bob decide to let the coin decide. They use the following protocol: 1. Alice and Bob agree on a one-way function. 2. Bob makes up a long random number. Then he ips a coin. Depending on whether head or tail comes out, he appends a \0" (zero) or \1" (one) bit at the end of the binary representation of the number. He furthermore performs the one-way function using the result as input. 3. Bob tells Alice the result of his calculation. 4. Alice picks either head (\1") or tail (\0") and tells Bob. 5. Bob reveals the random number he picked and tells Alice whether she has won or not. 6. Alice veri es Bob's calculation. This protocol is self-enforcing. Neither Alice nor Bob can cheat and the outcome of the coin ip is the same as if Alice and Bob had done it while sitting next to each other. To verify that, let's see what happens when, say, Bob tries to cheat. At step 2, he has to say Alice a value, which is supposed to be the result of f (x). The lowest bit of x represents the outcome of our imaginatory coin toss. No matter whether Bob chooses a \0" or a \1" as the lowest bit, Alice has a fair chance, 50% that is, of guessing the value correctly and winning. If Alice guesses correctly, she will learn that she has won at step 5, when Bob reveals the random number he has picked. If Bob cheats and tells her a 13

di erent random number, with the lowest bit inversed, Alice will notice it when she veri es that f (x) results in the same value as Bob told her in step 3: It will not, because a one way hash function has the quality x 6= x =) f (x) 6= f (x ).
0 0

Bob could cheat, if he could come up with an x and an x that ful ll f (x) = f (x ). Furthermore the lowest bit of x has to be \0", while the lowest bit of x is \1". Then he can contently announce the result of the one way function and reveal either x or x , depending on which one suits his plans better. This attack is very unlikely, though. Finding such an x/x collision in a MD5 hash, for example, has a chance of 1 in 2128. Even if it is theoretically possible to nd a collision in a one way hash function, Bob has to do it quickly, because Alice is waiting on the phone. If he spends more than a few moments calculating, Alice would become suspicious and abort the protocol. The only other way Bob has to avoid losing the coin toss is to abort the protocol at step 4. After Alice told him her pick, Bob knows whether he has won or not. If not, he refuses to complete the protocol and does not tell Alice the random number he picked. By doing so, it is very obvious to Alice that Bob cheats, though, and she will eventually stop going to the cinema with him. Bob gains nothing by doing so. He has prevented Alice from winning the toss, but he has not won himself either. No party participating in the protocol has lost anything. Alice, on the other hand, cannot cheat either. At step 3 Bob tells Alice the result of f (x), where x is the random number including the bit that determines the outcome of the imaginatory coin toss. But due to the nature of a one way function, Alice can not reverse the calculation: f 1 (y) = x. If she could, she would always win. Anyway, she can not. At this point she has to pick either \0" or \1". Once she does, she clearly wins or loses. She could refuse to continue the protocol and abort at this point. By doing so, though, she does not gain any advantage. Neither Bob nor Alice can cheat without immediately being discovered. The protocol is self-enforcing, because no third trustee is required.
0 0 0 0 0 ;

2.2 Blind Signatures

Sometimes it is desirable that one persons signs a document without knowing its contents. Just imagine the following situation: Alice is an undercover agent for a secret three letter agency. Alice's job is to travel to another country to spy. Since this job is quite dangerous, the agency wants to issue a document for Alice that gives her diplomatic immunity in case something goes wrong. The problem is just that Alice's cover name is secret, too. Even the agency itself does not not know the cover name she is using. Alice can not simply tell the directory of the Agency, Bob, her cover name and have him issue the require document. Of course Bob can neither sign a document blindly, because Alice could make him sign virtually anything then. So they use the blind signature protocol: 14

1. Alice makes up ten cover names. She uses the standard form for diplomatic immunityand inserts one name a time. Then she puts each of the ten forms into a special envelope, which is made of carbon paper on the inside. 2. Alice gives all ten envelopes to Bob. 3. Bob opens nine envelopes and veri es the document inside. 4. If all nine documents are correct forms, Bob signs the tenth envelope without opening it. The signature is copied through the carbon paper on the form inside. 5. Bob gives the unopened envelope back to Alice, who takes the form out and veri es, that the signature is okay. This protocol is also self-enforcing. Bob has no chance of cheating. If he signs the document under a wrong name, Alice will notice it. If he opens all ten envelopes, she will notice it, too. Alice's chances of cheating are small. If she gives Bob nine correct letters and one with a wrong document saying that Bob would owe her a million dollar, she will be discovered in nine out of ten cases. Her chance of getting away with it are 1=n. If the number of envelopes is high enough, Alice's chances are too small to accept the risk of being catched cheating. If this protocol is transferred to digital means, the \envelope" can not be used anymore, of course. Then Alice will use a technique called \blinding", which works as follows: 1. Alice takes a message and raises it to the power of b. b is a long random number and is usually called the blinding factor. 2. Alice gives the blinded message to Bob. 3. Bob signs it, and returns the result to Alice. 4. Alice divides out the blinding factor, leaving the original document signed by Bob. This protocol works only if the signing function and the multiplication are commutative. But even if they are not, plenty other methods of blinding a document other than by multiplication exist. The \opening an envelope" step in the described protocol would be, to reveal the blinding factor of a message to Bob. The protocol works the same.

15

Chapter 3

Secure Communication
Protecting the communication between two or more parties is a central goal of cryptography. \Protection", though, does not only mean \hiding it from others". Sending anonymous messages, secure key exchange or getting a receipt for a sent message are also important issues besides simply scrambling the plaintext.

3.1 Secure key exchange using symmetric encryption

Exchanging the keys for a cryptographic algorithms is the hardest part of real secure communication. The channel the two parties are using is obviously insecure, why else would they want to encrypt their conversation? So they can not exchange the keys on this channel, otherwise the parties would risk falling for a man in the middle attack. What they can do, though, is to use the following arbitrated protocol. This protocol assumes, that a trusted, third party exists, which knows both Alice and Bob and has means of encrypting data for both of them securely. 1. Alice calls Trent and requests a session key to communicate with Bob. 2. Trent generates a random key for a conventional encryption algorithm and encrypts two copies: One for Alice and one for Bob. Trent sends both copies to Alice. 3. Alice decrypts her copy of the session key. 4. Alice sends Bob his (encrypted) copy of the session key. 5. Bob decrypts his copy of the session key. 6. Alice and Bob use this session key to communicate securely. This protocols relies on the absolute security of Trent. All parties involved in secure communications must be registered with Trent. If Mallory is able to break into Trent's database and to steal the parties' keys, he is able to eavesdrop any communication that is initiated using this protocol. 16

3.2 Secure key exchange using asymmetric encryption

Using public key encryption and a trusted key distributor, the following protocol makes secure key exchange between parties possible. 1. Alice requests Bob's public key from Trent. 2. Alice generates a random session key for a conventional algorithm and encrypts the key using Bob's public key. 3. Alice sends the encrypted key to Bob. 4. Bob decrypts the session key using his secret key. 5. Alice and Bob use the session key for secure communication. This protocols relies on Trent's security, too. Trent could, for example, sign the Bob's public key with his own key and then send the signed key to Alice. Alice veri es Trent's signature and uses the public key. Mallory, sitting between Trent and Alice, can not fake Bob's key, unless he knows Trent's secret key. Neither can he eavesdrop the communication between Alice and Bob. Variations of this protocol are commonly in use today. They all use the idea of certifying public keys as \real" by signing them with a secret key. One example is the so called web-of-trust, utilized by the encryption program \Pretty Good Privacy" (PGP).

3.3 Interlock Protocol

A tricky defense against the man in the middle attack, which has been introduced in chapter 1.6.1, is the interlock protocol. Here is how it works: 1. Alice sends Bob her public key. 2. Bob sends Alice his public key. 3. Alice encrypts her message using Bob's public key. She sends the rst half of the resulting cipher-text to Bob. 4. Bob encrypts his message to Alice with Alice's public key. He also sends the rst half to Alice. 5. Alice sends Bob the second half of her encrypted message. 6. Bob puts the the two halfs together and recovers the plain-text of Alice's message. 7. Bob sends Alice the second half of his encrypted message. 8. Alice puts the the two halfs together and recovers the plain-text of Bob's message.

17

It is vital, for this protocol to work, that the rst half of the encrypted message can not be decrypted without the second half. This is very easy to achieve, though, using an algorithm that encrypts blocks of text. Another way is to insert one-way hash function values in the cipher-text, which must be known before decryption, but the original parameter of the function is located in the second half, etc. .. This protocol causes a problem for Mallory. Let us assume, that he is sitting in the middle of the conversation and is trying to replace the original messages with faked ones. He replaces the two public keys with his own copies, as described in chapter 1.6.1. Then he receives the rst half of Alices message to Bob. He can not read the contents without the second half. Nonetheless, he has to send Bob something, or the protocol would not proceed. Mallory has to make up a message, completely from the scratch, encrypt it with Bob's public key and to send it to Bob. Bob, then, follows the protocol and sends Alice the rst half of his message. Mallory has the same problem again. He has to make up a complete new message and send its rst encrypted half to Alice. Alice sends out the second half of her message to Bob, which is intercepted by Mallory. Now, Mallory can read the contents of the Alice's message. But he can not adapt the message to Bob anymore, because he has sent Bob the rst half already. If Mallory does not want to be discovered, he has to send Bob the second half of his made-up message, and so on. This protocol does not protect Alice and Bob from being eavesdropped by Mallory, but it protects them from receiving faked messages. If Alice and Bob know each other, or have agreed on a certain subject to communicate about, Mallory will have a hard time, making up messages that will not look very suspicious.

3.4 Getting a Receipt

If Alice sends Bob a message, she might want to know whether Bob received the message correctly. The following protocols includes a receipt into the communication: 1. Alice signs the message with her secret key and encrypts the result with Bob's public key. Then she sends the encrypted message to Bob. 2. Bob decrypts the message using his secret key. Then he veri es the signature from Alice. 3. If everything is correct, he signs the message with his secret key, encrypts it with Alice's public key and sends the result to Alice. 4. Alice decrypts the message and veri es Bob's signature. If the plain-text of the message is the same, she sent to Bob, she knows that he has received the message correctly. This protocol reveals a deny of service attack by Mallory reliably. There are circumstances where it does not satisfy all needs, though. Let's assume, Alice is a business partner of Bob. She has sold Bob very expensive computer equipment. Now Bob does not pay and Alice wants to send him a remainder. 18

When Bob receives the letter, he can simply abort the protocol and not proceed with sending the signed receipt back. If Alice sues Bob and takes the issue to court, she can not prove that Bob has received any remainders at all, because Bob never sent her a signature back. A protocol that xes this problem uses a trusted third party: 1. Alice signs the message with her secret key, encrypts it with Bobs public key and sends it to Trent, telling him, that this message is intended for Bob. 2. Trent blinds the encrypted message using a random blinding factor. Then he signs the blinded message and sends it to Bob. 3. Bob receives the blinded message and veri es Trent's signature. Then he signs the blinded message using his secret key and returns the result to Trent. 4. Trent veri es Bob's signature and divides the blinding factor out. Then he encrypts the message signed by Bob with Alice's public key and sends it to her. 5. Trent encrypts the blinding factor with Bob's public key and sends it to Bob. 6. Bob receives the message, decrypts it, unblinds the message he has received earlier and reads Alice's message. 7. Alice decrypts the message received by Trent and recovered the version of her letter, signed by Bob. Using this protocol, Alice can prove that Bob has received her remainder. Bob can not cheat. When he receives the blinded message from Trent, he does not know, that it is a remainder from Alice. Of course he can abort the protocol at this step, but then he accepts the risk of not receiving a totally di erent letter. (Furthermore, Trent will be able to con rm, that Alice has tried to send Bob a remainder, but Bob did not accept it. Depending on the case, this might help Alice a lot, too.) If Bob signs the blinded letter, he trusts Trent to send him the blinding factor afterwards.

3.5 Covert Communication

The mere opposite of requesting a receipt is to communicate in secrecy. Alice is accused of a major crime and is thrown to jail until the judge sees her. Bob is her lawyer, who is responsible to defend her. Unfortunately, the government of this country is not very friendly to \criminals" and does not allow private communication between Alice and her lawyer. All correspondence has to take place in unencrypted and signed form. Alice, now, wants to tell Bob a few things, that might help him defending her. These facts are not meant for the government, though. Alice and Bob have to nd a way to communicate secretly, without Walter the warden noticing it, even though he can read the whole letter and verify the signature on it. 19

One technique used to achieve this is the subliminal channel. Alice and Bob can agree on a subliminal code in the letters, like: Every sentence with an even number of words means a \0" and every sentence with an odd number of words stands for a \1". Using this agreement, they could transfer secret messages through the open conversation. Another way to establish a subliminal channel is through the signature on the document. Several digital signature algorithms include a random number in the signature. This number is necessary for padding, for making the signature more resistant against attacks for the secret key, and other reasons. It can not be retrieved without knowing the secret key, the signature has been issued with. Nonetheless, the signature is perfectly veri able. If both, Bob and Alice, know their other's secret keys, they can use this number to transfer a secret message through the signature! Walter will not discover it, though he is reading the whole letter and is verifying the signature. Unfortunately, other signature algorithms do not allow a subliminal channel and Walter will insist on using one of these algorithms | if he is smart. Another protocol, that can be used to broadcast an anonymous message, is known as the dining cryptographer problem. The story is, that three cryptographers are sitting in a restaurant and having dinner. When it comes to paying the bill, the waiter refuses the money and tells them, that they have been invited by an anonymous donor. The three cryptographers wonder who this donor has been. They do not want to accept an invitation by the Central Intelligence Agency (CIA) for example. But they would accept an invitation by one of their circle. If one of three cryptographers has paid the bill, though, they want to respect his wish to stay anonymous. So how can they nd out, whether one of the three cryptographers is paying or not, without him revealing his identify? The protocol works as follows: 1. Each cryptographer ips a coin behind his menu card in a way that only he himself and his right neighbor can see the outcome of the toss. 2. Each cryptographer then states aloud, whether the two coins he can see (his own and the one of his left neighbor) fell on the same side or on di erent sides. 3. If one of the cryptographers is the anonymous donor, he lies about the result and states the opposite. 4. An odd number of total di erences indicates, that one of the cryptographers is paying. 5. An even number of total di erences indicates, that the CIA is paying. If one the cryptographers is paying, his identify is not revealed. The other two cryptographers do not know he was lying. It is recommended to try this scenario with a pencil and a piece of paper. The amazing thing is, that this protocol works with any number of cryptographers, not only three. Even two cryptographers can perform the protocol, even though the one who did not lie does of course know that the other person paid. 20

This protocol can be used to broadcast an anonymous message in the following way: 1. The participant of the protocol arrange themselves in a circle. 2. At regular intervals, each user ips a coin, and transmits the outcome to his right neighbor, using an encryption protocol to protect the circle from eavesdroppers. 3. Every participant announces \same" or di erent." The one who wishes to broadcast an anonymous message, tells the truth or lies about the outcome of the coin toss, depending on the binary representation of his message. His message is \0110", he rst tells the truth, then he lies, lies again and tells the truth again. If the number of total number of \di erent"s in one round is odd, a \1" has been broadcasted and vice versa. If the outcome of a round does not match the data, the anonymous sender tried to transmit, he knows that someone else has been sending, too. Both senders stop then and wait for a random number of circles. The one who's random delay was shorter, starts broadcasting rst and \owns" the channel now. Of course this concept needs a very clever data format, to make sure, that the broadcasted message can be recovered in any way, but it is totally secure. Neither Eve nor Mallory can gain any information who is sending. If the broadcasted data is, for example, encrypted with the public key of the addressed party, it is even possible to send anonymous messages from one party to another. The other parties will not be able to decrypt the message. Neither will they be able to determine who the intended recipient is.

21

Chapter 4

Digital Cash
Money has its drawbacks. You have to carry the notes and coins around, you can lose them, people can steal it from you and it is very di cult to transfer from one location to another. You have to care about currencies, about not getting your notes damaged in any way and so on.. . There are quite a few advantages of Digital cash. So it is no wonder that credit cards and comparable concepts are more and more popular. Digital money, on the other hand, poses other problems, that are not easy to solve. Just look at todays credit cards: You can damage your card easily and make it invalid until it is replaced. Your card can easily be stolen or copied. If someone steals your purse, he will gain a hundred dollar, maybe a bit more, maybe even less. Your credit card, though, contains all the money you have and even more. All transfers you do can be traced back to you. It is not possible to spend money anonymously. You have to trust the credit card company to handle your account correctly. To a certain extent you can verify all bookings, but it is very di cult to convince the company that you did not spend ve hundred dollar for clothing recently. Various protocols exist, that implement digital cash without these drawbacks. Some are very good, some are not that good. Some are secure and anonymous, others are not. The very subject of digital money could easily ll a book of hundreds of pages. For this reason, this paper will describe one protocol, that would work in practice, represents the broad variety of protocols gives the reader an idea of what is happening in that eld of research. More sophisticated protocols are available.

4.1 A simple digital cash protocol

The following protocol implements an anonymous digital cash system that is very easy to understand: 22

1. Alice prepared 100 anonymous money orders for $1,000 each. On each money order she writes a di erent random number, which is long enough to make the chance that someone else is using it negligible. 2. Alice puts one each, and a piece of carbon paper, into 100 di erent envelopes and gives them to the bank. 3. The bank opens 99 envelopes and veri es that all money orders look the same. 4. The bank signs the remaining money order blindly. The signature goes through the carbon paper on the money order. 5. The bank gives the unopened envelope to Alice and deposits $1,000 from her account. 6. Alice opens the envelope and spends the $1,000 with a merchant. 7. The merchant checks the bank's signature to make sure the money order is valid. 8. The merchant asks Alice to write a random identity string on the money order. 9. Alice complies. 10. The merchant takes the money order to the bank 11. The bank veri es the signature and the identity string using its database. 12. If the money order has been used before, the bank compares the identity string in the database with the one one the money order. If is is the same, the bank knows that the merchant has photocopied the money order. If the strings are di erent, the bank knows that Alice has tried to cheat the merchant. 13. If the money order has not been used before, the bank credits $1,000 to the merchants account. Then the bank puts the random number into its database to make sure, the money order is not used again. This protocol works, but a number of problems are unsolved. Since the interaction between the merchant and the bank takes place after Alice has left, the merchant could be stuck with a bad money order. So Alice might be required to wait near the cash register until the money order clears. Alice could also trick the merchant by photocopying the money order and using the second copy again at the same merchant. Then Alice would provide the same identity string as she used the rst time. If the merchant does not keep a database of used identity strings, he would accept the money order and get trouble with the bank later. The idea behind this protocol is, that no paper is needed at all. The money order could be digital messages, signed by the bank. The nal order would be stored on a oppy disk, a credit card or a similar medium.

23

4.2 The perfect crime

Thanks to digital cash, Alice is now able to commit the perfect crime: 1. Alice kidnaps a baby. 2. Alice prepares 10,000 anonymous money orders for $1,000 each. 3. Alice blinds all 10,000 money orders using a blind signature protocol as described in chapter 2.2. She sends them to the government with a threat to kill the baby unless the government does the following: (a) Have a bank sign all 10,000 money orders. (b) Publish the results in a newspaper. 4. The authorities comply. 5. Alice buys a newspaper, unblinds the signed money orders and starts spending the money. 6. Alice frees the baby. Generally, digital money is not good for criminals, but this crime is special, because it uses the one sided anonymity of the money order: The spender is anonymous, the merchant is not. The government can, for example, easily verify how much money you receive, but it can not be veri ed what you spend it on.

24

Chapter 5

Practical issues when using cryptographic protocols

Protocols exist to solve all kind of problems. Many of them are very secure or self-enforcing. Even the adjudicated or arbitrated protocols may be perfectly usable under most circumstances. Some protocols seem complicated, but they could be performed almost completely by a computer program or special hardware. The human user would not have to worry about executing most steps. Many protocols are very similar to the steps we all take in everyday life anyway. Adapting them to a digital environment should be easy. With the growing signi cance of computer networks, like the Internet, and electronic telecommunication, sophisticated cryptographic protocols are necessary. Currently, nancial transfers, database maintenance and private mail are handled in more or less unprotected fashion. The Internet e-mail standards, for example, do not mention cryptography with a single word. The low-level networking stack TCP/IP does not provide any means of authentication or protection at all. All these shortcomings will have to be remedied in the near future, or we all may witness a new level of crime. The cryptographical protocols we currently know do not solve all problems satisfactorily, though. Key exchange is still a mostly unsolved problem. The only approaches that would work immediately, involve a trusted party, such as a Key Certi cation and Distribution Center. It is questionable, whether a central organization should receive so much power. Another problem is that the average protocols required way more calculating power, than a high-end personal computer is able to muster today. The digital cash protocol described above, for example, requires the following calculations: 1. 100 money orders have to be prepared by the customer, what will, without a doubt, be done by his computer. This includes nding 100 random numbers of signi cant length. 512 or even 1024 bit long numbers will de nitely be required. Because the customer will generate quite a lot of random numbers during his nancial life, the random number generator should better be of a very high quality. The problem is, though, that generating random numbers (or pseudo random numbers, as the computer scientists call them) is a very hard thing for a computer to do and requires a lot of calculation. Depending on how sophisticated the algorithm is, 25

2.

3.

4. 5. 6.

generating 100 1024-bit numbers will require about 20 seconds on a todays Pentium processor. The money orders have to be blinded. One way to blind a message is to raise it to a random number: me . For security reasons, e must at least be 50 bit long | or more. Assuming that m is the binary representation of the money order, using the ASCII code for example, we can expect m to be of 2048 bit length, probably more. Now the simple me statement looks monstrous: Raising a 2048 bit number to the power of a 50 bit number! And we have to do it once per money order, a hundred times that is. Another problem is that the result of this calculation will be rather long. We have to transfer the result of the calculation to the bank, though. Now the money order will have to be encrypted and signed, before we transfer them to the bank. Assuming RSA public key encryption, this is no big deal though. A todays Pentium can encrypt the hundred messages in less than four or ve seconds. Signing the messages, though, is a di erent story. This includes calculating md mod N , where m is about 10,000 bits long. (Note that this m is the result of the earlier blinding process. 10,000 bits is rather too optimistic than too pessimistic.) d and N are about the same size. Suitable key sizes today are 1024 bit, but since we're dealing with money orders, we should rather go for 2048 bit, just to be sure. Finally, we have to raise a 10,000 bit number to the power of a 2048 bit number modulo a 2048 bit number. Even using short-cuts like the Chinese Remainder Theorem and other algorithms, this will keep a Pentium occupied for about 3 seconds. Makes another ve minutes for the 100 money orders we have to sign. When the encrypted and signed money orders arrive at the bank, their computer has to decrypt and check the signature of all of them. What includes the calculations we just did again. 1 99 The bank has to unblind 99 money orders, what means calculating m e times. This is again a major e ort. Finally, the bank has to encrypt and sign one money order and send it to Alice. Alice has to decrypt it and check the signature.

Obvious getting one single money order requires several minutes of raw CPU power just for the calculations. Since these money orders are meant to replace todays bank notes, Alice will probably not only require a single one, but rather 40 or 50 di erent money orders with all kind of amounts of worth. If the bank has a thousand customers, its computer will be very busy verifying and calculating. And again, thousand customers is a rather optimistic gure. One may argue that computer power is always growing very quickly and todays Pentiums might be outrun by tomorrow's CPUs. But that helps only marginally, because the quicker the CPUs become, the larger the numbers have to be, to be secure against attacks. 26

Another problem is that the software performing these steps has to be abrock-solid. Imagine what happens if Alice's computer program has a bug! It generates ten-thousand correct money orders, but makes a mistake with the ten-thousand and rst. If the bank discovers the mal-formed money order, Alice will be sued for trying to cheat the bank! Another major problem, especially for digital cash, is that the money orders have to be secure for at least ten or twenty years. A money order the bank issues today must still be valid tomorrow. The algorithms used must be secure enough to resist all attacks for a reasonable time. But how do you chose such an algorithm? RSA, for example, is known and has been used for almost twenty years now. People put a lost of trust in this system and it is already used to issue realworld digital signatures or to protect sensitive data. The whole security of RSA depends on the fact, that it is impossible to factor a large composite number N until today. All known factoring algorithms fail to factor N if it is just big enough. But the whole algorithm falls if a clever mathematician discovers a number sieve that calculates the factors of N within reasonable time. Once it is possible to factor N within a day, even within a week, all RSA signatures are void. All RSA protected communication that has been monitored can be read immediately. It may never happen, but it may also happen right tomorrow. Would you like to bet all your secrets and all your money on the fact that the clever mathematician has something better to do all his life long? The Digital Encryption Standard (DES) was said to be secure for several decades when it was discovered. Governments and large companies use DES in software and hardware implementation to protect their secrets. If someone had to chose an encryption algorithm to be used in a digital cash system a few years ago, DES would de nitely have been the rst choice. Today, though, DES can be broken. Special hardware for brute force attacks can be built and these chips can crack a DES key within a few hours. If DES had been used for digital cash, the whole system would be attackable today. Cryptographers have enhanced DES and built Triple-DES, which is secure again. But for how long? These are serious risks. Just imagine what will happen, if the bank's key is compromised in any way? Once someone is able to break that key, all money orders in existence will have to be revoked. Absolute chaos would be the certain result. Another factor that is completely ignored in all cryptographic protocols is the human. Many people are not very talented with computers and mathematics. Will they be able to use these protocols e ciently? Or will they make mistakes that can cost them thousands of dollars, just because a poor guy has entered his secret key, when he was supposed to enter his public key? All this has happened already. So looking at the real-life usage of cryptographic protocols, we face problems with the CPU power, problems with choosing the underlying cryptography, problems with making the people understand the concept of the protocol. We furthermore face a new level of crime and misuse. Taking all this into account, concepts like digital cash look rather frightening than encouraging. The simple question: \Who is the person I am talking with right now?" can not be answered reliably in a conversation taking place on the Internet and
solutely

27

so far, no-one has found a way to ensure authenticity and security for digital communication. RSA, IDEA, Clipper, PGP and other concepts are a good start | but they're no solution. The builders of the \digital information highway" still face many problems, which can not be solved today. They certainly will be solved some day in the future. And cryptographic protocols will be a part of that solution.

28

Chapter 6

References
During my researches for this paper, many resources have been very helpful and enlightening. Below is a complete list of texts I used to gather the presented information. This list is meant to give the authors of these texts credit for their work. Furthermore it can be used as a list of recommended reading for the interested reader of this paper.

Schneier, Bruce Applied Cryptography, Second edition, Wiley Publishing,

ISBN 0-471-122845-7 Stallings, William Network and Internetwork Security, Principles and Practice, Prentice Hall, ISBN 0-02-415483-0 Knuth, Donald E. The Art of Computer Programming, Volume I, II and III, Addison & Wesley Schumacher, Stale Pretty Good Privacy (PGP) international Home Page, http://www.i .uio.no/pgp/ Zimmermann, Philip Pretty Good Privacy (PGP) Source Code and Manual, ftp://ftp.i .uio.no/pub/pgp/ Cate, Vince Vince Cate's Cryptorebel/Cypherpunk Page, http://www.o shore.com.ai/security/

29