Problem - Kevin Tafuro

compromise. If our system has such a property, it is said to have perfect forward
secrecy.
Solution
Use a separate base secret for each entity in the system. For any given client, derive a
new key called K1 from the base secret key, as described in Recipe 4.11. Then, after
you’re sure that communicating parties have correctly agreed upon a key, derive
another key from K1 in the exact same manner, calling it K2. Erase the base secret
(on both the client and the server), replacing it with K1. Use K2 as the session key.
Discussion
In Recipe 4.11, we commented on how knowledge of a properly created derived key
would give no information about any parent keys. We can take advantage of that fact
to ensure that previous sessions are not affected if throwing away the base secret
somehow compromises the current key, so that old session keys cannot be regenerated.
The security depends on the cryptographically strong one-way property of the
hash function used to generate the derived keys.
See Also
Recipe 4.11
Remember that when deriving keys, every key derivation needs to
include some kind of unique value that is never repeated (see Recipe 4.11
for a detailed discussion).
8.21 Ensuring Forward Secrecy in a Public Key
System
Problem
In a system using public key cryptography, you want to ensure that a compromise of
one of the entities in your system won’t compromise old communications that took
place with different session keys (symmetric keys).
Solution
When using RSA, generate new public keys for each key agreement, ensuring that
the new key belongs to the right entity by checking the digital signature using a longterm
public key. Alternatively, use Diffie-Hellman, being sure to generate new ran-
Ensuring Forward Secrecy in a Public Key System | 445
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.