How To Encrypt Data Using Asymmetric Encryption Algorithms

Asymmetric encryption is the public-key cryptography model you use when one key encrypts data and a different key decrypts it. If you need secure communication, identity verification, or key exchange, this is the model that makes it possible. It works differently from symmetric encryption, and that difference matters when you are deciding how to protect messages, files, and API traffic with real-world data protection methods.

Primary Use	Secure key exchange, identity verification, and small-payload data encryption
Best Fit	Hybrid encryption workflows for email, TLS, and file protection
Common Algorithms	RSA, elliptic curve cryptography, ElGamal, ECIES
Performance	Slower than symmetric encryption as of June 2026
Typical Use Case	Encrypting a session key instead of encrypting bulk data directly
Security Concern	Private key protection and certificate verification
Related Standard	TLS 1.3 from the IETF

Understanding Asymmetric Encryption Basics

Asymmetric encryption uses a public key to encrypt data and a matching private key to decrypt it. Together, those two keys form a key pair, and the pairing is what makes the system secure. If someone has the public key, they can encrypt data for the key owner, but they cannot decrypt it without the private key.

This model is valuable because it solves problems that symmetric encryption cannot solve cleanly on its own. You can safely publish a public key, use it for secure communication, and rely on it for identity verification when it is bound to a certificate or trusted directory. It also makes key exchange practical, which is why TLS handshakes and secure messaging systems depend on it.

The math behind asymmetric cryptography is the reason it works. RSA relies on the difficulty of factoring very large numbers built from primes, while elliptic curve cryptography relies on the hardness of elliptic curve discrete logarithms. In practice, that means you can distribute one key openly and still preserve confidentiality.

Public-key cryptography is not used because it is fast. It is used because it solves the hard problem of sharing trust over an untrusted network.

For most workloads, asymmetric encryption is best for small data items, not huge files. A large file encrypted directly with RSA or ECC would be slow, expensive, and awkward to manage. That is why most data protection methods use a hybrid design: asymmetric encryption protects a symmetric key, and symmetric encryption protects the actual data.

Common Asymmetric Encryption Algorithms

Not all asymmetric encryption algorithms are equally useful in production. The main choices you will see are RSA, elliptic curve cryptography systems, ElGamal, and hybrid application-level schemes such as ECIES. The right choice depends on compatibility, performance, and the security posture you need.

RSA

RSA is the most familiar public-key algorithm in enterprise environments. It is widely used in certificates, older VPN systems, and legacy application stacks because it is mature and broadly supported. Security depends on key size, and larger keys offer more resistance to brute-force attacks at the cost of slower performance.

As of June 2026, 2048-bit RSA is still common, but many security teams prefer 3072-bit RSA or elliptic curve options for new deployments where compatibility allows it. RSA remains useful when you need broad interoperability, but it is not the best answer when speed and smaller key material matter. For current vendor guidance, Microsoft documents RSA use in modern applications through its cryptography APIs: Microsoft Learn.

Elliptic Curve Cryptography

Elliptic curve cryptography is preferred when you want smaller keys and better performance. It delivers strong security with less computational overhead than RSA, which makes it attractive for mobile clients, cloud APIs, and constrained devices. That smaller footprint also reduces bandwidth and storage overhead during certificate and handshake exchanges.

Common elliptic-curve-based workflows are seen in TLS, secure messaging, and modern certificate deployments. In practical terms, ECC lets you achieve comparable security to large RSA keys while keeping the system more efficient. That matters when every millisecond counts or when the device doing the work has limited CPU resources.

ElGamal and ECIES

ElGamal is an older but still important asymmetric encryption scheme based on discrete logarithms. It is not as common in mainstream enterprise tools as RSA or ECC, but its design influenced later systems. ECIES, or Elliptic Curve Integrated Encryption Scheme, is a practical hybrid approach that combines elliptic curve key agreement with symmetric encryption and a message authentication mechanism.

ECIES is useful because it reflects how modern systems actually work: asymmetric math to establish trust, symmetric crypto to move data efficiently. OpenPGP-style workflows, secure file-sharing tools, and some application-layer encryption systems use similar patterns. The engineering lesson is simple: the algorithm should fit the job, not the other way around.

