SAMPLE QUESTIONS (EXTRA) Q1: Why is it not necessary in Fig. 9-15 for the KDC to know for sure it was talking to Alice when it receives a request for a secret key that Alice can share with Bob? A: Suppose that Chuck had sent the message “I'm Alice and I want to talk to Bob” The KDC would just return KA,KDC(KA,B) which can be decrypted only by Alice because she is the only other entity holding the secret key KA,KDC. Q2: Can we safely adapt the authentication protocol shown in Fig. 9-19 such that message 3 consists only of RB? A: In principle, if RB is never used again, then returning it unencrypted should be enough. However, such randomness is seldom found. Therefore, by encrypting RB, it becomes much more dif.cult for Chuck to break in and forge message 3. Q3: Devise a simple authentication protocol using signatures in a public-key cryptosystem. A: If Alice wants to authenticate Bob, she sends Bob a challenge R. Bob will be requested to return KB(R), that is, place his signature under R. If Alice is con.dent that she has Bob's public key, decrypting the response back to R should be enough for her to know she is indeed talking to Bob. Q4: Assume Alice wants to send a message m to Bob. Instead of encrypting m with Bob's public key K+B, she generates a session key KA,B and then sends [KA,B(m), K+B(KA,B)]. Why is this scheme generally better? (Hint: consider performance issues.) A: The session key has a short, .xed length. In contrast, the message m may be of arbitrary length. Consequently, the combination of using a session key and applying public-key cryptography to a short message will generally provide much better performance than using only a public key on a large message. Q5: What is the role of the timestamp in message 6 in Fig. 9-23, and why does it need to be encrypted? A: The timestamp is used to protect against replays. By encrypting it, it becomes impossible to replay message 6 with a later timestamp. This example illustrates a general application of timestamps in cryptographic protocols. Q6: Name three problems that will be encountered when developers of interfaces to local resources are required to insert calls to enable and disable privileges to protect against unauthorized access by mobile programs as explained in the text. A: An important one is that no thread switching may occur when a local resource is called. A thread switch could transfer the enabled privileges to another thread that is not authorized to access the resource. Another problem occurs when another local resource needs to be called before the current invocation is .nished. In effect, the privileges are carried to the second resource, while it may happen that the caller is actually not trusted to access that second resource. A third problem is that explicitly inserting calls to enable and disable privileges is suspect to programming errors, rendering the mechanism useless.