There's no single best encryption, but AES-256-GCM is the strongest common default for stored and in-app data, while TLS 1.3 with ephemeral ECDHE key exchange is the default for web traffic. Neither choice can compensate for a stolen key, a compromised browser, or confidential content retained longer than necessary.
The popular advice to pick the algorithm with the biggest key skips the decisions that usually determine whether an attacker gets your information. A journalist protecting a source, a lawyer exchanging a contract, and an engineer securing a website don't have the same problem. The useful question isn't just what is the best encryption, but what must remain secret, from whom, and for how long.
Best Encryption for Each Use Case at a Glance
Choose the scheme for the job before comparing algorithms. Encryption, key agreement, authentication, and deletion are separate controls, even when an application presents them behind a single lock icon.
Recommended encryption by use case
| Use case | Recommended encryption | Why it fits |
|---|---|---|
| Messaging between people | An established end-to-end protocol with elliptic-curve key agreement and AES-256 or ChaCha20-Poly1305 per message | Forward secrecy and evolving message keys can limit damage from a compromised key |
| File storage at rest | AES-256-GCM with a unique nonce per encryption | Provides authenticated encryption and benefits from hardware acceleration |
| Real-time voice and video | ChaCha20-Poly1305 or AES-GCM within an appropriate TLS- or DTLS-based protocol | Device hardware and latency requirements guide the choice |
| Website traffic | TLS 1.3 with ephemeral ECDHE and AES-GCM or ChaCha20-Poly1305 | Combines authenticated transport with forward-secret key agreement |
| Signatures and certificates | ECDSA P-256 or Ed25519, with RSA retained where legacy compatibility requires it | Efficient classical authentication, with post-quantum migration planned separately |
| Short-lived browser chat | AES-256-GCM with a key derived from the access key and enforced expiry | Protects content while limiting how long the relay retains ciphertext |
These are starting configurations, not complete security designs. The messaging recommendation assumes a protocol that implements message-key evolution and authenticates participants. Putting an elliptic-curve operation next to an AES operation doesn't automatically provide either property.
The same qualification applies to storage. An encrypted file remains exposed if the application saves its decryption key alongside it with equivalent access permissions. Likewise, an expiry label means little unless the server removes the associated ciphertext and the application accounts for other retained copies.
Identify the constraint that could change your choice
Before adopting a row, write down the requirement that matters most:
- Device compatibility: Must the application work well on phones without accelerated AES?
- Participant trust: How will people verify who holds the conversation keys?
- Retention: Must the content disappear, or remain recoverable as an official record?
- Recovery: Is losing access preferable to maintaining a recovery key?
A healthcare archive may need durable access and controlled recovery. A confidential first-contact conversation may deliberately reject both. Those requirements can lead to different systems even when both use the same cipher.
Find your use case in the table, then note the constraint that could disqualify the default. That constraint deserves more attention than a marketing claim about encryption strength.
How AES, ChaCha20, RSA, ECC and TLS Fit Together
Symmetric ciphers encrypt content using a shared secret. Asymmetric algorithms help establish secrets or verify signatures. TLS combines cryptographic components into a transport protocol. Comparing these as interchangeable products is a category error.
AES-GCM and ChaCha20-Poly1305 are authenticated encryption with associated data, or AEAD, constructions. They protect confidentiality and detect unauthorized changes. Applications must check authentication before releasing decrypted content, rather than treating readable output as proof that decryption succeeded.
AES is a block cipher; GCM supplies the authenticated-encryption construction around it. ChaCha20 is a stream cipher paired with the Poly1305 authenticator. Neither construction, by itself, establishes who the other person is.
The diagram separates the components by their responsibilities.
Assign each component a job
Role of each algorithm in a secure system
| Algorithm | Category | Main job | Typical key size |
|---|---|---|---|
| AES-GCM | Symmetric AEAD using a block cipher | Encrypt bulk data with integrity | Select the AES key size supported by the application's security profile |
| ChaCha20-Poly1305 | Symmetric AEAD using a stream cipher | Encrypt bulk data efficiently without relying on AES instructions | Fixed by the standardized construction |
| RSA | Asymmetric | Signatures and legacy key transport | Set by the required security level and compatibility policy |
| ECC, including X25519, P-256 and Ed25519 | Asymmetric algorithm family | Key agreement or signatures, depending on the algorithm | Defined by the selected curve and algorithm |
| TLS 1.3 | Protocol | Combine encryption, key establishment, and authentication for transport | Negotiated through supported cryptographic parameters |
ECC isn't one operation. X25519 is used for key agreement, while Ed25519 is a signature algorithm. P-256 can support elliptic-curve operations in different schemes. Their names don't make their roles interchangeable.
RSA signatures also shouldn't be confused with RSA key transport. A connection can use a certificate authenticated through RSA while establishing its session secret through ephemeral elliptic-curve key agreement.
Transport protection isn't end-to-end protection
TLS protects a connection between its endpoints. If those endpoints are a browser and an application server, the server can ordinarily process the content after transport decryption.
End-to-end encryption adds a different boundary: the intended participants hold the content keys, while the relay handles encrypted material. An application can use both layers, and usually should.
Practical rule: Name the layer before selecting the algorithm. Bulk encryption, key agreement, signatures, and transport solve different problems.
Avoid unauthenticated encryption as a default. A mode such as CBC requires additional, correctly composed authentication; choosing AEAD removes that particular composition task, though it doesn't remove key-management responsibilities.
Write your requirement as a specific job: encrypt a file, establish a session secret, authenticate a signer, or protect a network connection. Only then compare implementations.
Performance Trade-offs Between AES-GCM and ChaCha20
Hardware, record size, and implementation determine performance. A cipher that wins on a server can lose on an older phone, and a benchmark using large buffers may tell you little about short chat messages.
In Cloudflare's comparative measurements, AES-128-GCM and AES-256-GCM were faster for records larger than approximately 320 bytes, while ChaCha20-Poly1305 showed an average 7% advantage over the compared OpenSSL implementation across the tested implementation. The same source describes a Galaxy Nexus benchmark in which decrypting 1 MB took 41.6 ms with AES-128-GCM, compared with 13.2 ms with ChaCha20-Poly1305.
Which cipher tends to be faster by condition
| Condition | Typically faster | Reason |
|---|---|---|
| Desktop or server with hardware AES, large records | AES-GCM | Dedicated instructions accelerate encryption and authentication |
| Short records without AES acceleration | ChaCha20-Poly1305 | Efficient software execution without specialized AES hardware |
| Older mobile device decrypting a large buffer | ChaCha20-Poly1305 in the reported mobile test | The tested phone favored its software implementation |
| Desktop with hardware AES decrypting a large buffer | AES-GCM in the reported desktop tests | Hardware support changes the relative cost |
The mobile result isn't a prediction for every current phone. It demonstrates why a blanket claim that AES is always faster, or that ChaCha20 is always faster, is indefensible.
Understand what the processor accelerates
AES instructions accelerate the cipher operations. Carry-less-multiplication instructions accelerate the authentication calculations used by GCM. When both are available through an optimized implementation, AES-GCM can perform particularly well.
Without those instructions, software takes a different path. ChaCha20-Poly1305 can become attractive because its design works efficiently with ordinary processor operations.
Record size changes the balance too. Setup and per-record work represent a larger share of processing for a short message than for a large transfer. Your application's actual workload matters more than a throughput headline.
Benchmark the complete operation
Measure encryption and decryption through the browser APIs and application code you intend to ship. Include representative messages, attachments, and voice frames, then test low-end devices rather than only a developer workstation.
- Measure responsiveness: Check whether cryptographic work delays typing, playback, or interface updates.
- Separate costs: Distinguish key derivation, encryption, serialization, and network delay.
- Exercise failure paths: Confirm altered ciphertext is rejected without exposing partial plaintext.
For AES-GCM, every encryption must use a unique nonce under the same key. Benchmarking doesn't excuse nonce reuse, and a faster implementation isn't preferable if it mishandles authentication.
A small performance advantage doesn't justify a design that can repeat nonces or release unauthenticated plaintext.
Choose between sound implementations using measurements from your users' devices. Don't infer practical security or speed from the key length alone.
Forward Secrecy and Post-Quantum Risk for Long-Lived Data
Suppose an attacker records encrypted website traffic and later steals the server's long-term private key. Forward secrecy means that theft alone doesn't reveal the earlier session contents.
Ephemeral ECDHE can provide that protection when session secrets are generated correctly and discarded. Legacy RSA key transport doesn't provide the same property. For ordinary certificate-authenticated TLS connections, choose ephemeral key agreement rather than assuming that any encrypted handshake has forward secrecy.
This distinction also explains a limit: forward secrecy protects against certain later key compromises. It doesn't make classical elliptic-curve key agreement resistant to a sufficiently capable quantum attacker.
Separate symmetric security from public-key migration
NIST's post-quantum guidance identifies ML-KEM, ML-DSA, and SLH-DSA as available standards, and its transition material lists AES-256 at 256-bit classical security and security category 5, while identifying 2030 as the planned disallowance point for older 112-bit symmetric options.
The practical conclusion isn't that AES must suddenly be abandoned. Organizations must examine public-key mechanisms, including key establishment and signatures, while preserving strong symmetric encryption.
Use these inputs to prioritize migration:
- Confidentiality lifetime: How long would disclosure harm the people or organization involved?
- Adversary capability: Is collection by a well-resourced attacker a credible concern?
- Cryptographic dependency: Does the system rely on classical public-key exchange, signatures, or independently shared symmetric secrets?
A medical archive or record identifying a confidential source may remain sensitive long after its original exchange. Those systems need crypto-agility, meaning an operational ability to replace algorithms, formats, and dependencies without losing access or weakening controls. Our post-quantum encryption guide provides context for evaluating that transition.
Deletion changes exposure, not mathematical strength
A short-lived relay offers less retained material for an attacker to steal later than a permanent archive. However, deleting relay ciphertext doesn't erase traffic an adversary already recorded, nor copies saved by a participant.
Retirement of physical devices is another part of the retention problem. Reworx Recycling's data sanitization guide is a useful resource when planning how storage media should leave service, alongside application-level deletion.
Short retention reduces retained exposure. It doesn't retroactively protect a copy someone already captured.
List every place RSA or ECC protects information that must stay secret for years. Include backups, exported records, signing services, and third-party dependencies, then assign migration responsibility rather than waiting for a single universal replacement.
Endpoints, Keys and Metadata
Encryption doesn't protect plaintext displayed on a compromised device. A malicious browser extension, stolen access key, screenshot, or copied message can bypass the protection without attacking the cipher.
It also doesn't automatically conceal metadata. A relay or network observer may learn timing, traffic volume, or connection relationships even when message contents remain unreadable.
The operational distinction matters: Sophos's 2026 ransomware survey reports that 56% of incidents successfully encrypted organizational data, while 79% began with compromised identities. Those findings concern ransomware, not chat encryption, but they illustrate why cryptographic strength and resistance to account compromise are different engineering problems.
A derived key is only as strong as its starting secret
PBKDF2 increases the cost of guessing a secret; it doesn't make a predictable secret unpredictable. If an attacker obtains ciphertext and the derivation parameters, they may be able to test guesses offline, beyond the application's rate limits.
RFC 8018 treats the iteration count as a tunable cost parameter and describes 1,000 iterations as historical guidance, with 10,000,000 iterations contemplated for especially critical keys where user-perceived performance isn't a constraint. These are contextual examples, not modern deployment targets.
At Ciphar, we derive the encryption key using PBKDF2-HMAC-SHA-256 at 100,000 iterations, with a per-channel salt. That's a performance and compatibility setting, not proof that an arbitrary human-selected secret can withstand offline guessing.
Strengthen the controls around the cipher
- Generate the access key: Prefer a randomly generated secret over a memorable phrase invented by a participant.
- Separate channels: Use a unique random salt per channel rather than reusing derivation inputs.
- Constrain online guessing: Rate-limit attempts and surface failed access attempts to participants.
- Test slow devices: Measure derivation latency on low-end phones before raising the cost.
- Plan upgrades: Review parameters periodically and support migration.
Argon2id is a memory-hard alternative worth evaluating, but browser implementation quality, resource use, and interoperability require testing. Our encryption key management guide addresses the wider lifecycle around these choices.
Endpoint disposal belongs in that lifecycle too. Beyond Surplus's overview of secure media sanitization methods can help frame device-retirement procedures; encrypting conversations doesn't eliminate local exports or screenshots.
Before trusting any tool, answer three questions: How strong is the shared secret? How long is ciphertext retained? What remains exposed after a device is compromised?
Matching Encryption to Messaging, Storage and Voice
A confidential conversation often moves from text to an attachment and then to a call. Each transition changes what you need to protect, even if the application keeps the same interface.
Use these communication modes as separate threat-modeling decisions.
Messaging that ends versus messaging that persists
Must the conversation remain available later? Long-term messaging needs participant verification, forward secrecy, and ongoing protection of every enrolled device. A short first-contact conversation may instead prioritize avoiding persistent accounts and retained history.
Ciphar illustrates the latter model. Every message, file, reply, and voice frame is encrypted in the browser with AES-256-GCM before it touches the network. The derived key stays in browser memory and isn't sent to the server.
A channel and every associated encrypted blob are deleted from the relay 60 minutes after channel creation. Participants can also use the burn control for immediate relay deletion.
That scope is deliberate: it isn't a long-term messenger, group chat, file store, or regulated-communications tool. If a lawyer must preserve an official client record, a disappearing channel cannot substitute for the required records workflow.
Files that outlive the conversation
How long must this attachment stay secret? For storage, use authenticated encryption, keep keys under separate access controls, and maintain a migration plan for archives with long confidentiality requirements.
A downloaded attachment is an important edge case. Once a participant saves it outside the channel, channel expiry no longer governs that copy. The recipient needs a separate storage and deletion policy.
For document-specific workflows, PDFWix's guide to encrypting confidential contracts offers relevant context. Choose any online document workflow only after deciding whether uploading plaintext fits your threat model, and use our secure file-sharing guidance to consider delivery and recipient handling together.
This accompanying video offers another format for considering encryption choices.
Voice under latency and membership constraints
Which devices must sustain the call? Select a supported authenticated-encryption construction based on measured responsiveness, not a desktop-only benchmark.
Our voice audio is encrypted in the browser and carried through an end-to-end encrypted WebSocket relay keyed from the channel secret. Only other authenticated participants can decrypt it.
For a voice room, membership is a separate concern from audio encryption. Confirm who can join, who already possesses the secret, and how participants respond if access is compromised. An authorized participant can still record sound through their own device.
Encrypted audio also doesn't conceal call timing or participant connections. Protecting spoken content and hiding that a call occurred require different controls.
Confirm Your Encryption Choice Before You Rely On It
Test observable behavior before introducing confidential material. A documented algorithm is useful, but your acceptance checks should examine the complete workflow.
- Trace the access key. Confirm it doesn't appear in URLs, server logs, analytics, or error messages. Inspect sharing and failure paths, not just the normal screen.
- Alter a test ciphertext. In an authorized test environment, confirm the receiver rejects it without displaying partial plaintext.
- Verify expiry. Create a disposable channel, let its actual lifetime pass, and confirm its ciphertext is no longer retrievable from the relay.
- Exercise the burn control. Delete a test channel and check from another device that the relay no longer serves its content. Don't confuse this with erasing previously downloaded copies.
- Review the endpoint. Inventory browser extensions and check screen-capture permissions. Decide whether that device is appropriate for the conversation.
- Assign retention ownership. Name the person responsible for archives and document a post-quantum migration deadline based on the organization's requirements.
Start with dummy text and a harmless attachment. Test rejection, expiry, and immediate deletion before moving real content into the workflow, and record any failure as a reason to stop deployment.
Ciphar offers browser-based encrypted messages, files, and voice for short, identity-free conversations, with client-side encryption and enforced relay deletion. Visit Ciphar to review the security model and run a disposable test channel before deciding whether that scope fits your confidential exchange.