RSA	Best for broad compatibility and certificate ecosystems, but slower and more CPU-intensive
ECC	Best for smaller keys, faster operations, and modern systems
ElGamal	Useful conceptually and in some cryptographic systems, but less common in enterprise deployment
ECIES	Practical hybrid design for application-level encryption and secure transport

For algorithm definitions and implementation guidance, the IETF RFCs are the right place to start when you need protocol-level precision. If you are studying for the CompTIA Security+ Certification Course (SY0-701), this is exactly the kind of comparison you need to know cold: what the algorithm does, where it fits, and why the design matters.

When To Use Asymmetric Encryption

Asymmetric encryption is ideal when you need to send a secret to one recipient, verify identity, or exchange a symmetric key securely. It is not the right tool for encrypting a 10 GB backup archive directly. The more data you send, the more the performance cost works against you.

Use it when you want to secure API session setup, send encrypted secrets to one recipient, or prove the origin of a message through digital signatures. In TLS, for example, the public-key portion helps establish trust and exchange session material, while symmetric algorithms handle the bulk of the traffic after the handshake. That is the right division of labor.

A hybrid model is usually best when the payload is large. Encrypt the file or message with a fast symmetric algorithm such as AES, then wrap the AES key with RSA or ECC. This gives you the performance of symmetric encryption and the trust properties of asymmetric cryptography. The same principle shows up in secure email, secure file sharing, and enterprise key management systems.

The limitations are straightforward. Asymmetric operations are slower, computationally heavier, and more sensitive to key management mistakes. Public keys are easy to distribute, but private keys must be protected carefully, rotated when needed, and revoked when compromised.

For risk and workforce context, the U.S. Bureau of Labor Statistics continues to show strong demand for information security roles as of June 2026, which is one reason practical cryptography skills matter in operations, cloud security, and application security teams.

How To Encrypt Data Step By Step

The process below shows how to encrypt data using asymmetric encryption algorithms without turning the design into a performance problem. The safest pattern is to encrypt a small payload directly only when necessary, and to encrypt a symmetric session key most of the time.

1. Generate a secure key pair. Use a trusted cryptographic library or command-line tool instead of writing your own crypto. In OpenSSL, an RSA key pair can be generated with a command such as openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out private.pem, followed by public key extraction with openssl pkey -in private.pem -pubout -out public.pem.

   For elliptic curve workflows, choose a modern curve supported by your platform and library. The key point is to keep the private key offline or protected by access controls from the start, not after the fact.

2. Share the public key safely. A public key can be distributed openly, but it still needs authenticity. In a certificate-based system, the public key should be tied to a trusted certificate authority or identity verification process so recipients know the key really belongs to the person or system they expect.

   If the sender cannot verify the key origin, encryption alone does not guarantee the right recipient will get the message. That is where PKI, certificates, and fingerprint validation become part of the workflow.

3. Encrypt a small payload or a session key. If you must encrypt directly, keep the plaintext small. A better practice is to generate a random symmetric key, encrypt the real data with that key, and then encrypt the symmetric key with the recipient’s public key.

   This reduces computational load and avoids the size limits that make direct asymmetric encryption impractical. It also aligns with how secure messaging and file encryption systems are normally built.

4. Store the ciphertext with metadata. Save the encrypted output together with the algorithm name, key identifier, and any required initialization or wrapping details. Without metadata, future decryption can fail because nobody knows which algorithm or key version was used.

   For example, a wrapped key record might include the algorithm, certificate thumbprint, and timestamp. In operational environments, this is the difference between a recoverable encrypted archive and an unreadable blob.

5. Decrypt in a protected environment. Use the private key only in a secure process, secure enclave, HSM, or access-controlled server. The private key should never be exposed in source code, browser code, or a public repository.

   Decryption is simply the reverse operation, but the environment matters. A perfect algorithm cannot save a weak operational model.

6. Verify the output and handle errors. Confirm that the decrypted data matches the original and reject any corrupted ciphertext, wrong-key condition, or invalid padding error. Good implementations return explicit failures rather than silent corruption.

   That matters in cybersecurity because bad ciphertext handling can create data loss, break automation, or produce security bugs that are hard to trace.

The OpenSSL documentation is still one of the clearest references for practical command-line encryption workflows. If you are studying for Security+ SY0-701, being able to explain this sequence from key generation to decryption is more important than memorizing one specific command syntax.

