At a large enterprise environment I have come across a deployment approach for Digital Certificates where each user is issued two (2) key pairs:

One for signing documents, emails, etc. that is completely "personal" (perhaps kept only by him in an e.g. smart card)

One for encryption. To avoid any situations of user unavailability, blackmail etc. encryption by this latter key pair can be circumvented by the key management system (using appropriate policies etc.)

This approach is supposed to safeguard from an administrator signing as a user but I find certain usage scenarios making things complicated. E.g. how about sending signed and encrypted emails? Two public keys maintained for each user in the contact list?

So, is this an overall preferred (and widely used) design? Or should we just use it in certain cases where prevention of impersonation is the highest priority?


2 Answers 2


In a sane organization, it is actually necessary to have two distinct keys, one for signing and one for encryption.

When you receive some encrypted data (e.g. an encrypted email, as in S/MIME or PGP), you normally store the encrypted data (that's what happens by default for email). Therefore, if your private key becomes "unavailable", you cease to be able to read previously stored data: this is a data loss situation. "Unavailability" of the private key can take multiple forms, including hardware failure (your dog chew your smartcard to death) or "hardware" failure (the key holder is hit by a bus, or unceremoniously fired, and his successor should be able to read previously received business emails). To remove the risk of data loss through key loss, a backup of the private key must be stored somewhere (e.g. printed on a paper, in a safe)(this is often called escrow). In short words: encryption keys MUST be escrowed.

Loss of a signature private key does not imply any kind of data loss. Signatures which where previously generated keep on being verifiable. Recovering after a signature key loss involves getting a new key, and that's all. So there is no strong need for key backup here. On the other hand, signatures are normally meant to have legal value (there is little point in requesting a signature if you cannot use it against the signer, should he later on fail to follow on his promises). The legal value is conditional to the impossibility for any other individual than the key owner to generate a signature; this does not mix well at all with an escrow on the key. Hence, a signature key MUST NOT be escrowed.

Since a key cannot be both escrowed and non-escrowed simultaneously, you need two keys.

  • 3
    Wow! Although I understood the possible advantages of having a two key solution I had never pinpointed it specifically to key escrow. Thanks for putting everything in perspective.
    – George
    Nov 2, 2011 at 8:02
  • For completeness to add that in many commercial solutions (e.g. PGP Netshare, Microsoft EFS) encrypted material is safeguarded against key loss etc. not by duplicating the key but by creating a second administrator key with access to the data.
    – George
    Nov 2, 2011 at 8:07
  • 4
    But if people can gain access to your escrowed private keys, they can decrypt your data! Why does your argument for the signatures not apply to encryption? Mar 16, 2015 at 4:55
  • 2
    @RenéG: From the perspective of an organization, members (usually employees) should not be able to essentially destroy data by deleting their private key, dying, etc.—hence, private encryption keys should be escrowed. On the other hand, for legal reasons members should not be able to sign as other members, and the organization should take measures to preclude this scenario—hence, private signature keys should NOT be escrowed. Jun 1, 2016 at 21:03
  • In the context of PGP, how is this handled in practice? I thought the master key always had encryption capabilities, AND the master key is needed for other important things, such as issuing subkeys and revocation, which suggests that it MUST be escrowed, contradicting your point. Is this correct, or have I misunderstood something?
    – Betamos
    Feb 15, 2017 at 2:18

Using different keys for signing and encryption is quite common. Make sure to flag the keys appropriately.

A dedicated signing key, however, will offer no real protection against a rogue administrator. The admin is able to manipulate the application that is doing the signing. Note this is even true for smartcard: The administrator can manipulate the application that talks to the smartcard reader and submit manipulated data to it.

Smardcard readers with a display offer some protection, for e.g. money transfer. In most business cases, however, the signed information does not fit onto the display but is a pdf file.

  • If an administrator can circumvent it, then why get into double the trouble?
    – George
    Nov 1, 2011 at 13:06
  • I don't see how an admin can circumvent a smart card... Isn't it the case that the smart card is the only place the private key is stored? If the admin does not have access to the card, they have no way of generating a signature. No amount of "manipulating the application" will generate a fake signature (assuming the public key remains genuine).
    – SplashHit
    Nov 1, 2011 at 20:53
  • 10
    The idea behind the attack is this: The user wants to sign document A, but in the background the manipulated application signs document B, then confirms to the user that document A was signed. Smartcard readers from banks prevent this kind of attack by displaying the amount and target of a money transaction on their own display. But this does not work for complex documents. Nov 1, 2011 at 21:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .