Public-key cryptography is the approach that emerged in the mid-1970s to let two parties establish trust and protect information without first sharing the same secret key.
That shift led to asymmetric cryptography, also called public-key cryptography, where a mathematically related key pair is used instead of one shared secret. This article builds on the symmetric encryption concepts covered in Understanding Cryptography Part 1: Symmetric Encryption, because modern systems normally use both ideas together.
Why asymmetric cryptography changed security
Symmetric encryption remains the practical choice for encrypting large volumes of data. Disk encryption, VPNs, wireless protection, and the encrypted part of a TLS session all depend on fast symmetric algorithms because they are efficient and well suited to bulk data.
Asymmetric cryptography solved a different problem: how to communicate securely, prove identity, and verify integrity when the parties do not already share a secret. Diffie-Hellman key exchange, RSA, and elliptic curve cryptography made it possible to build protocols where a public value can be shared widely while a private value remains protected.
The distinction matters in real systems. A browser does not usually use a server’s public key to encrypt every byte of a web session. In modern TLS, asymmetric methods help authenticate the server and agree on fresh session keys, then symmetric authenticated encryption protects the traffic that follows.
The two-key idea
An asymmetric key pair contains a private key and a corresponding public key. The keys are mathematically related, but a properly generated private key cannot be feasibly derived from the public key with current classical computing methods and appropriate algorithm choices.
The operational rule is simple but unforgiving: the private key must remain private. It should not be emailed, copied casually, embedded in source code, placed in shared folders, or treated as a configuration value. The public key, by contrast, is designed to be distributed through certificates, key servers, repositories, SSH configuration, package registries, or other trusted publication mechanisms.
The second rule is that the pair works together. If one half of the pair is used for a cryptographic operation, the other corresponding half is used to complete or verify it. This is the foundation for both public-key encryption and digital signatures, but the direction of key use is different in each case.
Encryption and signing are different operations
Public-key encryption is about confidentiality. If a sender wants to send a protected message to a recipient, the sender encrypts data, or more commonly encrypts a temporary symmetric key, using the recipient’s public key. Only the recipient’s private key can decrypt it.
Digital signing is about authenticity and integrity. A signer uses a private key to create a signature over a message, document, executable, certificate, or software package. Anyone with the corresponding public key can verify that signature and detect whether the signed content has changed.
This difference is a frequent source of mistakes. Encrypting something with a public key does not prove who created it, because the public key is public. Signing something with a private key does not hide the content, because verification is intended to be public. Systems often need both protections, but they should be designed as separate controls.
How hybrid encryption works
Asymmetric algorithms are powerful, but they are not normally used to encrypt large files or continuous network traffic directly. They are slower than symmetric algorithms and have size limits and padding requirements that make them unsuitable for bulk encryption.
Instead, many protocols use hybrid encryption. The system creates a random symmetric session key, protects that key with an asymmetric mechanism, and then uses a symmetric cipher such as an authenticated encryption mode to protect the actual data. This pattern combines the key distribution advantage of public-key cryptography with the performance of symmetric cryptography.
- The recipient publishes a public key or certificate.
- The sender generates a fresh symmetric key for the session or message.
- The sender protects that session key using the recipient’s public key or a key agreement protocol.
- The recipient uses the private key or key agreement result to recover the session key.
- Both sides use the session key for efficient symmetric encryption and integrity protection.
That structure appears in different forms across secure messaging, file encryption, and network security protocols. The most important design point is that the long-term private key is not used as a general-purpose data-encryption tool; it is used to protect, authenticate, or derive keys under controlled conditions.
Digital signatures in practical terms
A digital signature begins with the content to be protected. The signing process uses the signer’s private key and a cryptographic hash of the content to produce a signature. The verifier then uses the signer’s public key to check that the signature is valid for that exact content.
When this works correctly, the verifier gains evidence that the content has not been altered and that the signer controlled the private key at the time of signing. Whether that signer should be trusted depends on identity binding, certificate validation, policy, and operational controls around the key.
This is why code signing, package signing, signed email, and signed certificates are operational security controls as much as cryptographic ones. A valid signature from a stolen private key may still verify technically, which is why key protection, timestamping, revocation, and incident response procedures matter.
Where public-key cryptography appears in daily work
TLS is the most visible example. In TLS 1.3, the handshake uses ephemeral Diffie-Hellman-style key exchange to establish fresh session secrets with forward secrecy. Server certificates still authenticate the server, and those certificates may use RSA or ECDSA signatures, but RSA key exchange is no longer part of the modern TLS 1.3 design.
That change is significant. With ephemeral key exchange, compromise of a server’s long-term private key should not automatically decrypt previously captured sessions, assuming the implementation and configuration are sound. This is one reason current TLS design separates authentication from session-key establishment.
Email security uses the same concepts in a different context. S/MIME relies on certificates and organisational trust chains, while PGP-style systems use public keys and trust models that are managed differently. In both cases, encryption protects message confidentiality, while signing provides evidence of origin and message integrity.
SSH also depends on asymmetric cryptography. Servers present host keys so clients can detect unexpected server changes, and users often authenticate with private keys rather than passwords. The security benefit depends heavily on protecting the private key, using passphrases where appropriate, and treating host-key warnings as meaningful rather than routine noise.
Software supply chains depend on signatures as well. Code signing, container image signing, and package signing help consumers verify that software has not been altered since it was signed by a trusted publisher. These controls are more important because attackers often target build systems, developer credentials, and signing keys rather than attempting to break cryptographic algorithms directly.
RSA and ECC: choosing the right tool
RSA remains widely deployed because it has long-standing support across certificates, smart cards, legacy systems, and enterprise infrastructure. Its compatibility is valuable when systems must work with older clients, older appliances, or constrained certificate ecosystems that have not fully modernised.
Elliptic curve cryptography offers comparable security properties with smaller keys and often better performance, especially for mobile devices, embedded systems, and high-volume services where handshake efficiency matters. ECC is common in modern TLS deployments, SSH keys, and certificate profiles, but compatibility should still be checked before changing production environments.
| Consideration |
RSA |
ECC |
| Compatibility |
Strong fit for older systems and broad enterprise support. |
Strong fit for modern platforms, but legacy support varies. |
| Performance |
Can be heavier at larger key sizes. |
Often efficient with smaller keys and faster handshakes. |
| Operational fit |
Useful where established PKI tooling assumes RSA. |
Useful for modern TLS, mobile, embedded, and cloud-native services. |
| Migration concern |
May persist for interoperability reasons. |
Requires validation across clients, devices, libraries, and certificate authorities. |
The practical decision is rarely based on cryptographic preference alone. Teams need to consider certificate authority support, client compatibility, hardware security module support, compliance requirements, library maturity, and the expected lifetime of the system. A cautious migration often starts with testing ECC certificates and keys in parallel with existing RSA-based services before making a broad cutover.
Certificates and PKI turn public keys into trust decisions
A public key by itself is only a public key. A certificate binds that key to an identity, such as a domain name, organisation, person, device, or service. X.509 certificates include fields such as the subject, issuer, validity period, public key, key usage, subject alternative names, and the certificate authority signature.
PKI adds the trust structure around those certificates. A root certificate authority signs intermediate authorities, and intermediates issue end-entity certificates for servers, users, devices, or code-signing identities. When a client validates a certificate, it checks the chain, the intended usage, the validity period, the hostname or identity, and whether the issuing authority is trusted for that purpose.
Revocation is one of the harder operational problems. Certificate revocation lists and OCSP can indicate that a certificate should no longer be trusted, but browsers, devices, and applications handle failure and availability differently. If revocation checking is unavailable, systems must decide whether to fail closed and risk disruption or fail open and risk accepting a revoked certificate.
This is where cryptographic design meets operations. Shorter certificate lifetimes can reduce reliance on revocation, but they require reliable automation. Longer lifetimes may reduce operational churn but increase exposure if private keys are compromised. Neither choice removes the need for monitoring, inventory, and renewal controls.
Private key protection is the control that makes the maths useful
The mathematics of public-key cryptography can be sound while the implementation is weak. Many incidents happen because private keys are copied into repositories, exported without control, left on developer laptops, stored without passphrase protection, or reused across systems with different risk profiles.
Private keys used for high-value services should be protected with controls appropriate to their sensitivity. Hardware security modules, TPM-backed storage, cloud key management services, restricted file permissions, strong access control, and auditable signing workflows all reduce the chance that a key can be stolen or misused.
Rotation and backup require careful design. Losing an encryption private key may make protected data unrecoverable, while losing a signing key can interrupt releases or break trust in update channels. Escrow may be appropriate for some encryption keys, but it is usually unsuitable for signing keys where exclusive control is central to trust.
Key reuse is another common pitfall. A key created for TLS server authentication should not be casually reused for code signing, document signing, or unrelated services. Separate keys support clearer policy, safer rotation, cleaner incident response, and reduced blast radius if one environment is compromised.
Standards give structure, but implementation still matters
Public-key systems are usually implemented through protocols and standards rather than raw algorithms. NIST SP 800-56A and SP 800-56B address key establishment approaches, RFC 5280 defines the Internet X.509 certificate profile, and RFC 8446 specifies TLS 1.3. These references matter because many security failures come from using the right algorithm in the wrong mode, with weak validation, poor randomness, or unsafe key handling.
Standards also help clarify responsibilities. Developers need reliable libraries and correct API use. Security architects need sound trust models and certificate policies. Operations teams need lifecycle management, monitoring, backup decisions, and incident procedures. Public-key cryptography works best when these responsibilities are designed together rather than treated as separate tasks.
Learning the concepts without losing the operational view
Asymmetric cryptography is easier to understand when the core rule is kept in view: public keys may be distributed, private keys must be protected, and each key pair has a defined purpose. From that foundation, encryption, signing, authentication, and key exchange become clearer.
Readers building wider security knowledge may also find value in structured topics such as identity, risk, governance, and security architecture. Readynez covers these areas in broader security learning paths, including the CISSP overview masterclass and CISM overview masterclass, where cryptography is treated as part of a larger security programme rather than an isolated theory topic.
Applying public-key cryptography safely
The value of asymmetric cryptography is that it supports trust between parties that do not already share a secret. It enables secure key establishment, digital signatures, certificate-based identity, SSH authentication, signed software, and protected communications across open networks.
The key takeaway is that strong algorithms are only one part of the system. Sound certificate validation, protected private keys, appropriate RSA or ECC choices, automation for renewal and rotation, and clear separation between encryption and signing are what make public-key cryptography reliable in practice. Readynez readers who want historical context on the original article series can also read more about Kevin Henry’s security teaching background.
