Introduction: Why Compare AES-256 and ChaCha20 for VPNs?

2026 Context: Speed, Privacy, and Network Realities

VPNs have long moved beyond being just a tool for IT pros—they’re now everyday essentials. From work laptops and home routers to smartphones, tablets, and even gaming consoles, everyone faces the same challenge: how to squeeze out maximum speed and stability without compromising security. In 2026, with home internet plans hitting 1–2 Gbps and 5G and Wi-Fi 6/7 pushing wireless speeds sky-high, bottlenecks often aren’t with providers or routers, but hidden deep within encryption itself. So the question “AES-256 vs ChaCha20—which is better for VPN?” isn’t academic—it’s practical. We’ll compare these two top algorithms based on current trends, real-world performance on PCs and mobiles, power usage, hardware acceleration, and the nuances of VPN protocols like WireGuard, OpenVPN, and IKEv2/IPsec. By the end, you’ll get no-nonsense recommendations.

Where These Ciphers Fit in the VPN Stack

It’s helpful to recall where these algorithms operate. AES-256 is mostly used in AES-GCM or AES-CBC modes (new configs rely on AES-GCM, a modern AEAD mode with authentication). ChaCha20 pairs with Poly1305, forming ChaCha20-Poly1305—also AEAD. For TLS 1.3 HTTPS and QUIC (HTTP/3), both AES-GCM and ChaCha20-Poly1305 are standard; OpenVPN supports both; IKEv2/IPsec mainly uses AES-GCM but supports ChaCha20-Poly1305 with growing adoption. WireGuard is unique—it exclusively uses ChaCha20-Poly1305, contributing to its speed and simplicity. So if you use WireGuard, you’re basically on ChaCha20; with OpenVPN or IKEv2/IPsec, you can choose, impacting performance.

Block vs Stream Cipher: Philosophical Differences

AES is a block cipher, working with 128-bit blocks, and the encryption mode (GCM, CBC, etc.) defines how these blocks link and authenticate. ChaCha20, on the other hand, is a stream cipher from the ARX family (add-rotate-xor); it generates a pseudo-random stream and combines it with data. What does this mean in practice? On CPUs without hardware AES, ChaCha20 can sometimes have a noticeable speed advantage and better resistance to some side-channel attacks. AES-256 has a trump card—hardware instructions (AES-NI on x86, Crypto Extensions on ARMv8) that turn complex math into lightning-fast micro-commands. So on modern desktops and servers, AES-256-GCM often outpaces ChaCha20, while on mobiles and budget routers, it’s often the opposite. No magic, just solid engineering.

Origins and Standards: Whom to Trust and Follow

AES-256: The Pride of Standardization and Corporate Choice

AES was chosen by NIST as a standard (FIPS-197) in the early 2000s, gaining massive industry and government support. AES-256 has a vast audit history, certifications, and proven real-world use. Today, in 2026, most regulators favor AES, especially under FIPS 140-3, where AES-GCM-certified crypto modules are common and well-supported. These certifications open doors to major tenders, banking, and government sectors. Yes, AES-256 is theoretically heavier than AES-128, but on CPUs with AES-NI, speed differences are usually minimal and organizational risks lower. For corporate VPNs, this is a decisive factor—and we won’t sugarcoat it.

ChaCha20-Poly1305: The Modern Classic Designed for Speed

ChaCha20 evolved from Salsa20, improved by Daniel Bernstein, and adopted by IETF for TLS and IPsec (RFC 7539). Its main appeal is blazing speed and ease of implementation on devices without hardware AES. Google championed ChaCha20-Poly1305 in mobile Chrome, and WireGuard made it its core. Today, ChaCha20-Poly1305 is everywhere—from mobile SoCs to single-board computers and routers running OpenWrt—and favored in containerized and cloud environments for predictable performance on virtual CPUs lacking full AES-NI. Frankly, in 2026, ChaCha20 isn’t just an “alternative”; it’s a de facto standard in modern VPN stacks valuing simplicity and speed.

