Skip to main content
Identity Authority
Category: FIDO & Passkeys

Key Pair

Also known as: public/private key pair, asymmetric key pair
Simply put

A key pair is a matched set of two cryptographic keys: a public key that can be freely shared and a private key that must be kept secret. The two keys are mathematically related so that data or actions handled by one key can be verified or reversed by the other. This pairing lets systems prove identity or protect information without both parties needing to share the same secret.

Formal definition

A key pair consists of a public key and its corresponding private key, forming the basis of asymmetric (public-key) cryptography, where one key is published while the other is retained privately. In IAM contexts, key pairs are used for functions such as authenticating a principal to a remote system, for example, an SSH key pair used to authenticate a user or process connecting to a host, or an EC2 key pair used as a security credential to prove identity when connecting to an instance. Note that a key pair's role depends on the operation: the private key may be used to create digital signatures (verified with the public key) or to decrypt data (encrypted with the public key), and correct handling requires that the private key never be disclosed. This entry does not cover key generation algorithms, key lengths, or key management lifecycle specifics, which vary by implementation and deployment.

Why it matters

Key pairs underpin much of the trust that IAM systems depend on, because they let a principal prove identity or protect data without sharing a common secret with the other party. In practice, this asymmetry is what allows an SSH key pair to authenticate a user or process to a remote host, or an EC2 key pair to serve as a security credential when connecting to an instance. The public key can be distributed freely to any system that needs to verify the holder, while the private key stays with its owner, which reduces the exposure that comes with symmetric shared secrets that both sides must hold.

The security of this model rests entirely on the confidentiality of the private key. Because a public key can be published without weakening the pairing, the operational risk concentrates on how the private key is stored, transmitted, and used. If a private key is disclosed, an attacker can typically impersonate the legitimate holder or decrypt data intended for them, depending on how the key is used. This is why correct handling of private keys, rather than the mere fact of using a key pair, is the decisive control in these deployments.

It is worth noting that a key pair's role depends on the operation being performed. The private key may be used to create digital signatures that are verified with the public key, or to decrypt data that was encrypted with the public key. Treating these operations as interchangeable can lead to design errors, so architects should be explicit about which function a given key pair serves in a given flow.

Who it's relevant to

System Administrators
Administrators who manage SSH access to hosts rely on key pairs to authenticate users and processes connecting to remote systems. Their primary concern is ensuring private keys are stored securely and never disclosed, since the confidentiality of the private key is what makes the authentication trustworthy.
Security Architects
Architects designing access flows need to be precise about the role a key pair plays in a given operation, whether the private key is used to create signatures verified by the public key, or to decrypt data encrypted with the public key. Conflating these functions can introduce design errors, so the intended operation should be specified explicitly.
Cloud and Platform Engineers
Engineers working with services such as Amazon EC2 use key pairs as security credentials to prove identity when connecting to instances. They are responsible for controlling how the public key is distributed to instances and how the private key is protected on the client side.
Compliance Officers
Those responsible for auditing access controls should verify that private keys are handled such that they are never disclosed, since a key pair's security value depends on private-key confidentiality rather than on the use of asymmetric cryptography alone. Note that key management lifecycle specifics are out of scope for this entry and vary by deployment.

Inside Key Pair

Private Key
The secret half of the key pair, held only by its owner and never shared. In most deployments it is used to create digital signatures or to decrypt data encrypted to the corresponding public key. Its confidentiality is the foundation of the pair's security guarantees.
Public Key
The freely distributable half of the key pair. It is used by relying parties to verify signatures produced by the private key or to encrypt data intended for the private key holder. Publishing it does not compromise the private key.
Asymmetric Relationship
The mathematical binding between the two keys such that operations performed with one can only be reversed or verified with the other. This asymmetry is what distinguishes key pairs from symmetric (shared-secret) keys, where a single key is used for both directions.
Signing Versus Encryption Usage
Depending on configuration, a key pair may be designated for digital signing, for encryption, or scoped to a single purpose. In IAM contexts, signing key pairs are commonly used to sign tokens such as JWTs, while encryption key pairs may protect payloads; a signature attests to origin and integrity, not confidentiality.
Key Identifier and Metadata
Deployments typically associate a key pair with an identifier (for example a JWK 'kid'), validity period, and intended algorithm, allowing relying parties to select the correct public key for verification. Exact metadata fields depend on the format and profile in use.

Common questions

Answers to the questions practitioners most commonly ask about Key Pair.

