8 Examples of Asymmetric Encryption in Practice (2026)

Most organizations know they need to change their public-key cryptography before they've worked out where it runs. In a 2024 Ponemon Institute survey of 4,052 respondents across nine countries, 61% of organizations planned to migrate to post-quantum cryptography within five years, according to the Entrust report. A migration plan needs more than an algorithm name. Engineers need to know which keys encrypt, which authenticate, and which establish session secrets.

Asymmetric cryptography already supports everyday traffic, from HTTPS connections to signed software releases and SSH authentication. Most applications combine it with symmetric encryption rather than using public-key operations to encrypt entire payloads. BroLabel's guide to key pairs explains the public-key and private-key relationship behind these systems.

The useful distinction is purpose. Encryption protects confidentiality, key agreement establishes a shared secret, and signatures authenticate data. Common lists of examples of asymmetric encryption often mix these together, so the examples below identify what each mechanism does.

For a design review, ask what decision follows: which key size to accept, which padding to reject, how to authenticate a peer, and who owns replacement when the cryptography changes.

1. RSA (Rivest-Shamir-Adleman)

RSA supports encryption and digital signatures, but those operations require different schemes. Its security depends on the practical difficulty of factoring a large integer constructed from secret prime factors. You'll encounter it in TLS certificates, S/MIME messages, OpenPGP keys, and SSH authentication.

The public key can support encryption or signature verification. The private key supports decryption or signing, depending on the scheme. Don't describe a signature as encryption with the private key, because that hides important differences in encoding and verification.

Decide the Key Size and Padding Separately

For applicable federal uses, NIST's algorithm-transition guidance identifies RSA moduli of at least 2048 bits as meeting a minimum 112-bit security-strength requirement. Treat that as a scoped baseline, not a guarantee that every RSA implementation is secure.

Say a financial application receives an encrypted data key from a partner. The review must specify the encryption scheme and error handling, not merely approve RSA.

• Encryption: Use RSA-OAEP through a maintained cryptographic library. Reject new designs using PKCS#1 v1.5 encryption.
• Signatures: Prefer RSA-PSS where the protocol and consumers support it.
• Key separation: Keep encryption and signing responsibilities distinct, with explicit permissions and lifecycle owners.
• Implementation: Review padding failures, logging, and exception paths alongside the cryptographic call.

Make these requirements part of your secure coding practices, rather than leaving them in an architecture diagram. For SSH, distinguish an RSA key from the older ssh-rsa signature algorithm: retaining the key doesn't require retaining obsolete signature negotiation.

The trade-off is compatibility versus operational cost. RSA remains useful in existing integrations, but accepting it should include an inventory entry and a replacement path.

2. Diffie-Hellman Key Exchange (DH and ECDH)

A browser and an API server need the same session secret, but neither should send that secret across the network. Diffie-Hellman solves key agreement, not bulk encryption. Each participant combines a private value with the other participant's public value to derive matching secret material.

Finite-field DH uses arithmetic modulo a prime. Elliptic Curve Diffie-Hellman, or ECDH, performs key agreement using elliptic-curve operations. Protocols then feed the result into a key-derivation function before using it for symmetric encryption.

Require Ephemeral Keys and Authenticated Peers

The design decision is whether session keys depend on fresh, temporary secrets. Ephemeral DH or ECDH supports forward secrecy when implementations generate, handle, and erase those secrets correctly. Later theft of a long-term authentication key then doesn't, by itself, reveal previously established session keys.

Practical rule: A shared secret doesn't prove who's on the other end. Authenticate the exchange before trusting it.

For a service-to-service connection, that authentication might come from a validated certificate and a handshake signature. For SSH, it includes validating the server's host key. Skipping identity verification creates an interception opportunity even when the key-agreement mathematics is sound.

• Algorithm choice: Prefer established, library-supported options such as X25519 or P-256 instead of custom groups.
• Protocol integration: Use the protocol's specified derivation and transcript binding. Don't treat the raw shared secret as an application key.
• Failure behavior: Reject invalid peer inputs and unsupported groups rather than switching to an unapproved configuration.
• Evidence: Record the negotiated group and authentication method in integration tests.