Compliance and Regulation: Straight Paths and Challenges

If you must comply with strict rules—banking, government, critical infrastructure—AES-GCM is usually the only foolproof “green light” option. Sure, ChaCha20-Poly1305 implementations pass internal audits and are accepted in some jurisdictions, but FIPS-certified AES modules pave the smoother path to production. What to do? Practical advice: prioritize AES-256-GCM (or AES-128-GCM for faster speed with solid security) if compliance is key; if you’re a startup, SaaS, media service, or product developer without tight regulations, ChaCha20-Poly1305 offers speed and simplicity, especially on mobile and in containers. Ideally, support both and switch dynamically.

Performance: Who’s Faster and When

Desktops and x86/x64 Servers: The Power of AES-NI and High Clock Speeds

Modern Intel and AMD CPUs with AES-NI deliver high AES-256-GCM speeds. Properly tuned OpenVPN with multithreading can hit gigabits per core. In IKEv2/IPsec with kernel modules and NIC offload, 1–10 Gbps lines are common without maxing CPU. WireGuard’s ChaCha20-Poly1305 is impressive too, often reaching 1–5 Gbps on multithreaded systems, but on x86 with strong AES-NI, AES-GCM usually wins given equal conditions. Exceptions? Definitely—in heavily virtualized environments where guest OSes lack full AES instruction access or CPU frequencies are cut, ChaCha20 can shine with its streamlined, predictable implementation. But on bare-metal, AES-NI dominates.

ARM and Mobile SoCs: ChaCha20 Often Leads, But Not Always

On smartphones and tablets without powerful AES hardware acceleration or with weak driver support, ChaCha20-Poly1305 consistently outperforms AES-GCM—lower latency, less heat, and more stable speeds under poor 5G signals. From ARMv8 Crypto Extensions onward, many chips (2021–2026) feature solid AES acceleration. In these cases, AES-GCM catches up, sometimes even surpassing ChaCha20 on short sessions. We see 400–900 Mbps with WireGuard on flagships and 200–500 Mbps with OpenVPN AES-GCM when well-configured. Bottom line: on mid-range Android devices, ChaCha20 usually wins; on flagships, the gap narrows; on older budget devices, ChaCha20 almost always leads.

Routers, SBCs, IoT: Bottlenecks and Optimization Wonders

OpenWrt routers and ARM-based single-board computers are battlegrounds for AES vs ChaCha. Hardware AES crypto accelerators (in Qualcomm, Broadcom, Marvell chips) let AES-GCM reach hundreds of Mbps while freeing CPU for routing and firewall tasks. Without acceleration, ChaCha20 usually wins: its stream ARX design fits NEON well and works cache-friendly. In IoT, where every milliwatt matters, ChaCha20 remains a trusted friend. But pay attention to drivers—sometimes great AES hardware can’t be used due to Linux driver limitations, making ChaCha20-Poly1305 the practical champ, even if you intended AES.

Security: Strong Theory, But Practice Matters More

Cryptographic Strength: Both Are Trusted

Both AES-256-GCM and ChaCha20-Poly1305 are modern, reliable AEAD constructions. Brute forcing either is unrealistic. Differences arise mainly from implementations and related cryptographic details. GCM is highly sensitive to nonce reuse—reuse once, and confidentiality and integrity vanish. ChaCha20-Poly1305 also requires unique nonces, but implementation errors are rarer due to code simplicity and lack of substitution tables. In 2026, both remain gold standards. Don’t pick ciphers based on myths—choose based on your hardware, protocol, drivers, and DevOps processes. DevOps mistakes are far likelier than attacks from mythical supercomputers.

Side-Channel Attacks: Timing and Cache Considerations

