Skip to main content
Commerce Security Authority
Category: Cryptography Fundamentals

Public Key

Also known as: asymmetric public key
Simply put

A public key is one half of a matched pair of cryptographic keys used in asymmetric cryptography, and it can be shared openly with anyone. It is typically used to encrypt data that only the holder of the corresponding private key can decrypt, or to verify digital signatures created with that private key. Because it is meant to be distributed freely, sharing a public key does not by itself expose the secret private key.

Formal definition

A public key is the publicly distributable component of an asymmetric (public-key) key pair, mathematically related to a corresponding private key. In practice it is a large numerical value, often generated by software, and is used to verify digital signatures produced with the associated private key or to encrypt data intended for decryption only by the private key holder. Its confidentiality is not required; however, its authenticity and binding to an identity typically depend on supporting mechanisms such as certificates and public key infrastructure, which are out of scope for the term itself.

Why it matters

Public keys underpin much of the trust in modern payment and internet communications. Because a public key can be shared openly without exposing its matched private key, it enables two parties who have never met to establish confidentiality and to verify the origin of data. In payment environments this supports capabilities such as securing data in transit and validating digital signatures, which are foundational to the integrity of transaction flows and software supply chains.

The security value of a public key depends heavily on its authenticity and its binding to a genuine identity. A public key on its own is just a large numerical value; it does not prove who controls the corresponding private key. That assurance typically comes from supporting mechanisms such as certificates and public key infrastructure, which are separate from the key itself. If an attacker can substitute their own public key for a legitimate one, they may be able to intercept or impersonate a party, so the trust chain around the key matters as much as the key.

It is important not to overstate what a public key achieves. Asymmetric cryptography is intended to help protect confidentiality and verify signatures, but it does not by itself prevent fraud, guarantee that a private key has been kept secure, or replace controls governing how sensitive data is stored and handled. Its effectiveness is a function of correct implementation, key management, and the surrounding infrastructure rather than the presence of a public key alone.

Who it's relevant to

Security engineers
Engineers implementing encryption in transit, digital signatures, or software signing rely on public keys as one half of an asymmetric pair. They need to ensure that public keys are correctly generated, distributed, and bound to identities through certificates and key management processes, since the key alone does not establish trust.
Compliance officers
Compliance teams should understand that a public key does not require confidentiality, unlike the corresponding private key, and that the security of asymmetric cryptography depends on the surrounding infrastructure and key management rather than on the key label. Confirm applicable cryptographic control requirements against the current published standard.
Payment processors and acquirers
Organizations handling transaction data use public-key techniques to help protect data confidentiality and to verify signatures across parties that may not share a prior trust relationship. They should treat the authenticity and binding of public keys, via certificates and public key infrastructure, as a critical dependency rather than assuming the key alone provides assurance.

Inside Public Key

Asymmetric key pair relationship
A public key is one half of an asymmetric key pair, mathematically related to a corresponding private key. Data encrypted with the public key can generally only be decrypted with the matching private key, and signatures created with the private key can be verified with the public key.
Distributable component
The public key is the portion of the pair intended to be shared openly, in contrast to the private key, which must be protected from disclosure. Distribution of the public key does not by itself compromise the confidentiality of data protected by the pair.
Certificate binding
In many deployments the public key is distributed within a digital certificate that binds the key to an identity and is signed by a certificate authority, allowing relying parties to establish a degree of trust in the key's ownership.
Cryptographic function supported
Public keys are used to support functions such as verifying digital signatures, encrypting data or session material intended for the holder of the private key, and establishing keys during protocols such as TLS. The specific function depends on the algorithm and implementation.
Relationship to payment data protection
When asymmetric cryptography is applied to protect cardholder data, the public key participates in encryption or key establishment. Whether such protection affects PCI DSS scope depends on the overall implementation and validation, not on the presence of a public key alone. Sensitive authentication data must not be retained after authorization even when cryptographic protection is applied.

Common questions

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

