Consider a token issuer/validator. Every token is PKI signed.

Is it more secure to use a new key-pair (performance could be ignored for now) per request or is it no difference to have only one key-pair for all?

It's a theoretical question, an implementation could be for example to generate a key-pair with expiration usage time etc.

The question looks obvious, but I, as a newbie in security, have concerns about it.

  • 3
    The question should not be "which one is more secure?", the question is "what are the threats or attack vectors you are protecting from? What are your concerns regarding security? Are these concerns founded on real threats? The idea is to narrow the scope of these threats in order to size the security accordingly.
    – Laiv
    Commented Feb 12, 2019 at 10:04

1 Answer 1


Cryptography is complicated, so adding your own ideas can accidentaly make the cryptosystem more brittle. Don't do it if you don't know what you are doing (I wouldn't know either).

What a Public Key Infrastructure addresses is how to exchange keys. Briefly, there are web of trust based models to ensure the authenticity of a key, and there are certificate authority based models.

A cryptosystem is not going to get more secure by using a public key less. Either the system works or it doesn't. However, asymmetric encryption has two notable limitations:

  • It is computationally expensive. Therefore, most protocols that need to transfer large amounts of encrypted data use the public/private keys to negotiate a session key and then use that key with symmetric encryption for the remainder of the session. With current CPUs, symmetric encryption like AES is practically free.

  • A key that is trusted by others has to be kept safe. For example, you might not want to put a highly trusted private key on multiple servers. Instead, it can make sense to use set up your own Certificate Authority that can sign multiple short-lived keys. For example, you might use an internal CA to encrypt data flows within an intranet.

However, in a token validation use case (like JWT) these problems do not arise. In particular, the token is usually just signed, not encrypted, so no performance issues arise. Furthermore, a certificate might be significantly larger than a signed token, thus making it unattractive to create per-use public/private key pairs.

However, in JWT tokens cannot be invalidated once they are signed. The only way to expire tokens is to expire the key they were signed with. This means that keys used for signing tokens should be rotated/expired on a schedule, for example every week (this depends primarily on your business requirements). This also makes it necessary that everyone who wants to validate the tokens can automatically retrieve and verify the new public keys as well. It is possible to have multiple valid keys at the same time (in fact, there should be some overlap in their validity), but doing this excessively makes key management more challenging.

  • Thanks for your answer. By invalidation I mean that the particular key won't be used for signing anymore again in the future. JWT can hold the information wich key was used to sign, so even when the used key is "old" and not used anymore for new tokens it could be used for validation by the id in the token. The can be permanently deleted from the system, when its creation date is older then the expiration time of a token (because it makes no sense to validate an expired token anymore).
    – ttulka
    Commented Feb 12, 2019 at 14:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.