Historically, timing and cache attacks targeted poor AES software implementations using S-Box tables, especially on devices without AES-NI. Hardware AES-NI mitigates these by making operations constant-time. ChaCha20 naturally leans toward constant-time with add-rotate-xor ops and no tables or branches, earning its reputation as safer on cheap and older devices. But let’s be honest: quality 2026 libraries (BoringSSL, OpenSSL 3.x, libsodium) pay close attention here, and with proper builds, both ciphers behave securely. Real risks come from leaking keys in RAM, RNG bugs, secret logging, or unstable power management. The crypto algorithm isn’t to blame—it’s how it’s built and run.

AEAD Modes and Common Configuration Errors

Choose AEAD: AES-GCM or ChaCha20-Poly1305. Avoid outdated combos like AES-CBC+HMAC for new deployments unless necessary. Ensure nonce uniqueness, properly generate keys, and don’t skimp on entropy. Use modern cipher suites with OpenVPN and IKEv2; WireGuard limits you to ChaCha20-Poly1305—which is good, fewer chances to misconfigure. A key point—key length: AES-128-GCM suffices for most scenarios and often outperforms AES-256-GCM, but if policy demands "256 or nothing," use 256. ChaCha20’s default is 256-bit, making choice easier. The biggest mistake is trying to "improve" secure defaults by adding exotic tweaks.

Power Consumption and Heat: Especially Important on Mobile

Battery Prefers Efficiency Over Cipher Brand

Encryption load on phones and laptops isn’t trivial. A 10–20% CPU difference can mean extra hours on the road. ChaCha20 often wins on devices lacking strong AES acceleration—less heat, smoother frequency, steady speed. On modern ARMv8 chips with hardware AES, differences vanish—AES-GCM can be as efficient or better running in dedicated SoC blocks. Simple advice: don’t fight beliefs, test your own phone. Ten minutes of iperf3 through your VPN server and you’ll see which eats less battery. Real-world testing beats any article, including this one.

Throttling and Sustained Speed Over Time

A short burst is one thing, long streaming another. If encryption heats the chip, the system throttles frequencies, and speeds can drop from 800 to 300 Mbps in 20–30 minutes. ChaCha20 generally heats less on mid-range devices, maintaining steady speeds longer. On flagships with good cooling and strong AES acceleration, it’s a wash. Pro tip: reduce CPU strain at the protocol level—prefer WireGuard over OpenVPN, enable MTU autotuning, monitor cellular roaming, and use keepalive wisely. This smooths load spikes and helps preserve battery life.

5G, Wi-Fi 6/7, and Crypto: Keeping Up with Fast Radios

Networks are getting faster. Radio capacity grows, making the cipher the new bottleneck. With steady 5G, you’ll hit cipher limits. AES-GCM on x86 with AES-NI can sustain gigabit speeds effortlessly; ChaCha20 in WireGuard on powerful phones handles hundreds of Mbps—plenty for streaming. Wi-Fi 6/7 brings lower latency and higher packet rates—making parallelism (AES-GCM’s strength) and kernel lock avoidance (WireGuard’s strength) crucial. Final advice: don’t just focus on the cipher—consider the whole pairing of protocol + hardware + drivers + network.

Hardware Acceleration and Low-Level Details

AES-NI, ARMv8 Crypto Extensions, NEON: When AES Goes Turbo

On x86, AES-NI is magic: each AES step is a dedicated instruction, delivering stellar speed and minimal side channels. ARMv8 offers Crypto Extensions—hardware AES and SHA acceleration used in Android, iOS, and server chips. This gives AES-GCM a massive boost, making it the default speed king. NEON helps both AES and ChaCha, but AES benefits more when Crypto Extensions are available. Our takeaway: if your CPU supports AES instructions and software uses them, AES-256-GCM usually leads. Verifying is easy: just run openssl speed or iperf3 via VPN and watch the difference.

ChaCha20 and SIMD: Speed Without Hardware AES