Does a public key need to be kept secret like other keys used in payment security?
No. A public key is designed to be shared openly; that is what distinguishes it from the corresponding private key, which must be protected. In asymmetric cryptography, the security of the system does not depend on keeping the public key confidential. However, this does not mean the public key requires no protection at all: its authenticity and integrity still matter, because an attacker who substitutes a fraudulent public key can impersonate a party or intercept communications. This is why public keys are typically distributed within certificates that bind the key to an identity and are validated against a trusted certificate authority.
If a message is encrypted with a public key, does that alone confirm who sent it?
No. Encrypting with a recipient's public key provides confidentiality toward that recipient, not proof of the sender's identity. Anyone with access to a public key can use it, so encryption to a public key does not authenticate the originator. Sender authentication is a separate function, typically achieved through digital signatures created with the sender's private key and verified with the sender's public key. Confidentiality and authentication address different goals and should not be conflated; a given exchange may use one, the other, or both depending on how the protocol is designed.
How is a public key distributed so that relying parties can trust it?
Public keys are commonly distributed inside digital certificates issued by a certificate authority, which binds the key to an identity and is itself signed so that relying parties can validate it against a trust chain. The specific certificate formats, validation procedures, and trust anchors depend on the protocol and environment in use. Regardless of distribution method, the receiving party should verify the key's authenticity and integrity before relying on it, so that a substituted or forged key is detected.
What key management practices apply to the private key paired with a public key?
While the public key is shared, the paired private key must be generated, stored, and used under strong controls, and access to it should be restricted. Key management expectations, including generation, storage, rotation, and retirement, are addressed within PCI DSS and are treated in more detail by standards such as PCI PIN and PCI P2PE where they apply to specific cryptographic uses. Because requirement numbering and wording differ between versions, confirm the applicable controls against the current published standard for your environment rather than assuming a fixed requirement number.
How should key length and algorithm choices for public keys be evaluated?
Public key strength depends on the algorithm and key length selected, and what is considered adequate changes over time as cryptanalysis and computing capabilities evolve. Rather than treating any specific size as permanently sufficient, organizations should align choices with current, published guidance on strong cryptography and plan for the ability to migrate as recommendations change. Exact acceptable parameters depend on the source, the period, and the intended use, so verify against the applicable standard and current guidance.
What happens if a private key is compromised, and what does that mean for its public key?
If the corresponding private key is compromised, the key pair can no longer be trusted, because an attacker may be able to decrypt data intended for the holder or forge signatures that verify against the public key. In that case the associated certificate should be revoked and relying parties notified through the appropriate revocation mechanisms, and a new key pair should be issued. Because a compromised private key undermines every use of its public key, incident response planning should include procedures for revocation, re-issuance, and confirming that relying parties stop trusting the affected key.

Common misconceptions

Because a public key can be shared openly, publishing it weakens the security of the system.
The public key is designed to be distributed. Security of the pair depends on protecting the private key. However, an unauthenticated public key can be substituted by an attacker, which is why binding the key to an identity through certificates and validating that trust chain matters.
Using a public key to encrypt cardholder data automatically removes systems from PCI DSS scope.
Encryption is one of several data-protection techniques and is distinct from tokenization, truncation, masking, and hashing. Its effect on scope depends on how it is implemented, how keys are managed, and how the deployment is validated, not on the use of a public key by itself. Encryption also does not authorize retention of sensitive authentication data after authorization.
A public key alone proves who you are communicating with.
A raw public key conveys no identity. Trust in the key's ownership comes from the surrounding infrastructure, such as a certificate signed by a trusted authority and proper validation of that certificate. Public-key mechanisms address message-level integrity and confidentiality and are separate from transaction authentication controls such as EMV chip authentication, 3-D Secure, strong customer authentication, and multi-factor authentication.

Best practices

Validate the trust chain of any certificate carrying a public key, including signature verification, validity period, and revocation status, rather than trusting a key solely because it was received.
Protect the corresponding private key with appropriate access controls and key-management processes, since the security of a public key pair depends on private-key confidentiality.
Select algorithms and key sizes consistent with current, industry-accepted cryptographic guidance, and confirm requirements against the current published PCI DSS standard rather than assuming a fixed requirement number.
Do not treat public-key encryption as a substitute for the prohibition on storing sensitive authentication data after authorization; ensure such data is not retained regardless of cryptographic protection.
Distinguish the role of encryption from tokenization, truncation, masking, and hashing when designing data protection, and validate any scope-reduction claims through the appropriate assessment process.
Document how public keys, certificates, and their associated private keys are generated, distributed, rotated, and retired as part of an overall key-management lifecycle.