A typical SSH review should examine curve25519-sha256 key exchange separately from the host-key signature algorithm. The trade-off is compact, efficient agreement versus compatibility with older peers. Resolve that compatibility deliberately rather than enabling every available group.

3. ECDSA (Elliptic Curve Digital Signature Algorithm)

ECDSA authenticates messages. It doesn't encrypt them. A service signs with a private scalar, and a verifier checks that signature against the corresponding public point. Typical uses include TLS certificates, signed tokens, and transaction authorization.

Its appeal is compact public-key material. The AWS explanation of elliptic-curve cryptography describes the equivalence between a 256-bit elliptic-curve key and a 3072-bit RSA key at approximately 128-bit security strength. That comparison concerns security strength, not interchangeable formats or identical runtime performance.

Review Nonce Handling Before Approving the Curve

ECDSA signing uses a per-message secret value commonly called a nonce. Reusing that value across different messages can expose the private key. A strong curve won't compensate for broken nonce generation.

Consider an API that issues JWTs using ES256. The reviewer should inspect the signing library, key storage, and verification configuration, not just confirm that the token carries the expected algorithm label.

• Signing implementation: Use a maintained library with deterministic nonce generation where appropriate. Don't implement nonce arithmetic yourself.
• Curve selection: Choose an approved curve that your certificate authorities, clients, and cryptographic modules support.
• Token verification: Pin accepted algorithms and trusted keys. Don't let an untrusted token header determine verification policy.
• Side channels: Use implementations designed to protect secret-dependent operations.

The practical trade-off is smaller keys versus stricter implementation discipline. Deterministic nonce generation reduces dependence on fresh randomness for each signature, but it doesn't eliminate key-generation or side-channel risks.

Record the curve, signature algorithm, key owner, and verification rules together. If an application accepts multiple signing algorithms during migration, test each path explicitly and give the temporary compatibility path an owner.

4. Ed25519 (EdDSA on Curve25519)

For a new internal SSH deployment, Ed25519 is often a straightforward signing choice when the fleet and its assurance requirements support it. OpenSSH, libsodium, and Go's crypto/ed25519 package provide established implementations. It also fits application signatures where both producer and consumer control their software stacks.

Ed25519 is an EdDSA signature scheme, not an encryption or key-agreement mechanism. Ed25519 and X25519 solve different problems, despite their related mathematical foundations. Don't substitute one key type for the other or assume a library supports safe conversion.

Make Compatibility an Explicit Acceptance Test

Ed25519 derives its per-message signing value deterministically from secret material and the message. That avoids dependence on fresh external randomness for each signature. It doesn't make an exposed private key safe, and it doesn't remove the need for secure key generation.

Choose a signature algorithm your entire verification fleet can enforce, not just one your development laptop can generate.

Say a deployment platform signs release manifests with Ed25519. Before adoption, test verification in the deployment agent, recovery environment, offline installer, and any hardware-backed signing service. A successful developer test doesn't establish production interoperability.

The review should resolve these details:

• Verification rules: Use strict, maintained verification code that handles malformed encodings safely.
• Assurance requirements: Confirm that the actual module and operating mode satisfy your validation requirements. An algorithm name alone isn't evidence.
• Key custody: Restrict signing access and avoid exporting production private keys into build jobs.
• Fleet visibility: Inventory Ed25519 and ECDSA separately, including which services verify each.

The trade-off is a convenient signing interface versus uneven platform support. For an existing enterprise PKI, ECDSA may fit current tooling better. For a controlled internal system, Ed25519 can simplify the supported signing configuration without justifying custom cryptographic code.

5. ElGamal Encryption and Signature Scheme

ElGamal is most relevant when a design needs specific mathematical properties, not when an application just needs to encrypt a file. Its encryption construction uses a recipient's public key and a fresh ephemeral secret to produce a randomized ciphertext. Repeated encryption of the same message can therefore produce different ciphertexts.

The encryption and signature constructions are distinct. Approval of one doesn't establish that the other is appropriate, and neither should enter a new system merely because an old library exposes it.

Justify the Property You Actually Need