ChaCha20 lacks dedicated hardware instructions like AES-NI but vectorizes well on NEON, AVX2, and AVX-512. Implementations in BoringSSL, OpenSSL, and libsodium from 2024–2026 have squeezed maximum SIMD gains: on mid-level ARM, ChaCha20 can easily outpace AES-GCM; same on x86 without AES-NI. A bonus: it keeps CPU load steady without spikes, great for virtualization and containers. Also, ChaCha20-Poly1305 is much simpler to keep constant-time, reducing audit headaches, making it popular for applications needing predictability.

Network Cards, Offload, IPsec, and TLS Engines

In enterprise setups, offload and kernel support make a difference. Some NICs offload AES-GCM for IPsec and TLS, pushing speeds to 10–100 Gbps. ChaCha20 offload is rare, so AES is the obvious choice on ultra-fast links. The Linux XFRM stack for IPsec is mature, and OpenSSL 3.x handles crypto engines well. AES wins here not because ChaCha is weak, but because hardware is built for AES. If building office-to-DC tunnels at 10 Gbps+, AES-GCM is almost guaranteed.

Practical Tests and 2026 Cases: From PCs to Routers

Desktop PC and Laptop with AES-NI: Numbers Speak

Scenario: Ryzen 5 with AES-NI, Linux 6.x, OpenVPN and WireGuard. OpenVPN with AES-256-GCM hits 1.2–1.6 Gbps per core, higher total with multithreading; ChaCha20-Poly1305 clocks 0.9–1.4 Gbps. IKEv2/IPsec with AES-GCM and kernel modules reaches 3–5 Gbps. WireGuard (ChaCha20) achieves 1.5–3 Gbps, sometimes more on latest kernels and tuned MTU. AES uses less CPU and runs quieter. Bottom line: on desktops with AES-NI, opt for AES-GCM with OpenVPN/IPsec; like WireGuard? Stick with ChaCha20 for great speed and simplified config. WireGuard’s ease often outweighs a few hundred Mbps difference.

Mid-Level Smartphone: Real Life, Not Benchmarks

Scenario: Android phone from 2023–2025 without robust Crypto Extensions. WireGuard (ChaCha20) consistently hits 300–600 Mbps, with moderate heat and predictable battery drain. OpenVPN with AES-256-GCM manages 150–350 Mbps, sometimes catching up if hardware AES is enabled. On 2025–2026 flagships with ARMv8 Crypto Extensions, OpenVPN AES-GCM can match or trail WireGuard by 10–20%, depending on radio and frequencies. Streaming and cloud gaming value not just peak speed but stability during roaming. Here, WireGuard with ChaCha20 often shines: faster tunnel setup, smoother IP changes, fewer hiccups.

Router with OpenWrt: Accelerators Decide the Fate

Scenario: home router on ARM SoC without hardware AES. OpenVPN AES-GCM hits 60–120 Mbps, sometimes 150. ChaCha20-Poly1305 reaches 120–250 Mbps with good builds and flow offload enabled. If the chip has AES hardware and driver support, speeds ramp up: AES-GCM hits 300–600 Mbps; ChaCha20 delivers 200–400. IKEv2/IPsec can exceed those further thanks to kernel. Simple advice: check your SoC’s capabilities (model name plus "crypto engine") and if your OpenWrt driver version supports it. Implementation matters more than branded logos. A good driver crowns AES king; absent one, ChaCha20 claims the throne.

VPN Protocols: WireGuard, OpenVPN, IKEv2/IPsec, and Choosing Wisely

WireGuard: ChaCha20 by Default and Ready Speed

WireGuard embodies minimalism: kernel-level static crypto and ChaCha20-Poly1305 as the sole cipher. No choosing between AES and ChaCha—you get a pre-tuned stack focused on simplicity and security. By 2026, WireGuard is mature, with familiar key managers and widespread adoption as VPN providers’ default. Key points: set MTU properly, enable roaming, and keep device clocks synced. If you have mobile clients and value simplicity, WireGuard is almost always a top pick. It excels with ChaCha20 exactly where it matters: on unstable mobile networks and low-power CPUs.

