Problem - Kevin Tafuro

In such a scenario, the sender has to have some way to ensure that it really does have
the public key of the entity with which it wants to communicate. It can do this either
by using a trusted third party (see Chapter 10) or by arranging to transport the public
key in a secure manner, such as on a CD-R.
If the recipient can send a message back to the sender using the session key, and that
message decrypts correctly, the sender can be sure that an entity possessing the correct
private key has received the session key. That is, the sender has authenticated
the receiver, as long as the receiver’s public key is actually correct.
Such a protocol can be modified so that both parties can authenticate each other. In
such a scheme, the sender generates a secret key, then securely signs and encrypts the
key.
It is generally insecure to sign the unencrypted value and encrypt that,
particularly in a public key–based system. In such a system, it is not
even a good idea to sign encrypted values. There are several possible
solutions to this issue, discussed in detail in Recipe 7.14. For now, we
are assuming that you will be using one of the techniques in that recipe.
Assuming that the recipient has some way to receive and validate the sender’s public
key, the recipient can now validate the sender as well.
The major limitation of key transport is that the machine initiating a connection may
have a weak source of entropy, leading to an insecure connection. Instead, you could
build a key agreement protocol, where each party sends the other a significant chunk
of entropy and derives a shared secret from the information. For example, you might
use the following protocol:
1. The client picks a random 128-bit secret.
2. The client uses a secure technique to sign the secret and encrypt it with the
server’s public key. (See Recipe 7.14 for how to do this securely.)
3. The client sends the signed, encrypted key to the server.
4. The server decrypts the client’s secret.
5. The server checks the client’s signature, and fails if the client isn’t authenticated.
(The server must already have a valid public key for the client.)
6. The server picks a random 128-bit secret.
7. The server uses a secure technique to sign the secret and encrypt it with the client’s
public key (again, see Recipe 7.14).
8. The server sends its signed, encrypted secret to the client.
9. The client decrypts the server’s secret.
10. The client checks the server’s signature, and fails if the server isn’t authenticated.
(The client must already have a valid public key for the server.)
430 | Chapter 8: Authentication and Key Exchange
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.