A useful example is an electronic voting design using EC-ElGamal for encrypted tallying. Its homomorphic structure can let a tallying component combine encrypted votes without first revealing each vote. That property also creates requirements for proving that submitted ciphertexts encode permitted choices.

For ordinary file encryption, this complexity is usually the wrong trade-off. Use a maintained hybrid encryption construction with authenticated symmetric encryption rather than assembling raw ElGamal operations.

• Threat model: State whether attackers can submit modified ciphertexts and observe decryption behavior.
• Integrity: Don't assume basic ElGamal encryption detects tampering.
• Protocol proofs: For homomorphic applications, specify how the system rejects invalid submissions without exposing protected values.
• Randomness: Generate fresh ephemeral secrets using the cryptographic library's supported interface.

Say a privacy-preserving aggregation service must combine encrypted contributions. The design review should ask who can decrypt the aggregate, whether small groups reveal individual values, and how the service handles malicious inputs. The encryption primitive alone answers none of those operational questions.

The trade-off is algebraic flexibility versus protocol complexity. Use ElGamal when that flexibility is a documented requirement and the complete construction has received specialist review. For legacy GnuPG encryption subkeys, inventory the dependency and recipient compatibility before planning replacement.

6. OpenPGP (Pretty Good Privacy Standard)

An encrypted email and a signed Git tag can both use OpenPGP, but they create different security obligations. OpenPGP is a message and key-management format that combines cryptographic mechanisms. It isn't a single asymmetric algorithm.

For confidential messages, a symmetric session key protects the content, while public-key cryptography protects access to that key. For signatures, the recipient verifies the signed content against a trusted public key. GnuPG and Thunderbird are familiar places where teams encounter these workflows.

Separate Identity, Encryption, and Release Authority

The difficult decision is often which key should be trusted for which action. A cryptographically valid signature doesn't prove that the signer is authorized to publish a production release. The verification policy must establish that authorization.

Say a build pipeline verifies an OpenPGP-signed release tag. Fetching a public key from the same untrusted download location as the release isn't enough. The pipeline needs a separately established trust anchor and a controlled process for replacing it.

• Primary-key protection: Keep the primary certification key offline where practical, and use purpose-specific subkeys for routine operations.
• Expiration and recovery: Maintain expiration policies, protected backups, and revocation material.
• Recipient support: Test newer formats and curve choices against the software that must decrypt archived or newly issued messages.
• Release enforcement: Verify the expected signer and exact signed artifact, not merely the presence of any signature.

For email encryption, include historical data in the review. Removing an old decryption key without a recovery plan can make retained messages unreadable. Keeping that key indefinitely, however, extends the consequences of compromise.

The trade-off is decentralized flexibility versus difficult trust administration. OpenPGP works best when teams assign ownership for key distribution, revocation, and release authorization. A signed commit or tag should be an enforceable input to release policy, not decorative evidence in a repository interface.

7. TLS 1.3 Handshake with Asymmetric Key Exchange and Authentication

A TLS certificate doesn't tell you how a connection establishes its session secret. In a certificate-authenticated TLS 1.3 handshake, ephemeral key agreement establishes secret material, while a handshake signature proves possession of the certificate's private key. Symmetric authenticated encryption then protects application traffic.

A representative handshake using X25519 and RSA-2048 transmitted approximately 1,376 bytes for the key-exchange public key, certificate, handshake signature, and certificate chain, according to Cloudflare's KEMTLS analysis. That's a specific comparison, not a universal TLS packet size.

Review Negotiation, Identity, and Renewal

For an HTTPS API or a service mesh such as Istio or Linkerd, inspect key agreement and certificate authentication separately. An RSA certificate doesn't mean the connection uses legacy RSA key transport. Likewise, a strong negotiated group doesn't establish that the client checked the server's identity correctly.

• Protocol policy: Prefer TLS 1.3 and retain older supported configurations only for documented compatibility requirements.
• Identity validation: Verify trust chains and the intended service identity. For mutual TLS, enforce authorization after client authentication.
• Early data: Keep replay-sensitive operations out of 0-RTT processing.
• Certificate lifecycle: Automate renewal, test reload behavior, and alert on failures before certificates expire.