Is a signed token the same as an encrypted token when using a key pair?
No. Signing and encryption are distinct operations even though both can use a key pair. Signing uses the private key to produce a signature that anyone holding the public key can verify for integrity and origin; it does not conceal the token's contents. A signed JWT, for example, is typically still readable by anyone who intercepts it. Encryption, by contrast, protects confidentiality so that only a holder of the appropriate key can read the contents. Confirming a token is signed tells you nothing about whether it is also encrypted, and in many deployments tokens are signed but not encrypted.
Does possessing a public key let someone impersonate the key holder?
No. The public key is intended to be distributed and is used to verify signatures or to encrypt data to the key holder; it does not permit impersonation. Impersonation would require the corresponding private key, which must remain secret. In most deployments the security of the pair rests entirely on protecting the private key, while the public key can be published freely. If a private key is exposed, however, the assurances the pair provides are broken and the key should be rotated.
Where should the private key of a key pair be stored?
Storage depends on your threat model and deployment context, but the general principle is to keep the private key confidential and to limit where it can be extracted. In many deployments private keys are held in a hardware security module (HSM), a trusted platform module, a secure enclave, or a managed key-management service rather than in plaintext on disk. Access should be restricted and audited. The correct choice varies by vendor, compliance requirements, and whether the key is used by a person, a service, or a device.
How often should a key pair be rotated?
Rotation frequency depends on policy, risk tolerance, and any applicable standards or profiles rather than a single fixed interval. Considerations typically include the sensitivity of what the key protects, exposure risk, and operational overhead of rotation. Keys should also be rotated immediately if compromise is suspected. Because behavior varies by vendor and configuration, consult your key-management platform's guidance and your organization's cryptographic policy for specific intervals.
How do consumers of a public key discover and trust the correct one?
The distribution mechanism depends on the protocol and deployment. In some ecosystems public keys are published at a well-known endpoint (for example a JWKS endpoint referenced in an OIDC or OAuth 2.0 deployment), where relying parties fetch keys to verify signatures. In others, trust is established through certificates issued by a certificate authority or through pre-shared, out-of-band exchange. Trust in the key ultimately rests on the surrounding trust model, so verify which mechanism your standard profile and vendor prescribe.
What happens when a private key needs to be revoked or is compromised?
The response depends on how the key is trusted. When trust flows from a certificate, revocation is typically communicated through mechanisms such as certificate revocation lists or online status checks, though propagation and enforcement vary by configuration. When relying parties fetch keys from a published key set, removing or rotating the key at the source and allowing consumers to refresh can end its acceptance. Any tokens or artifacts signed by a compromised key should be treated as untrustworthy, and dependent systems and credentials should be reviewed. Specific procedures and timing vary by vendor and profile.

Common misconceptions

A signed token is also encrypted, so its contents are protected from being read.
Signing with the private key provides integrity and proof of origin, not confidentiality. A signed but unencrypted token (such as a typical JWT) can be decoded and read by anyone who obtains it. Encryption is a separate operation and must be applied explicitly if confidentiality is required.
Publishing or sharing the public key weakens the security of the key pair.
The public key is designed to be distributed. Verifiers and encrypting parties need it to function, and its exposure does not reveal the private key. Security depends on keeping the private key secret, not on restricting the public key.
Possessing a valid key pair or verifying a signature by itself authenticates a user.
A key pair proves control of the private key, which supports possession-based verification, but authentication of a principal is a distinct step that binds that key to an identity within a given trust context. The signature validates origin and integrity; asserting who the principal is depends on the surrounding protocol and configuration.

Best practices

Protect private keys with strong storage controls such as hardware security modules or dedicated key management services, and never distribute or embed them where the public key alone would suffice.
Separate keys by purpose where feasible, using distinct key pairs for signing and for encryption rather than reusing one pair across both functions.
Publish public keys through a discoverable, verifiable mechanism (for example a JWKS endpoint) and include a key identifier so relying parties can select the correct key for verification.
Establish a key rotation schedule and support overlapping validity so that older public keys remain available to verify tokens signed before rotation, avoiding validation failures.
Define and enforce revocation and compromise-response procedures so a suspected private key exposure can be handled without relying solely on expiration.
Do not treat a valid signature as equivalent to user authentication or confidentiality; verify signatures for integrity and origin while applying encryption and identity binding separately as the deployment requires.
Promotional banner for the Pentest Readiness checklist download