Problem - Kevin Tafuro

When using RSA, if you’re doing one-way key transport, the client need not have a
public key. Here’s a protocol:
1. The client contacts the server, requesting a one-time public key.
2. The server generates a new RSA key pair and signs the public key with its longterm
key. The server then sends the public key and the signature. If necessary,
the server also sends the client its certificate for its long-term key.
3. The client validates the server’s certificate, if appropriate.
4. The client checks the server’s signature on the one-time public key to make sure
it is valid.
5. The client chooses a random secret (the session key) and encrypts it using the
one-time public key.
6. The encrypted secret is sent to the server.
7. The parties attempt to communicate using the session key.
8. The server securely erases the one-time private key.
9. When communication is complete, both parties securely erase the session key.
In two-way authentication, both parties generate one-time keys and sign them with
their long-term private key.
See Also
Recipes 8.17, 13.2
8.22 Confirming Requests via Email
Problem
You want to allow users to confirm a request via email while preventing third parties
from spoofing or falsifying confirmations.
Solution
Generate a random identifier, associate it with the email address to be confirmed,
and save it for verification later. Send an email that contains the random identifier,
along with instructions for responding to confirm receipt and approval. If a response
is received, compare the identifier in the response with the saved identifier for the
email address from which the response was received. If the identifiers don’t match,
ignore the response and do nothing; otherwise, the confirmation was successful.
Confirming Requests via Email | 447
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.