Asymmetric Encryption: Public and Private Key Systems

Asymmetric encryption is the cryptographic foundation underlying secure internet communications, digital identity verification, and authenticated data exchange across public networks. Unlike symmetric encryption, asymmetric systems use mathematically linked key pairs — one public, one private — eliminating the need to share secret keys over potentially compromised channels. This page describes how those systems are structured, the dominant algorithms in active use, the regulatory and compliance contexts that mandate their application, and the operational boundaries that govern algorithm selection.

Definition and scope

Asymmetric encryption, also called public-key cryptography, is a class of cryptographic system in which two distinct but mathematically related keys perform complementary functions: one key encrypts or verifies, and the other decrypts or signs. The public key can be distributed freely; the private key remains secret to its owner. A message encrypted with the public key can only be decrypted by the corresponding private key, and a digital signature generated with the private key can only be verified by the corresponding public key.

NIST SP 800-175B Rev. 1, Guideline for Using Cryptographic Standards in the Federal Government: Cryptographic Mechanisms, formally defines public-key cryptography and specifies approved algorithms for federal use. The three principal families of asymmetric algorithms in active federal and commercial deployment are:

NIST's post-quantum standardization effort, formalized through FIPS 203, FIPS 204, and FIPS 205 (published August 2024), introduces lattice-based and hash-based algorithms — CRYSTALS-Kyber, CRYSTALS-Dilithium, and SPHINCS+ — to replace RSA and ECC in contexts where quantum computing poses a credible threat. The transition timeline and scope are described in post-quantum cryptography.

How it works

The operational mechanics of asymmetric encryption follow a defined sequence regardless of the underlying algorithm family:

  1. Key generation: A key pair is generated using a cryptographically secure random number generator. The private key is derived first; the public key is computed from it through a one-way mathematical function. The security of the system depends on the computational infeasibility of reversing this function.
  2. Public key distribution: The public key is shared through a trusted channel — typically a digital certificate issued by a certificate authority operating within a public key infrastructure (PKI).
  3. Encryption (confidentiality use case): A sender retrieves the recipient's public key, uses it to encrypt the plaintext, and transmits the ciphertext. Only the holder of the corresponding private key can decrypt.
  4. Decryption: The recipient applies the private key to the ciphertext, recovering the original plaintext. The private key never leaves the recipient's secure environment.
  5. Digital signing (authentication use case): The signer applies the private key to a hash of the message, producing a signature. Any party with the public key can verify authenticity and integrity by recomputing the hash and checking the signature. See digital signatures reference for the full signing workflow.
  6. Key exchange: In protocols like TLS 1.3, asymmetric operations are used exclusively to authenticate parties and negotiate a session key; bulk data encryption is then performed symmetrically using AES for performance reasons.

Asymmetric operations are computationally expensive relative to symmetric operations. RSA encryption of a 256-byte payload is orders of magnitude slower than AES-256 encryption of the same payload on equivalent hardware, which is why hybrid approaches — asymmetric for key exchange, symmetric for data — dominate production deployments.

Common scenarios

Asymmetric encryption appears across distinct operational contexts, each with its own standards requirements:

Decision boundaries

Selecting the appropriate asymmetric system requires matching algorithm characteristics to operational constraints, threat models, and compliance obligations.

RSA vs. ECC: RSA remains widely supported across legacy systems and is often required for interoperability with older hardware security modules. ECC offers equivalent security at shorter key lengths, reducing computational overhead — relevant for constrained environments such as IoT devices and mobile platforms. For new deployments without legacy constraints, NIST SP 800-57 Part 1 Rev. 5 recommends ECC over RSA due to the security-per-bit advantage.

Key length minimums by compliance regime:

Quantum readiness: RSA and ECC are both vulnerable to Shor's algorithm on a sufficiently capable quantum computer. Organizations under long-data-retention mandates — healthcare records, classified archives — face "harvest now, decrypt later" exposure even before quantum hardware matures. NIST's post-quantum algorithm standards (FIPS 203–205) define the migration path. Quantum threats to encryption quantifies the threat timeline as understood by the cryptographic research community.

Private key storage: The security model of asymmetric encryption collapses if the private key is compromised. Hardware security modules and secure enclaves are the accepted mitigation for production private key storage, with FIPS 140-3 Level 3 or higher validation required in high-assurance federal deployments. Encryption key management covers the lifecycle governance framework.

References

Explore This Site

Regulations & Safety Regulatory References