How To Encrypt Data Using A Hybrid Encryption Workflow

Hybrid encryption is the standard pattern for protecting large data. It uses asymmetric cryptography to protect a symmetric session key, then uses that session key to encrypt the real payload. This is the architecture behind many secure email systems, file-sharing tools, and TLS-style session setups.

Here is the practical pattern. First, generate a random AES key. Next, encrypt the file with AES, because AES is fast and efficient for large data. Then encrypt the AES key with the recipient’s RSA public key or an ECC-based scheme such as ECIES. At the end, you store three things: the encrypted file, the wrapped key, and the metadata needed for decryption.

This design balances performance and security. The file itself gets protected by a symmetric algorithm that can handle large inputs efficiently. The key that unlocks the file gets protected by asymmetric encryption, which makes it safe to transfer over untrusted channels.

The cleanest public-key design is usually not “encrypt everything with public key.” It is “use public key to protect the key that protects everything else.”

That is why protocols and systems that need both speed and trust almost always settle on hybrid workflows. Secure email tools, enterprise document protection systems, and standards-driven transport layers all rely on this pattern because it scales without giving up confidentiality. NIST guidance on approved cryptographic use remains the best anchor for those architecture decisions: NIST CSRC.

Tools, Libraries, and Formats

Use trusted libraries instead of writing cryptographic code from scratch. For many environments, OpenSSL, the Python cryptography library, libsodium, and language-specific SDKs provide safer defaults and fewer footguns than custom implementations. The right tool depends on the language stack, deployment target, and whether you need modern primitives, certificate handling, or file-format support.

• OpenSSL for command-line workflows, certificates, and interoperable encryption operations
• Python cryptography for application code that needs clean primitives and good API design
• libsodium for modern, opinionated cryptographic building blocks
• Vendor SDKs when you must integrate with cloud key services or platform-managed certificates

Key formats matter too. PEM is human-readable and common in certificate and key exchange workflows, while DER is a binary encoding often used behind the scenes. OpenPGP keys show up in secure email and file-sharing contexts. The format does not change the math, but it does affect compatibility, portability, and parsing.

Public-key systems also depend on PKI, which binds a public key to a verified identity through certificates. Without PKI or a comparable trust model, you may encrypt to the wrong key and never know it. That is why certificate validation is as important as encryption itself.

Always test in a development environment before handling real sensitive data. The wrong padding setting, wrong key size, or wrong file format can break decryption long before you reach production. For platform guidance, Microsoft Learn and vendor documentation are safer references than guessing from examples online: Microsoft Learn.

What Security Best Practices Should You Follow?

Private key protection is the first rule. Store private keys in an HSM, secure keystore, or tightly controlled file system location, and limit who can access them. If the private key leaks, the encryption model fails regardless of how strong the algorithm was.

Use strong algorithms and appropriate key sizes for the threat model. Asymmetric crypto is only as good as its current cryptographic standing, and deprecated choices should be removed from design reviews. When possible, prefer authenticated encryption on the symmetric side and digital signatures where authenticity matters.

Do not roll your own cryptography. That warning is not theoretical; most homegrown crypto failures come from bad padding, incorrect random number generation, weak key handling, or a mistaken assumption about what encryption actually guarantees. Encryption protects confidentiality, while signatures protect integrity and origin.

Plan for rotation, revocation, and backup. Keys age, certificates expire, and systems fail. A secure architecture includes a revocation path, documented recovery process, and backup copies that are themselves protected.

• Rotate keys on a schedule that matches your policy and risk level
• Revoke certificates quickly when keys are compromised or retired
• Back up private keys only in protected, access-controlled form
• Audit access to key material and decryption services

For encryption and cipher-strength guidance, consult the NIST Cybersecurity Framework and publications. For identity and certificate handling, the IETF and vendor documentation provide the operational details you need to avoid bad defaults.

What Mistakes Should You Avoid?

The most common mistake is trying to encrypt large data directly with asymmetric encryption. That creates unnecessary CPU load, increases implementation complexity, and often hits size or padding limits. A hybrid model is almost always the better answer for real-world data protection methods.

Another common mistake is exposing private keys in source code, logs, or client-side applications. Once a key is embedded in code shipped to a browser or mobile app, assume it is compromised. The private key belongs in a protected service, not in plaintext files or debug output.