OpenVPN: Flexible but More CPU Expensive

OpenVPN supports AES-GCM, ChaCha20-Poly1305, and many other ciphers—a strength and a curse. You can tailor configs to hardware and compliance needs, but it’s easy to mess up and pick suboptimal sets. In 2026, the recommended defaults are: AES-256-GCM with AES-NI on x86; ChaCha20-Poly1305 on ARM without AES; solid crypto libraries, multithreading, sensible windows. Use UDP over TCP when possible—QUIC and UDP offer lower latency. Historically, OpenVPN consumes more CPU than WireGuard, so for max mobile speeds, OpenVPN typically loses, though on beefy servers with AES-NI it can shine.

IKEv2/IPsec: The Corporate Sweet Spot

IKEv2/IPsec’s strengths: maturity, hardware offload support, compatibility with routers, firewalls, and cloud VPCs. AES-GCM is native here, often best for 1–10 Gbps links. ChaCha20-Poly1305 is possible but hardware support is rare, so practical reasons to pick it are fewer. For office L2L tunnels and datacenter or regional channels, AES-GCM in IKEv2/IPsec offers the fewest surprises. For mobile clients, IKEv2 with EAP is popular but struggles with roaming compared to WireGuard. Thus, a typical mix: IKEv2 for backbones and branches, WireGuard for employees and devices.

Clear Recommendations: How to Pick the Best Cipher for You

If You Have a Desktop or Server with AES-NI

Go with AES-256-GCM in OpenVPN or IKEv2/IPsec—it’s the fastest, most energy-efficient path, especially at gigabit speeds. Using WireGuard? No worries: ChaCha20 offers fantastic speed and simple management; the AES-NI advantage is often negligible in real use. For compliance, AES is nearly irreplaceable.

If You Use Smartphones and Tablets

On 2025–2026 flagships with ARMv8 Crypto Extensions, AES-GCM and ChaCha20-Poly1305 often tie. On mid-range and older devices, ChaCha20 is usually faster and more efficient. The sweet spot is WireGuard with ChaCha20 for mobile—it handles roaming, unstable radios, and sleep modes well. If OpenVPN is needed, try both ciphers and pick whichever uses less CPU in iperf3 tests.

If It’s a Router or Single-Board Computer

Look at hardware. If AES acceleration and driver support exist, pick AES-GCM. If not, choose ChaCha20-Poly1305. For L2L and DC links, prefer IKEv2/IPsec with AES-GCM and NIC offload if possible. For home devices with limited CPU, WireGuard with ChaCha20 often delivers better latency and steady speeds.

Common Mistakes and Myths: Avoid the Pitfalls

Top Configuration Errors

The biggest mistake: ignoring MTU and MSS—fragmentation kills speed and causes phantom issues. Second: sticking with outdated cipher suites like AES-CBC if not needed. Third: overlooking CPU hardware capabilities—you’ll be surprised how much AES-NI speeds real traffic. Fourth: neglecting nonce uniqueness and quality RNG. Fifth: testing on idle networks and wondering why speeds drop under load. Our advice: test multiple scenarios with iperf3 and bpftrace, monitor CPU profiles, and always update firmware and kernels—drivers evolve rapidly.

Myths to Leave Behind

"AES-256 is always slower than AES-128"—not true; with AES-NI differences are minimal or masked by background tasks. "ChaCha20 is insecure because it’s new"—it’s well audited and battle-tested by now. "WireGuard is less secure because it has fewer options"—actually, fewer options mean fewer configuration errors. "ChaCha20 is always better on mobile"—often yes, but on ARMv8 with good AES, AES-GCM can tie or lead. "You must chase 2 Gbps"—no, stable 300–600 Mbps on mobile is often more valuable than a short-lived gigabit that throttles in 20 minutes.

Optimizations and Implementation Checklist

