Asymmetric Encryption: Public and Private Key Systems
Asymmetric encryption — also called public-key cryptography — is the structural foundation of authenticated digital communication, enabling two parties to exchange encrypted data without sharing a secret key in advance. This page covers the mechanism, key variants, common deployment scenarios, and the decision boundaries that determine when asymmetric methods are appropriate versus symmetric alternatives. Regulatory frameworks from NIST, FIPS, and industry standards bodies establish specific algorithm and key-length requirements that govern compliant implementations across federal and commercial sectors.
Definition and scope
Asymmetric encryption operates on mathematically linked key pairs: a public key, which may be freely distributed, and a private key, which is held exclusively by its owner. Data encrypted with the public key can only be decrypted by the corresponding private key, and vice versa. This architecture solves the key-distribution problem inherent in symmetric encryption, where both parties must share the same secret before any secure exchange can occur.
NIST SP 800-175B Rev 1, Guideline for Using Cryptographic Standards in the Federal Government, formally classifies asymmetric algorithms as a distinct cryptographic family and mandates minimum key lengths for federal information systems. For RSA, NIST specifies a minimum key size of 2048 bits for systems operating beyond 2030, with 3072 bits recommended for longer-term security horizons. For elliptic-curve algorithms, 256-bit keys (P-256) provide comparable security to RSA-3072 at substantially lower computational cost.
The scope of asymmetric encryption spans three primary functions:
- Confidentiality — encrypting data so only the private-key holder can read it
- Authentication — signing data so recipients can verify the sender's identity
- Key establishment — negotiating shared symmetric keys over untrusted channels (as in TLS handshakes)
The encryption providers on this site cover the full provider landscape structured around these functional categories.
How it works
Asymmetric encryption relies on mathematical problems that are computationally easy in one direction but infeasible to reverse without the private key. Three distinct algorithm families dominate deployed infrastructure:
RSA (Rivest–Shamir–Adleman): Based on the difficulty of factoring the product of two large prime numbers. RSA is specified in NIST FIPS 186-5, Digital Signature Standard, and in PKCS #1 (RFC 8017). Key generation, encryption, and signature verification are computationally intensive relative to symmetric operations, making RSA unsuitable for bulk data encryption.
Elliptic Curve Cryptography (ECC): Based on the algebraic structure of elliptic curves over finite fields. NIST-approved curves — P-256, P-384, and P-521 — are specified in FIPS 186-5. ECC achieves equivalent security strength to RSA at significantly shorter key lengths: a 256-bit ECC key is considered roughly equivalent to a 3072-bit RSA key (NIST SP 800-57 Part 1 Rev 5, Table 2).
Diffie–Hellman / ECDH: A key agreement protocol rather than a direct encryption scheme. Diffie–Hellman allows two parties to derive a shared secret over a public channel without transmitting the secret itself. The elliptic-curve variant (ECDH) is dominant in TLS 1.3, where it is used for ephemeral key exchange before symmetric session keys are established.
The operational sequence for a public-key encryption transaction follows discrete phases:
This hybrid model — asymmetric for key establishment, symmetric for bulk encryption — is the architecture used by TLS, PGP, and S/MIME.
Common scenarios
TLS/HTTPS: Every HTTPS session uses asymmetric cryptography during the handshake phase. TLS 1.3, standardized in RFC 8446, mandates ephemeral key exchange (ECDHE), ensuring forward secrecy so that compromise of a long-term private key does not expose past session traffic. The for this site situates TLS within the broader encryption service landscape.
Digital signatures and code signing: Software vendors, certificate authorities, and federal agencies use RSA or ECDSA signatures to authenticate software packages, firmware, and documents. Federal agencies operating under FIPS 140-3 must use validated cryptographic modules for any signature generation.
Email encryption (S/MIME and PGP/GPG): Both standards use public-key encryption to protect message confidentiality and authenticate senders. S/MIME relies on X.509 certificates issued through hierarchical PKI; PGP uses a decentralized web-of-trust model. HIPAA-covered entities transmitting protected health information (PHI) by email must apply encryption meeting NIST standards (HHS guidance references NIST SP 800-111 for encryption of data at rest, and SP 800-52 for transmission).
SSH key authentication: Secure Shell (SSH) supports RSA, ECDSA, and Ed25519 key pairs for server and user authentication, replacing password-based access in hardened server environments. Ed25519, based on the Edwards-curve Digital Signature Algorithm, is increasingly preferred for its performance and resistance to timing side-channel attacks.
PKI and certificate infrastructure: Public Key Infrastructure (PKI) is the governance layer that binds public keys to verified identities through X.509 certificates. The how to use this encryption resource page maps the PKI-related service categories covered across this reference network.
Decision boundaries
Asymmetric encryption is not universally the optimal choice. The principal tradeoffs against symmetric encryption involve performance, key management complexity, and post-quantum vulnerability.
Asymmetric vs. symmetric encryption:
| Dimension | Asymmetric (RSA/ECC) | Symmetric (AES) |
|---|---|---|
| Key distribution | No pre-shared secret required | Requires secure prior exchange |
| Performance | 100–1,000× slower than AES for bulk data | High throughput, hardware-accelerated |
| Key length for 128-bit security | RSA: 3072 bits; ECC: 256 bits | AES: 128 bits |
| Primary use | Key exchange, authentication, signatures | Bulk data encryption |
| Post-quantum status | Vulnerable (RSA, ECC broken by Shor's algorithm) | AES-256 considered resistant with doubled key length |
Post-quantum considerations: NIST's Post-Quantum Cryptography Standardization project finalized its first standards in 2024, including FIPS 203 (ML-KEM, for key encapsulation) and FIPS 204 (ML-DSA, for digital signatures). Federal agencies under National Security Memorandum 10 (NSM-10) are directed to inventory and migrate cryptographic systems away from RSA and ECC toward post-quantum algorithms on a defined timeline. Organizations subject to FISMA, FedRAMP, or DoD RMF must treat this transition as an active compliance requirement, not a future consideration.
Key length selection: NIST SP 800-57 Part 1 Rev 5 defines security strength categories in bits and maps them to algorithm/key-length combinations. Systems processing data with a confidentiality requirement extending past 2030 should not be deployed with RSA-2048; RSA-3072 or P-256 ECC represents the minimum threshold for new implementations.
Certificate authority trust: Any asymmetric deployment involving public certificates depends on the integrity of the issuing CA. The CA/Browser Forum's Baseline Requirements, enforced by browser vendors, set certificate lifetimes, validation standards, and key requirements for publicly trusted certificates. Failures in CA trust — such as the Diginotar breach — demonstrate that the security of public-key systems is bounded by the weakest trusted authority in the certificate chain.