Weak keys, deprecated algorithms, and unsafe padding schemes are also frequent problems. A system that still depends on outdated defaults is a system that will eventually fail a security review. The safer approach is to choose well-supported libraries, current algorithms, and configuration settings recommended by the vendor.

Teams also confuse encryption with signing. Encryption protects confidentiality, while digital signatures prove origin and integrity. The same key is not used for both jobs, and the direction matters: the public key can verify a signature, but it cannot decrypt signed content unless it is part of an encryption scheme.

Finally, do not skip certificate verification or output validation. If you do not confirm that the key belongs to the expected identity, you can encrypt sensitive data to an attacker’s public key. If you do not verify decrypted output, you may accept corrupted or tampered data as valid.

How Do You Verify It Worked?

You know the process worked when the recipient can decrypt the ciphertext with the correct private key and recover the original data exactly. The decrypted output should match byte-for-byte, not just “look close.” If you encrypted a file, checksum comparison is the fastest confirmation.

1. Check the decrypted output. Confirm that the plaintext matches the source message or file content exactly.
2. Validate the key identity. Make sure the public key or certificate used for encryption belongs to the intended recipient.
3. Inspect algorithm metadata. Confirm the ciphertext references the same algorithm and key version used at encryption time.
4. Look for decryption failures. Wrong-key errors, padding errors, or MAC failures point to configuration or integrity problems.
5. Test rollback recovery. Confirm you can decrypt after a key rotation, restore, or service restart.

Common error symptoms are easy to spot once you know what to look for. A padding error often means the wrong key or wrong mode was used. A certificate mismatch usually means the sender trusted the wrong public key. A corrupted ciphertext problem often means the data was altered in transit or stored incorrectly.

If you need a standards reference for what “correct” looks like, check protocol documentation from the IETF or official vendor docs for your platform. In operational cybersecurity, verification is not a separate step from encryption. It is the step that tells you whether the encryption was actually usable.

Practical Example Walkthrough

Here is a simple, realistic workflow. A sender wants to send a confidential note to a recipient. The sender uses the recipient’s public key to encrypt a short secret message, then sends the ciphertext over email or a messaging channel. The recipient uses the matching private key to decrypt it.

If the message is short, direct asymmetric encryption can work. In a testing scenario, that is useful because it makes the trust model obvious: one key encrypts, the other key decrypts. But for a real file, the same sender should switch to hybrid encryption immediately.

In the file case, the sender generates a random AES key, encrypts the file with AES, and then encrypts the AES key with the recipient’s public key. The encrypted file, wrapped key, and metadata are then delivered together. The recipient first decrypts the AES key with the private key, then uses that key to decrypt the file.

That workflow is what most production systems really mean when they say “encrypt data with public key cryptography.” The public key protects the exchange of trust, while the symmetric algorithm protects the data itself.

To validate success, compare the decrypted file hash to the original hash and confirm the ciphertext cannot be opened without the private key. If the file opens with a wrong or missing key, you have a design flaw. If the decryption fails when the private key is unavailable, that is expected and proves the confidentiality control is working.

For practical certification context, this kind of end-to-end reasoning aligns with the CompTIA Security+ Certification Course (SY0-701), where you need to understand not just the terms, but the workflow and the risk behind each design choice.

Conclusion

Encrypting data with asymmetric encryption algorithms comes down to one simple rule: use the public key to protect data or a session key, and use the private key to recover it. That is why asymmetric encryption is central to secure communication, identity verification, and key exchange in cybersecurity. It is also why it is rarely the best choice for large files on its own.

For most workloads, hybrid encryption is the practical answer. Encrypt the payload with symmetric encryption, then wrap the symmetric key with RSA or elliptic curve cryptography. That gives you speed, compatibility, and a cleaner security model.

Choose trusted libraries, protect private keys carefully, verify certificates and metadata, and test everything in a controlled environment before touching production data. Those habits prevent the mistakes that break encryption projects in the real world.

If you are building your foundation for the CompTIA Security+ Certification Course (SY0-701), this is one of the core patterns worth mastering. Public keys protect data. Private keys recover it. The rest is disciplined implementation.

CompTIA® and Security+™ are trademarks of CompTIA, Inc.