Quick Pre-Launch Checklist

  • Define priorities: speed, battery life, compliance, ease of management.
  • Check CPU flags: AES-NI on x86, Crypto Extensions on ARMv8.
  • Try WireGuard with ChaCha20 for mobile clients; IKEv2/IPsec with AES-GCM for backbone.
  • Tune MTU/MSS, enable roaming where needed, and monitor NAT timers.
  • Test with iperf3 over different window sizes; compare CPU and heat.
  • Update kernels, OpenSSL/BoringSSL, OpenVPN/strongSwan, and WireGuard tools.
This checklist seems simple but covers 80% of common issues. Honestly, one CPU flag can change your cipher choice.

Practical Tips for Maximum Speed

  • On x86 with AES-NI, use AES-256-GCM and kernel acceleration if possible.
  • On ARM without AES acceleration, enable ChaCha20-Poly1305 and disable unnecessary router services.
  • For OpenVPN, switch to UDP, enable multithreading, and use modern crypto libraries.
  • For WireGuard, set correct MTU, PersistentKeepalive for NAT, and log only metadata, not secrets.
  • In clouds, check virtual CPU flags and hypervisor AES policies.
These steps seem boring but yield real percentage gains, sometimes even doubling speeds.

Short Verdicts for Typical Scenarios

  • PC/server with AES-NI: AES-256-GCM usually best.
  • Mid-level smartphone: ChaCha20-Poly1305 in WireGuard.
  • 2026 flagship: tie; choose based on protocol convenience.
  • Router without AES acceleration: ChaCha20.
  • Router with AES acceleration: AES-GCM.
  • Corporate backbone >1 Gbps: IKEv2/IPsec + AES-GCM, offload if possible.
Simple and direct. But always verify on your hardware—surprises happen.

Future and 2026 Trends: The Industry Direction

Unification Around AEAD and Config Minimalism

We see a trend toward tighter defaults: AES-GCM and ChaCha20-Poly1305 as basics, everything else optional or case-specific. WireGuard solidified the "less options, fewer mistakes" culture. OpenVPN and IPsec configs are shrinking, and old schemes are phasing out. In 2026, the top trend is secure defaults—no wizardry.

Growth of Hardware AES and Attempts to Speed Up ChaCha

Manufacturers continue adding AES and SHA blocks to SoCs, especially mobiles. ChaCha20 remains favored where AES is absent or unavailable. Vector acceleration experiments for ChaCha using AVX-512 and enhanced NEON are underway, showing gains. But a dedicated "ChaCha-NI" hardware instruction isn’t expected soon. So, for multi-gigabit links, AES keeps the hardware edge.

Containers, Clouds, and QUIC

Apps increasingly run behind reverse proxies and QUIC tunnels. TLS 1.3 stacks can choose between AES-GCM and ChaCha20-Poly1305 dynamically, balancing CPU load. In containers, ChaCha20’s predictability sometimes beats theoretical AES gigabit speeds if hypervisors limit instructions. The trend is clear: auto-select cipher based on hardware, less manual tuning, more telemetry.

Summary: A Short Answer to a Big Question

The Main Takeaway in One Paragraph

On x86 with AES-NI, pick AES-256-GCM for max speeds and compliance; on mobile and weaker ARM, ChaCha20-Poly1305 often offers stability, lower heat, and longer battery; WireGuard fixes the choice to ChaCha20 by design; for IKEv2/IPsec and high speeds, AES-GCM objectively leads, especially with offload. And always test on your own hardware—this isn’t a cliché, it saves time and stress.

What to Deploy Right Now

  • Home PC/laptop: OpenVPN/IKEv2 with AES-256-GCM or WireGuard (ChaCha20) for simplicity.
  • Smartphone: WireGuard (ChaCha20); if OpenVPN needed, compare AES-GCM and ChaCha20 in practice.
  • Router: AES-GCM if acceleration exists; otherwise, ChaCha20; for L2L, IKEv2/IPsec.
  • Cloud/VPS: if AES is limited, ChaCha20 in WireGuard; else AES-GCM with IKEv2/IPsec.
