Like what you see? Get it in one document for easy printing!
Click Here!
Use coupon code "certiguide" to save 20%!
(Expires 2004/12/31)

Test yourself better with 300 extra Security+ questions!
Get It Here!

Custom Search

Table Of Contents  CertiGuide to Security+
 9  Chapter 4:  Basics of Cryptography (Domain 4.0; 15%)
      9  4.5  Key Management and Certificate Lifecycles
           9  4.5.10  Key Usage

Previous Topic/Section
4.5.10  Key Usage
Previous Page
Pages in Current Topic/Section
Next Page
4.6  Summary
Next Topic/Section  Multiple Key Pairs (Single, Dual)

Conventional hierarchical PKI uses a single key pair – one public key and one private key. According to VeriSign, “Key Pairs are used for one or more of three basic purposes: encryption, authentication and non-repudiation.” A single key used for multiple purposes violates non-repudiation410. Up until now, we’ve primarily been discussing situations in which each individual has only one key pair.

RSA recommends that you assign two key pairs per person -- one key pair for signing messages, providing authentication and non-repudiation, and a second key pair for encryption. This allows someone to recover the encryption key and decrypt documents that were encrypted using it, without their gaining the ability to sign documents with that user’s private key as well (which could lead to forgery and violation of non-repudiation).411

PKI Goals

Use the receiver’s public key to encrypt a confidential message which will be able to be decrypted only by them (using their private key)

To send a confidential encrypted message to multiple users, send a separate message to each user, each encrypted with that user’s public key.

Use your own private key to encrypt a message which anyone can decrypt, to prove that you are the sender of the message (non-repudiation) and that the message has not changed during transport (integrity) as long as they trust your public/private key pair.

(A variation on the above) You can use a private key issued by a trusted CA, and a public key embedded in a digital certificate signed by that CA, to encrypt a message which anyone can decrypt, to prove that you are the sender of the message (non-repudiation) and that the message has not changed during transport (integrity).

(And a variation on THAT…) Because it can be processor-time-consuming to encrypt an entire message for data integrity, you can take a shortcut and compute a digest of the message, then encrypt that digest with your own private key. Anyone who decrypts the digest with your public key and compares it to the original digest you published for the message will know that it was not tampered with if the two digest values are the same.

With a single key pair, this protection is not available. When a single key pair is used, key recovery gives the individual recovering the key the ability to masquerade as the user whose key was recovered, if desired, in addition to allowing them to encrypt/decrypt communications from and to that user.

Since an organization already has to have infrastructure in place to manage a single set of keys, it’s generally not that much more difficult, from an administrative point of view, to add a second set of keys for each user (as long as any key management software/hardware used supports this). Because of the low incremental cost and the potential value of implementing a PKI with dual key pairs, it’s something to consider.

Note that when using dual key pairs, you may wish to treat the archiving and escrow of signing keys different than encryption keys. The reason for this is that if a signing private key is lost, it’s no big deal – just generate another key pair for future messages (the public half of the old signing key will still be “good” for reading messages signed with the old private key). Additionally, if the employee were no longer with the company, although you might have a need to go back and decrypt messages encrypted with his or her private key, you wouldn’t need to digitally sign a message with his or her identity. Contrast this with the loss of an encryption private key – which means that any outstanding messages to the recipient, created with the recipient’s public key, cannot be read412.

Single/Multiple Keys

Multiple key pairs, the idea of assigning more than one public/private key pair to each user, are an idea that resulted from problems identified in the use of recovered keys.

Key recovery not only allows the holder of the recovered private key to decrypt communications encrypted using the associated public key; it also allows the holder of the recovered key to encrypt messages using that private key. This means that anyone recovering the user’s private key can masquerade as that user, which is a security issue.

The answer to this is to use two key pairs – one for signing messages to provide authentication and non-repudiation, and one for sending confidential messages. When the private key needed to decrypt messages is recovered, that still does not give the holder the ability to sign messages as that user.




412. Kaufman, Charlie, Radia Perlman and Mike Speciner, Network Security – Private Communication in a Public World, Prentice-Hall, April, 2002,

Previous Topic/Section
4.5.10  Key Usage
Previous Page
Pages in Current Topic/Section
Next Page
4.6  Summary
Next Topic/Section

If you find useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider buying an inexpensive PDF equivalent of the CertiGuide to Security+ from (Use coupon code "certiguide" by December 31, 2004 to save 20%!) Thanks for your support!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $

Home - Table Of Contents - Contact Us

CertiGuide for Security+ ( on
Version 1.0 - Version Date: November 15, 2004

Adapted with permission from a work created by Tcat Houser et al. Version Copyright 2004 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.