Include termination points in your AWS cloud-security review: load balancers, gateways, proxies, and application servers may use different configurations. Test the deployed endpoints, not only the application's local TLS library.

The trade-off is interoperability versus configuration complexity. Also review resumption explicitly, because pre-shared-key modes don't all provide the same properties as a fresh certificate-authenticated ephemeral exchange. A protocol version alone isn't a complete security policy.

8. ML-KEM (Module-Lattice Key Encapsulation Mechanism, formerly CRYSTALS-Kyber)

ML-KEM establishes shared secret material using post-quantum cryptography. It doesn't sign certificates or encrypt application payloads directly. A sender encapsulates a secret to a public key, and the recipient decapsulates it using the matching private key. A surrounding protocol derives traffic keys from that material.

Its lattice-based construction is designed to resist attacks from future quantum computers. During transition, deployments can combine it with classical key agreement, such as X25519, through a standardized hybrid construction.

Inventory First, Then Benchmark the Migration

NIST's post-quantum migration program identifies RSA and ECC as quantum-vulnerable technologies and notes that three post-quantum standards were finalized in August 2024. The engineering task is to identify affected uses, prioritize them, and test replacements.

For a health-data API with long confidentiality requirements, prioritize the external connection and every downstream termination point. Inventory authentication separately, since changing key establishment doesn't make classical signatures quantum-resistant.

Cloudflare reported about a 4% TLS-handshake slowdown in its post-quantum key-agreement deployment. Treat that as deployment evidence, not your performance forecast.

• Protocol support: Test a supported hybrid option such as X25519MLKEM768 across clients, proxies, and servers.
• Operational behavior: Measure handshake latency, packet sizes, failures, and fallback.
• Assurance: Confirm the cryptographic module's validation status where required.
• Governance: Assign migration owners and preserve evidence alongside your ISO 27001 framework documentation.

The trade-off is stronger protection against a future threat versus additional deployment and interoperability work. Don't implement your own hybrid combiner or silently downgrade after negotiation failures.

How the eight asymmetric schemes compare at a glance

Turning These Examples Into Design Review Checks

Pick the schemes your systems depend on, then turn each choice into a testable requirement. Start with an external API, a release-signing workflow, and a sensitive data exchange. Those paths expose different failures: weak negotiation, unauthorized signing, and unrecoverable encrypted data.

Record purpose before algorithm. An inventory entry that says RSA is incomplete. State whether the key authenticates a server, signs a release, or decrypts stored session keys, because each purpose needs different controls and a different migration plan.

Make Approval Specific Enough to Enforce

For each cryptographic use, keep the following decisions next to the architecture documentation:

• Accepted configuration: Define the minimum key size, approved curve, padding, or protocol mode.
• Trust boundary: Identify who supplies the public key and how the system establishes its authenticity.
• Private-key custody: Name the storage mechanism, permitted callers, and recovery process.
• Failure behavior: Specify what happens when verification fails, negotiation finds no approved option, or a certificate expires.
• Migration ownership: Assign a responsible team and record dependencies that could block replacement.

Test rejection as carefully as success. Submit a signature from an unauthorized key, a malformed ciphertext, an expired certificate, and an unsupported negotiation option. Verify that the system rejects them without leaking sensitive details or falling back to an unapproved path.

Keep design evidence connected to implementation. A documented requirement for ephemeral key agreement means little if a gateway negotiates something else. A release-signing policy is incomplete if the deployment system accepts unsigned artifacts through an emergency path that nobody reviews.

Review standard: An approved cryptographic decision should identify the configuration, the owner, and the evidence that production follows it.

DevArmor supports this work by documenting security architecture and decisions as audit-ready artifacts, with guidance designed to align with NIST SSDF and OWASP SAMM. The useful outcome is traceability from a design requirement to the code, configuration, and review evidence that implement it.

These examples of asymmetric encryption become operationally useful when engineers can answer concrete questions. What does this key do? Who trusts it? What happens if it leaks? How will the team replace it without losing confidentiality, availability, or access to historical data?

DevArmor offers continuous threat modeling, security design reviews, and policy enforcement that connect approved security decisions to development workflows. Visit DevArmor to explore how your team can turn cryptographic requirements into traceable reviews and implementation checks.