This isn’t dogma, but a perfect starting point.

What Never to Do

  • Don’t enable outdated schemes for "compatibility" without a clear need.
  • Don’t ignore MTU and MSS—they’re free optimizations.
  • Keep kernels, drivers, and crypto libraries updated.
  • Don’t decide based on hearsay—run a few tests and monitor CPU and battery.
Let’s leave unnecessary myths in the past, where they belong.

FAQ: Quick Answers to Common Questions

Is AES-256 always more secure than AES-128, and is the speed tradeoff worth it?

AES-256 is theoretically stronger and guards against some future attacks, but in practice AES-128-GCM today offers ample security and is often faster. Corporate policies demanding "256 or nothing" focus on compliance and uniformity, not actual "breakability." If you want max speed without a 256-bit mandate, AES-128-GCM is a rational choice. But if you want extra margin and have AES-NI hardware, AES-256-GCM runs smoothly without major slowdowns.

Why is ChaCha20-Poly1305 better for mobile and weak devices?

ChaCha20 is a stream ARX cipher: no lookup tables, minimal branching, well suited for SIMD. This delivers predictable speed on CPUs without hardware AES and lowers risks of side-channel leaks from poor implementations. Practically, this means less heat, steadier speed during long sessions, and battery savings. Plus, WireGuard standardized ChaCha20, so it inherently supports roaming and NAT on mobile. Bottom line: on mid and older phones, ChaCha20 often outperforms AES-GCM; on flagships, it’s a tie.

Can I enable AES-256 in WireGuard instead of ChaCha20?

Short answer: no. Standard WireGuard uses ChaCha20-Poly1305 by design. There are experimental branches and patches, but they’re not production-ready or widely supported. This design choice reduces config errors, speeds audits, and simplifies mobile support. If you need AES compliance, look to IKEv2/IPsec or OpenVPN with AES-GCM and hardware acceleration.

What’s better for a 1–10 Gbps office: WireGuard or IKEv2/IPsec?

For L2L tunnels, inter-office links, and backbones at 1–10 Gbps, IKEv2/IPsec with AES-GCM usually wins, especially with NIC offload and mature Linux XFRM stacks. WireGuard can offer great speeds on strong CPUs, but IPsec offers more integration, QoS, and monitoring options, with vendors having years of experience. For remote workers, WireGuard is often easier: lower latency, smoother roaming, nicer clients.

If I care only about PC speed, what should I use?

On x86 with AES-NI, AES-256-GCM in OpenVPN or IKEv2/IPsec is typically fastest, often reaching gigabit speeds. But don’t discount WireGuard: ChaCha20 delivers close numbers with much simpler config. The best way to decide is to run 2–3 iperf3 tests and evaluate not only peak speeds but stability under load and heat. Often WireGuard’s convenience outweighs a theoretical few hundred Mbps gain.

What about old routers or budget SBCs?

If your device lacks hardware AES or drivers can’t use it, pick ChaCha20-Poly1305. This stream cipher with NEON often doubles speed compared to unaccelerated AES. If your SoC includes an AES crypto engine and OpenWrt supports it, use AES-GCM. Check the exact model—sometimes a firmware update unlocks AES offload, boosting speed dramatically.

Is a "hardware" ChaCha20 like AES-NI coming soon?

Unlikely in the near future. Vendors focus on AES and SHA because they’re industry staples—IPsec, TLS, corporate standards, NIC offload. ChaCha20 optimizations continue in SIMD (AVX2, AVX-512, NEON) with excellent speeds now. But don’t expect "ChaCha-NI" hardware soon. Does this mean ChaCha20 loses? No. On mobile, containers, and low-end hardware, it often dominates; where hardware AES exists, AES-GCM logically leads.